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'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.
Free Conference Call -- No Spam, High Quality
someone is intercepting my DNS requests.
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.
Free Conference Call -- No Spam, High Quality
I'm on Comcast. When I tried to use another DNS server it was blocked.
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.
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...
errr....umm...*whooosh* *whoosh* Is this thing on ?
How does this affect DNS with DNSSEC applied? Wouldn't there be a mismatch in the signing keys?
In the USA, we like stuff watered down, like beer, television, and freedom.
no sign of any DNS hijacking in western MA.
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.
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.
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.
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
every day http://en.wikipedia.org/wiki/Special:Random
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.
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!
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.
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.
Zero tolerance equals zero intelligence
They could be doing this for security reasons, to prevent DNS domain hijacking.
Votator.com implements a fair voting scheme (free
with comcast in NJ.
Thn again I don't get advertising page IPs in response to non-existant names either.
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!
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 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.
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.
I like you, Stuart. You're not like everyone else, here, at Slashdot.
Here are the ICSI results. 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.
OpenSource.MathCancer.org: open source comp bio
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.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
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.
Comcast customer in Colorado, just outside of Boulder. Not happening here; I use OpenDNS and am definitely hitting their servers.
What did the walrus say to the penguin? "No soap, radio."
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.
http://netalyzr.icsi.berkeley.edu/restore/id=ae8199f5-18807-f5eeee66-ce59-42a4-8803
Note that my DNS servers are Level3 servers (4.2.2.2, 4.2.2.4) since they are much faster than Comcast DNS.
~ C.
or set up a server in your LAN.. run BIND, setup to do recursive lookup...
use that as your DNS server
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!
The real "Libtards" are the Libertarians!
Here are my ICSI results.
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.
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!
http://netalyzr.icsi.berkeley.edu/restore/id=4b65aebb-18883-4ded0c2e-9922-4ace-8be5
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...
So far
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!
I judt got a nre Kinesis keybiartf so please excusr ant egregiou typos.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
;; 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?
CAn'T CompreHend SARcaSm?
Californians are in some kind of budget crisis...or are they? I am in Timbuktu if that matters.
TCP is generally only used for excessively large requests or zone transfers
Tm
Support TBI Research: http://www.raisinhope.org
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!
I am a science fantasy fan
you should not have posted your session ID if you wanted to erase the details of your ip address..
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.
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
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.
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?
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.
That is, Comcast Town
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
You couldn't have just dropped the link?!
Don't panic
I can verify this is happening in Lynnwood, WA - just north of Seattle - on my Comcast residential connection. First port 25 is blocked, now 53 is being rerouted? GD Comcast is a bunch of toolsheds.
My working third party server connected to the dummy DNS server just fine, while my home Comcast connected PCs couldn't. Tested in Windows 2008, Gentoo and Windows XP @ home - same results on all 3.
Webalyzer results: here
I have the luxury of residential AND commercial internet service from Comcast in Monroe, WA. I can try both tonight.
In Liberty, Rene
Sorry guys, He's a hijacked machine on my botnet. I Apologize about the story.
I tested this with a server on a Comcast biz account (MI) going to a server on a non-Comcast network. Worked fine.
So basically this story is total bullshit? Here on Slashdot? Shocking. Even if it was true who does this affect? About 20 of you out there that would even notice? For the average user this makes absolutely no difference in our service. Yes, I'm just an average user. Sorry! Sorry I'm just an average user!
I'm in Bellevue, WA, and it's not happening to me.
The more the big guys push the small guys out of business, the more this kind of crap is going to happen...
look at that... it still worked.
I wonder if comcast decided to server your request when it could not resolve your dns server?
Hmm. I RTFA and it appears that the author's beef is that Comcast is responding where the responder is non-existent.
To replace unresolved DNS lookups with IP addresses of ad servers, Comcast has to proxy port 53 traffic, yes?
Well, if they do that, they can certainly redirect to their own DNS resolvers if the specified DNS resolver is non-responsive, just as easily as they can substitute an IP address when the specified resolver fails to resolve.
They can also redirect all port 53 traffic to their resolver, always, but it does not appear that they are doing this.
That doesn't strike me as evil as the article suggests. Still, they should disclose that they do this.
In Liberty, Rene
I wonder if a business class versus a home/residential version of Comcast service makes a difference.
And which one the guy used?
So I'm thinking... ok, if Comcast hijacked your dns, why would they send it to an earthlink IP?
So I navigate to 207.69.131.9...
And I get javascript redirecting me to:
http://earthlink-help.com/main?AddInType=Bdns&Version=1.4.11&FailureMode=1&ParticipantID=xj6e3468k634hy3945zg3zkhfn7zfgf6&ClientLocation=us&Referer=&FailedURI=http%3A%2F%2F207.69.131.9%2F&SearchQuery=
Where I get some kind of branded search and this:
I'm not sure why Comcast would redirect you to Earthlink in the first place... but even if they did, I seriously doubt they'd redirect you to a search for pr0n in particular. Time to dig a little more.
I wonder if this could be caused by NAT boxes interfering with DNS.
I know my Netgear Wireless router does strange things with DNS requests but I never tried to verify what was going on.
It is simply wrong, misleading, and unworthy of slashdot
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.
I am using OpenDNS with Comcast here in Portland, OR because their DNS servers are way freaking slow. All indications seem to be that it is working correctly.
I am interested in signing up for your TRON fanzine. Please advise, is it a monthly, or a quarterly?
I don't care why you're posting AC
Howard County, MD. No problems using a specified DNS server.
First, I hate comcast. I have a lot of reasons to hate comcast. I wish they would just go away. their service sucks, their support sucks, and well if they wanted to suck .... I would be worried about the horrible deadly diseases they would carry.
Anyways. I understand for the geek this sucks, but for the average home user, I think this is a good thing. How many less computers will be hijacked due to not being redirected to some rogue site? How many clueless people will not give up their bank account information to scammers because their dns couldn't be redirected?
I believe this is a necessary evil. I believe if they were doing it for legitimate reasons, they should have a choice to opt out for those in the clue.
Unfortunately as scammers/crackers(btw.. WTF? crackers? all scum bags who crack computers are white? What? :P) etc escalate because more and more retards are getting on the internet without having a clue how to protect themselves, this is going to become more and more of a norm.. isps "trying to protect you from yourself".
Think of it as getting a ticket for not wearing a seat belt. Supposedly it's to protect you from yourself.. but in reality it is to earn more money, and take away your control over your life.
Let the flamebait flow!
Hmm, in reflection, Comcast does not have to proxy port 53 to replace unresolved domains with their own IP address -- the resolvers can do this, and using alternate resolvers avoids the annoyance.
Comcast could proxy port 53 and do as I described above, which would be "less evil" than what the article claims, but as others note, they don't even seem to do that.
In Liberty, Rene
Rogers Cable in Canada does this.
It's very annoying.
Perhaps he wanted to mask his IP? ;)
Pretty essential if he is running on HyperVM...
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
I had to put a different Verizon DNS into the Router to get them to stop hijacking my DNS. I was having VPN issues and issues with stuff running as http://localhost/ and then it got my attention... They all seem to monitor as much as they can, Seems like ISP = iSPY4NSA!!!
$20 says this guy's router is actually doing the hijacking and redirecting requests to the servers it receives via DHCP.
I got a different result here. Not sure why yet, but just because they appear to be blocking incoming UDP 53 doesn't really bother me as we are are using our static for a mail server and VPN. It's being blocked alright but as of right now I dunno how or why. You can't always trust applets like this.
--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.--
We have a firewall alright, but aren't hosting any web pages so that might just be it too.
I, for one, am absolutely astounded that /.'s editors would post some blog rant without fact checking it first... That would be irresponsible to the point of incompetent, something virtually unheard of around here.
It's not as if the original blog ranter said "Full disclosure: I dont know if its Comcast or Earthlink thats responsible for this behavior..." or anything. Screw it, he's not getting in the way of your Two Minute's Hate!
+1 history
You better watch out, there may be dogs about . .
YHBT. YHL. HAND.
http://n7.netalyzr.icsi.berkeley.edu/summary/id=ae8199f5-24744-ed002743-edf2-4f04-8f17
from the report:
"Direct UDP access to remote DNS servers (port 53) is allowed.
The applet was also able to directly request a large DNS response."
Conducted my own test based on how OpenDNS works. Changed my DNS server settings to OpenDNS (208.67.222.222 and 208.67.220.220) then tried to browse to a non-existent web page (http://comcast.sucks.com). Since it doesn't exist, I got the OpenDNS Guide search results page instead of a 404 or some other generic error. Unless someone can poke holes in this method, this pretty clearly indicates to me that Comcast is not doing anything sketchy with DNS requests, at least not in my geographic location (Sacramento, California); as always, your mileage may vary.
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
Wow it's nice to know that Comcast has both a twitter account and a brand new Slashdot account. Oh, it's most likely that you're an employee (maybe tech support), 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? If so, I'd suggest a listing on the main corporate 'contacts' page, so that it'd be easy to verify it as 'official'. Also, the DNS team (or even the guy on duty) might not be complicit in the skulduggery, so your assessment might not be correct.
The force that blew the Big Bang continues to accelerate.
Comcast user in California using OpenDNS with following ICSI Netalyzer results:
Result Summary
c-24-7-17-xxx.hsd1.ca.comcast.net / 24.7.17.xxx
Recorded at 15:13 EDT (19:13 UTC) on Tue, June 09 2009. Permalink. Transcript. Wildcard DNS content.
Noteworthy Events
Major Abnormalities
* We received unexpected and possibly dangerous results when looking up important names
Minor Aberrations
* Your DNS resolver returns results even when no such server exists
Address-based Tests
NAT detection: NAT Detected
Your global IP address is 24.7.17.xxx while your local one is 192.168.1.xxx. 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.
port sequence plot
DNS-based host information: OK
You are not a Tor exit node for HTTP traffic.
You are listed on the Spamhaus Policy Based Blacklist, meaning that your provider has designated your address block as one that should not be sending any email.
The SORBS DUHL believes you are using a dynamically assigned IP address.
Reachability Tests
General connectivity: OK
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.
Network Access Link Properties
Network latency measurements: Latency: 81ms Loss: 0.0%
The round-trip time (RTT) between your computer and our server is 81 msec, which is good.
We recorded no packet loss between your system and our server.
TCP connection setup latency: 98ms
The time it takes your computer to set up a TCP connection with our server is 98 msec, which is good.
Network bandwidth measurements: Upload 1.0 Mbit/sec, Download 6.5 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 1.0 Mbit/sec. This level of bandwidth works well for many users.
Your Downlink: We measured your downlink's receiving bandwidth at 6.5 Mbit/sec. This level of bandwidth works well for many users.
Network buffer measurements: Uplink 370 ms, Downlink 51 ms
We estimate your uplink as having 370
Comcast denies that it is doing this http://twitter.com/ComcastBonnie/status/2092813922
I use Comcast and OpenDNS. Everything is as it should be here (central Indiana).
I want a new quote. One that won't spill. One that don't cost too much. Or come in a pill.
Getting 'response from unautorized servers' when I do nslookup. The servers are comcast servers. Can't reach *lot's* of site, by the way, fine going via my emergency alternate route (dial in, just think of that!). Massachusetts located.
This seems like it's an Earthlink issue not a Comcast one if it exists at all. According to the blog he's in some sort of deal with Comcast + Earthlink service. He's getting Earthlink Adverts on non-existent pages. His DNS 'reroutes' are rerouting to an Earthlink page. If there's any truth to this it's because of Earthlink + Comcast and not Comcast on its own.
Comcast DNS is working as expected in Upstate NY, I use OpenDNS from home (comcast cable service) and all is working as expected I can review my open dns logs and see that it is indeed serving me dns.
(Comcast, North of Boston)
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 in 2003 and Warner Music Group in February 2004. It is not a cable company; it spun off Time Warner Cable in March 2009.
This information is false, we do not intercept port 53 traffic. The author of the linked blog should post their complete nslookup results, not the edited text they have posted. We'd also like to know what NAT is being used (some of those proxy DNS in odd ways). Jason Comcast National Engineering & Technical Operations
My DSL line is physically leased by earthlink from covad. I use opendns, no redirection away from opendns.
I personally use the "worse than Hitler" meme all the time. When highway crews block a road and back up traffic I refer to them as worse than Hitler. When my landlord said I had to put my garbage can somewhere else I referred to him as worse than Hitler. My fiance has even sometimes jokingly said that I am worse than Hitler when I make some small infraction just because I use the phrase all the time.
I personally consider it an expression of emotion rather than a logical statement.
Cow Cube
Sounds like more of the same...
http://www.gucomics.com/comic/?cdate=20090527
I don't trust DNS.
My /etc/hosts is REEEEEEEEEEEEEEAAAAAAAAAAAALLLLLLLLLLLLLLLLY long.
Every once in a while, a site doesn't work anymore.
When that happens, I call my parents to get the new IP address.
they can certainly redirect to their own DNS resolvers if the specified DNS resolver is non-responsive
The responder wasn't non-existent, the responder was simply non-responsive. The active listen on port 53 should have caught any attempt by Comcast to see if it was a "real" DNS server. To do what you describe, they still would have had to send something to the specified DNS server, which apparently never happened.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Assuming your using a standard switch as you gateway device it would be much easier to simply setup the DNS servers to listen on an alternate port. VPN (which I'm assuming you use for other things too) in most cases would be over-kill. In fact a simple iptables rule could handle the port redirect on the listening dns server.
Quack, quack.
I'm in the Portland, Oregon area. Tag: kdawsonfud.
Don't blame me -- I voted for Roslin.
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 as of 31 Dec 2008. Too bad.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
With that attitude, one could could also say, "After all, one only needs EMacs regardless if it is on Unix based computer or even almost ready for the desktop Pre MS Windows 7 OS's
http://koitsu.wordpress.com/2009/06/09/comcast-isnt-messing-with-my-port-53-traffic/
It does indeed do its job very well. It crashes faster than an other OS that I have ever used.
All of us power users have all the IPs memorized.
Only his tendency toward a dazed stupor prevented him from screaming aloud.
[root@localhost ~]# nslookup slashdot.org
Server: 208.67.222.222
Address: 208.67.222.222#53
Non-authoritative answer:
Name: slashdot.org
Address: 216.34.181.45
So primary the root zone for yourself and don't use their DNS. They can't intercept DNS requests to 127.0.0.1
The root zone is just a bunch of pointers to the TLD servers that have all the big files and the root zone is tiny.
Just declare yourself authoritative for . and use the root zone of your choice. The legacy one is at : ftp://rs.internic.net/domain/
Need Mercedes parts ?
having your own police helps.
"I haven't RTFM..."
I'd suggest first RTFM, and then you'll be prepared to RTFA.
Yes, the comments here DO say a lot. And how you got modded +5 is beyond me.
You are now a level -1 Flaimbait.
If it was hard to write it should be hard to read.
ok, I already know it is like a train station but for ships. However, I am still looking online describing what is a port (i.e. Port 53, Port 80, 88, etc.).
Probably a bi. Monthly. Bi-monthly.
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.74.164, which resolves to npls-cns02.bonitasprngs.fl.naples.comcast.net.
DNS resolver properties: Lookup latency: 130ms
Your ISP's DNS resolver requires 130 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.
port sequence plot
DNS lookups of popular domains: OK
74 of 74 popular names were resolved successfully. Show all names.
In the following table reverse lookups that failed but for which a Start Of Authority (SOA) entry indicated correct name associations are shown using an "X", followed by the SOA entry. Absence of both IP address and reverse name indicates failed forward lookups.
Name IP Address Reverse Name/SOA
www.abbey.co.uk 165.160.13.20 X (pdns1.cscdns.net)
ad.doubleclick.net 74.125.242.24 iad09megaadvi[...]ubleclick.net
www.alliance-leicester.co.uk 194.130.105.121 X (alice.ioko365.com)
www.amazon.com 207.171.166.252 166-252.amazon.com
www.ameritrade.com 204.58.27.121 beta-new.tdameritrade.com
www.bankofamerica.com 171.161.161.173 www.bankofamerica.com
www.bankofscotland.co.uk 195.171.171.21 X (ns0.bt.net)
www.bankofthewest.com 207.114.194.101 X (dns1a.bankofthewest.com)
www.barclays.co.uk 213.219.1.141 X (dns1.lon7.telecityredbus.net)
www.capitalone.com 208.80.50.112 X (chia.arin.NET)
www.careerbuilder.com 208.82.7.22 X (smokey.careerbuilder.com)
www.chase.com 159.53.60.105 X (ns1.jpmorganchase.com)
chaseonline.chase.com 159.53.64.54 resources-cdc2.chase.com
www.citi.com 192.193.232.227 X (ns.citicorp.com)
www.citibank.com 192.193.232.227 X (ns.citicorp.com)
www.citimortgage.com 192.193.103.118 X (ns.citicorp.com)
www.cnn.com 157.166.226.26 www.cnn.com
www.desjardins.com 142.195.128.44 desjardins.com
www.deutsche-bank.de 217.73.49.24 www.deutsche-bank.de
www.e-gold.com 209.200.169.10 unknown.prolexic.com
www.ebay.com 66.135.217.243 hp-core.ebay.com
www.etrade.com 12.153.224.22 etrade.com
www.f-secure.com 96.17.147.114 a96-17-147-114.[...]echnologies.com
www.facebook.com 69.63.186.31 www.13.06.ash1.facebook.com
www.fdic.gov 192.147.69.84 www.fdic.gov
www.friendfinder.com 208.88.180.81 X (ii53-30.friendfinderinc.com)
www.geocities.com 98.137.46.72 intl1.geo.vip.sp2.yahoo.com
www.google.com 74.125.65.103 gx-in-f103.google.com
www.halifax.co.uk 212.140.245.97 halifax.co.uk
www.hsbc.co.uk 193.108.74.126 X (ns3.hsbc.com)
www.irs.gov 96.17.147.97 a96-17-147-97.d[...]echnologies.com
www.jpmorganchase.com 159.53.60.166 X (ns1.jpmorganchase.com)
www.lloydstsb.com 193.34.230.181 X (ns2.lloydstsb.co.uk)
mail.google.com 209.85.133
They're using their grammar skills there.
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.
because interfering-exploiting DNS(can't wait 4 imes, where DNSSec infrastructure are become mandator ISP license aquiring(&Native IPv6 perhaps !)) easiest way to build botnets and/or use ISp 4 inteligency gathering. i mean, this case must be investigated by NSA, not FTC.
At least for Comcast in zip 20190:
$ nslookup
> insomniaccoder.com
Server: 208.67.222.222
Address: 208.67.222.222#53
Non-authoritative answer:
Name: insomniaccoder.com
Address: 72.32.231.8
That's one of the two OpenDNS servers on port 53. Unless Comcast is faking/proxying/whatever the traffic and responding with OpenDNS' IP address.
Pedro
----
The Insomniac Coder
I'm a Comcast user in Lancaster, MA. I had no problems connecting to anything, and my DNS was not being tampered with. The only blocked services were Windows networking ports (135, 139, 445).
I took out my last subnet
s/subnet/octet/
Bring back Sirius Punk!
Uh, "non-authoritative response" is what you always get (according to the RFCs) when the response came from a resolver's cache, as opposed to directly from the authoritative nameservers.
This factoid neither confirms nor denies whether Comcast is hijacking DNS transactions.
As for not being able to reach "*lot's* [sic] of site[sic]", since you haven't specified whether the DNS lookups are failing, this could be a totally separate problem/issue.
Verified not happening here via Comcast in Key West.
Enough said.
Seriously, if you're going to copy/paste, at least try one that bothered to, I don't know, at least spell properly. Web sights? Really?
Don't thank God, thank a doctor!
I was originally Earthlink dialup (I lived in a VERY rural area in California), moved to Mississippi where it became TW. TW got replaced about 2 years ago or so by Comcast. My results appear clean: 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.74.165, which resolves to npls-cns03.bonitasprngs.fl.naples.comcast.net. DNS resolver properties: Lookup latency: 170ms Your ISP's DNS resolver requires 170 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. port sequence plot DNS lookups of popular domains: OK 74 of 74 popular names were resolved successfully. Show all names. In the following table reverse lookups that failed but for which a Start Of Authority (SOA) entry indicated correct name associations are shown using an "X", followed by the SOA entry. Absence of both IP address and reverse name indicates failed forward lookups. Name IP Address Reverse Name/SOA www.abbey.co.uk 165.160.15.20 X (pdns1.cscdns.net) ad.doubleclick.net 209.62.176.153 eqnjmegaadvip3.doubleclick.net www.alliance-leicester.co.uk 194.130.105.121 X (alice.ioko365.com) www.amazon.com 72.21.207.65 X (ddiamond.amazon.com) www.ameritrade.com 204.58.27.97 beta-new.tdameritrade.com www.bankofamerica.com 171.159.65.173 www.bankofamerica.com www.bankofscotland.co.uk 195.171.171.21 X (ns0.bt.net) www.bankofthewest.com 207.114.194.101 X (dns1a.bankofthewest.com) www.barclays.co.uk 213.219.1.141 X (dns1.lon7.telecityredbus.net) www.capitalone.com 208.80.50.112 X (chia.arin.NET) www.careerbuilder.com 208.82.5.22 X (smokey.careerbuilder.com) www.chase.com 159.53.60.105 X (ns1.jpmorganchase.com) chaseonline.chase.com 159.53.64.54 resources-cdc2.chase.com www.citi.com 192.193.232.227 X (ns.citicorp.com) www.citibank.com 192.193.217.200 X (ns.citicorp.com) www.citimortgage.com 192.193.103.118 X (ns.citicorp.com) www.cnn.com 157.166.226.25 www.cnn.com www.desjardins.com 142.195.128.44 desjardins.com www.deutsche-bank.de 217.73.49.24 www.deutsche-bank.de www.e-gold.com 209.200.169.10 unknown.prolexic.com www.ebay.com 66.135.200.145 hp-core.ebay.com www.etrade.com 12.153.224.22 etrade.com www.f-secure.com 96.17.74.131 a96-17-74-131.d[...]echnologies.com www.facebook.com 69.63.184.31 www-11-01-ash1.facebook.com www.fdic.gov 192.147.69.84 www.fdic.gov www.friendfinder.com 208.88.180.81 X (ii53-30.friendfinderinc.com) www.geocities.com 98.137.46.72 intl1.geo.vip.sp2.yahoo.com www.google.com 209.85.165.99 eo-in-f99.google.com www.halifax.co.uk 212.140.245.97 halifax.co.uk www.hsbc.co.uk 193.108.74.126 X (ns3.hsbc.com) www.irs.gov 96.17.75.10 a96-17-75-10.de[...]echnologies.com www.jpmorganchase.com 159.53.60.166 X (ns1.jpmorganchase.com) www.lloydstsb.com 193.34.230.181 X (ns2.lloydstsb.co.uk) mail.google.com 209.85.165.18 eo-in-f18.google.com mail.live.com 64.4.20.169 dp2.mail.live.com mail.yahoo.com 209.191.92.114 l2.login.vip.mud.yahoo.com www.mbna.com 209.135.59.10 X (ns1.usi.net) www.mbna.net 209.135
Direct UDP access to remote MSSQL servers (port 1434) is blocked.
This is most likely due to a filtering rule against the Slammer worm
Direct TCP access to remote SMTP servers (port 25) succeeds, but does not return the expected content.
Direct TCP connections to remote POP servers (port 110) succeed, but do not receive the expected content.
Direct TCP connections to remote IMAP servers (port 143) succeed, but do not receive the expected content.
Your ISP's DNS server returns IP addresses even for domain names which should not resolve. Instead of an error, the DNS server returns an address of 63.251.179.56, which does not resolve. You can inspect the resulting HTML content here.
And people were worried about comcast messing with their stuff
I've been a Comcast residential high-speed customer since it came out here in 2001. Between 2003 and 2005, their DNS servers would fail all the time, so I went into the router and changed the DNS servers to the "for off-campus use" DNS servers of my local university. Worked like a charm.
The problem is since long gone. I might get blasted for saying this, but I've actually had really good luck with Comcast high-speed Internet.
The only part that sucks? Back in 2001 when it was Excite@home, there was no speed cap sent to the modem, and 7 mbps was commonplace. Today, my modem is capped at 6.6 mbps, and I typically get around 5 in a speed test.
We're also on Comcast in Cali and use 3rd party DNS.. without issue. Comcast isn't messing with any of our port 53 traffic either: 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 209.244.1.19, which resolves to ics3.SanJose1.Level3.net. DNS resolver properties: Lookup latency: 120ms Your ISP's DNS resolver requires 120 msec to conduct an external lookup, and 110 msec to lookup an item in the cache. Your resolver is using QTYPE=A for default queries. Your resolver is not automatically performing IPv6 queries. Your DNS resolver requests DNSSEC records. Your DNS resolver will accept DNS packets of up to 4096 bytes. Your DNS resolver can successfully receive a large (>1500 byte) DNS response. Your resolver does not use 0x20 randomization, but will pass names in a case-sensitive manner. Your ISP's DNS resolver respects a TTL of 0 seconds. Your ISP's DNS resolver respects a TTL of 1 seconds. DNS glue policy: OK Your ISP's DNS resolver does not accept generic additional (glue) records -- good. Your ISP's DNS resolver accepts additional (glue) records for nameservers located in subdomains of the queried domain. 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. port sequence plot DNS lookups of popular domains: OK 74 of 74 popular names were resolved successfully. Show all names. In the following table reverse lookups that failed but for which a Start Of Authority (SOA) entry indicated correct name associations are shown using an "X", followed by the SOA entry. Absence of both IP address and reverse name indicates failed forward lookups. Name IP Address Reverse Name/SOA www.abbey.co.uk 165.160.13.20 X (pdns1.cscdns.net) ad.doubleclick.net 209.62.176.153 eqnjmegaadvip3.doubleclick.net www.alliance-leicester.co.uk 194.130.105.121 X (alice.ioko365.com) www.amazon.com 72.21.210.250 210-250.amazon.com www.ameritrade.com 204.58.27.97 beta-new.tdameritrade.com www.bankofamerica.com 171.161.161.173 www.bankofamerica.com www.bankofscotland.co.uk 195.171.171.21 X (ns0.bt.net) www.bankofthewest.com 207.114.194.101 X (dns1a.bankofthewest.com) www.barclays.co.uk 213.219.1.141 X (dns1.lon7.telecityredbus.net) www.capitalone.com 208.80.50.112 X (chia.arin.NET) www.chase.com 159.53.60.105 X (ns1.jpmorganchase.com) chaseonline.chase.com 159.53.60.54 resources-cdc1.chase.com www.citi.com 192.193.217.200 X (ns.citicorp.com) www.citibank.com 192.193.217.200 X (ns.citicorp.com) www.citimortgage.com 192.193.218.222 X (ns.citicorp.com) www.cnn.com 157.166.224.26 www.cnn.com www.desjardins.com 142.195.128.44 desjardins.com www.deutsche-bank.de 217.73.49.24 www.deutsche-bank.de www.e-gold.com 209.200.169.10 unknown.prolexic.com www.ebay.com 66.135.200.145 hp-core.ebay.com www.etrade.com 12.153.224.22 etrade.com www.f-secure.com 8.18.65.65 X (ns2.Level3.net) www.facebook.com 69.63.180.12 www2.02.07.facebook.com www.fdic.gov 192.147.69.84 www.fdic.gov www.friendfinder.com 208.88.180.81 X (ii53-30.friendfinderinc.com) www.geocities.com 98.137.46.72 intl1.geo.vip.sp2.yahoo.com www.google.com 74.125.155.99 px-in-f99.google.com www.halifax.co.uk 62.172.43.225 www.halifax.co.uk www.hsbc.co.uk 193.108.74.126 X (ns3.hsbc.com) www.jpmorganchase.com 159.53.60.166 X (ns1.jpmorganchase.com) www.lloydstsb.com 193.34.230.181 X (ns2.lloydstsb.co.uk) mail.google.com 74.125.155.17 px-in-f17.google.com mail.live.com 64.4.20.174 dp1.mail.live.com mail.yahoo.com 66.163.169.186 l1.login.vip.sp1.y
PPN
Tried it from northwestern Washington-state to California. No problems.
They're not redirecting DNS in my area of North Florida, but
Apart from their God-awful downtime (about an hour a day at around 3am EST)... ...and 1-hour almost instant disconnect if you're participating in a torrent they've flagged as unacceptable... ...and terrible upstream speeds (about 45k / sec after the first 3 second burst)... ...and random massive latency... ...and questionable traffic shaping... ...and "not really" unlimited internet...
They're ok-ish. Apart from being FUCKING EVIL. That said, the local cartel apparently hasn't gotten the same memo that caused TFA's seizure.
Ok, they suck compared to, say, Speakeasy in the old days, but AT&T hasn't upgraded infrastructure in my neighborhood to support DSL, so Comcast is quite literally the only game in town. Yeah, I'm 5 miles outside of downtown and I can't get DSL here because up until a few years ago only poor folk lived in these old houses and it wasn't worth the time. Same reason there's no cable underground in Jacksonville's downtown... Cox cable (at the time) decided only poor folks lived there in the 70s when they last dug up the streets.
Anyhow, apart from blocking non-comcast SMTP, here's all Netalyzer anomalies:
RPC (Port 135) blocked
NetBIOS (Port 139) blocked
SMB (Port 445) blocked
DNS resolver (Comcast DNS): 1700ms (!!!)
Nothing I'd flag as unacceptable apart from the DNS latency. I learned to get my own SMTP host on an alternate port years ago as blocking port 25 is standard procedure on most ISPs.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
From TFA:
"(Full disclosure: I don't know if it's Comcast or Earthlink that's responsible for this behavior, but Comcast is who I pay for internet access, so I'm blaming them for now, even though it's obvious Earthlink is involved)."
Later in article:
"The astute reader will notice that the addresses returned are those of the Earthlink host-not-found advertising page."
Sounds like it's Earthlink doing this (atleast, from a technical standpoint. At OSI layer 8 = business/political layer, it could be an agreement between the two of them). I understand why there might be some bad feeling against Comcast based on previous episodes, but based on your description it sounds like Comcast is just providing the last mile of connectivity and the actual IP communication with the Internet is Earthlink's piece (since they're your ISP). Comcast is just handling billing (and last mile cabling / layer 2 linkage). Taking it up with Comcast might still be useful in resolving the issue, but it sounds like they'd be the middlemen in this scenario.
Sorry this isn't re: Comcast, but I fired Comcast from providing my home cable service back in about 2003 since they wanted to put me on a NATted segment of their network on an RFC 1918 IP address. Ever since moving to Wide Open West, aka Wowway.com, traffic destined to my machine on port 53 from outside their network has been blocked. I don't pay extra for server connectivity, so I take my chances. Nevertheless, I've operated a hobby mail server sampling spam since being connected.
I run OpenDNS and we have about 12,000,000 end users. A large number of those are comcast users. We would know if this was true, and we haven't had a single report about it.
I also know a few /really smart/ people in the Comcast engineering department who run their DNS infrastructure. These guys wouldn't do something like block port 53.
Based on the above, there is no truth to this rumor from what I can tell and from those I've talked to. I think an update on this story is warranted.
The comcast engineering team pride themselves on running a great network and robust infrastructure and I think they do a pretty good job (though of course I'm biased and think OpenDNS does a better job on the DNS side of the house) :-)
-David
# Hack the planet, it's important.
https://ws.arin.net/whois/?queryinput=!%20NET-69-253-0-0-1
CIDR: 69.253.0.0/16
NetType: Reassigned
Out of this larger block:
https://ws.arin.net/whois/?queryinput=!%20NET-69-240-0-0-1
I'm thinking it could be the smaller provider with that /16 that is proxying DNS instead of comcast itself, possibly a small company that is leasing this and using some filter software of their to keep employees from browsing NSFW sites.
http://netalyzr.icsi.berkeley.edu/restore/id=43ca253f-12250-938258b8-71f4-4051-9c5a
I wouldn't mind so much if comcast's DNS servers didn't break on a regular basis. I use a different DNS because I got sick of waiting for theirs to come back up during some stupid 1am maintenance schedule. Why can't they do the maintenance at noon when housewives are on and hackers are sleeping?
“Common sense is not so common.” — Voltaire
c-76-123-201-223.hsd1.va.comcast.net / 76.123.xxx.xxx Your global IP address is 76.123.xx.xx while your local one is 192.168.xx.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. port sequence plot DNS-based host information: OK You are not a Tor exit node for HTTP traffic. You are listed on the Spamhaus Policy Based Blacklist, meaning that your provider has designated your address block as one that should not be sending any email. The SORBS DUHL believes you are using a dynamically assigned IP address. Reachability Tests General connectivity: Note Basic UDP access is available. Direct UDP access to remote DNS servers (port 53) is blocked. The network you are using appears to enforce the use of a local DNS resolver. Direct UDP access to remote MSSQL servers (port 1434) is blocked. This is most likely due to a filtering rule against the Slammer worm. 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.
Never mind, your behind a NAT. That could be doing it.
http://netalyzr.icsi.berkeley.edu/restore/id=ae8199ad-23094-f50550b1-c25f-4332-87fe Seems like OpenDNS is working OK for me.
Try browsing to http://207.69.131.9/
I am getting...
"We are sorry, porn cannot be found.
We suggest that you check the spelling of the web address or try a different search term."
I did not search for anything.........
http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-12268-d90b4111-dd9a-4663-ac6d
Currently in Peachtree City Georgia, Comcast triple play service - across wifi 2 stories away from base in concrete apt. structure
"It's the Law of the Universe, and I'm the sheriff." Slash-cott 2/10-2/17
This is what I have. I figure the service is about the same for a whole bunch of small cities just north of Chicago, so I'm putting down the county rather than the specific city for my location. (Also I think most of the stuff that is blocked is due to my router settings. I don't see a reason to have ports open if I'm not actively using them.)
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.
http://netalyzr.icsi.berkeley.edu/restore/id=4b65af4b-21402-5204573b-cf62-4504-84c7 permalink from the ICSI Netalyzr from a comcast user in Utah. Doesn't show any DNS issues.
I do however, know that comcast is fail, and unreliable as shit.
This proof now that there is a need for a new internet and to go back to the mom and pop providers that don't pull all of this bull crap. I miss the days of my small ISP where I could call them and get helpful, friendly tech support instead of having to navigate the myriad of voice prompts and CSRs that barely speak English. I am all for the creation of new internet to go back to the ways of no regulation, no service tiering, and a completely neutral internet.
Comcast has always been a dog that likes to test the fences and then gets slapped down. Remember their infamous "filter" that was forcibly shut down? They want to see what they can get away with. They'll fight and growl but if enough people notice and threaten to complain to the FCC or some other government agency, they'll stop.
Fact. I also got the same message. No search for porn on my end either. Check the redirected querystring; "&SearchQuery=" it's blank. This, if it's a registered earthlink IP, is something THEY are doing. :)
This actually makes for a better headline than the actual one. I was just logging in after work to comment on why is this even still here? We've made ComcastBonnie's poor damn day miserable because some /b/tard got all click-happy on his keyboard. She probably didn't want in the least to deal with DNS hijacking, Port 53, 'redirection', 'filtering' or any of this.
c-24-0-249-85.hsd1.pa.comcast.net / 24.0.249.85
http://n17.netalyzr.icsi.berkeley.edu/summary/id=43ca3cda-24640-2921bc58-01af-4d27-a12e
is the permalink for me from that test.
I think hahaha. I used to be big into computers, not so much anymore.
That's what pre-med'll do to you.
K. Holland
kt.holla1@gmail.com
$ nslookup
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached
> server 207.69.131.9
Default server: 207.69.131.9
Address: 207.69.131.9#53
> comcast.sucks.com
> server www.microsoft.com
Default server: www.microsoft.com
Address: 207.46.193.254#53
Default server: www.microsoft.com
Address: 207.46.192.254#53
> comcast.sucks.com
>
So when I point lookups at the comcast ad servers even, or Microsoft, the lookups fail. Might be because we are on a business account here (to get a block of static IPs) but if our own captive ISP DNS servers are not reachable we'd have problems as we have some internal non-standard stuff going on for our internal networking. Our faked top level domain for our non-routable machines just would not show up. Again, might be because we are business clients of Comcast, but they have done all sorts of things like capped our bandwidth, excessively applied traffic shaping, etc. (corrected with a phone call mentioning we are business clients and _they_ committed to the usage rates we subscribed to.) But other than a few glitches we've been pretty happy with their service.
One check for the original author. Are the DNS servers "recommended" at your install time in an Earthlink domain or Comcast one.
- Tjp
I am in wallow with my inner money grubbing capitalistic pig. ... Oink!
I rean the Netalyzr test and this is what I got.
http://n12.netalyzr.icsi.berkeley.edu/summary/id=ae8186a4-26161-bcbcc8bc-23a1-4c30-b4f9
It's information from a Comcast rep that could clear the company's name, potentially.
It is not fair of Slashdot to call a company evil if they don't ensure that clarifying/corrective information is also made prominent, if it is available.
I posted this and the only red there is the pop server and that was caused by my software firewall. So, the yellow warnings I believe probably also are caused by my software firewall. I really wouldn't want these ports open to the outside network anyway.
The editors should be a lot more careful about fact checking when posting stories like this. If it turns out to be false, and damaging to Comcast's business due to the amount of Slashbots ranting about how much they hate the ISP, Slashdot's parent company could be looking at a lawsuit from Comcast for libel; and IMHO, they'd be within their rights.
The anti-Capitalist bias on this site truly is genuinely appalling, and it highlights yet again the complete lack of integrity inherent in the double standard that Stallman has indoctrinated into his minions. Corporations doing the wrong thing doesn't give us carte blanche to likewise behave badly. If anything, it's exactly the opposite.
Here is my results from netalyzr:
Result Summary
c-68-53-176-XXX.hsd1.in.comcast.net / 68.53.176.XXX
Recorded at 19:46 EDT (23:46 UTC) on Tue, June 09 2009. Permalink. Transcript.
Noteworthy Events
Major Abnormalities
* No DNS Port Randomization
Minor Aberrations
* Certain protocols are blocked in outbound traffic
* Your computer's clock is slightly slow
Address-based Tests
NAT detection: NAT Detected
Your global IP address is 68.53.176.XXX while your local one is XXX. 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.
port sequence plot
DNS-based host information: OK
You are not a Tor exit node for HTTP traffic.
You are listed on the Spamhaus Policy Based Blacklist, meaning that your provider has designated your address block as one that should not be sending any email.
The SORBS DUHL believes you are using a dynamically 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: 46ms Loss: 0.0%
The round-trip time (RTT) between your computer and our server is 46 msec, which is good.
We recorded no packet loss between your system and our server.
TCP connection setup latency: 48ms
The time it takes your computer to set up a TCP connection with our server is 48 msec, which is good.
Network bandwidth measurements: Upload 7.4 Mbit/sec, Download >20 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 7.4 Mbit/sec. This level of bandwidth works well for many users.
Your Downlink: We measured your downlink's receiving bandwidth at >20 Mbit/sec. This level of bandwidth works well for many users.
Network buffer measurements: U
Three Mobile Prepaid Broadband in Australia does this.
Upon connecting, a prepaid user gets an RFC1918 address. All TCP traffic is NAT'ed. All DNS requests are not NAT'ed, they are proxied through three's caching nameserver.
The problem with that is it causes hell for any caching nameserver at the client end. The client's nameserver expects to talk to the authoritative nameservers for whatever domain it looks up. It sends requests with the RD (Recursion Desired) bit cleared, because an authoritative nameserver does not need to use recursion to look up a name.
Three's proxy nameserver sees the cleared RD bit and, if the requested data is not already in the cache, returns an NXDOMAIN error to the client. It makes the client unable to resolve most domain names.
I'm on Comcast in central California. Random character URLs and typos are all resolving via correctly OpenDNS, which is configured on my router.
http://n18.netalyzr.icsi.berkeley.edu/summary/id=ae817952-25497-39a13fe0-7769-4072-beae All seems fine to me. So if you really want to test this.. Change your resolver to 70.88.178.97 (Comcast Business IP) and then attempt to lookup some name such as http://atlantic.ocean/ or http://www.servers.ucann2/ The second page is a parked page which is correct, the first page should give you a ftp style listing, if you do not get either of these pages, then you may be experiencing this type of hijacking. But I highly doubt this would be performed on commercial accounts, maybe residential. David - UCANN2
David Scott UCANN2
ICSI link from Augusta: http://netalyzr.icsi.berkeley.edu/restore/id=43ca3cda-24704-6729e1f9-944a-4263-9b69
"During times of universal deceit, telling the truth becomes a revolutionary act" -- George Orwell
http://netalyzr.icsi.berkeley.edu/restore/id=ae819c33-24534-54c0c922-5d71-4950-9aea
Everyone that has reported this problem has a Comcast account that is somehow lined with Earthlink service. Even the linked article says so. Why don't we investigate that route? Did Comcast buy out Earthlink recently? Is there some kind of cross-promotional service where you buy from Earthlink over Comcast infrastructure? They fit into this somehow...
CAn'T CompreHend SARcaSm?
it's really sad that, not only are Slashdotters foolish enough to post a results page with their own IP in them, but also that the advice to do so was given by a Slashdot editor!
We've been modded as Flamebait for months when criticizing this guy but... but I mean....really? REALLY? *facepalm*
If I was a subscriber, I'd be canceling. Taco should be pissed, and you should be ashamed of yourselves for posting those Netalyzr direct URLs unless you're testing from a business with a public IP address; and really if we're talking about Comcast home accounts, what good is that?
CAn'T CompreHend SARcaSm?
I haven't had time to re-test to find out what my current situation is, but I can tell you that I have experienced COMCAST mucking up my DNS traffic in the past.
I have a Linux server on my local network that acts as a caching DNS for all of my client machines. Several months ago I found that there were large holes in my internet access (including for some reason, most hotels in Las Vegas... I was planning a vacation).
I have 2 separate internet connections to my house, one from COMCAST and one from QWEST. I did not do significant detective work when I had the problem. I used some online DNS tools to verify that the sites had good DNS entries (when not querying through COMCAST), I then accessed them with IP addresses successfully, SO, I went to my router and added a rule for all port 53 traffic to go over the QWEST connnection and (surprise)... everything worked!
I chalked it up to something being messed up on COMCAST's network and not a nefarious plot; I left the rule in to direct all of the port 53 traffic out the QWEST connection and I haven't had a similar problem since.
Nuke
Well, there may be another motive to this original post than has been discussed here.
And it's sinister too.
In order to run the suggested test which the OP requests, one must allow the "Netalyzer" JS access to your machine. And that is an excellent way to investigate and acquire "interesting" data on people. Does this ring any bells??
So now Netaylzer people will have an interesting list of Slash-dotters who are concerned about this & Comcast issues in general. Ah at least then we will be safer than before we had that list of subversive "Slash-dotters".
Wonder where htey will use this newly acquired information. ????
While we're on the topic of DNS, could someone please tell the DNS folks at Cox Cable that it's really rude to arbitrarily rewrite all TTLs to 30 seconds.
There's a reason why some people set their TTLs to higher than 30 seconds. Fortunately, I have my DD-WRT box set to use OpenDNS' resolvers, which work well.
All of my attempts to inform Cox of their TTL issue have met with responses like "We've received your email regarding your difficulties in configuring your wireless router at home. Here's some instructions for configuring your wireless router..." even when I don't mention anything about a wireless network.
Is there any chance that this is done to thwart 'IP-over-DNS' attempts?
Many ISP's will forward port 53 traffic happily, even before a cable modem is provisioned. If you attempt to go to any site (port 80, etc.) it will redirect you to their provisioning page. But DNS requests work.
So there are tools to funnel *all* of your traffic through a tunnel on port 53, as fake DNS requests.
You need a DNS server on the other end as an exit for the gateway, and control over your domain to redirect the requests appropriately, but I've used it on unprovisioned modems in a pinch, and it does work. I wouldn't want to download Redhat ISO's over it, but for casual browsing when nothing else is available, it does work. (Not recommending the practice of course.)
I could see grabbing control of port 53 to avoid this tunneling (although it's doubtful it's widespread enough to warrant such work).
In general, I'm a bit mixed on the topic; I'm all for net neutrality, but to provide a good, consistent user experience, an ISP taking control of DNS requests (and cacheing) isn't too far out there. If they are redirecting things inappropriately, however, then that's an absolute no-no, and should be slapped down immediately...
Love many, trust a few, do harm to none.
I can confirm DNS is redirected from Comcast IP 76.115.5.109 in Salem, Oregon using NetCat to open a port on a server I have sitting in Seattle, Washington and verifying the port responds to a dig client sitting in Kent, Washington. The Seattle and Kent machines are not on Comcast's network.
If I allow Comcast's server to resolve my request (both existant and NXDOMAIN) the result is correct. If I try to force use of a specific resolver, my request never makes it to the resolver and times out.
using Comcast in CT.. OpenDNS.org for DNS service.. works flawlessly. Perhaps OP is the subject of a conspiracy targeting only him.
If this makes you feel any better, Verizon also does this and none of us really care.
My college is blocking outbound port 53
"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."
I once lamented/assailed in /. that /. can't expect to attain journalistic credibility, and responses came to me to the effect that i was crazy to expect credibility here.
So, to your lament(?), i say, Kojak would say, "It's about page hits/impressions, baby....."
Some of this kind of "story posting" my be considered the work of miscreants in many of the more respectable journals. Now, if the IEEE or some such entity takes hold of this story and watches comcast to see if this story is false, or if the story is breaking the lid off a clandestine, localized test (maybe comcast is doing something on behalf of the NSA? Maybe in exchange for immunity from ALL sorts of future investigation/prosecution/fines...), then we might have something to talk about....
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
In the Boston, MA area, I get these results from home (dynamic IP account plugged into a NAT switch):
> Direct UDP access to remote DNS servers (port 53) is allowed.
> Direct TCP access to remote DNS servers (port 53) is allowed.
Noteworthy Events
Major Abnormalities
We received unexpected and possibly dangerous results when looking up important names
Your DNS resolver returns results even when no such server exists
Minor Aberrations
Your computer's clock is slightly fast
Address-based Tests
NAT detection: No NAT Detected
Your global IP address is 98.141.97.123 and matches your local one. You are not behind a NAT.
Your machine numbers 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: OK
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 allowed. 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 allowed. 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: 46ms Loss: 0.0%
The round-trip time (RTT) between your computer and our server is 46 msec, which is good. We recorded no packet loss between your system and our server.
TCP connection setup latency: 48ms
The time it takes your computer to set up a TCP connection with our server is 48 msec, which is good.
Network bandwidth measurements: Upload 920 Kbit/sec, Download 4.7 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 920 Kbit/sec. This level of bandwidth works well for many users. Your Downlink: We measured your downlink's receiving bandwidth at 4.7 Mbit/sec. This level of bandwidth works well for many users.
Network buffer measurements: Uplink 300 ms, Downlink 69 ms
We estimate your uplink as having 300 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 69 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
I've noticed for some time that it seems whenever comcast dns is not working (and this is *very* frequent, for periods of 15 seconds to a minute, as often as not), that neither do any other dns servers. I ran a test just now, periodically doing lookups through comcast and through 4.2.2.1, and there appeared to be a very high correlation between failures of the two. At the same time, I was also running a ping out to google, and it never missed a beat. This would suggest that either comcast is proxying dns traffic, or does some weird traffic shaping on port 53.
I'm a comcast customer from Indiana with a "sticky" ip, though not a true static. It appears that they're messing with the DNS in my area
http://tinyurl.com/ncghzc
Comcast Residential in Minnesota. I use OpenDNS to filter the net here at home so the kiddies don't hit to much porn while trying to do homework. http://netalyzr.icsi.berkeley.edu/restore/id=482c3e43-1843-a5565296-caaa-42bf-819d
https://www.speakservers.com/
A quick search of information on Earthlink returned this:
http://en.wikipedia.org/wiki/Earthlink#DNS_and_filtering_controversy
Which links to a page with DNS servers that are unsupported and unfiltered... might pay for anyone affected to at least try them.
"If true, this is a pretty serious escalation in the Net Neutrality wars."
Now, you can either wait until Comcast say they do, or don't. You can wait until someone else says it's happening too. Or you can post it and let people say on the blog that they don't see it.
Now that last one won't happen UNLESS someone reports widely enough this accusation. Without wide reporting, if it's a local problem, it will get blown out of proportion since only local people will hear of it and check.
If it doesn't get widely reported, it won't be tested and it could stay unresolved. Then 2 years down the line someone will hear of this and say "In the past, Comcast has...". There's no proof it didn't happen, is there.
So slashdot HAS done the right thing.
Barnpot.
Though many others don't see the problem, so it likely isn't corporate wide if it exists at all.
But "proving" DNS works (which normally uses UDP) by showing ***TCP*** access is frigging stupid.
Hello i you want free comcast internet. goto a store buy a cable modem. do not subscribe the modem to comcast. plug the modem in. set it up. you will notice they gave you an outbound ip addy. now if you are on a router or your pc is directly hooked up goto any page. you will notice it redirected you to a self registration page. now on the pc/router change your dns server to 4.2.2.2 and 4.2.2.3 respectfully.
there you go free internet from comcast. nothing more than changing your dns. and if this works to get free inet then they are NOT screwing with your dns.
and to slashdot this site is getting worse by the day. all opinion articles.
starting to think you should rename the site to debatedot.org
buy modem. plug it in. do not register the modem with comcast. change your dns manually. free inet
goto a store. buy a cable modem. plug it into your comcast line. change your dns manually. your done free inet from comcast i believe the speeds are 5/1mbit or something along those lines but its free. with a bit of modem modification you can uncap your modem completely.
I got almost the same results, except for this:
Direct TCP access to remote RPC servers (port 135) is allowed.
Direct TCP access to remote NetBIOS servers (port 139) is allowed.
Direct TCP access to remote SMB servers (port 445) is allowed.
Can anyone tell me what that means?
Seriously? Did no one check the IP? The IP Whois shows that IP in the redirect is owned by Earthlink, not Comcast.
http://ws.arin.net/whois/?queryinput=207.69.131.9
I hate Comcast as much as the next person (almost drove across town to defecate on their desks I was so pissed), but they are clearly not at fault here.
I'm surprised the Comcast "engineers" didn't pick up on this; or at the very least their spokesperson (read: spokesgirl).
I just logged into the DNS server at my office via ssh and enabled djbdns on a public port. I opened the firewall to allow me to access it. Then on my home comcast account (consumer / not business) I ran host -t a comcast.com work.dns.com (fake name) and got back comcasts proper DNS entries. I then changed DNS for comcast.com on the temp DNS at work so that comcast.com would return an A record of 127.0.0.1 and from my home account I ran the same command. Our work systems our on a private metro ethernet provider who is not comcast but either way, my home computer on a residential comcast account connecting to a remote DNS server not on comcast and asking for the A record for comcast.com returned the address modified as I told it to in a way that comcast would never approve and it all went through fine so it seems comcast is not redirecting DNS in Miami, Florida.
I doubt even they would do it. I just blindly posted the data while forgetting "yeah were running a mail server and VPN but not web server". We just apparently didn't everything we didn't use blocked at the firewall. I did wonder about that network buffer thing though everything else seems OK from them 1500 ms is a lot? I think they are throttling that.
Network buffer measurements: Uplink 1500 ms, Downlink 100 ms
We estimate your uplink as having 1500 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large uploads at the same time.
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.
Dynamic IPs are not ``dynamic'' if one nevers gives up the lease. I have WOW (wide open west / http://wowway.com/ ) Internet and the only time my IP has changed is when our router was replaced (giving it a different client ID) and, of course, when I directly plugged my computer into a hub connected to the modem (to give it direct Internet access). Because WOW has blocked all UDP traffic on port 53, I have a gracious friend who has ComCast and serves my DNS. Comcast doesn't seem to change IPs unless if the router/DHCP client releases a lease. This means I essentially don't need to change glue records at all. But Comcast has seemed to more often supposedly required people to re-plug-in their modems and (I'm guessing only from slight experience) Comcast may have even forced an IP change upon one router I've had access to.
Has any other WOW user tested serving DNS? I sent a query to WOW people and they said:
Port 53 is reserved for internal WOW! network use only. Please try using an alternate port.
Thanks for the heads up on the link: comcastisfuckingwithyourport53traffic.wordpress.com. I should be getting a call from IT-Security any minute now...
Port 53 blocked. Comcast user in Plymouth MA
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
True, they'll use Ubuntu or any other Linux distribution from the last 8 or so years. You stick with Windows and let us know when you get your registry fixed.