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

[David Dagon]

On Mon, Dec 21, 2009 at 04:47:16PM +0000, Colm MacC?rthaigh wrote:
> No doubt, this question has been asked before - but I can't seem to
> find a good, documented, answer for it;
> 
> Why aren't the TTLs on NS delegations served by root servers and TLD
> operators prime numbers?

This is an interesting question. In the various published studies of
root and TLDs behaviors, I have not observed significant periodic
simultaneous NS refreshes.  NS refreshes might never become
synchronized, since I believe they are driven primarily by stub
behavior.  So perhaps a prime TTL would never have any measurable,
real-world impact (since the user-driven refreshes are essentially
random).

Some trace-driven simulations, while incomplete, have shown that small
NS TTLs would increase traffic to root and gTLDs by a factor of five:

  http://pdos.csail.mit.edu/papers/dns:ton.pdf

Yes, the study was very limited in scope, but it shows that the length
of the TTL, rather than divisibility, is the most important design
consideration.  RFC 1912 seems to agree.

We might imagine there are networks with little or no user-driven
traffic, and that all NS refreshes are therefore the result of cron'd,
automated processes.  Such networks might create storms of
simultaneous NS refreshes (at least all in the same time zone).  In
such a case, answering with a prime close to a target TTL would
stagger their refreshes.  

But even if we supposed such cron-only networks are widespread, I do
not expect they are synchronized.  Broido, for example, noted
significant clock skew in private DNS updates (now terminated in
AS112):

  http://www.caida.org/publications/papers/2006/private_dns_updates/

So I expect that even automated NS refreshes are themselves
distributed by (likely random) local clock skews.

Your idea is still very interesting, however, and there might be some
applications elsewhere.  Obviously on the host side (e.g., sizing
caches in memory), primes are useful.  But on the network side, I
cannot imagine a system of queues (corresponding to actual DNS
architectures) where prime inter-arrivals play a significant role.

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.

While I can't imagine a network-oriented use of prime TTLs, there are
many channel uses (a low capacity covert channel; a unique marker for
which NAT'd server provided the answer, etc.)  A very interesting
question to think about.

-- 
David Dagon              /"\                          "When cryptography
dagon at cc.gatech.edu      \ /  ASCII RIBBON CAMPAIGN    is outlawed, bayl
Ph.D. Candidate           X     AGAINST HTML MAIL      bhgynjf jvyy unir
Georgia Inst. of Tech.   / \                           cevinpl."