<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div dir="auto"><a href="https://www.icann.org/en/system/files/files/common-transition-process-manual-21dec22-en.pdf" target="_blank">https://www.icann.org/en/system/files/files/common-transition-process-manual-21dec22-en.pdf</a><br />
<br />
el</div>
</div>
<div name="messageSignatureSection"><br />
--
<div dir="auto">Sent from my iPhone</div>
</div>
<div name="messageReplySection">On Oct 18, 2023 at 01:02 +0200, Bill Woodcock via gtld-tech <gtld-tech@icann.org>, wrote:<br />
<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;">
<blockquote type="cite">On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech@icann.org> wrote:<br />
<br />
On Tue, Oct 17, 2023 at 12:38:13PM +0000, Francisco Arias via gtld-tech wrote:<br />
<br />
<blockquote type="cite">ICANN is transferring the operation of the .DESI gTLD to an Emergency<br />
Back-end Registry Operator (EBERO) to ensure the continued operation<br />
of the generic top-level domain (gTLD) and protect registrants. As<br />
part of this transfer, .DESI has transitioned from a secure DNSSEC<br />
state to an insecure DNSSEC state (i.e., the DS records for .DESI have<br />
been removed from the root zone). After the transfer, ICANN will work<br />
with the designated EBERO provider to transition the .DESI gTLD back<br />
to a secure state (i.e., signing the zone for .DESI and adding new DS<br />
records for .DESI in the root zone). After evaluating available<br />
options, we believe the temporary move to an insecure state was the<br />
best available option.<br /></blockquote>
<br />
I gather a graceful key rollover from the current algorithm 8<br />
(RSASHA256) KSK to a new KSK for the same algorithm at the new operator<br />
was not an option?<br />
<br />
All that this would have required of the new operator is to add the new<br />
providers KSK and ZSK to the DNSKEY RRset, augment the zone apex NS<br />
RRset and resign the zone.<br />
<br />
So presumably the prior operator was unable and/or unwilling to sign<br />
updated zone apex DNSKEY and RRsets?<br />
<br />
Or was this just a "risk" decision. It would be reassuring to know that<br />
for more "critical" zones there is, when/if needed, a more graceful,<br />
known to work process.<br /></blockquote>
<br />
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.<br />
<br />
So, policy, but very bad policy.<br />
<br />
-Bill<br />
<br />
<br />
_______________________________________________<br />
gtld-tech mailing list<br />
gtld-tech@icann.org<br />
https://mm.icann.org/mailman/listinfo/gtld-tech<br />
<br />
________________________________________________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.</blockquote>
</div>
</body>
</html>