Bell Starts Hijacking NX Domain Queries 310
Posted
by
timothy
from the opendns-dot-org-is-a-nice-resource dept.
from the opendns-dot-org-is-a-nice-resource dept.
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."
Thank god I don't work there anymore (Score:5, Insightful)
If true, a SERIOUSLY broken opt-out... (Score:5, Insightful)
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 [defcon.org] 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.
Re:From a typical web surfer's point of view (Score:5, Insightful)
Re:From a typical web surfer's point of view (Score:5, Insightful)
These pages are helpful for the typical web surfer
How is that? By encouraging them to use a search engine with which they are unfamiliar, or by leading them away from their intended target with advertising. Look at the Sample Page [domainnotfound.ca] again, and explain to me the utility in that crap. Domain errors should ideally result in a big red "X" so the user knows to turn around and try again.
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.
Now this is an interesting idea. Let me tell you the best way to handle this - on the client side, after the proper DNS opportunities have been exhausted. This is because the client best knows the users browsing proclivities (most often viewed pages, favorite search engines, etc).
Re:From a typical web surfer's point of view (Score:5, Insightful)
Re:If true, a SERIOUSLY broken opt-out... (Score:4, Insightful)
I'm not sure how an opt out that uses cookies is supposed to work. My mail client, for example, does a DNS lookup for smtp.domainwithtypoinname.com. The resolver on my machine sends a UDP packet containing the DNS request to the DNS cache. The DNS cache replies with NXDOMAIN. The function called by my mail client returns failure. How does the DNS cache get hold of the cookie to know that it should return the real NXDOMAIN?
Hopefully the root servers will start using DNSSec soon, so the resolver can just flag these and the libc functions can return the same kind of failure as they would for an NXDOMAIN reply.
Re:Does the Taco add on work here? (Score:3, Insightful)
It does not work for every non-browser application that uses DNS.
Re:From a typical web surfer's point of view (Score:3, Insightful)
How is the only protocol affected HTTP? When a DNS query is made, it doesn't state what it's for -- regardless of the protocol to come, the DNS query is the same. Yet when an NX should be returned, a valid but incorrect response is returned. This is quite a significant difference.
Re:If true, a SERIOUSLY broken opt-out... (Score:4, Insightful)
The doofuses behind this are unaware of the existence of any software other than a browser that uses DNS. They would tell you that DNS is part of the Web.
This ought to be illegal (Score:3, Insightful)
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.
Re:And yet I don't see it (Score:3, Insightful)
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]
This broke Safari's domain completion feature (Score:2, Insightful)