[dns-operations] Paranoid mode for resolvers

Mike Jones mike at mikejones.in
Mon Sep 5 12:00:16 UTC 2011

On 5 September 2011 11:10, Olaf Kolkman <olaf at nlnetlabs.nl> wrote:
> My first thought when reading this, and speculating on whether you would want to implement such mechanism, is that recursive nameservers might not be the best place. Regulations that say that 'take down' should be in effect in 'X hours' are typically bound to the locality of the registry and such timings should be signaled by the authorities.
> As often with first thoughts, I am probably missing some aspects of this problem space.

My first thought was simply limiting records to the TTL of the
delegation, so if you get a delegation for example.com with a TTL for
24 hours then 18 hours later get an NS record with a TTL of 48 hours,
you cap it to 6 hours (the remaining time on the delegation), however
that might cause a problem when you consider there is no real
difference between the delegation for example.com and the delegation
for com, and I don't think large resolver operators would be happy
with everything under com suddenly expiring at the same time every 48
hours as the delegation gets refreshed!

Storing the original TTL that the delegation was received as and
merely using that as an upper bound (so a 24 hour delegation received
18 hours ago and you return a TTL of 48 hours, it is capped at 24
hours) would probably work fine, but would still mean if i can keep
you updating your NS records before they expire you'll still never
check the parents. I can also point to for example the tk ccTLD as an
example of why using the delegated TTL as an upper bound might not be
ideal, they use a 5 minute TTL on "free domains" (even though they
only update their servers every hour or so?).

It probably needs something in between like re-checking the delegation
when it expires (ignoring cached NS records from the child servers),
and capping the maximum TTL for caching records to the original
delegation TTL?

Or just leave it as it is. If it ain't broke... (although I'm sure
many would argue that it is, but for example "after an attack i cant
get my fix pushed out to everyone instantly" can also be rephrased as
"an attacker cant get their changes pushed out to everyone instantly")

- Mike

More information about the dns-operations mailing list