Hacker News Reader

Comment by Macha | Hacker News Reader

Isn't their example of google that won't be affected? I was under the impression that very few DNS queries actually go to the root nameservers as ISP's and so on have it all cached. And since I highly doubt there is any ISP that has not had a user visit google.com in the last 48 hours, Google will still function for people?

In fact, the only people I can see this affecting (in the unlikely event it does happen) are people setting up new sites.

View on HN

The pastebin post says that 'While some ISPs uses DNS caching, most are configured to use a low expire time for the cache.'

(Just re-iterating the post for Macha... I don't personally believe that the expire-times for ISP DNS cache is as short as Anonymous is making it seem -- but I don't have any numbers off-hand)

Most ISP's dns cache servers honor the TTL defined in the authoritative SOA records, unless is 1 minute or less.

I think the average TTL time for a dns zone would be measured in minutes. It needs to be that low in order to do SRV load-balancing, A/B testing, etc.

In any case, in the highly unlikely event that they manage to overload the 13 servers, there's plenty of time for every domain to temporarily extend the TTL on March 31.

Most TTLs for nameservers are on the order of days.

The negative cache time is defined by the SOA minimum field. Forward cache times are defined at the RR set level.

In my experience many ISPs do the exact opposite, and inflate cached TTLs up to a week. Makes migrations a pain in the ass.

Please prove this assertion by posting the address of a resolver that behaves as you describe.

There are more polite and productive ways of asking for proof of the phenomenon. Or, better yet, use Google the way it was meant to be used, and find out for yourself (just search for stories about DNS migration/propagation issues). People have documented visits to their old IP addresses for a very long time (much longer than the TTL) after updating their DNS with new IP addresses.

I don't see how you could construe my comment as being in anyway impolite.

Google does not turn up any useful results for this subject. The only reference I've seen to resolvers doing something unusual with caching is on the dns-operations mailing list where I ran into a fellow who doesn't cache records with a TTL less than a minute.

Since you claim it is simple to find a resolver that extends the TTL beyond what the authoritative server has specified, can you please point me to such a resolver?

EDIT: Just to be clear, I'm after a server that I can query or something equally authoritative.

EDIT2: My apologies if this is seen as belaboring but please note that nicksuan's comment is not referring to CPE, stub resolvers or client apps.

Your original comment is impolite because it is presented as a demand without any explanation. A demand of proof without explanation can be interpreted as an accusation of lying. Something like, "I haven't seen this phenomenon myself; could you link to some example bad ISPs or articles documenting it?" would be much better.

As for proof, I'm not a professional sysadmin, but based on my reading the most proof you're likely to get is indirect proof in the form of requests to IP addresses long after they've been removed from DNS. If those requests are concentrated in a few ISP subnets, it's reasonable to infer that it's the ISP, not customer equipment, that is caching beyond TTL.

Your interpretation of my original comment seems extremely hypersensitive to me. Perhaps there is cultural difference at play here.

The experience I've had in hosting ten-thousand odd zones suggests that these resolvers do not exist. I've seen a great many claims but am yet to actually see a resolver that extends TTLs in the wild and so I consider them all but myth.

In the past there has been issues at the client - predominately with browsers, MTAs and stub-resolvers - so if I were to observe activity that suggested a stale cache I'd be more likely to attribute it to a bug (be it new or old) if no other data were available.

Reply on news.ycombinator.com