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

[Bill Woodcock]

Thank you for the reference, Eberhard.

“If there is sufficient time and the EBERO, ICANN and failing registry operator concur on implementation details, a pre-publication strategy may be used.”

That seems like very weak sauce to me, and in actual fact was insufficient to protect registrants’ interests in having a clean roll.  The EBERO being lazy does not seem to me to be sufficient reason to allow a dirty roll.

                                -Bill



> On Oct 18, 2023, at 09:17, Dr Eberhard W Lisse via gtld-tech <gtld-tech at icann.org> wrote:
> 
> 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.
> _______________________________________________
> 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 --------------
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/832dc3c4/signature.asc>