[dns-operations] Who Ignores TTLs ?

Roy Arends roy at dnss.ec
Mon Feb 21 16:22:46 UTC 2011


On Feb 17, 2011, at 2:01 AM, Simon Lyall wrote:

> I keep seeing a persistent complaint that some DNS caching operators ignore TTLs or otherwise keep records for longer than the TTL would indicate.
> 
> I suspect this might be an urban legend since most DNS caching software doesn't even offer this as an option last time I checked.
> 
> Does anybody actually do this? Because it keep being brought up by some peopel as to why things like GSLB don't work.

At Nominet, we see various forms of TTL ignorance, independent of load balancing via DNS . A few of them:

1) TTL is approximate

The bulk of caching resolvers will adhere to TTL, but not the exact value. Mostly, we see resolvers come back slightly before TTL expires. Don't know the exact error rate yet, will have to investigate. 

2) Incredible bursts

We very often see a massive amount of request from a single address, for a single domain name. Sometimes 200-300 queries within a few hundred milliseconds (with an average delta of 3 milliseconds between queries). The load vaporizes as soon as the resolver receives the first response we send. This is not a DDoS, and normally, this will be hidden in the noise and thunder of the regular load. 

3) Disproportionate NXDOMAIN load.

Due to caches capping negative caching to a few minutes (independent of a higher ttl in the SOA), we see a disproportionate query rate for names that do not exist. In theory, there are many more names that do not exist compared to those that do exist, however in practice (tested in november 2009) using one day of query-load on a single nameserver, the set of queries for unique existing names is larger than the set of queries for unique non-existing names. The reason I mention it here is that caches can be configure to override negative TTL.

So, either due to cache optimization, misconfiguration, bad implementations or implementation override, caches appear not to adhere to TTL.

Hope this helps,

Roy
 




More information about the dns-operations mailing list