Comcast Intercepts and Redirects Port 53 Traffic 527
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.
Not happening to me (Score:5, Informative)
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.
Not happening here (Score:2, Informative)
I have several domains I run on a private DNS server that I access from my house using Comcast. I haven't experienced this. I'm in California if it matters.
I suppose users could tunnel DNS over some other port if they had to.
Using OpenDNS on Comcast (Score:1, Informative)
no sign of any DNS hijacking in western MA.
I really am hoping this is NOT a gullibility test (Score:2, Informative)
My connection is comcast for biz-- go crazy- I took out my last subnet
The ICSI Netalyzr Beta
Introduction Analysis Results
Result Summary
74-92-106-XXX-Philadelphia.hfc.comcastbusiness.net / 74.92.106.XXX
Recorded at 14:15 EDT (18:15 UTC) on Tue, June 09 2009. Permalink. Transcript.
Noteworthy Events
Minor Aberrations
Certain protocols are blocked in outbound traffic
Address-based Tests
NAT detection: NAT Detected
Your global IP address is 74.92.106.XXX while your local one is 192.168.15.XX. You are behind a NAT. Your local address is in unroutable address space.
Your NAT renumbers TCP source ports sequentially. The following graph shows connection attempts on the X-axis and their corresponding source ports on the Y-axis.
DNS-based host information: OK
You are not a Tor exit node for HTTP traffic.
You are not listed on any Spamhaus blacklists.
The SORBS DUHL believes you are using a statically assigned IP address.
Reachability Tests
General connectivity: Note
Basic UDP access is available.
Direct UDP access to remote DNS servers (port 53) is allowed.
The applet was also able to directly request a large DNS response.
Direct UDP access to remote MSSQL servers (port 1434) is allowed.
Direct TCP connections to remote FTP servers (port 21) failed.
This is commonly due to how a NAT or firewall handles FTP traffic, as FTP causes unique problems when developing NATs and firewalls.
Direct TCP access to remote SSH servers (port 22) is allowed.
Direct TCP access to remote SMTP servers (port 25) is allowed.
Direct TCP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote HTTP servers (port 80) is allowed.
Direct TCP access to remote POP servers (port 110) is allowed.
Direct TCP access to remote RPC servers (port 135) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote NetBIOS servers (port 139) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote IMAP servers (port 143) is allowed.
Direct TCP access to remote SNMP servers (port 161) is allowed.
Direct TCP access to remote HTTPS servers (port 443) is allowed.
Direct TCP access to remote SMB servers (port 445) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote SMTP/SSL servers (port 465) is allowed.
Direct TCP access to remote secure IMAP servers (port 585) is allowed.
Direct TCP access to remote authenticated SMTP servers (port 587) is allowed.
Direct TCP access to remote IMAP/SSL servers (port 993) is allowed.
Direct TCP access to remote POP/SSL servers (port 995) is allowed.
Direct TCP access to remote SIP servers (port 5060) is allowed.
Direct TCP access to remote BitTorrent servers (port 6881) is allowed.
Network Access Link Properties
Network latency measurements: Latency: 26ms Loss: 0.0%
The round-trip time (RTT) between your computer and our server is 26 msec, which is good.
We recorded no packet loss between your system and our server.
TCP connection setup latency: 29ms
The time it takes your computer to set up a TCP connection with our server is 29 msec, which is good.
Network bandwidth measurements: Upload 4.3 Mbit/sec, Download 7.1 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 4.3 Mbit/sec. This level of bandwidth works well for many users.
Your Downlink: We measured your downlink's receiving bandwidth at 7.1 Mbit/sec. This level of bandwidth works well for many users.
Network buffer measurements: Uplink 229 ms, Downlink 220 ms
We estimate your uplink as having 230 msec of buffering. This level may serve well for maximizing speed while minimizing the impact of large transfers on other traffic.
We estimate your
Re:Using OpenDNS on Comcast (Score:5, Informative)
Likewise in Southern New Jersey (and Philadelphia before this -- the very heart of Comcast darkness)
I get OpenDNS error pages for nonexistent domains.
Re:Not happening to me (Score:4, Informative)
Me too. I'm also in CA and it is not curently happening.
Re:DNSSEC? (Score:5, Informative)
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.)
Comcast results in Houston, TX (Score:4, Informative)
Here are the ICSI results [berkeley.edu]. Results are from a PC behind a bog-standard Linksys WRT-54g, for what it's worth.
Not my field, but I see Direct TCP access to remote DNS servers (port 53) is allowed. I'll leave it to the networking experts to pick through the rest of the report.
Just run BIND in your computer (Score:0, Informative)
or set up a server in your LAN.. run BIND, setup to do recursive lookup...
use that as your DNS server
Re:Just run BIND in your computer (Score:4, Informative)
And your recursive DNS server performs its own lookups via requests on port 53 to the root servers, which get intercepted by Comcast, ...
Re:Not happening to me (Score:4, Informative)
Re:Not happening to me (Score:5, Informative)
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 (Score:5, Informative)
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
errmm... (Score:3, Informative)
TCP is generally only used for excessively large requests or zone transfers
Tm
Official Response (Score:4, Informative)
So let me see if I have this straight... (Score:5, Informative)
News for nerds, indeed.
Re:Not happening to me (Score:5, Informative)
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:Port 53 Rerouted in Seattle :| (Score:4, Informative)
Your netalyzr results show no DNS issues in the link you posted, using a Comcast DNS server:
Re:Is this happening for ANYONE? (Score:3, Informative)
This is probably your NAT. We see such behavior among random visitors, but not those restricted to Comcast, and only a few Comcast-based visitors show this behavior.
Re:So let me see if I have this straight... (Score:1, Informative)
I can understand the paranoia at least. We've seen this kind of shit [slashdot.org] being pulled before.
Not blocking in NY (Score:2, Informative)
TWX is MPAA, but not RIAA or cable (Score:3, Informative)
From your post, I don't think you're aware that Time Warner is actually one of the presiding members of the RIAA (and the MPAA).
Time Warner is a member of the MPAA. It is not a major record label; it spun off Time-Life Records [wikipedia.org] in 2003 and Warner Music Group [wikipedia.org] in February 2004. It is not a cable company; it spun off Time Warner Cable [wikipedia.org] in March 2009.
Re:Not happening to me (Score:3, Informative)
Re:"Official Response" (Score:5, Informative)
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.
Disregard; ORSN is SK (Score:3, Informative)
Apparently the ORSN project has been shut down, at least for the moment, due to lack of involvement and resources.
Some of the servers continue to operate, but it was officially discontinued [dns-oarc.net] as of 31 Dec 2008. Too bad.
Re:"Official Response" (Score:1, Informative)
Dude, there was a whole Wired article about how much effort Comcast has gone through lately with trying not to suck. Included in this article was the whole ComcastCares Twitter thing, which proved so successful that it went from one tech not wanting people to badmouth Comcast, to a team of Comcast employees deployed specifically to respond to events such as this.
For an overwhelmingly evil company, their Twitter presence is actually one of the brightest... most human... spots that Comcast has.
Re:Not happening to me (Score:3, Informative)
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?
My access is through Comcast, though like TFA's writer I get it from Earthlink, and I have a static IP with a consumer not a business account.
Falcon
Re:As one of the authors of Netalyzr... (Score:5, Informative)
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:"Official Response" (Score:3, Informative)
Re:"Official Response" (Score:2, Informative)
Re:Not happening to me (Score:3, Informative)
I've had my Comcast IP (outside Boston) change about 2 or 3 times on me in the span of about 5 years. It doesn't happen often, but it does. I believe it's only been when they need to add capacity to an area.
try democracy (Score:3, Informative)
Re:Fuck `Em All (Score:5, Informative)
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.
Re:Not happening to me (Score:3, Informative)
Same here. I routinely test work DNS servers from home (on Comcast). They include non-public domains that will not resolve anywhere else. Other zones may differ from what the authoritative nameserver would answer.
They may be intercepting DNS somewhere, but not here in Atlanta.
Re:Not happening to me (Score:5, Informative)
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:Not happening to me (Score:3, Informative)
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.
Depends on where you are. With Qwest (and a local third party ISP) I've had the same IP number since I got the service, maybe 10 years ago. That's regular consumer-grade (1.5M/1.0M) DSL. The reverse DNS lookup gives a name that has my ISP username embedded into it.