Slashdot Mirror
Comcast Intercepts and Redirects Port 53 Traffic
An anonymous reader writes "An interesting (and profane) writeup of one frustrated user's discovery that Comcast is actually intercepting DNS requests bound for non-Comcast DNS servers and redirecting them to their own servers. I had obviously heard of the DNS hijacking for nonexistent domains, but I had no idea they'd actually prevent people from directly contacting their own DNS servers." If true, this is a pretty serious escalation in the Net Neutrality wars. Someone using Comcast, please replicate the simple experiment spelled out in the article and confirm or deny the truth of it. Also, it would be useful if someone using Comcast ran the ICSI Netalyzr and posted the resulting permalink in the comments.
I suppose users could tunnel DNS over some other port if they had to.
I route all of my DNS requests through a VPN to the DNS server at my office. Not everybody has this luxury though. I wonder if OpenDNS would be inclined to set up a VPN solution for people stuck with an ISP as arrogant as Comcast?
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
I'm a Comcast user, and I run a DNS server for a few private domains that only I use
Are you running that and hoping that your dynamic IP address doesn't change or do you have a business account with a fixed IP? If it's a business account than I would assume that they aren't redirecting those but could still be redirecting on consumer accounts.
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
I'm wondering how this post ever made it to the slashdot front page. I haven't RTFM, but as it's from the domain comcastfuckingwithyourport53traffic.wordpress.com I don't see any reason to lend it credence.
The comments to this story say a lot, almost as much as the domain the story links to. Somebody screwed up posting this.
Free Martian Whores!
Are you certain? If they are redirecting the traffic in their network so that one of their DNS servers responds to the query as if it was your DNS server (i.e. forging the response packets so that they appear to come from your server) then the only way to tell would be to place a deliberately wrong IP entry for a well known address on your server (i.e. something that Comcast wouldn't know about) and then run the query again to see if you get the wrong result (no redirection or impersonation) OR if you get the expected result (redirection or impersonation). Also, they might only be forwarding queries that they don't recognize to your server so that any custom or unusual queries hit your server but stuff like google.com is answered by their server(s).
We have not seen any redirection issues with Comcast user's DNS settings.
Questions on netalyzr itself will be answered in this thread.
Test your net with Netalyzr
Funny,
Here are the results from a static IP:
--Knoxville.hfc.comcastbusiness.net --
--UDP access to remote DNS servers (port 53) appears to pass through a firewall or proxy.
The applet was unable to transmit an arbitrary request on this UDP port, but was able to transmit a legitimate DNS request, suggesting that a proxy or firewall intercepted and blocked the deliberately invalid request.
The applet was unable to directly request a large DNS response. This suggests that a proxy or firewall is unable to handle large extended DNS requests or fragmented UDP traffic.--
There might be some other issues here:
http://www.auditmypc.com/port/udp-port-53.asp
I don't see anyone else mentioning this, but it seems they could be using a particular area to test this "policy"
I had a sucky sig.
Have you heard of IP over DNS? The DNStunnel software sends IP packets as TXT records over a real DNS, the client sends data in the request itself. Since these are real resolvable DNS records, proxying port 53 won't work. When I tried this software, I could only get a single stream over the tunnel, so I ran SSH over the DNStunnel and used ssh to forward a TCP port that I then ran OpenVPN on. This actually works, but it is very slow. And I can imagine that people would eventually find out because the wifi provider's DNS cache will fill up with IP data.
Except that he actually received and sent the packets on the server and verified as such.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs