Slashdot Mirror
Crowdsourcing Confirms: Websites Inaccessible on Comcast
My first clue came when a friend of mine set up the website http://www.helpmatt.org/ and asked her friends to donate. I said the website appeared to be down; they replied back that it was working fine for other people — and I narrowed it down to Comcast DNS servers not resolving the hostname www.helpmatt.org correctly. When I accessed the same website over my Frontier DSL connection, it worked. (I had recently signed up for Comcast cable Internet to save money over DSL, but I kept my DSL connection "just in case" something went wrong. At the time, I thought maybe I was being paranoid -- how hard could it be for a cable company to just run a straight Internet connection to my house and not screw anything up? Hollow laugh.)
I put out an informal survey to my Comcast-using friends, and a few of them said they couldn't access the website either. Still, I thought, this wasn't enough evidence that it was Comcast's fault; maybe the hostname was only resolving intermittently, and just by sheer coincidence it happened to be up when all of my non-Comcast-using friends tried it? I was about to do a more formal experiment, and recruit a larger sample of testers through Amazon Mechanical Turk to test whether the site was inaccessible to other Comcast users, when the problem spontaneously fixed itself and suddenly the website became accessible 100% of the time to everyone.
But, my curiosity had been piqued. Was there something wrong with Comcast's DNS servers -- whether deliberate or not -- that was causing other websites not to resolve correctly? I wrote a perl script to take a sample of websites -- part of the same list that I had used to find websites that were mis-blocked as 'pornography' by Smartfilter — and attempt to resolve them using both Comcast's main DNS server (75.75.75.75) and one of Google's public DNS servers (8.8.8.8). (You won't be able to do this experiment yourself unless you have a Comcast Internet connection, because while Google's DNS servers accept queries from anywhere, Comcast's DNS servers will refuse queries from any IP address not assigned to one of their customers.)
The script ran through a few hundred hostnames and flagged anything that failed to resolve on Comcast but resolved correctly on Google, although most of these were false positives caused by Comcast's DNS servers being temporarily unresponsive. But after running through the list of false-positives repeatedly, I found the first website that consistently failed to resolve on my Comcast Internet connection while resolving on Google: http://www.021yy.org/.
The website is for a second-hand furniture store in Shanghai; I have no idea what the domain "021yy.org" has to do with the business. (Perhaps the IP address that the domain name resolves to used to be occupied by a different website, and that IP address was inherited by the furniture store but the old hostname still points to it.) The hostname www.021yy.org resolves to the IP address 116.251.210.33 (for *ahem* non-Comcast users, that is), which according to the Asia Pacific Network Information Centre is part of a block of IP addresses assigned to a hosting company in Singapore. I'm not blocked from accessing the IP address of the website over Comcast; I can ping and send web requests to the IP address 116.251.210.33 with no problem. Only the hostname fails to resolve. (I can still access the site by using a VPN or a proxy server.)
So, I created a survey on Amazon Mechanical Turk, asking people three questions:
- Can you access the website http://www.021yy.org/?
- If you can't access the site, what error message does your browser give you?
- What provider are you using?
and offered 25 cents to every user who filled out the survey, up to a maximum of 50 people. Amazon Mechanical Turk, if you've never used it before, lets you create low-payment tasks and outsource them to a crowd of workers. Like any simple and powerful tool, it can be used for purposes that the original creators probably never imagined (presumably including this experiment), and someday I'd like to look into the most creative and bizarre things people have done with it. (Although, in this case, it seems like the site may not have done a great job of matching this task with available workers. Only 20 people filled out my survey in the 24 hours after I created it -- surely, out of all the available Mechanical Turk workers, there were more than 20 people who would have been interested in doing a simple website accessiblity check for 25 cents?)
20 unique users filled out the survey and reported:
- Out of the 14 non-Comcast users, 100% of them were able to access the site.
- Out of 6 Comcast users, 4 of them were blocked from accessing the site, and reported errors symptomatic of DNS failures ("Oops! Google Chrome could not find www.021yy.org" or "Server not found. Firefox can't find the server at www.021yy.org").
Even with such a small sample, that's enough to conclude that it's not a coincidence. (The real question is how two out of those six Comcast users were able to access the site at all. Maybe they're in a region of the country that's assigned different DNS servers. If I did the survey again, I'd ask people to include where they were living.)
So Comcast users -- at least some of them, probably most of them -- are blocked from accessing certain websites, which are perfectly accessible to users on other providers. I "only" had to test a few hundred domain names before finding one that would consistently fail to resolve on Comcast while resolving successfully on other companies' nameservers. With hundreds of millions of distinct websites "out there," if the same proportion holds, that would suggest that there about a million or more websites similarly affected. And that's not even counting all the other sites — like helpmatt.org, and also including some of the sites in my sample — which apparently resolve 100% of the time on other providers while sometimes failing to resolve on Comcast, but where the failure was not consistent enough to use them as a test case for the Mechanical Turk survey.
Unlike, say, the kerfuffle over Comcast threatening to de-prioritize content delivery from websites that don't pay them a fee, it's unlikely that Comcast is meddling with traffic intentionally here (especially since the sites' IP addresses are not blocked). It's more of a demonstration that if a company is sufficiently big and if it's sufficiently hard to prove that a problem is being caused on their end, the problem can exist for a long time without being solved. I called Comcast tech support after I discovered that sites were blocked on their network but not on other providers, and said that the problem really needed to be brought to the attention of the higher-ups, but tech support was adamant that it was impossible for a member of the public to reach anybody higher up than the call center.
Even if the number of affected sites is huge, at least it's only a small percentage of websites — I did have to run my script on a few hundred sites before I found one that appeared to be resolving on other DNS servers but not on Comcast. But that likely would have provided scant comfort to my friends who set up the helpmatt.org site, when they were urging people to visit the site and donate, and 25% of potential visitors were unable to reach the page. When it's your website, it's kind of a big deal.
Stop using your ISP's DNS
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
You can use downforeveryoneorjustme.com, though it will use its own DNS and routing so it will still require you to figure out which of those is the problem.
Wish I had mod points, I'd moderate you "informative".
You would if you made more interesting remarks than this.
Wish I had mod points, I'd moderate you "informative".
You would if you made more interesting remarks than this.
Wish I had mod points, I'd moderate you "insightful".
DNS deals with this issue using TTL (time to live) for the records it hands out. The Authoritative DNS server for the domain gives out the TTL it wants for every query it receives. Other non-authoritative DNS servers are supposed to throw away any record they cache once it reaches it TTL Now if you have TTL's measured in days, you lower the load on your DNS server, but any IP changes can take a long time to propagate. The trade off is that lowering the TTL increases the load on the authoritative server. So, there are going to be differences in resolved domains that will resolve themselves over time.
However, that's not what the author is complaining about. He's getting no resolution for his request, meaning that the DNS server he queried was unable to retrieve the record from cache, nor find a DNS record for the domain when making a query upstream. My guess is that Comcast's DNS infrastructure is just overloaded so when trying to obtain information about more obscure domains like this it fails now and then. Such failures get cached for awhile so they hand out no matches to others as well. If enough folks start requesting the domain, it eventually will get cached properly and start to resolve. Of course, another possible option is that the domain got black holed by Comcast's DNS for being involved in a phishing expedition or other bad thing too, but it's hard to know.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Wish I had mod points, I'd moderate you "informative".
You would if you made more interesting remarks than this.
Wish I had mod points, I'd moderate you "insightful".
I wish I had mod points, I'd moderate you "Underrated". Your comment has a je ne sais quoi.
True story: At one place I worked, if you typed "quit" into nslookup, it came back with "exit.not.quit.stoopid.oursite.ourcompany.com".
Hi - Jason from Comcast's DNS team here. First off, we have a nifty website @ http://dns.comcast.net/ where you can check our cache and find a form to contact us directly. Let's breakdown the issues with www.021yy.org. 1 - Sub-optimal TTL: The DNS admin is not doing themselves any favors; the TTL for www.021yy.org seems to be set to 60 seconds. That will cause recursion every 60 seconds or less from US-based DNS servers to authoritative servers in China. I recommend a more industry standard TTL to enhance cacheability of these records and minimize global recursions at this frequency. I would suggest no less that 5 minutes (300 seconds in the DNS record) or even as much as 1 hour which is usually fine (3600). 2 - Auth servers seem to be in China? If you expect many users of www.021yy.org in the US, you may want to add at least one authoritative name server in the US so that when recursion does need to occur that it is faster than US-to-China transit time. 3 - Are the auth servers responsive? I get NXDOMAIN responses when asking several recursive servers, such as Google's. Macintosh-3:~ jason$ dig @8.8.8.8 021yy.org ns ; > DiG 9.8.3-P1 > @8.8.8.8 021yy.org ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER> DiG 9.8.3-P1 > @8.8.8.8 slashdot.org ns
; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER- opcode: QUERY, status: NOERROR, id: 26387 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;slashdot.org. IN NS ;; ANSWER SECTION:
slashdot.org. 19088 IN NS ns2.p03.dynect.net.
slashdot.org. 19088 IN NS ns4.p03.dynect.net.
slashdot.org. 19088 IN NS ns1.p03.dynect.net.
slashdot.org. 19088 IN NS ns3.p03.dynect.net. ;; Query time: 17 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Mar 11 17:42:38 2014 ;; MSG SIZE rcvd: 116
In any case, we're flushing our cache right now just in case but I am not sure that will solve a deeper DNS issue with the authoritative DNS service for this domain.