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."
That's fine, but whether or not it's helpful for the typical Web surfer is completely irrelevant.
It's a clear example of a layering violation. If you want URL fixing, great, but do it in the browser, don't hijack DNS which other services depend on.
As far as I am concerned, it is really is clear cut that this shouldn't be happening!
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.)
But at least when you opt-out it will then make it return NX responses (yes I have Embarq and that was one of the first things I'd do (or end up doing accidentally) when the IP changed)
And it seems to work until you end up changing IP (DSL so I only changed when the link went down.)
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.
does anyone know if they're applying this to other ISP who lease bandwidth from bell? Such as Teksavvy and the like? I'm switching from bell anyhow, but I'd be pissed if they force that on other ISPs too (along with throttling).
Doubt it. Teksavvy has their own DNS servers.
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.
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.
I use dnsmasq on my router, you could use it locally as well. It has a --bogus-nxdomain=<ipaddr> option that you can use for this purpose.
c++;
OpenDNS only does this if you use their filtering options. If you use just the standard straight up dns service you can opt out.
But compared to Bell you can switch the behaviour permanently off in your User Control Panel of T-Online. No weird cookies are required...
The web is an incredibly huge piece of the internet.
Please tell us about these 65,000 other services that need a properly functioning DNS. Since the only protocol affected here is HTTP, and the only applications that use invalid URLs are either human-driven (browsers) or malware, I suggest that the NX response is fundamentally outdated and useless.
Not true. The DNS doesn't know if the thing making a request is a web browser or something else, so it affects literally every protocol. SMTP, POP3, SMB, everything. Only now, when you try to debug something like that it looks like the server does exist, it's just ignoring SMTP connections. You spend ages barking up completely the wrong tree.
Even more fun is if the person affected is trying to work from home over a VPN link. If it's set up for split tunnelling, it'll try to resolve a hostname using the default DNS first and only if that fails will it try the VPN. Hint: Windows uses DNS to resolve hostnames for fileshares. All of a sudden, internalhost.yourcompany.com resolves on the public internet and they're trying to save their files to a server that's run by their ISP (and, naturally, isn't offering any SMB fileshares). Cue a bunch of angry calls to the helpdesk.
No, every protocol directed at an address obtained by DNS is affected.
Go green: turn off your refrigerator.
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
Bresnan Communications pulls this same crap. The only way to opt-out is accept thier cookie.
I have written scripts for my job, which would break dns was hijacked by my isp. It's not acceptable.
;-)
I added a stub section to an article on wikipedia about this a while ago, it would be great if someone would lengthen it
http://en.wikipedia.org/wiki/DNS_hijacking#Use_by_ISPs
I fear the Y2038 bug
The web is an incredibly huge piece of the internet.
Please tell us about these 65,000 other services that need a properly functioning DNS. Since the only protocol affected here is HTTP, and the only applications that use invalid URLs are either human-driven (browsers) or malware, I suggest that the NX response is fundamentally outdated and useless.
Wow, you are one clueless user. Please don't put fingers to keyboard and start talking authoritatively when you clearly know absolutely nothing about the subject or the problem at hand. Think before you type, next time.
Maybe you've heard of a little thing called "email?" It pretty much takes a huge chunk bandwidth on the net (mostly spam, granted), and then we have P2P stuff, which takes up the bulk of bandwidth I believe - far, far exceeding the HTTP protocol. These are just two of the services that are affected by it, and both exceed web traffic by significant margins. The web bandwidth is indeed a tiny fraction compared to everything else... just because web surfing dominates your life does not make it the dominate service on the internet.
The NX response is everything. It's the foundation of the entire domain resolution system. Saying it's outdated is absolutely and patently ludicrous. There are two proper responses that drive the entire internet, the return of a valid IP address and an NX response. When you start screwing with either one of those, you break the internet. Outdated indeed.
HanseNet / Alice also does this and as T-Online the opt-out process is done via a user control panel and is permanent, until you opt-in again. No cookies are set. While it shouldn't be necessary to do this in the first place it is MUCH better than a cookie based system as used by Bell.
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.
Here are some. I don't know which ones hijack NX responses, but the 4.2.2.x entries seem reliable.
-mkb
Another day I helped a user troubleshoot the same kind of problem (in their case it was OpenDNS, which has the same kind of misbehavior). Windows was not finding the other machines in the network, because it was configured to look first on DNS (the order is configurable) and then broadcast. Since OpenDNS was falsely returning a found result for names which did not exist, Windows never tried the broadcast which would have found them in the local network. Installing BIND on a spare machine on their network solved that problem instantly.
How did this ever get +5 ? Seriously, if you register a non-existant domain, they won't hi-jack you. First, there's this thing called TTL on requests, when a DNS server caches a response from an authoritative source, it is not permanent. It has a Time to Live, defined in the Start of Authority in the zone on the master server or on the entry itself. So after a while, the DNS server will query the authoritative source again to make sure its answer is still correct and up to date. This is also implemented for NXDOMAIN queries, as defined in RFC2308. Section 3 is specific that NXDOMAIN queries should also return the SOA and that the receiving cache is to use the minimum TTL (the last value in the SOA). The default on this is 3600 seconds, or you guessed it, 1 hour. Since your domain will take 24-48 hours to show up on the ccTLDs or gTLDs anyhow, 1 hour isn't going to make or break anything as far as caching a NXDOMAIN answer and anyway, you wouldn't have gotten that traffic to begin with.
"Not to mention all the idiots who use words like boxen."
Anonymous Coward on Monday August 04, @06:49PM
At least OpenDNS is clueful enough to filter out BS like the following:
http://www.domainnotfound.ca/bellassist/dnsassist/content/ErrorPage/_iceUrlFlag=15?_IceUrl=true&q=www.non-existent-domain.com-INSERT-MALWARE-HERE%3CSCRIPT%3E
There are 1.1... kinds of people.
These pages are helpful for the typical web surfer.
Do you work in marketing?
Clue: DNS stands for "Domain Name Service", not "Targeted Advertisement Injection". The "typical web surfer" already has a tool that is responsible for handling unresolvable addresses, it's built into the browser. If you want more help, suggestions for typo fixing, etc. then the browser is the proper location.
There are client programs out there that rely on getting proper DNS responses, including correct "domain not found" replies when the domain does not exist.
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.
No, it doesn't. And running contrary to published standards isn't a minor offense. They're called standards for a reason, and client-side programs expect a certain behaviour. Breaking that means breaking customers' software. And no, the web should not work this way. If you want to get a search page on DNS error, a Firefox plugin would be the proper approach, not DNS manipulation.
What this is is the equivalent of your phone company hijacking every call with a mistyped phone number to a toll line with a "helpful" operator that helps you guess the correct number. The only difference is the payment method.
Assorted stuff I do sometimes: Lemuria.org
. 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
Not happy with Rogers at all. But don't have any alternatives where I live.
If you're on Rogers, use 64.71.255.202 as a DNS server. It's the non-hijacking server they set up after many users complained the re-directing was buggering up remote workers and VPN users.
It won't be pushed out through DHCP, but it works fine as a static setting.
They're not intercepting your communications with any outside server. You asked them for the IP address linked to a given domain name, they asked a higher-level DNS server that returned NXDOMAIN to them, and instead of just returning the same NXDOMAIN to you like everyone else would they returned a pointer to the server hosting their search page. Underhanded? Sure. But intercepting and modifying your communications? Not really. Your communications were with the ISP to being with, not the upstream DNS servers, and nothing really obligates the ISP to return the standard response.
You could configure your system to query one of those upstream DNS servers directly. If they messed with that, then they would be interfering in your communications.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat