×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comcast Intercepts and Redirects Port 53 Traffic

kdawson posted more than 4 years ago | from the why-we-need-ipv6 dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

527 comments

Not happening to me (5, Informative)

jimmyhat3939 (931746) | more than 4 years ago | (#28269017)

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.

Linus Torvalds is a turd burglar (-1, Flamebait)

linustorvaldsisaturd (1573171) | more than 4 years ago | (#28269083)

Linux just isn't ready for the desktop yet. It may be ready for the web servers that you nerds use to distribute your TRON fanzines and personal Dungeons and Dragons web-sights across the world wide web, but the average computer user isn't going to spend months learning how to use a CLI and then hours compiling packages so that they can get a workable graphic interface to check their mail with, especially not when they already have a Windows machine that does its job perfectly well and is backed by a major corporation, as opposed to Linux which is only supported by a few unemployed nerds living in their mother's basement somewhere. The last thing I want is a level 5 dwarf (haha) providing me my OS.

Re:Not happening to me (5, Interesting)

Shakrai (717556) | more than 4 years ago | (#28269131)

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.

Re:Not happening to me (1)

sanosuke001 (640243) | more than 4 years ago | (#28269273)

I don't have Comcast (anymore) but when I was living in CT I was privileged (/s) enough to have them as my only choice. This was at the time when they first started filtering BT traffic; I never had an issue so it might be a subsection of their consumer base.

Also, I have road runner now and I don't have a static IP. I just have a dyndns.org hostname I use coupled with their IP update tool that keeps my IP updated. they have free accounts as long as they stay updated. ie. deleted after 30 days without an update but I get nice emails reminding me 5 days in advance. He might be doing the same?

Re:Not happening to me (1)

Shakrai (717556) | more than 4 years ago | (#28269413)

Also, I have road runner now and I don't have a static IP. I just have a dyndns.org hostname I use coupled with their IP update tool that keeps my IP updated. they have free accounts as long as they stay updated. ie. deleted after 30 days without an update but I get nice emails reminding me 5 days in advance. He might be doing the same?

Not if he's using his nameserver as an authoritative nameserver for one or more domains. You can't list those by hostnames, you have to list them by IP address. That said, I don't know how Comcast works but my Roadrunner IP hasn't changed in over a year. That's one of the nice things about them vs. Verizon DSL, where it seems to change on a almost daily basis.

Re:Not happening to me (3, Informative)

whoever57 (658626) | more than 4 years ago | (#28269215)

I just verified that it's not currently happening. I'm in California if that matters.

Me too. I'm also in CA and it is not curently happening.

Re:Not happening to me (5, Interesting)

CodeBuster (516420) | more than 4 years ago | (#28269251)

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

Re:Not happening to me (3, Informative)

jeffmeden (135043) | more than 4 years ago | (#28269473)

Or, more simply, query something you know doesn't exist (like asdfdsafdsafhdsds.com) against your server (which is presumably above any such hijacking) and see if the request gets hijacked. Isn't that the point of this outrage? Getting typojacked when you try to go to a genuinely invalid URL?

Re:Not happening to me (5, Informative)

whoever57 (658626) | more than 4 years ago | (#28269481)

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 (2, Interesting)

mea37 (1201159) | more than 4 years ago | (#28269621)

That's the only way you can think of to verify what's happening?

GP controls the DNS server in question. Think server logs and monitoring tools.

California? (0, Offtopic)

bogaboga (793279) | more than 4 years ago | (#28269475)

Californians are in some kind of budget crisis...or are they? I am in Timbuktu if that matters.

Re:Not happening to me (4, Informative)

EvilBudMan (588716) | more than 4 years ago | (#28269495)

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

I'd first post but (1, Funny)

Anonymous Coward | more than 4 years ago | (#28269025)

someone is intercepting my DNS requests.

Not happening here (2, Informative)

jimmyhat3939 (931746) | more than 4 years ago | (#28269047)

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.

Re:Not happening here (3, Interesting)

Shakrai (717556) | more than 4 years ago | (#28269095)

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?

That's it! I'm giving up the booze! (0)

Anonymous Coward | more than 4 years ago | (#28269137)

Somma bitch! I'm having this really weird deja vu! I think I'm seeing your post twice, but slightly different! I guess this is what happens when you're a serious alcoholic!

Fuck! I'm going to poor every drop of booze in my house down the sink!

Re:That's it! I'm giving up the booze! (1)

interkin3tic (1469267) | more than 4 years ago | (#28269423)

Fuck! I'm going to poor every drop of booze in my house down the sink!

Comcast has rerouted your sink too, so that will only help them! Getting drunk in this case? Not one of their better evil plans...

Re:Not happening here (4, Interesting)

mcgrew (92797) | more than 4 years ago | (#28269229)

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.

Not surprised (0, Redundant)

Hyppy (74366) | more than 4 years ago | (#28269071)

I've tried really hard to be shocked and surprised. I can't. This is just another example of a continuing trend of anti-customer behavior by these guys.

Re:Not surprised (1)

delta98 (619010) | more than 4 years ago | (#28269457)

I agree. I tried to not sport a foil hat while keeping an eye on the reaction of some media power base's while he web was taking it's current form. Hell, I watched this grow from a little seed into what it is today and I see the problem in as far as whom owns the pipe.My ball my rules. That sucks. We all paid for this not only in our suv\bscriber fees but in grants and low interest loans to those who now have control through our tax dollars. There is a solution and there will be another round of cat and mouse. So it continues..

Re:Not surprised (2, Insightful)

nomel (244635) | more than 4 years ago | (#28269575)

No...it's anti-anyonebutnormalcustomer behavior. The people running dns servers are probably 0.000001% of internet users....the rest are probably just infected machines.

The question is *why* do they care about filtering DNS traffic? Do they offer this service as a paid service elsewhere, costing them *money*? Or is it simply to try to get a handle on worms and malware, which uses tons of bandwidth for a network as big as comcast, costing them *tons of money*.

They have a profit based mindset...it shouldn't be hard to figure out why they're doing it. If the cost from malware is more than the loss of a portion of a fairly insignificant customer base that in reality probably costs them what several regular users cost, then they'll choose to block the port!

At one point I called support and asked what kind of account I would need to legally (in terms of usage agreement: no servers allowed) run a website. They said I'd have to go elsewhere to a *hosting company*. That's probably what they'll tell you here.

I think as much as we complain, in the end, if you want a direct and unfiltered, higher risk, and more expensive to maintain connection to the internet, you'll have to...pay more....just like if you want to use 5x the bandwidth of a normal user, you'll have to pay more.

I like the idea of the internet being a standard connection, wide open and the same anywhere...but that's not going to happen without regulatory laws, cause it doesn't make much business sense.

not a comcast issue (1)

Archfeld (6757) | more than 4 years ago | (#28269073)

but rather this appears to be earthlink. Time to find a new ISP. Since their policy changed it should invalidate any long term contract you have, time to move on. The ONLY language either entity will uncerstand is you voting with your dollars, by giving them to another company. I realize comcrap will probably see this as a violation of their right to profit, but OH WELL...

DNSSEC? (1)

Your Anus (308149) | more than 4 years ago | (#28269077)

How does this affect DNS with DNSSEC applied? Wouldn't there be a mismatch in the signing keys?

Re:DNSSEC? (4, Informative)

ScytheBlade1 (772156) | more than 4 years ago | (#28269233)

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

Using OpenDNS on Comcast (1, Informative)

Anonymous Coward | more than 4 years ago | (#28269085)

no sign of any DNS hijacking in western MA.

Re:Using OpenDNS on Comcast (4, Informative)

CompSci101 (706779) | more than 4 years ago | (#28269175)

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

I get OpenDNS error pages for nonexistent domains.

Re:Using OpenDNS on Comcast (1)

aztektum (170569) | more than 4 years ago | (#28269447)

Me not so much a fan of OpenDNS. I prefer pointing my DNS @ L3's servers... 4.1.1.1-.6

I have Comcast Biz class (no cap, less snooping since there is a signed agreement dictating such - for me at least). I will check this when I have a chance.

Re:Using OpenDNS on Comcast (1)

geekboy642 (799087) | more than 4 years ago | (#28269543)

You may want to change that. I remember seeing an article a few weeks back saying that L3 was going to implement some access restrictions on those to lower their traffic.

Fuck `Em All (5, Funny)

Cpt_Kirks (37296) | more than 4 years ago | (#28269091)

When Comcast took over from Time Warner here, I bailed.

I mean, Time Warner is evil. AT&T (who I switched to), is evil.

But Comcast is Motherfucking Sith Lord EVIL.

Scary fucking eeeeevil. Nazi evil. RIAA evil.

 

Re:Fuck `Em All (5, Funny)

Em Emalb (452530) | more than 4 years ago | (#28269123)

So what are you trying to say?

C'mon man, stop beating around the bush and get to your point.

Re:Fuck `Em All (4, Funny)

interkin3tic (1469267) | more than 4 years ago | (#28269461)

C'mon man, stop beating around the bush and get to your point.

It had something to do with star wars. The sith lord part tipped me off.

Re:Fuck `Em All (1)

Shakrai (717556) | more than 4 years ago | (#28269171)

Scary fucking eeeeevil. Nazi evil.

Yes, because hijacking your DNS packets and injecting RST packets to interfere with bittorrent is comparable to putting millions of people in ovens and trying to conquer Eurasia.......

Re:Fuck `Em All (0)

Anonymous Coward | more than 4 years ago | (#28269245)

You're right, there's no contest between the two.

The Third Reich has NOTHING on Comcast.

Re:Fuck `Em All (4, Funny)

Itninja (937614) | more than 4 years ago | (#28269253)

I think the parent was just using a bit of hyperbole there. Also, it appears he only has a limited understanding of what the word 'evil' means. And the word 'fuck'. And, well, he just don't appear to be that bright in general.

Re:Fuck `Em All (1)

fpophoto (1382097) | more than 4 years ago | (#28269275)

Yes, because hijacking your DNS packets and injecting RST packets to interfere with bittorrent is comparable to putting millions of people in ovens and trying to conquer Eurasia......

Good point, although I think the result will be the same for both: failure.

Re:Fuck `Em All (0, Flamebait)

danpritts (54685) | more than 4 years ago | (#28269243)

glad to hear that comcast is morally equivalent to the perpetrators of the holocaust, who killed 12 million people in concentration camps.

Re:Fuck `Em All (3, Insightful)

CorporateSuit (1319461) | more than 4 years ago | (#28269301)

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

Re:Fuck `Em All (1)

sckeener (137243) | more than 4 years ago | (#28269581)

I like to think of it as indifferent Evil vs Active Evil.

Time Warner doesn't care about their customers (indifferent Evil)

vs

Comcast is out to get their customers. (Active Evil)

another good way to describe them is....Time Warner is a Thief whereas Comcast is an Assassin.

(I don't don't know who would be the Thief-Acrobat. Which one's stock is fluctuating today?)

That's a negative (5, Funny)

jjb3rd (1138577) | more than 4 years ago | (#28269093)

I'm a comcast user and it works for me...perhaps his home network is the problem. A Linux user having a misconfigured network?!??! Oh wait this is Slashdot...nevermind.

Neither here... (1)

Nightwraith (180411) | more than 4 years ago | (#28269109)

Doesn't seem to be happening in Northwest Indiana either.

Given the poor availability of the Comcast DNS servers in this area, forcing their use seems like a very quick way to flood their customer service lines.

Re:Neither here... (1)

MBGMorden (803437) | more than 4 years ago | (#28269593)

Given the poor availability of the Comcast DNS servers in this area, forcing their use seems like a very quick way to flood their customer service lines.

Not saying it isn't a bad practice, but how often do you honestly think that their users reconfigure their system to utilize a DNS server other than that of their ISP? Sure it happens, but it's done by tech geeks like us. The entirety of their user base that does this, even if they all called, probably wouldn't be enough to "flood their customer service lines".

Sometimes I think that we overestimate just how outraged a customer base will be to a specific change. It's akin to claiming that Pepsi is going to have to deal with a shitstorm of complaints for ceasing production of "Caffeine Free Diet Cherry Crystal Clear Pepsi".

I really am hoping this is NOT a gullibility test (2, Informative)

way2trivial (601132) | more than 4 years ago | (#28269115)

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 downlink as having 220 msec of buffering. This level may serve well for maximizing speed while minimizing the impact of large transfers on other traffic.
HTTP Tests
Address-based HTTP proxy detection: OK

There is no explicit sign of HTTP proxy use based on IP address.
Header-based HTTP proxy detection: OK

No HTTP header or content changes hint at the presence of a proxy.
HTTP proxy detection via malformed requests: OK

Deliberately malformed HTTP requests arrive at our server unchanged. We are not able to detect a proxy along the path to our server using this method.
Filetype-based filtering: OK

We did not detect file-content filtering.
JavaScript-based tests: OK

The applet was not run from within a frame.
Your web browser reports the following cookies for our web page:
netAlizEd (set by our server)
Your web browser was unable to fetch an image using IPv6.
HTTP caching behavior: OK

There is no suggestion that a transparent HTTP cache exists in your network.
DNS Tests
Restricted domain DNS lookup: OK

We are able to successfully lookup a name which resolves to the same IP address as our webserver. This means we are able to conduct many of the tests on your DNS server.
Unrestricted domain DNS lookup: OK

We are able to successfully lookup arbitrary names from within the Java applet. This means we are able to conduct all test on your DNS server.
DNS resolver address: OK

The IP address of your ISP's DNS Resolver is 68.87.64.147, which resolves to phil-cns01.inflow.pa.bo.comcast.net.
DNS resolver properties: Lookup latency: 120ms

Your ISP's DNS resolver requires 120 msec to conduct an external lookup.
Your resolver is using QTYPE=A for default queries.
Your resolver is not automatically performing IPv6 queries.
Your DNS resolver does not use EDNS.
Your resolver does not use 0x20 randomization, but will pass names in a case-sensitive manner.
DNS glue policy: OK

Your ISP's DNS resolver does not accept generic additional (glue) records -- good.
Your ISP's DNS resolver does not accept additional (glue) records which correspond to nameservers.
Your ISP's DNS resolver does not follow CNAMEs.
DNS resolver port randomization: OK

Your ISP's DNS resolver properly randomizes its local port number.
The following graph shows DNS requests on the x-axis and the detected source ports on the y-axis.

DNS lookups of popular domains: OK

74 of 74 popular names were resolved successfully. Show all names.
1 popular name has a mild anomaly. The ownership suggested by the reverse name lookup does not match our understanding of the original name. The most likely cause is the site's use of a Content Delivery Network. Show all names.
DNS results wildcarding: OK

Your ISP correctly leaves non-resolving names untouched.
Host Properties
System clock accuracy: OK

Your computer's clock agrees with our server's clock.
Browser properties

The following parameters are sent by your web browser to all web sites you visit:
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.30 Safari/530.5
Accept: application/xml,application/xhtml+xml,text/html; q=0.9,text/plain; q=0.8,image/png,*/*; q=0.5
Accept Language: en-US,en;q=0.8
Accept Encoding: gzip,deflate,bzip2,sdch
Accept Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Feedback
Please take a moment to tell us about your network. All fields are optional. If you would like to contact us with questions about your results, please contact us with your session ID, or get in touch on the mailing list.

How is your machine connected to the network?
Wireless Wired
Where are you right now?
At home
At work
In a public setting (wifi hotspot, Internet cafe, etc.)
Other (please describe in comments below)

Feel free to leave additional comments below.

Your email address:

ID 4b65b8c9-17282-eef97e72-2eeb-4e02-bf77 FAQs + ICSI

Re:I really am hoping this is NOT a gullibility te (0)

Anonymous Coward | more than 4 years ago | (#28269523)

you should not have posted your session ID if you wanted to erase the details of your ip address..

Using OpenDNS here (1)

rpmonkey (840379) | more than 4 years ago | (#28269129)

I switched my DNS to OpenDNS because Comcast's DNS servers were unreliable for me. I am definitely hitting OpenDNS because if I typo a domain I'm redirected to the OpenDNS guide page. I'm a Northern California Comcast user.

Re:Using OpenDNS here (1)

pdragon04 (801577) | more than 4 years ago | (#28269355)

You're missing the point of the article. Even if you use OpenDNS, you're still getting redirected to Comcast's DNS servers.

Re:Using OpenDNS here (1)

Improv (2467) | more than 4 years ago | (#28269463)

Not if they're reaching the OpenDNS guide page on typos.

Re:Using OpenDNS here (1)

pdragon04 (801577) | more than 4 years ago | (#28269517)

If you're not experiencing the issue described in the article, you're right, you'll see the OpenDNS error page. If you're experiencing what the article is describing, you will not see the OpenDNS error page, but whatever Comcast redirects you to.

Re:Using OpenDNS here (0)

Anonymous Coward | more than 4 years ago | (#28269431)

I switched my DNS to OpenDNS because Comcast's DNS servers were unreliable for me. I am definitely hitting OpenDNS because if I typo a domain I'm redirected to the OpenDNS guide page. I'm a Northern California Comcast user.

Same here. Southern Maine user.

No problems for me (0)

Anonymous Coward | more than 4 years ago | (#28269141)

I use opendns and it seems to be functioning fine. My requests show up on my account and I get the occasional Opendns search if I misstype something.

Comcast is not alone in this (1)

timon (46050) | more than 4 years ago | (#28269143)

I use Sprint Mobile Broadband at home and the last time I checked (several months ago), they were still intercepting and redirecting port 53 traffic.

Security (1)

YayaY (837729) | more than 4 years ago | (#28269147)

They could be doing this for security reasons, to prevent DNS domain hijacking.

Re:Security (1, Insightful)

Anonymous Coward | more than 4 years ago | (#28269247)

They could be doing this for security reasons, to prevent DNS domain hijacking.

Yeah, right.

Re:Security (0)

Anonymous Coward | more than 4 years ago | (#28269539)

They could be doing this for security reasons, to prevent DNS domain hijacking.

That could be true. After all anyone else could hijack the DNS request right after comcast hijacks it first... Oh wait

Doesn't happen for me (1)

nedlohs (1335013) | more than 4 years ago | (#28269161)

with comcast in NJ.

Thn again I don't get advertising page IPs in response to non-existant names either.

DNS-Based Filtering (2, Interesting)

Bicx (1042846) | more than 4 years ago | (#28269185)

So does this mean that my DNS-based filtering through OpenDNS would stop? If so, my kids could be stumbling onto porn, malware, and dangerous sites that I was trying to shield them from. Thanks Big Brother! That's just awesome. No, that's Comcastic!

Well Written! (1)

sys.stdout.write (1551563) | more than 4 years ago | (#28269201)

I believe all academic journals should be published in the prose employed by the write-up. Well done, sir!

For those of us in the Midwest, Charter Communications can suck it too.

I'm in philly (Comcast HQ) (0)

Anonymous Coward | more than 4 years ago | (#28269255)

i ran the ICSI netalyzer and it reported the this as one of my "minor concerns"

Reachability Tests:
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 also able to directly request a large DNS response.

If you want real Comcast fun... (1)

NecroPuppy (222648) | more than 4 years ago | (#28269263)

Take a look at the packet loss on their Augusta, GA servers. Regularly, from 10 PM to 1 AM (or later), 50%+ packet loss.

I know because a buddy's radio show keeps crapping out, and it goes through there. But when I rebroadcast the show as a test (and don't go through that server), the issues don't happen.

But their L1 and L2 techs can't figure out the problem.

Comcast results in Houston, TX (3, Informative)

macklin01 (760841) | more than 4 years ago | (#28269269)

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.

errmm... (2, Informative)

Tmack (593755) | more than 4 years ago | (#28269503)

Most dns traffic uses UDP

TCP is generally only used for excessively large requests or zone transfers

Tm

Re:errmm... (1)

macklin01 (760841) | more than 4 years ago | (#28269597)

Whoops! Good point. :-)

Here's the relevant line, then: Direct UDP access to remote DNS servers (port 53) is allowed.

Thanks -- Paul

Hmmm... (1)

tthomas48 (180798) | more than 4 years ago | (#28269289)

Interesting side-note. Time Warner's DNS servers stopped working recently for my Playstation 3. I switched to OpenDNS and all is well, but does anyone have an idea what's going on here? I thought DNS was DNS.

NN wars? (1)

Red Flayer (890720) | more than 4 years ago | (#28269293)

If true, this is a pretty serious escalation in the Net Neutrality wars.

It's not just an escalation in the NN wars (I didn't know we were fighting a war, anyway. I thought it was just a 'security detachment' or 'police action').

This represents a fundamental shift in how the internet works. If you can't use your own DNS servers, or at least send requests to an outside DNS server, then the internet loses some of its ability to route around damage (again, using the convention that 'damage' includes shit like deep packet inspection, etc).

If true, this is really a sad day... for it represents the true beginning of the end of the internet as we know it.

And now that I've got the Chicken Little hyperbole out of the way... seems to me like Comcast wants to be a forced portal, not just an ISP. Hopefully they are rewarded with the same fate AOL was rewarded.

The scary part (1)

Chardish (529780) | more than 4 years ago | (#28269295)

This practice effectively prohibits the use of alternative DNS roots, such as OpenNIC. In other words, it gives ICANN even stronger dominance over internet naming.

Not for me... (1)

catseye (96076) | more than 4 years ago | (#28269307)

Comcast customer in Colorado, just outside of Boulder. Not happening here; I use OpenDNS and am definitely hitting their servers.

Works fine in Chicago too (1)

hoosbane (643500) | more than 4 years ago | (#28269313)

Just tried it from my home machine on Comcast in Chicago, and nothing's being redirected. Lookups for non-existant domains return NXDOMAIN like they should.

Just run BIND in your computer (0, Informative)

Anonymous Coward | more than 4 years ago | (#28269359)

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 (3, Informative)

argent (18001) | more than 4 years ago | (#28269437)

And your recursive DNS server performs its own lookups via requests on port 53 to the root servers, which get intercepted by Comcast, ...

Damn! That may stop my plan...... (3, Funny)

whoever57 (658626) | more than 4 years ago | (#28269365)

Last time I had some spare time in an airport, I found that the T-Mobile hotspot allowed 53/UDP traffic out, so I was thinking of setting up openvpn on port 53 (instead of its usual 1194) in order to access my home machines (without a T-Mobile login). If Comcast intercepts this traffic, my evil plan won't work!

Comcast results in PA. (1)

thesolo (131008) | more than 4 years ago | (#28269385)

Here are my ICSI results [berkeley.edu] .

Direct UDP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote DNS servers (port 53) is allowed.


My office is just outside of Philadelphia, so southeastern PA, for regional results.

OpenDNS (2, Interesting)

Clipless (1432977) | more than 4 years ago | (#28269397)

A good friend of mine was using OpenDNS on Comcast and one day, without warning, his internet service was cut off.
When he called the phone rep said that Comcast had disabled his internet because he was not using their DNS server and that if he wanted to have Comcast as a provider he had no choice but to use DNS servers provided by DHCP!

Here's a permalink showing it may be happening... (1, Insightful)

Anonymous Coward | more than 4 years ago | (#28269399)

http://netalyzr.icsi.berkeley.edu/restore/id=4b65aebb-18883-4ded0c2e-9922-4ace-8be5

Thanks for publishing the trick (0)

Anonymous Coward | more than 4 years ago | (#28269403)

Now every isp in the world will know that it could
be useful to do that. Thanks for letting them
know about these tricks. This ensures that
DNS will be useless in few years...

Is this happening for ANYONE? (5, Insightful)

Itninja (937614) | more than 4 years ago | (#28269435)

Was the original poster a shill for some other ISP or what? An anonymous user submits a story decrying a great technical wrong by Comcast, that no one appears to be able to reproduce. So a little fact check action might in order here. Up next, "toyotasuxors@ford.com says: Toyota tracking all US drivers with a device hidden in the glove box!

Re:Is this happening for ANYONE? (0)

Anonymous Coward | more than 4 years ago | (#28269577)

Yes, Me.

http://netalyzr.icsi.berkeley.edu/restore/id=4b65aebb-18883-4ded0c2e-9922-4ace-8be5

Falsely advertising "Internet access" (2, Interesting)

davidwr (791652) | more than 4 years ago | (#28269441)

Are you buying "Internet access" or something else? If you bought "Internet access" and you aren't getting it that's breach of contract. Odds are you are buying "partial Internet access as spelled out by the terms and conditions" which is probably not "Internet access."

Are they advertising "Internet access" or something else? If they are advertising "Internet access" and not delivering, that's false advertising. Unfortunately, it takes either deep pockets or a friend in your friendly neighborhood Attorney General's office to fight this battle.

Of course, most major IPSs haven't delivered "Internet access" to home users for years. They routinely block port 25 and other widely-abused ports, and some throttle traffic in ways that are not non-discriminatory. Business users, especially big business users, usually can get real Internet access but they have to pay.

Boston South Shore: Nope (1)

Tokerat (150341) | more than 4 years ago | (#28269453)

[machine]:~ [user]$ nslookup comcast.sucks.com testserv.mydomain.com
;; connection timed out; no servers could be reached

This was tested on testserv.mydomain.com (doesn't exist) because I knew it wouldn't respond. I don't have an outside box to test it with, so while not 100% conclusive, according to this test I should still get a DNS response if Comcast is intercepting. ICSI Netalyzr shows the following:

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 access to remote FTP servers (port 21) is allowed.
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.

Are you sure Comcast is doing this, or is it being intercepted by a NAT gateway or proxy?

If they worked maybe more people would use them (1)

Xeriar (456730) | more than 4 years ago | (#28269505)

Was mostly a couple years ago, but even still, I had to keep a note of alternative DNS servers just in case Comcast's went on a fritz. Crazy annoying, and try explaining it to laymen!

Official Response (4, Informative)

ComcastBonnie (1449629) | more than 4 years ago | (#28269531)

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.

As one of the authors of Netalyzr... (5, Interesting)

nweaver (113078) | more than 4 years ago | (#28269563)

We have not seen any redirection issues with Comcast user's DNS settings.

Questions on netalyzr itself will be answered in this thread.

So let me see if I have this straight... (5, Informative)

BaronHethorSamedi (970820) | more than 4 years ago | (#28269573)

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.

Federal Wiretapping Laws (0)

Anonymous Coward | more than 4 years ago | (#28269605)

If this is true, wouldn't it be a violation of the Federal Wiretapping Act? They are certainly intercepting electronic communications, and worse yet, they are redirecting them and sending their own response. Is anyone an actual lawyer that is familiar enough with the act to comment intelligently on whether this is a violation or not?

As most of you may have noticed by now.... (0)

Anonymous Coward | more than 4 years ago | (#28269613)

Comcast does not intercept port 53. A check using Netalyzer from ICSI or running a dig or nslookup will validate this for you against any third party resolver or any of the Comcast DNS servers.

This is just plain old FUD.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...