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

[Colm MacCárthaigh]

On Mon, Dec 21, 2009 at 11:08 PM, Robert Edmonds <edmonds at isc.org> wrote:
> David Dagon wrote:
>> There might be unintended costs of random prime TTLs.  If an authority
>> did vary its TTLs (e.g., providing 86413, 86423, 86441, 86453, 86461,
>> 86467, 86477, 86491, 86501, 86509, 86531, etc., randomly instead of
>> 86400) it might trip up primitive DNS monitoring heuristics (e.g.,
>> those looking for flux-style networks).  Research projects that store
>> unique records, and use the TTLs for uniqueness, would also see an
>> explosion in storage.
>
> note that the TTL is the _maximum_ length of time an RRset may validly
> be cached for.  if there do happen to be measurable operational
> advantages to prime TTLs, it would be much easier to simply have the
> cache lower the TTL of a cached RRset to a nearby prime.

There are strategies that would help within resolvers, but I don't
think this one would help. I guess my use of the word "unique" has
caused some confusion here. I don't mean that the root zone, or TLD
zones should contain random, unique-per-delegation TTLs. I also don't
think the effects would exhibit as a periodicity of queries at the
root or TLD nameservers. I just think that it would be marginally
useful for the NS records in the root zone to have a prime TTL, and
the same for NS records in the TLD zones. I can imagine the root zone
delegating with a TTL of 172801 and "com." and other TLDs delegating
with a TTL of 172807 say.

Yes the TTLs are so long that the occurence is rare, but TTLs that are
whole-divisors of the existing numbers are so common (e.g.
www.example.com) that the effect of that occurence, rare as it is, is
worse than it need be.

At its most simple, lets take a simple delegation like;

   foo.example.com.  3600 IN NS bar.example.org.
   bar.example.org.    3600 IN A 192.0.2.53

typically, a query for "foo.example.com" will result in 3 cache entries;

   foo.example.com NS record
   bar.example.org   A record
   foo.example.com A/AAAA /whatever record

and they will be primed at the same time, by the same client query.
The clock starts ticking for each of them then.

If the TTLs are the same, then they will also expire at the same time.
So the query that comes along at expiry-time + 1 has to go through the
effort of making all 3 resolutions again - the impact is client
latency for that query. I recognise it's a terminal case, but I
believe it to be real.

If the records had different TTLs, this would not happen as often -
it's better caching behaviour. When a miss occurs, usually only one
record will need to be resolved. Ocasionally the TTLs will coincide
anyway, but this can be minimised by using prime numbers, which unique
factorise their products.

That's all I'm saying :-)

-- 
Colm