[gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program

[Bill Woodcock]

> On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech at icann.org> wrote:
> 
> On Tue, Oct 17, 2023 at 12:38:13PM +0000, Francisco Arias via gtld-tech wrote:
> 
>> ICANN is transferring the operation of the .DESI gTLD to an Emergency
>> Back-end Registry Operator (EBERO) to ensure the continued operation
>> of the generic top-level domain (gTLD) and protect registrants. As
>> part of this transfer, .DESI has transitioned from a secure DNSSEC
>> state to an insecure DNSSEC state (i.e., the DS records for .DESI have
>> been removed from the root zone). After the transfer, ICANN will work
>> with the designated EBERO provider to transition the .DESI gTLD back
>> to a secure state (i.e., signing the zone for .DESI and adding new DS
>> records for .DESI in the root zone). After evaluating available
>> options, we believe the temporary move to an insecure state was the
>> best available option.
> 
> I gather a graceful key rollover from the current algorithm 8
> (RSASHA256) KSK to a new KSK for the same algorithm at the new operator
> was not an option?
> 
> All that this would have required of the new operator is to add the new
> providers KSK and ZSK to the DNSKEY RRset, augment the zone apex NS
> RRset and resign the zone.
> 
> So presumably the prior operator was unable and/or unwilling to sign
> updated zone apex DNSKEY and RRsets?
> 
> Or was this just a "risk" decision.  It would be reassuring to know that
> for more "critical" zones there is, when/if needed, a more graceful,
> known to work process.

I think it’s just a matter of policy.  The one instance of this that I watched up-close, when .WED was placed on EBERO, it was a fully functional registry, the EBERO operator was offered a clean roll, and they just ignored it and did a dirty roll without responding to any of the coordination attempts.

So, policy, but very bad policy.

                                -Bill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mm.icann.org/pipermail/gtld-tech/attachments/20231018/354febd5/signature.asc>