[gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program
Bill Woodcock
woody at pch.net
Wed Oct 18 07:21:57 UTC 2023
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>
More information about the gtld-tech
mailing list