[dns-operations] Prime TTL values for TLD and root server delegations.

[Jim Reid]

On 21 Dec 2009, at 16:47, Colm MacCárthaigh wrote:

> Why aren't the TTLs on NS delegations served by root servers and TLD
> operators prime numbers?

Because there's no benefit in making them prime numbers. There's no  
operational advantage in making the TTL for some NS or A record for a  
TLD 172801 seconds (assuming that's prime) instead of 172800. What  
matters here is that the TTLs are "long enough". A 2 day TTL is not  
unreasonable. It's a good compromise between longevity -- important  
name servers shouldn't move about all that often -- and avoiding  
possibly stale data lying around caches for too long. It also gives a  
reasonable frequency for the rate at which the TLD delegation data  
should expire from caches and gets "refreshed".

Your concerns about the data all expiring at the same time for some  
delegation is misplaced. A resolver isn't going to "refresh" that  
delegation until the last datum for it has gone from the cache. So  
staggering the TTLs will have no effect because the resolver's  
behaviour won't change, just the timing of when it fetches that data:  
eg at 172801 seconds after it had been cached instead of 172800,  
assuming 172801 was the largest of these hypothetical randomised,  
prime TTLs. The resolver will "refresh" the delegation for .tld when  
it no longer has any data for that TLD. ie When the data that had the  
largest TTL expires from the cache. NB in this context I'm using  
"refresh" as a shorthand for "getting a referral once no more data for  
the delegation is in the cache" rather than its true meaning in DNS  
jargon for SOA serial number checking.

Another point: just because a bunch of data possibly expires from the  
cache at the same time, it doesn't automatically follow that it all  
has to be "refreshed" at that point.

It's also likely that cached data in a referral will get updated  
during routine resolving operations. For instance when a response from  
a .tld server includes the TLD's NS RRset, displacing whatever had  
previously been cached from a root server's referral for that TLD.

Note too that since DNSSEC works on RRsets, the NS records for a zone  
should all have the same TTL. So should the A (and AAAA) record sets  
for those names.

The scenario you describe is not worth worrying about. If a bunch of  
RRs expire from cache at the same time, so what? Introducing some  
entropy to those values isn't going to make any noticeable difference  
as far as resolver operations are concerned. It will however  
complicate the job of publishing and signing zone data. The trade-off  
simply isn't worth it.