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

Wed Oct 18 07:17:12 UTC 2023

https://www.icann.org/en/system/files/files/common-transition-process-manual-21dec22-en.pdf

el

--
Sent from my iPhone
On Oct 18, 2023 at 01:02 +0200, Bill Woodcock via gtld-tech <gtld-tech at icann.org>, wrote:
> > 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
>
>
> _______________________________________________
> gtld-tech mailing list
> gtld-tech at icann.org
> https://mm.icann.org/mailman/listinfo/gtld-tech
>
> ________________________________________________By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gtld-tech/attachments/20231018/501a8691/attachment-0001.html>