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.

Comments

Not happening to me

[jimmyhat3939]

I'm a Comcast user, and I run a DNS server for a few private domains that only I use. I have not experienced this, and I just verified that it's not currently happening. I'm in California if that matters.

Re:Not happening to me

[whoever57]

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'm certain. I sent a query to a DNS server that I control. I ran tcpdump on the DNS server and I could see the packets from my home IP address coming in with the query and the refusal going out (I asked the DNS server that I control to resolve yahoo.com, which it should refuse to do).

Re:Not happening to me

[EvilBudMan]

They are blocking port 53 it appears here in Virginia.

--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.--

I don't know about them hijacking it though. I'm not sure what causing it yet.

Look this way for more info:
|
|
|
  \
      \
      V

Re:Not happening to me

[whoever57]

Just to be clear about the parameters of this test... I assume the PC from which you sent the request isn't on the same local network as the DNS server?

The machine from which I sent the request is connected to a Comcast residential Cable Internet connection. The server at the other end is a virtual machine in a colo facility somewhere -- not a Comcast facility. And before anyone asks, I tried both tcp and udp requests with the same result (no interception, no transparent proxy).

Re:Not happening to me

[alta]

Comcast is using nearly off the shelf DHCP with really long expires times. When you get an IP, you'll have it for months, and usually don't loose it until those months have passed AND you reboot your equipment and get a new IP.

DSL on the other hand is using PPPoE (PPP over ethernet.) Every time it starts a new session it gets a new IP, completely independant of what it had before. And from my experience with ATT/Bellsouth it's not daily, it's hourly. Unlike a direct link, PPPoE must renegotiate every time there's a momentary signal loss, just like dialup would do.

From what I've read, they use PPPoE because it's the easiest way to enable/disable users in real time via a RADIUS server. Comcast has to use more complicated methods to kill accounts (in some places, even send out a truck to put on a filter)

Re:Using OpenDNS on Comcast

[CompSci101]

Likewise in Southern New Jersey (and Philadelphia before this -- the very heart of Comcast darkness)

I get OpenDNS error pages for nonexistent domains.

Re:DNSSEC?

[ScytheBlade1]

DNSSEC is validated at the resolver level. However, even if you run your own local DNS resolver, DNSSEC wouldn't come into play -- Comcast can simply strip the KEY/RRSIG records entirely before sending them to you -- leaving your resolver thinking that the zone has no DNSSEC records at all (at which point, they are blindly accepted as valid).

I'd imagine that there is an option somewhere in bind to only accept signed records (and if not, there will be eventually I'm sure), but even if Comcast wasn't futzing with your dataz, you wouldn't have a functional internet.

(I'm on comcast, and am not seeing this redirection. I also run a local DNS resolver.)

Official Response

[ComcastBonnie]

Hey guys, I just caught this on Twitter, and I can confirm that we do not and have not hijacked any DNS traffic in our network and certainly not to 3rd party resolvers. 'nuff said. I spoke with our DNS engineering folks, and they have confirmed. If you would like to contact me, I'm @ComcastBonnie on Twitter.

So let me see if I have this straight...

[BaronHethorSamedi]

An anonymous reader submits a "story" linking to a random blog spouting off rumors about a nefarious scheme by Comcast to redirect port traffic. The "story" is then published under a headline asserting the rumor as fact, while the summary is actually a plea for the fact-checking on the story to be done by readers.

News for nerds, indeed.

Re:"Official Response"

[fluxrad]

I'd watch what you call an 'Official Response' as many corporations have very strict rules about talking to the press, or making any binding claims to a general audience. Are you authorized for such communication?

Yes she is. She's handled one of my responses before. Recently corporations have started hiring "social networking" types to answer questions on places like twitter, facebook et al. It would Slashdot is another one of these venues.

Re:As one of the authors of Netalyzr...

[nweaver]

A colleague who knew about our launch told us we just got slashdotted.

We actually WANT to get slashdotted, because that helps us measure the network.

Re:Fuck `Em All

[RulerOf]

group sex with Oprah Winfrey, Rosie O'Donnell, Roseanne Barr and Chelsea Clinton

That's the absolute worst thing I've read in a long time.

Well done, sir.