Slashdot Mirror
Bell Starts Hijacking NX Domain Queries
inject_hotmail.com writes "Bell Canada started hijacking non-existent domains (in the same manner as Rogers), redirecting NX-response queries to themselves, of course. Before opting-out, you get their wonderfully self-promoting and self-serving search page. When you 'opt-out,' your browser receives a cookie (isn't that nice) that tells them that you don't want the search page. It will still use their broken DNS server's non-NX response, but it will show a 'Domain Not Found' mock-up page that they (I surmise) tailor to your browser-agent string. During the opt-out process, they claim to be interested in feedback, but provide no method on that page (or any other page within the 'domainnotfound.ca' site) to contact them with complaints. They note that opting-in is 'recommended' (!), and that 'In order for opt-out to work properly, you need to accept a "cookie" indicating that you have opted out of this service. If you use a program that removes cookies, you will have to repeat this opt-out process when the cookie is deleted. The cookie placed on your computer will contain the site name: "www.domainnotfound.ca."' Unfortunately most Bell Internet users won't understand the difference between their true NX domain response, and Bell's injected NX response."
Well, that's the bad old ma Bell that's still alive and kicking in Canada.
These pages are helpful for the typical web surfer. In fact, an automatic URL "fixing" service would be one of those revolutionary Web 2.0 features that exists in the recesses of the web, part of the infrastructure and totally natural to use.
Yes, it breaks some scripts and runs contrary to published standards, but it presents a new (actually pretty old) conception of how the web should work.
You wouldn't believe the amount of angry customer calls I had escalated to me by people who think that computers, modems and internet service are all the same things and I was responsible for all of them. If you want me to share them with you, bring lots of hard liquor - you're going to need it.
The Deutsche Telekom / T-Online does exactly the same in Germany.
Love over Gold.
Taco stands for Targetted Advertising Cookie Opt-Out. It is a firefox addon that keeps a generic, non-user specific cookie opting out of the things that need cookies to opt out of.
excitingthingstodo.blogspot.com
If this is a true description of the opt-out, it is SERIOUSLY broken.
Simply put, any opt-out mechanism MUST enable the user's computer to properly receive an NXDOMAIN response. Because the problem is NOT the advertising web page on a web browser typo for http, but all the other things that do DNS lookups.
For example, NXDOMAIN wildcarding even snagged and confused Dark Tangent into thinking that someone was trying to MitM the Defcon forums!
I can accept an ISP doing this only under the following conditions:
a) The opt-out is a one-click item on the page
b) The opt-out is perminent and for all connected through that IP/customer link
c) The opt-out is a real opt-out which will cause NXDOMAIN responses to be properly returned as NXDOMAIN.
This clearly fails B and C.
Test your net with Netalyzr
Is there any way a local caching name server can detect this brokenness and return the right answer? I seem to remember some bind configs a few years back that would do that but I'm not sure if they would still work.
Or maybe a firefox plugin could detect this damage and restore the original, correct behavior somehow.
Isn't this sort of forgery exactly what DNSSEC is supposed to prevent?
(And no, don't go suggesting DNSCurve. It doesn't protect against your ISPs caching resolver being malicious like this.)
I'm not sure if this is a troll or not, but just in case it isn't: openDNS does the same sort of hijacking.
Bell's current business model pretty much relies on people not caring about the shit they pull.
It's sort of interesting (or infuriating depending if I'm trying to use the internet..). My new ISP makes it no secret they hate everything Bell does. I think that largely has to do with them leasing their lines from Bell, and having their service screwed up when Bell does things of this nature. I imagine I'll be getting an email from my ISP soon telling me who to complain to about the service getting buggered yet again. Thanks Bell, I'll be by your office in the morning with a fresh cinderblock. I see you replaced your front window from the last time I put one through it.
And that was the last Terry Fox run I ever participated in.
If you're using TekSavvy, then you're using TS's DNS servers, so your query goes to TS's DNS server which should respond with NXDOMAIN. You aren't even contacting the Bell DNS, so there's no opportunity for them to interfere.
It's possible, since Bell controls the last mile, that they could intercept NXDOMAIN results going to your machine and replace them using DPI, but I can't see how they'd get away with that without being in violation of CRTC rules about changing the meaning of communication. And, at least for me on Primus, this doesn't seem to be the case (yet).
Then you've never used Cisco's VPN client.
Hint: Connecting to internal-machine.yourcompany.com over the VPN doesn't work when internal-machine.yourcompany.com can be resolved from outside the company.
How is this cookie supposed to work for lookups from apps other than a web browser?
I am becoming gerund, destroyer of verbs.
I have Charter, and they do the same thing . I just use 4.2.2.1 and 4.2.2.2 as my primary DNS servers. Although, I can't really speak to their IPv6 capability.
Buckle your ROFL belt, we're in for some LOLs.
if the problem is what it is to solve -- unlikely.
Unlikely indeed. A simple search on that site for "Test" turns up many results. Several of them have notes like this next to them: "Sponsored by: www.momshomeroom.com/msn ", and "Sponsored by: www.Tests.com "
Looks like helping the customer is a secondary concern after all.
I'm not a fan of OpenDNS because they also do NXDOMAIN wildcarding.
However, they do have a working opt-out in the OpenDNS dashboard, however you need to use their notification mechanism so they can track where you are to maintain the opt-out.
Test your net with Netalyzr
So, what happens if I buy ping a domain that doesn't exist? Presumably this will then cache the DNS NXDOMAIN reply. If I then buy the domain, set up a DNS entry, and then try to connect to it, I will get their sever instead of mine. This sounds like it would fall foul of computer misuse laws; intentionally hijacking a connection. The presence of ads means that they're doing it for commercial purposes, which usually carries a heavier sentence. Other ISPs will not be breaking these laws, because they will just be inadvertently blocking my connection, rather than hijacking it.
I am TheRaven on Soylent News
For those of you who want to let Bell hear a bit of your mind, the comments form is here:
https://www.bell.ca/support/PrsCSrvInt_CtUs_Eform.page
The first hit for me is the wonderful errornerd.com, which can fix these errors if you download their registry utility.
They can even fix a host of other errors, even 404s and errornerd.com is a fraud errors.
Are you a grammar Nazi? I'm trying to improve my English; please correct my errors!
This...
When you "opt-out", your browser receives a cookie (isn't that nice) that tells them that you don't want the search page. It will still use their broken DNS server's non-NX response, but it will show a 'Domain Not Found' mock-up page that they (I surmise) tailor to your browser-agent string. ...is just ****ing unacceptable. That's not ****ing opting out.
That is unlikely. I think it would require deep packet inspection to work. You do not really need your provider's DNS (although it is useful when it works properly). You should be able to run a minimal DNS server locally and set it to bypass your ISP and go to higher level servers.
This seems to only affect lookups for queries prefixed with www. For example, a lookup of blerght.com returns nx, while www.blerght.com returns 67.63.55.2. There may well be other subdomain queries that it also hijacks.
DNS is recursive, right? Starting with the TLD servers, then downwards. Someone upstream of Bell is returning a 'domain not found' and Bell is intercepting that and modifying it.
I understand that you're using Bell's local DNS servers to start the search, but the effect is the same as them intercepting and modifying your communications.
ISPs doing this kind of crap should get sued under whatever law most closely applies.
DNS doctoring is bad for many reason.
Just because a domain exists doesn't mean it's the one you wanted. Think of all those properly registered phishing sites out there, just waiting for a user typo. What's the difference between them and a DNS search redirect? If anything, this highlights the broken behavior of using the (non-)existence of a domain name for anything useful. You really care about whether you got the RIGHT site, not just *a* site.
Oh, I see... so then Bell can decide for me whether I'm about to see the "right" site? Yeah, that WOULD be helpful. Thankfully it will be easy to agree on what's the "right" and "wrong" sites. No problem there.
[/sarcasm]
I only post comments when someone on the internet is wrong.
The opt-out is a true opt-out. You enter a list of IP addresses to opt-out on your account screen, and from there it gives you real NXDOMAIN responses (and it even works with filtering).
They're reselling InfoSpace. Click on this link to demonstrate.
InfoSpace claims to be passing search queries to Google, Yahoo, Bing, Ask, and Twitter, then combining the results. I'm surprised they can do that. Google, Yahoo, and Bing all prohibit that in their terms of service. (With Google, you're only allowed to use Google's display format, expressed in their AJAX API, but you can add additional info. Google doesn't allow reordering or combining their results. Yahoo is more flexible; you can reorder, reformat, and, subject to some restrictions, add ads. Bing allows reordering and combining for Web searches, but not other types of searches.)
Their DNS does indeed return the proper NXDOMAIN responses if you a) sign up for an account, b) register your IP with them, and c) disable all the "advanced" features they offer. Set it to be basic no-frills DNS and that's indeed what you get with them.
So yes, their opt-out for that sort of thing, while a bit of a pain, does work properly. But considering that their entire service is opt-in to begin with, there's not a lot to complain about on that score.
For people with dynamic IPs, they offer software to run that pings them every so often to update your IP and make you stay opted out. Actually, they use that because you can create "templates" of settings to apply to different networks you use and such.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
I've made the point before, but it's worth pointing out again that this is just typosquatting on a massive scale.
.COM domain names that are one character misspellings of any Alexa top 100,000 site you enter. It also displays screenshots of those typosquatting sites. It's a nifty way to get a quick idea of the rampant growth of typosquatting. Here's an example that shows the 425 registered .COM domain names that are one character away from google.com.
Many people don't realize that there's TONS of traffic going to typo domains (whether registered or not). For instance, youtuve.com (notice the v instead of the b) got 347,852 visitors over the last 31 days. It redirects to another domain for cloaking purposes, but here is the traffic report. This level of traffic provides the financial incentive to implement these DNS schemes.
By the way, there's a new, free typosquatting scan tool at aliasencore.com. It shows you all the registered
Full disclosure: I am Graham MacRobie, the CEO of Alias Encore, Inc. We help companies recover cybersquatting domain names, but we focus solely on "slam-dunk" typosquatting cases (obviously only registered domain names). I can speak from personal experience in this field that the very last thing we need is wholesale typosquatting at the DNS level. Bell Canada should turn this "feature" off immediately.
. So whether or not the DNS server returns the proper error message or resolves to a site is *meaningless* for any piece of software to rely on.
Just like a server that inherently trusts the client is broken, so is any software that makes assumptions about a remote site just because it exists.
Knowing whether a site exists can still provide useful information for a wide variety of uses. Nobody is using the existence of a server as a form of authentication, okay? We have other mechanisms for verifying the identity of a site, when such identification is important. As the simplest example of how this screws things up, having a valid NX response versus a made up lie of a response will make the difference between an app failing immediately because the NX response says the server doesn't exist, versus waiting and eventually timing out trying to connect to a server that doesn't exist, but the app doesn't know it's because the server is slow, or the service is down, or the packet filter rules are eating your packets.
Just because you don't know or understand how this breaks things doesn't mean it isn't broken.
The behavior of identifying typosquatters and directing the user to the site they intended is properly implemented in the web browser. Not by fucking up one of the fundamental protocols of the internet. The web isn't the internet. And this behavior is broken even for the web.
The enemies of Democracy are
This change breaks the URL completion feature in Safari where if you type "cnn", Safari automatically displays "cnn.com". If you type a URL that is in your browser history, then of course Safari will auto complete it before submitting the http request, but if it's a domain you haven't visited before, you now get the useless Bell page instead of the page you really wanted. Does Bell just use Internet Explorer? If they were Mac users, they wouldn't have done this.
There's no forgery. You are connecting to their server just as you intended to and it is giving exactly the response they configured it go give. However, that response is not the one specified by the RFC.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.