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

[Colm MacCárthaigh]

2009/12/21 Jim Reid <jim at rfc1035.com>:
> 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.

Avoiding cache-misses seems like an operational advantage to me. The
entire point of TTLs is to facilitate caching after all :-) Having the
NS record and the A record associated with that NS expire at the same
is sub-optimal. What's more, the behaviour will affect the most
frequently queried records. I agree that the problem happens rarely,
but it's still avoidable.

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

There is no shortage of convenient prime numbers :-)

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

I'm not suggesting any randomisation :-) I'm wondering why the TTLs
themselves are not prime. To take the simplest example;

   foo 10 IN NS bar.example.com
   bar.example.com 20 IN A 192.0.2.0

if foo is a frequently accessed record - e.g. at least 1 query per
second. Won't the NS and A expire at the same time, always? That's two
extra resolution queries. If the 10 and 20 were instead 11 and 23 ..
this occurs every 253 seconds, or one in every 23 times compared to
the former example. We as DNS administrators can configure our own
zones like this ... but not the root or TLD.

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

That helps - that makes some more sense of it.
-- 
Colm