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

[Robert Edmonds]

Colm MacCárthaigh wrote:
> 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.

if the root zone delegating with a TTL of, say, 172759, and the TLDs
delegating with a TTL of, say, 172787 is just as useful as you think it
is for 172801 / 172807 then you can simply hack your recursor to
decrement the incoming TTLs for delegation records to achieve the same
result without violating any RFCs and without having to convince ICANN
or the TLDs to make your proposed changes.

i don't see any semantic difference between primizing in the recursive
cache (so long as the TTL is never increased, only decreased) and
primizing in the authoritative data.

perhaps a more interesting performance hack would be to asynchronously
refresh recently, frequently accessed records a few seconds before they
expire.

-- 
Robert Edmonds
edmonds at isc.org