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

[Dr Eberhard W Lisse]

Bill,

my understanding is that this is a FAILED Registry which in July asked ICANN to terminate so this probably means they stopped engaging (which might have implications about the cleanliness of the roll) and the number of registrants is small and thus presumably don’t care about signing if even about their names at all.


el

--
Sent from my iPhone
On Oct 18, 2023 at 09:22 +0200, Bill Woodcock <woody at pch.net>, wrote:
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gtld-tech/attachments/20231018/c8c00d0f/attachment.html>