[dns-operations] Who Ignores TTLs ?

Olaf Kolkman olaf at NLnetLabs.nl
Wed Feb 23 10:59:24 UTC 2011

On Feb 23, 2011, at 10:03 AM, Olaf Kolkman wrote:

> On Feb 21, 2011, at 5:22 PM, Roy Arends wrote:
>> 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 
> From the recursive nameserver perspective I can say what Unbound does with respect to honoring/ignoring TTLs.  I do not think this is the behavior you are worried about, but it may serve as datapoint.
> Small TTL values are honored as long as they are larger than the cache-min-ttl config parameter. If the TTLs are smaller then the cache-min-ttl is used as the TTL. Per default the value of that param is 0, which means that RRsets with a TTL==0 will be disgarded. (Even when the TTL is 0 some RRs stick around internally for a second in order to do keep them around for validation)
> By default any TTL larger than 24hrs will be treated as being 24 hrs. The  cache-max-ttl config parameter governs that behavior. RFC 2308 security considerations seem to allow for this.

Oh, I should add. (reading mail sequentially)
Unbound also does prefetching. But only if a query comes in for an RRset that is about to expire, not for any RRset that happens to be in the cache and is about to expire. In other words prefetching only happens for RRsets that are in popular demand anyhow.



Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2210 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20110223/9b35bdb1/attachment.bin>

More information about the dns-operations mailing list