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

Rubens Kuhl rubensk at nic.br
Wed Dec 11 13:53:44 UTC 2019



> Em 11 de dez de 2019, à(s) 10:20:000, Jim Reid <jim at rfc1035.com> escreveu:
> 
> 
> 
>> On 11 Dec 2019, at 12:51, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
>> 
>> IMHO, this is by far the biggest issue with your proposal: TLDs change
>> from one technical operator to another and, when it happens, all name
>> servers change at once.
> 
> That’s not correct.
> 
> In principle, they could all change at once, In reality, they don’t. When making a change of this nature, established wisdom is to change half of the NS records (or their glue), wait a few days to see that all is well and then change the other half. I think IANA would try to persuade a TLD to do that if they came with a proposal to change all of the TLD's NS records in one transaction. Though if the TLD insisted, IANA would respect their choice.
> 
> Come to think of it, changing all of the NS records at once is generally a bad idea for any zone. That would probably only make sense when all of the existing name servers were dead or no longer serving the zone.
> 


Jim,

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.

One of such transitions in 2019 was .natura and the root zone history can show how it was done. I am polishing out a few tidbits in that change process and will publish the change process of that case as a template that serves well single-registrant TLD transitions.

Rubens


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191211/3d215960/attachment.sig>


More information about the dns-operations mailing list