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 _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations