Comcast the Latest ISP To Try DNS Hijacking 352
Posted
by
timothy
from the c'mon-fellas dept.
from the c'mon-fellas dept.
A semi-anonymous reader writes "In the latest blow to DNS neutrality, Comcast is starting to redirect users to an ad-laden holding page when they try to connect to nonexistent domains. I have just received an email from them to that effect, tried it, and lo and behold, indeed there is the ugly DNS hijack page. The good news is that the opt-out is a more sensible registration based on cable modem MAC, rather than the deplorable 'cookie method' we just saw from Bell Canada. All you Comcast customers and friends of Comcast customers who want to get out of this, go here to opt out. Is there anything that can be done to stop (and reverse) this DNS breakage trend that the ISPs seem to be latching onto lately? Maybe the latest net neutrality bill will help." Update: 08/05 20:03 GMT by T : Here's a page from Comcast with (scant) details on the web-jacking program, which says that yesterday marked the national rollout.
I noticed this yesterday (Score:4, Interesting)
I noticed this yesterday, and they only seem to hijack www.example.com, and not example.com or ftp.example.com.
Still a pain in the ass, and I'm in the process of opting-out. The opt-out is pretty easy, and I've also sent an email to comcast regarding this.
Re:Opt-out page down already? (Score:5, Interesting)
Which, if true, makes the opt-out process even more ludicrous. If I'm at home opting out, shouldn't they just DETECT my mac address, and do the opt-out automatically?
Instead, I had to enter my mac address manually (along with my e-mail address) - and then they told me it would take two business days to go through. (Granted, I got a confirmation e-mail the next day saying it was done, but why isn't this automated?)
The flip side of net neutrality (Score:4, Interesting)
No new legislation is needed. Just get the courts involved. Let content providers sue the heck out of Comcast for making a dime off of abusing their domain names. The ISPs think that Google, etc. are "using their pipes to make money," well this is using the content provider's domain and brand to make money. Technical details aside, the effect on the relationship between the content provider and their users is the same whether it is literally hijacking control over the subdomains or creating the perception to user that that is happening. No matter what Comcast may claim, they are altering the relationship between the domain holders and their users.
Re:Serious question (Score:5, Interesting)
To use an example from my company, we have many users with laptops. We have set up MS Outlook on these systems to use Outlook Anywhere. The way Outlook Anywhere works is that is first tries to connect to the internal mail server (mail.company.inside) and if it can't connect to that then tries the external mail sever for an Outlook Anywhere connection (mail.company.com). With a properly set up and unmunged DNS, when they are at home it tries to connect to the internal server and gets a DNS not found response and then tries the external server. With this new bothced DNS setup, it tries the internal server and gets an IP address response, so it tries to connect to that server to retrieve it's email. Unfortunately, the DNS sends the IP address of the web server that serves up it's ad page, so Outlook sits and times out waiting for a response, meaning these people can't get their email from home.
Yes, this could be worked around by host files, but we are 1000 person company. Why would we want to try setting up local host files on these systems that then have to be updated whenever we change servers just because an ISP doesn't want to set up DNS based on the proper specs?
"Accidently" Hacking their Server (Score:5, Interesting)
So if you are trying to pen test some machines you own and Comcast points you to their server who is to blame? Are you really responsible if Comcast hijacks your DNS requests and sends you to their server?
I was testing against a known invalid DNS entry (ie: personally owned but not parked domain name). How are you responsible when they hijack your connection?
Even better is when someone pwns Comcast's server and and exploits all of Comcast's customers with a browser exploit hosted there.
Re:Serious question (Score:5, Interesting)
Using DNS lookups to tarpit certain kinds of spam. If everything resolves, then such methods simply fail.
Besides, interfering with DNS resolution is just plain bad. Quite frankly, I wish we had an organization controlling the root servers that had a backbone, and would simply stop answering queries from any network that decided to interfere with DNS resolution.
Re:Treewalk or OpenDNS (Score:2, Interesting)
Re:Serious question (Score:4, Interesting)
Which seems like a good idea until they come in house. While they are at home and pointing to a RFC-compliant DNS server, it's great, but when they come in-house, they then can't see any of the internal servers because they are still looking at the external DNS server instead of the internal ones given by DHCP. It really is a no win situation.
Re:Treewalk or OpenDNS (Score:5, Interesting)
Because after all, if I don't use their DNS, why should I care where they are directing non-existant domain traffic to?
Using OpenDNS, Treewalk, ns1.sprintlink.net, etc doesn't matter because a) Returning the A record when the domain does not exist blatantly violates the RFCs: the established commonly agreed upon standards without which the internet would cease to function and b) some ISPs redirect your DNS traffic to their servers whether you like it or not. Some outright block DNS servers that don't belong to them, and others silently redirect your requests. c) In the README file of your latest application, you shouldn't have to tell everyone that they need to use your DNS servers just to get a *correct* response.
It isn't just you at home with your pr0n that has to deal with this BS. I have to deal with it where I work, because my company's ISP is a cable provider who does this redirect crap. So when I go to write an app that *might* use DNS, I have to screw with this nonsense because the cableco can't be bothered to return an NX - but instead always returns an A record for their server - subject to change without notification. So when they change to redirect to another server, wtf am I supposed to do then? The only way my app could possibly tell there was a problem is to see if the response matches this redirect server. And no, it isn't an option for my application to just willy nilly pick a DNS server of its choice to use. My application requests a lookup from the OS's network layer, but has no particular knowledge of the DNS servers - exactly how it is supposed to be.
If I give my app to other people, are they supposed to put into the app's configuration the A record information that would correspond to their particular ISP's "redirect" host? My app needs to know when the DNS lookup failed. I have no way to tell when every damn name returns an A record. I count on the DNS server to respond in the way the RFCs set out. Comcast and the other ISPs are saying "fuck your rules"
As has been said until we're blue in the face:The internet is not the web. If the ISPs and the browser folks want to sit down and see what the RFC permits and figure out how to return a url in the NX that the browser would recognize and could handle, then I have no problem with that. As long as it doesn't interfere with the normal operation of an NX response. As I'm sitting here thinking about it, the place for this information seems to be either in the DHCP lease, or in the wpad.dat auto-proxy configuration file. But Comcast and the others like them have decided they don't have to play well with others.
Re:Comcast's version is orders of magitude better. (Score:3, Interesting)
c: It does NOT get *.whatever, only www.*.(TLD), thus even when you don't opt out, it is at least limited to web-related typos. This is actually a big deal, as I think Comcast is the first one NOT to do it for everything.
You can run more than just web sites on a www. domain.
there are two sides to this coin (Score:5, Interesting)
The other side of the coin is the customer experience. Think about the average internet user. They cannot tell the difference between a 404 error and a 504 error.
People often unknowingly mistype URLs and automatically believe that their internet is broken and they need to call their ISP in order to get it working again. My personal experience working tech support for a large ISP is that mistyping domain names is a huge call driver, and this service is meant to address that.
That's the other side, now flame on.
Hold the phone - it's bad, but not that bad (Score:5, Interesting)
Look at the DomainHelperLogic [comcast.net] and the only thing it hijacks are DNS lookups that begin with www and end with a valid TLD (.com, a ccTLD like .us, etc.).
While I think this still stinks that they are hijacking DNS at all, and as a Comcast customer I will complain and opt-out, I think they're doing it in a fairly logical way.
But it's not that bad. If you do a DNS lookup for any domain (say for an MX or NS record) you're never going to see this. Your lookups will only be affected if the query starts with www, followed by a domain, ending with a valid TLD (.com, a CC, etc.).
If your internal office uses something such as mycompany.internal, then even a www.mycompany.internal query isn't going to get hijacked since .internal isn't a valid TLD. If you are using mycompany.com for internal use, you should own mycompany.com externally, and negative replies will still work and not get hijacked.
Again, while I oppose monkeying with DNS, this appears to be fairly well thought out and not anywhere near as bad as most other implementations.
more comments from the 4th contributor to the spec (Score:1, Interesting)
Ralf Weber dns at fl1ger.de
Fri Jun 19 10:21:04 UTC 2009
* Previous message: [dns-operations] will germany therefore make dnssec illegal on their shores?
* Next message: [dns-operations] will germany therefore make dnssec illegal on their shores?
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Moin!
On 19.06.2009, at 11:27, Stefan Schmidt wrote:
> On Fri, Jun 19, 2009 at 03:12:10AM +0000, bmanning at vacation.karoshi.com :-(.
> wrote:
>>> http://yro.slashdot.org/story/09/06/16/1657255/A-Black-Day-For-Internet-Freedom-In-Germany [slashdot.org]
>>> ______________________
>>
>> doubtful that it will be illegal - just ineffective.
>> DE may become a haven for questionable DNS use, esp
>> with this offical sanction to hijack.
There are other countries doing this already. In Europe at least:
- Sweden
- Denmark
- Belgium
- Switzerland
- Italy
so while I signed the petition I still will have to do this
> This is exactly the question i will ask at the "DNSSEC Testbed for
> Germany"
> event 2nd of July in Frankfurt am Main.
> -> http://www.denic.de/en/domains/dnssec/dnssectestbed.html [denic.de]
Well technical I can answer this now, the way DNS is deployed currently
(Clients ask ISP resolver and don't validate) DNSSEC and this
blocking is compatible. But I think it really is a political debate
rather then a technical one. DNS blocking can be a good thing
(Conficker anyone), the problem with this law is that there is no
control of the list, and that there is a IMHO justified fear that
this technique will be used for other blockings (gambling, music).
So long
-Ralf
---
Ralf Weber (Internet Citizen)
e: dns at fl1ger.de
------------------------
that's a pretty strange statement coming from one of the fathers of F***-the-DNS
Does Comcast intercept all DNS requests? (Score:3, Interesting)
My main question would be: Does Comcast intercept and answer all DNS requests on its wires?
My reason for asking is that I've generally found that it's not a very good idea to use the ISP's nameservers. They never work very well, in my experience. When I've been responsible for such things, I've generally looked for a few good nameservers that are (electronically) nearby, and tell my machines to use them. I usually get faster and more accurate DNS resolution that way.
But if the ISP is looking specifically for any DNS requests, ignoring their destination address, and forging an answer that points to their own machine, then the above strategy won't work.
Yes, forging replies to packets not addressed to you is a nasty thing to do. Comcast has been caught red-handed doing this, e.g. to tell both ends of a P2P connection that the other has closed the connection. So it seems likely that they may be doing the same thing here. But I can't quite tell from what I've read.