[dns-operations] root? we don't need no stinkin' root!

[Ondřej Surý]

> On 28 Nov 2019, at 08:09, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> * Ondřej Surý:
> 
>>> On 27 Nov 2019, at 23:08, Florian Weimer <fw at deneb.enyo.de> wrote:
>>> * Mark Allman:
>>> 
>>>> Let me try to get away from what is or is not "big" and ask two
>>>> questions.  (These are legit questions to me.  I have studied the
>>>> DNS a whole bunch, but I do not operate any non-trivial part of the
>>>> DNS and so that viewpoint is valuable to me.)
>>>> 
>>>> (1) Setting aside history and how things have been done and why
>>>>    (which I am happy to stipulate is rational)... At this point,
>>>>    are there tangible benefits for getting information about the
>>>>    TLD nameservers to resolvers as needed via a network service?
>>>> 
>>>> (2) Are there fundamental problems that would arise in recursive
>>>>    resolvers if the information about TLD nameservers was no longer
>>>>    available via a network service, but instead had to come from a
>>>>    file that was snarfed periodically?
>>> 
>>> What's the change rate for the root zone?
>> 
>> https://twitter.com/diffroot
> 
> Selective quoting does not help to further the discussion.

Including cruft also does not help to further the discussion, but fair enough, I reinstated
the rest of your email into the reply.

> Raw change
> rates do not tell us if zones keep at least of some of their servers
> at constant addresses over really, really long periods of time.

.bank
- deleted NS {ac1|ac2}.nstld.com. and added NS {a|b|c}.nic.bank. on November 20
and
- deleted NS {ac3|ac4}.nstld.com. and added NS {d|e|f}.nic.bank. on November 23

Does that answer your question?

That doesn’t include changes to GLUE records which are equally as important, so the
only value you can work with and rely on is the TTL. (172800 - 48h).

The TTL on DS is 1 day and is even more important to get the updated DS early
when there’s a breach and DS needs to be swapped as early as possible.

>> If there is a full
>> transition of the name server addresses for a zone, how long does it
>> typically take from the first change to the completion of the sequence
>> of changes?
>> 
>> If the answer, “this has never happened”, then using a fairly static
>> data source should probably be okay (similar to how the browser PKI is
>> maintained).  Due to the way DNSSEC works with its periodic renewal of
>> signatures, validating non-recursive resolvers will automatically
>> verify the freshness of the local root zone copy.  Even if there are
>> few such clients, I expect that for most operators, it will
>> effectively prevent undetected decay due to a stale root zone (where
>> more and more stale delegations accumulate until performance is
>> seriously impacted, and fresh bootstrap using external data is
>> needed).
>> 
>> The other question is whether that data source will make it harder for
>> ICANN or someone else to hand over control over the TLD in a
>> unilateral manner.  And then it's not even clear whether that's a good
>> thing or not.
>> 
>> Other uncertainties relate to the size of the root zone.  It seems
>> that the phase of aggressive growth is more or less over.  But
>> hard-coding an assumption that resolvers can load the root zone into
>> memory is on a different level because it limits policy basically for
>> forever.
>> 
>> I've thought a bit whether the root domain list should be pushed into
>> (non-validating) stub resolvers, but I don't think that's possible
>> because people really like to use local domains.


Ondrej
--
Ondřej Surý
ondrej at sury.org