Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
The Internet Networking

Crowdsourcing Confirms: Websites Inaccessible on Comcast 349

Bennett Haselton writes with a bit of online detective work done with a little help from some (internet-distributed) friends: "A website that was temporarily inaccessible on my Comcast Internet connection (but accessible to my friends on other providers) led me to investigate further. Using a perl script, I found a sampling of websites that were inaccessible on Comcast (hostnames not resolving on DNS) but were working on other networks. Then I used Amazon Mechanical Turk to pay volunteers 25 cents apiece to check if they could access the website, and confirmed that (most) Comcast users were blocked from accessing it while users on other providers were not. The number of individual websites similarly inaccessible on Comcast could potentially be in the millions." Read on for the details.

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:

  1. Can you access the website http://www.021yy.org/?
  2. If you can't access the site, what error message does your browser give you?
  3. 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.

This discussion has been archived. No new comments can be posted.

Crowdsourcing Confirms: Websites Inaccessible on Comcast

Comments Filter:
  • Stop (Score:5, Insightful)

    by TheRealMindChild ( 743925 ) on Tuesday March 11, 2014 @01:40PM (#46456467) Homepage Journal
    Stop using your ISP's DNS
    • Re:Stop (Score:5, Insightful)

      by Anonymous Coward on Tuesday March 11, 2014 @01:45PM (#46456537)

      Thats good for people who know how to change it, let alone know what DNS is. 99% of the population doesn't which means this does have ramifications for accessibility of a site. Though admittedly, it appears to be a decently small problem.

      • Interesting. I don't always want to be messing with my DNS setting every time I get a 404 not found.

        What is needed is a quick way to temporarily try using a different DNS, to see whether that's the problem.

        • by PrimaryConsult ( 1546585 ) on Tuesday March 11, 2014 @02:15PM (#46456833)

          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.

        • Interesting. I don't always want to be messing with my DNS setting every time I get a 404 not found.

          What is needed is a quick way to temporarily try using a different DNS, to see whether that's the problem.

          I don't think there is a downside to using somebody else, across the board. Google seems good at 8.8.8.8 and 8.8.4.4. Use it for everything (desktops, servers) and don't remember ever having a slow response.

          • by Cardcaptor_RLH85 ( 891550 ) on Tuesday March 11, 2014 @02:48PM (#46457189) Homepage
            There is one potential issue. I only found it when I was using a smaller regional ISP while I dealt with a billing dispute with Charter. If your ISP uses extreme levels of NAT and is used primarily by tech-savvy people (those who would be likely to use Google DNS in the first place). It may look to Google like a single IP address is hammering their DNS servers with queries and they may block that particular public IP address. I got that one explained to me by the president of that small ISP about a year ago when I asked why my DNS queries weren't going through and ended up being escalated to the top.
          • While I'm generally a fan of Google products, their DNS is one thing that has let me down. This may have finally changed again, but a month or so ago Google DNS stopped resolving eztv.it (a torrent site dedicated to TV shows). I added another third party DNS server to my resolve list and that fixed it, but it did make me wonder just how many other sites Google had quietly removed from its DNS entries.
        • by DarkOx ( 621550 )

          nslookup
          >server 8.8.8.8
          >hostname
          >exit

          You can 8.8.8.8 is google but you could just any valid dns server.

    • Totally agree here. Comcast has always had DNS problems, and I never recommend using them for DNS.

      However, now that both Comcast and ATT are forcing you to use their router, and their router does not allow you to change DNS, this is much more of a problem.
      • How so? Just about every modern OS (can't speak for OSX from experience, but I'll call it an educated guess) lets you set the computer's DNS instead of having it assigned via DHCP from the router.

        • Re:Stop (Score:5, Informative)

          by Anonymous Coward on Tuesday March 11, 2014 @02:21PM (#46456893)

          I wish kids with no experience would stop running their mouths. That is BS, and even you would understand it if you would think about it. On many of their routers, Comcast redirects port 53 to 75.75.75.75. It doesn't matter what DNS server you set the clients to because Comcast will transparently proxy to their server. As an example with our new IP block from Comcast that isn't yet setup on their DNS server to allow access:

          $ nslookup aol.com 75.75.75.75
          Server: 75.75.75.75
          Address: 75.75.75.75#53

          ** server can't find aol.com: REFUSED

          $ nslookup aol.com 8.8.8.8
          Server: 8.8.8.8
          Address: 8.8.8.8#53

          ** server can't find aol.com: REFUSED

          $ nslookup aol.com 208.67.222.222
          Server: 208.67.222.222
          Address: 208.67.222.222#53

          ** server can't find aol.com: REFUSED

          That shows they're intercepting traffic to both OpenDNS and Google's DNS. We're currently using a modem owned by Comcast, but last week when I swapped in an older modem for testing, I could use DNS on both OpenDNS and Google.

      • Forcing you to use their router? Is this a Comcast-wide policy, or something local to your area? I have never used their router... and for that matter, I even use my own (owned, not rented) modem. I also have a different DNS set up, one that blocks a large amount of potentially objectionable websites (OpenDNS Family Shield).

        • Re:Stop (Score:4, Interesting)

          by jythie ( 914043 ) on Tuesday March 11, 2014 @02:16PM (#46456835)
          Comcast bought up hundreds if not thousands of smaller local ISPs and cobbled their networks together. so hardware policies are highly dependent on where you are and what the history of the local connection is. Even if it is over broadband that Comcast laid down, the back end could be any number of fragments of previous companies.
      • Re:Stop (Score:4, Informative)

        by ichthus ( 72442 ) on Tuesday March 11, 2014 @02:03PM (#46456727) Homepage

        However, now that both Comcast and ATT are forcing you to use their router...

        Eh? I have Comcast and use my own cable modem and router. Whatchu talking 'bout, Willis?

      • comcast is not forcing the use of their router. I don't own their router, I bought mine at a store a year ago and its been working fine the last year with my comcast 'blast' service (which does give me a pretty consistent 50meg down and 10meg up).

        the router never needs dns, anyway. hosts need dns. and hosts can use any dns they want; you can break dhcp apart so that you get ip and netmask and default gw from them but you can ignore their 'suggested' dns resolver.

      • Re:Stop (Score:5, Informative)

        by N_Piper ( 940061 ) on Tuesday March 11, 2014 @02:09PM (#46456787)
        Fun Fact: Comcast home networking support are trained to use 8.8.8.8 as part of the trouble shooting protocol.
      • by jaymz666 ( 34050 )

        I use my own modem and my own router on Comcast, what's this about them forcing you to use their router?

    • Re: (Score:3, Informative)

      www.opendns.org 208.67.222.222 208.67.220.220
      • Re:Stop (Score:4, Interesting)

        by capedgirardeau ( 531367 ) on Tuesday March 11, 2014 @03:01PM (#46457317)

        OpenDNS has the terrible policy of turning back the error:

        "This website is not responding"

        When in fact it was a DNS lookup failure.

        I have written them repeatedly and filed a bug report, but they seem to think it is an acceptable response.

    • This is fine if it's just me, I don't us my ISPs DNS anyway, but when you're trying to run a business and a significant portion of your potential customers can't find you...This can be a REAL issue.
  • by jaymz666 ( 34050 ) on Tuesday March 11, 2014 @01:44PM (#46456513)

    I stopped using comcast DNS servers years ago, and have avoided many an "outage".
    I remember several large DNS outages on comcast that I was completely unaware of for hours or days, until some mention came up.
    I have been using OpenDNS mostly, but I fall back to the google DNS servers if something there flubs up

            208.67.222.222
            208.67.220.220

    Remember these numbers

    • by AK Marc ( 707885 )
      Bah, I've been using 198.6.1.3 since that was the main DNS server for the largest ISP on the planet (by volume of traffic, not subscribers). Unfortunately, MCI bought them out and went under, but the DNS server is still up.
      • Funny, I've been using 192.168.2.100 for at least the last 7 years. I've switched ISPs, seen ISPs (and their servers) come and go, but that server has been rock solid. Except for that one time when it was going through fsck on a 6TB volume, then I had to fall back to 192.168.2.1 for a while (which is just a cache of whatever upstream server it got from DHCP).

    • Is OpenDNS still doing re-directions and other weird stuff?
      I haven't thought about them since the mess with google redirects in 2007 or 2008.

  • by interkin3tic ( 1469267 ) on Tuesday March 11, 2014 @01:44PM (#46456517)
    Gasp! I can't access it through comcast? How ever will I buy office chairs in china without 021yy.org?!?! It's SO much better than those humps over at 022yy.org.

    (In case the link gets slashdotted, it's a website for office furniture in Chinese. At least according to google translate.)
  • by krkhan ( 1071096 ) on Tuesday March 11, 2014 @01:44PM (#46456519) Homepage

    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.

    Why are you assuming that this scales linearly? Are you suggesting that this is a technical glitch? If the websites are blocked due to the nature of their content it most certainly won't scale in a linear fashion.

    • by AK Marc ( 707885 )
      They will scale in a linear faction, so long as the initial ones were nearly random. If you find playboy.com and then try penthouse.com, and hustler.com, the results wouldn't scale linearly, as the test sites were very non-random. If you actually had a random list of sites on the Internet, and tried 10, there's no reason to assume that the next 1,000,000 wouldn't scale linearly.
    • Probably because he only had one data point? Since the example site was selling furniture, I doubt his argument was that the blocking was due to content restrictions. And what scale would *you* expect even if it was due to content? You sound very sure that there's no linear correlation, but we don't even know how he selected the domains he tried (random vs. alphabetic vs. ip order). He at least used the phrase "if the same proportion holds", while you assert that "certainly" wouldn't be the case. So I

  • I routinely come across websites that I can see, but for some reason my Verizon account refuses to stream the video for. I wait a day, and boom, they can stream again.

    Companies develop issues all the time. Sometime it is on the website end, sometimes on the ISP end.

    Not much you can do about it.

  • by Zontar_Thing_From_Ve ( 949321 ) on Tuesday March 11, 2014 @01:49PM (#46456567)
    My ISP, who is not Comcast but another major American ISP, also blocks certain websites via DNS failures. Simply switching DNS to Google's DNS servers or FreeDNS resolved the problem.
  • by AK Marc ( 707885 ) on Tuesday March 11, 2014 @01:50PM (#46456575)
    So, if you do the DNS query from another provider's DNS, can you get to the website over Comcast? Seems like a basic troubleshooting step that was missed. At least not mentioned in the extended summary.
    • by armanox ( 826486 )

      Sure it was - and yes, he could get there.

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

  • if you do a compare between two DNS servers then you are bound to also come up with differences that show how outdated one server is compared to the other... There has to be many new domains registered / re-registered and associated / re-accociated with a new IP every minute, if you run the script for long enough between two different snapshots you are bound to find one of these...

    So my appropriately verbose question in response to your post is: how often do you think google and comcast update their DNS ser

    • Re:Old DNS cache? (Score:5, Informative)

      by bobbied ( 2522392 ) on Tuesday March 11, 2014 @03:00PM (#46457301)

      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.

  • by astro ( 20275 ) on Tuesday March 11, 2014 @01:51PM (#46456583) Homepage

    DNS is a theoretically good system and one that we obviously all rely on every day. However, so many DNS implementations from the registrar level down to your cheap little wifi-router-all-in-one box that connects to your ISP are so totally broken. I think the way this is written is pretty trollish and should instead have focused on the wider question of how we can advance to where so many devices and programs that have to deal with name resolution will act more to-spec and consistently. Comcast should take some heat here for a partially broken DNS implementation, but without better evidence, I see no intentional evil in this particular story.

  • Hmm. I have BOTH Comcast residential and business class service. I wonder if the reponses are different.

  • Just because you use comcast's pipes doesn't mean you have to use their DNS.
    8.8.8.8 and 8.8.4.4 are the addresses to use for DNS

    • 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/ [021yy.org].

    • by lgw ( 121541 )

      Sure, just in case there's some tiny aspect of your web browsing that Google doesn't already know, use their DNS too! OpenDNS is there for good reason.

  • The majority of issues I have had with any cable company were related to their DNS being shitty. For some reason, cable companies don't know how to operate DNS.
  • Comment removed (Score:5, Interesting)

    by account_deleted ( 4530225 ) on Tuesday March 11, 2014 @01:59PM (#46456677)
    Comment removed based on user account deletion
    • by lgw ( 121541 )

      Bennet Hazelton is the source of the bottom tier of Slashdot stories. I swear they post his stories just to get the page hits from everyone complaining about them.

    • Yeah, within first paragraph I realized his issue is just a generic DNS issue as a result of using his default ISP settings. Besides the fact that DNS does take some time to propagate changes to the world, most ISP's or even DNS providers like OpenDNS, still cache their databases to some extent for the sake of less traffic.

      I think the OP qualifies as the kind of person who "knows enough to be dangerous, but nothing more."

  • Those are the possibilities, in decreasing order of probability.

    As much as I despise Comcast, they are unlikely to deliberately block random DNS lookups.

  • " Comcast threatening to de-prioritize content delivery from websites that don't pay them a fee,"

    last i heard...wasn't Nexflix *trying* to pay them a fee for better delivery?

    i think its an important distinction. with all the kerfluffle about net neutrality, shouldn't we make sure the players are well identified?

  • 1) The author has managed to uncover a conspiracy by Comcast to hold the good people at http://021yy.org/ [021yy.org] down by denying the no doubt millions of potential customers that would be flocking to the domain otherwise. After all, that domain name rolls right off the tongue.

    or

    2) Comcast doesn't have an entry in it's DNS servers for the site because it is a Chinese domain that looks like spam that no customer of theirs has tried to access before now.

  • Sorry, maybe you've skipped a salient point in the article, but the sites are not inaccessible. It seems plausible that there are some shannigans going on the Comcast DNS, just switch to a public DNS server for heaven's sakes. This is a really dumb post, sorry.
    • by MobyDisk ( 75490 )

      Perhaps they should put a message on the web site saying that if you can't access it you should change... your DNS server... settings... Oh wait... no, that won't work.

  • by Dusty ( 10872 ) on Tuesday March 11, 2014 @02:17PM (#46456855) Homepage

    How does Comcast's DNS look like when tested by namebench [google.com]?

    Does it find the same problem?

  • Just about every single Comcast customer I have ever met, myself included, would tell you how terrible their service is, AND how few other options they have for high-speed internet.
  • We frequently seem to have problems with Comcast's business-class DNS, but the sample size for this experiment is one tiny business in China. Not exactly comprehensive.

    China has more Internet users than the United States, and their service is pretty good. I'm a heavy user of the Chinese Internet, and I rarely have problems traversing their networks. But at the same time, malware is common there due to software piracy. Careful, temporary, targeted blocks of Chinese malware hosts can and do happen. Perhaps th

  • by Burdell ( 228580 ) on Tuesday March 11, 2014 @02:32PM (#46457025)

    The DNS for 021yy.org is rather fishy looking. The .org servers have NS records pointing to ns1.booen.com and ns2.booen.com, which have a 20 second time to live (vs. a normal 1 day TTL), which is common in botnet command & control networks. Also, the ns1/2.booen.com servers give answers to 021yy.org A lookups, but return NXDOMAIN for NS lookups (which is completely bogus; NXDOMAIN means that 021yy.org does not exist, not that it doesn't have NS records, which would still be bogus).

    The NXDOMAIN for NS records would cause many caching servers to cache NXDOMAIN for all records (not just NS), which would cause the domain to not resolve (depending on the order things were looked up). Basically, I don't see this as a Comcast problem, but rather a problem with the DNS servers for 021yy.org. This may be accidental (although AFAIK no normal DNS server would reply with A records but return NXDOMAIN for NS records), but looks possibly like it is intentional and possibly part of a botnet C&C. There's a lot of that going on lately.

  • by asmkm22 ( 1902712 ) on Tuesday March 11, 2014 @02:57PM (#46457273)

    If someone asked me to "go check a website" and the site URL looked like some random malware host, I'd probably not choose his 25 cent task either. What is this guy smoking?

  • by Megane ( 129182 ) on Tuesday March 11, 2014 @02:59PM (#46457295)

    Turns out that for some reason, their DNS servers were making a query for the name of my nameservers as listed in the registrar database. When those failed, it dropped any caching of the address like a hot potato, thus resulting in very spotty name resolution. Using Google's DNS worked just fine, if a bit slower due to the lack of multi-hosting.

    So basically, if the registrar has example.com's nameservers listed as foo.example.com = 10.1.1.1 and bar.example.com = 10.1.1.2, AT&T's DNS will query 10.1.1.1 to look for foo.example.com. If that DNS server lists itself as ns1.example.com, but does not resolve foo.example.com, AT&T's nameserver will think something is fishy and decide you don't exist at all.

    This was a pain in the ass to figure out, but everything has been fine since I fixed that. I would still like to find a place where this behavior is documented, because I was only able to discover it by turning debug logging on for my nameserver. I also found out that someone in Germany had been using it as their primary DNS for who knows how long, so I shut off recursive searches from outside my LAN.

  • by egarland ( 120202 ) on Tuesday March 11, 2014 @03:01PM (#46457311)

    This was probably just a negative cache entry. Someone on Comcast (possibly you) probably tried to look up helpmatt.org before it was propogated to all the root servers, and 75.75.75.75 got a lookup failure and cached it. Negative caching is part of proper DNS operation and it can last a while. DNS is full of delays like this.

    FYI... It's working just fine now.

    root@atomrouter:~# host helpmatt.org 75.75.75.75
    Using domain server:
    Name: 75.75.75.75
    Address: 75.75.75.75#53
    Aliases:

    helpmatt.org has address 192.155.89.14
    helpmatt.org mail is handled by 20 alt1.aspmx.l.google.com.
    helpmatt.org mail is handled by 30 aspmx3.googlemail.com.
    helpmatt.org mail is handled by 30 aspmx2.googlemail.com.
    helpmatt.org mail is handled by 20 alt2.aspmx.l.google.com.
    helpmatt.org mail is handled by 10 aspmx.l.google.com.

  • by jlivingood ( 1572291 ) on Tuesday March 11, 2014 @04:49PM (#46458331)
    Hi - Jason from Comcast's DNS team here. First off, we have a nifty website @ http://dns.comcast.net/ [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.

If you have a procedure with 10 parameters, you probably missed some.

Working...