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

[Kim Davies]

Quoting Rubens Kuhl on Wednesday December 11, 2019:
> 
> That's not of what RSPs (Registry Service Providers), ICANN GDD and ICANN IANA have been doing in RSP transitions. What has been working best is to double DS the zone with losing KSK and gaining KSK, have both RSPs sign each other ZSKs and NSs, and replace all DNS servers at gaining RSP, then losing RSP, then IANA.

To explain a little bit more detail on the philosophy behind the IANA
approach: we are seeking to reduce risk wherever possible, particularly
with fundamental changes that have the potential to significantly
impair a TLD if they are executed incorrectly. These includes scenarios
such as a complete change of the NS-set (the new NS-set may not be
proven to handle the full production load for the TLD or otherwise be
misconfigured), and changes to the DS-set (where we want to avoid taking
a leap-of-faith the TLD will validate correctly when rolling over to an
unproven key).

We try to mitigate these risks by encouraging staggered or overlapping
approaches to key rollovers and to NS-set changes. For NS-sets, the
theory is that some of the population of the staggered set will still be
from the current, proven set and should be able to at least partially
service TLD resolution. For DS changes, we have had instances where
TLD managers have requested a DS record be listed in the root, and to
take in on faith without evidencing the associated DNSKEY, only to find
upon later rollover that it was the wrong fingerprint, resulting in an
emergency response to restore a valid delegation to the TLD.

Listing the DNSKEY in the zone in advance, even if it is not yet used
for signing, also provides a valuable safeguard. It proves the requester
has authorship, either directly or indirectly, of the TLD's zone file.
This is a benefit that also accrues from asking for NS-set changes to
be reflected in apex of the TLD zone first, and for glue changes to be
first reflected in the host's authoritative A/AAAA records. It serves
as an additional check to make sure any change to the zone is properly
authorized at the root zone level because it has already been validated
through publication in the child, which is under the TLD operator's
control.

Requesters can seek to perform the changes differently and we evaluate
these on a case-by-case basis. We are sympathetic to operational
realities and specific complexities of certain changes, which is why
you may see changes that do not always adhere to these approaches. In
general, through, we strongly advocate migrations happen in such a
fashion that minimize potential risk to basic resolution, even if it is
at the cost of some potential additional administrative complexity
in making the change.

kim