.DESI to Be Placed in the Emergency Back-end Registry Operator Program
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, 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. For more information, please see the announcement at https://www.icann.org/en/announcements/details/desi-to-be-placed-in-the-emer... - - -- Francisco Arias Sr. Director, Technical Services Global Domains & Strategy ICANN https://icann.org/resources/pages/pgp-keys-2012-02-25-en#FranciscoArias -----BEGIN PGP SIGNATURE----- iQFOBAEBCgA4FiEEH96Bn3vsHLISfu5Umk0ze9UQ45cFAmUuf/caHGZyYW5jaXNj by5hcmlhc0BpY2Fubi5vcmcACgkQmk0ze9UQ45eapgf+O6OlrzpuFY5loiIhKkEk wJ1vh0qZQZXWE7UFhY2ixcip3xd7h+S37xEb8E895RxtWp8jMrZ8EtXAltT/bylG K0Q5xAzACnsznMLSrZ7a4K47D+Igpm8iINEUSofsiuQDDLUr9e5/MGljHP4JOSr6 7AZfMonb67+i0rSAOIS+x3DUGoDtEj5/W/2R1BD6CdrhHp0iDtcT8vnMR7aMr+hl bx+1f4p86Vwk1QaEYxUOWQhoFfFNHUD3iG3+z7Sw4xdE4Xaa8AOzRy74947ZqbC0 kjdp6PYvGzc3Q7ZvZ/TwxM06s4vr7fsLxrslUqZ9c8qJlNkGaLX9/kS7ezOlRi7p Vg== =QVDv -----END PGP SIGNATURE-----
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. -- Viktor.
On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech@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
https://www.icann.org/en/system/files/files/common-transition-process-manual... el -- Sent from my iPhone On Oct 18, 2023 at 01:02 +0200, Bill Woodcock via gtld-tech <gtld-tech@icann.org>, wrote:
On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech@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@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.
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@icann.org> wrote:
https://www.icann.org/en/system/files/files/common-transition-process-manual...
el
-- Sent from my iPhone On Oct 18, 2023 at 01:02 +0200, Bill Woodcock via gtld-tech <gtld-tech@icann.org>, wrote:
On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech@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@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@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.
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@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@icann.org> wrote:
https://www.icann.org/en/system/files/files/common-transition-process-manual...
el
-- Sent from my iPhone On Oct 18, 2023 at 01:02 +0200, Bill Woodcock via gtld-tech <gtld-tech@icann.org>, wrote:
On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech@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@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@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.
https://ntldstats.com/tld/desi Tiny numbers of everything -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: gtld-tech <gtld-tech-bounces@icann.org> on behalf of Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> Date: Wednesday, 18 October 2023 at 11:15 To: Bill Woodcock <woody@pch.net> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: Re: [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. 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@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@icann.org> wrote: https://www.icann.org/en/system/files/files/common-transition-process-manual... el -- Sent from my iPhone On Oct 18, 2023 at 01:02 +0200, Bill Woodcock via gtld-tech <gtld-tech@icann.org>, wrote: On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech@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@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@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.
My argument isn’t that .DESI specifically does or should matter to anyone who isn’t a registrant. My argument is that if something’s worth doing, it’s worth doing well. There’s no point in being able to exercise the process for a clean roll, and not doing so. The effort is relatively trivial, and it’s good practice for when it’s needed. Always slacking off and doing dirty rolls because you’re lazy, you don’t get any practice running the necessary process, so when you do need it, you’re unprepared. That’s just bad policy. -Bill
On Oct 18, 2023, at 12:21, Michele Neylon - Blacknight <michele@blacknight.com> wrote:
https://ntldstats.com/tld/desi Tiny numbers of everything -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: gtld-tech <gtld-tech-bounces@icann.org> on behalf of Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> Date: Wednesday, 18 October 2023 at 11:15 To: Bill Woodcock <woody@pch.net> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: Re: [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. 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@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@icann.org> wrote:
https://www.icann.org/en/system/files/files/common-transition-process-manual...
el
-- Sent from my iPhone On Oct 18, 2023 at 01:02 +0200, Bill Woodcock via gtld-tech <gtld-tech@icann.org>, wrote:
On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech@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@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@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.
Disclaimer (I no longer work for an EBERO), I think we need to be a little careful about calling people lazy and suggesting they are slacking off is not helpful when we aren't in possession of all the facts and decision making processes that led this and previous transitions into this space. Brett -- Brett Carr System Development Manager UK-DNS. On 18/10/2023, 15:02, "gtld-tech on behalf of Bill Woodcock via gtld-tech" <gtld-tech-bounces@icann.org <mailto:gtld-tech-bounces@icann.org> on behalf of gtld-tech@icann.org <mailto:gtld-tech@icann.org>> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. My argument isn’t that .DESI specifically does or should matter to anyone who isn’t a registrant. My argument is that if something’s worth doing, it’s worth doing well. There’s no point in being able to exercise the process for a clean roll, and not doing so. The effort is relatively trivial, and it’s good practice for when it’s needed. Always slacking off and doing dirty rolls because you’re lazy, you don’t get any practice running the necessary process, so when you do need it, you’re unprepared. That’s just bad policy. -Bill
On Oct 18, 2023, at 12:21, Michele Neylon - Blacknight <michele@blacknight.com <mailto:michele@blacknight.com>> wrote:
https://ntldstats.com/tld/desi <https://ntldstats.com/tld/desi> Tiny numbers of everything -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ <https://www.blacknight.com/> https://blacknight.blog/ <https://blacknight.blog/> Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ <https://michele.blog/> Some thoughts: https://ceo.hosting/ <https://ceo.hosting/> ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: gtld-tech <gtld-tech-bounces@icann.org <mailto:gtld-tech-bounces@icann.org>> on behalf of Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@icann.org>> Date: Wednesday, 18 October 2023 at 11:15 To: Bill Woodcock <woody@pch.net <mailto:woody@pch.net>> Cc: gtld-tech@icann.org <mailto:gtld-tech@icann.org> <gtld-tech@icann.org <mailto:gtld-tech@icann.org>> Subject: Re: [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. 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@pch.net <mailto:woody@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@icann.org <mailto:gtld-tech@icann.org>> wrote:
https://www.icann.org/en/system/files/files/common-transition-process-manual... <https://www.icann.org/en/system/files/files/common-transition-process-manual...>
el
-- Sent from my iPhone On Oct 18, 2023 at 01:02 +0200, Bill Woodcock via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@icann.org>>, wrote:
On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@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@icann.org <mailto:gtld-tech@icann.org> https://mm.icann.org/mailman/listinfo/gtld-tech <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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@icann.org <mailto:gtld-tech@icann.org> https://mm.icann.org/mailman/listinfo/gtld-tech <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284 Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
As I said, I’m not talking about .DESI specifically, as I’m well aware that I’m not in possession of all the facts. As I said, I was speaking from my observations of .WED. -Bill
On Oct 18, 2023, at 16:08, Carr, Brett via gtld-tech <gtld-tech@icann.org> wrote:
Disclaimer (I no longer work for an EBERO), I think we need to be a little careful about calling people lazy and suggesting they are slacking off is not helpful when we aren't in possession of all the facts and decision making processes that led this and previous transitions into this space.
Brett
-- Brett Carr System Development Manager UK-DNS.
On 18/10/2023, 15:02, "gtld-tech on behalf of Bill Woodcock via gtld-tech" <gtld-tech-bounces@icann.org <mailto:gtld-tech-bounces@icann.org> on behalf of gtld-tech@icann.org <mailto:gtld-tech@icann.org>> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
My argument isn’t that .DESI specifically does or should matter to anyone who isn’t a registrant.
My argument is that if something’s worth doing, it’s worth doing well. There’s no point in being able to exercise the process for a clean roll, and not doing so. The effort is relatively trivial, and it’s good practice for when it’s needed. Always slacking off and doing dirty rolls because you’re lazy, you don’t get any practice running the necessary process, so when you do need it, you’re unprepared. That’s just bad policy.
-Bill
On Oct 18, 2023, at 12:21, Michele Neylon - Blacknight <michele@blacknight.com <mailto:michele@blacknight.com>> wrote:
https://ntldstats.com/tld/desi <https://ntldstats.com/tld/desi> Tiny numbers of everything -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ <https://www.blacknight.com/> https://blacknight.blog/ <https://blacknight.blog/> Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ <https://michele.blog/> Some thoughts: https://ceo.hosting/ <https://ceo.hosting/> ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: gtld-tech <gtld-tech-bounces@icann.org <mailto:gtld-tech-bounces@icann.org>> on behalf of Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@icann.org>> Date: Wednesday, 18 October 2023 at 11:15 To: Bill Woodcock <woody@pch.net <mailto:woody@pch.net>> Cc: gtld-tech@icann.org <mailto:gtld-tech@icann.org> <gtld-tech@icann.org <mailto:gtld-tech@icann.org>> Subject: Re: [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. 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@pch.net <mailto:woody@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@icann.org <mailto:gtld-tech@icann.org>> wrote:
https://www.icann.org/en/system/files/files/common-transition-process-manual... <https://www.icann.org/en/system/files/files/common-transition-process-manual...>
el
-- Sent from my iPhone On Oct 18, 2023 at 01:02 +0200, Bill Woodcock via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@icann.org>>, wrote:
On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@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@icann.org <mailto:gtld-tech@icann.org> https://mm.icann.org/mailman/listinfo/gtld-tech <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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@icann.org <mailto:gtld-tech@icann.org> https://mm.icann.org/mailman/listinfo/gtld-tech <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
_______________________________________________ gtld-tech mailing list gtld-tech@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.
Not knowing any of the .WED facts, I could speculate that an orderly transition (clean roll) can be one of the last things on a losing registry’s mind. el -- Sent from my iPhone On Oct 18, 2023 at 16:10 +0200, Bill Woodcock via gtld-tech <gtld-tech@icann.org>, wrote:
As I said, I’m not talking about .DESI specifically, as I’m well aware that I’m not in possession of all the facts. As I said, I was speaking from my observations of .WED.
-Bill
On Oct 18, 2023, at 16:08, Carr, Brett via gtld-tech <gtld-tech@icann.org> wrote:
Disclaimer (I no longer work for an EBERO), I think we need to be a little careful about calling people lazy and suggesting they are slacking off is not helpful when we aren't in possession of all the facts and decision making processes that led this and previous transitions into this space.
Brett
-- Brett Carr System Development Manager UK-DNS.
On 18/10/2023, 15:02, "gtld-tech on behalf of Bill Woodcock via gtld-tech" <gtld-tech-bounces@icann.org <mailto:gtld-tech-bounces@icann.org> on behalf of gtld-tech@icann.org <mailto:gtld-tech@icann.org>> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
My argument isn’t that .DESI specifically does or should matter to anyone who isn’t a registrant.
My argument is that if something’s worth doing, it’s worth doing well. There’s no point in being able to exercise the process for a clean roll, and not doing so. The effort is relatively trivial, and it’s good practice for when it’s needed. Always slacking off and doing dirty rolls because you’re lazy, you don’t get any practice running the necessary process, so when you do need it, you’re unprepared. That’s just bad policy.
-Bill
On Oct 18, 2023, at 12:21, Michele Neylon - Blacknight <michele@blacknight.com <mailto:michele@blacknight.com>> wrote:
https://ntldstats.com/tld/desi <https://ntldstats.com/tld/desi> Tiny numbers of everything -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ <https://www.blacknight.com/> https://blacknight.blog/ <https://blacknight.blog/> Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ <https://michele.blog/> Some thoughts: https://ceo.hosting/ <https://ceo.hosting/> ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: gtld-tech <gtld-tech-bounces@icann.org <mailto:gtld-tech-bounces@icann.org>> on behalf of Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@icann.org>> Date: Wednesday, 18 October 2023 at 11:15 To: Bill Woodcock <woody@pch.net <mailto:woody@pch.net>> Cc: gtld-tech@icann.org <mailto:gtld-tech@icann.org> <gtld-tech@icann.org <mailto:gtld-tech@icann.org>> Subject: Re: [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. 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@pch.net <mailto:woody@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@icann.org <mailto:gtld-tech@icann.org>> wrote:
https://www.icann.org/en/system/files/files/common-transition-process-manual... <https://www.icann.org/en/system/files/files/common-transition-process-manual...>
el
-- Sent from my iPhone On Oct 18, 2023 at 01:02 +0200, Bill Woodcock via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@icann.org>>, wrote:
On Oct 17, 2023, at 21:07, Viktor Dukhovni via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@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@icann.org <mailto:gtld-tech@icann.org> https://mm.icann.org/mailman/listinfo/gtld-tech <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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@icann.org <mailto:gtld-tech@icann.org> https://mm.icann.org/mailman/listinfo/gtld-tech <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
_______________________________________________ gtld-tech mailing list gtld-tech@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@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.
Bill Woodcock via gtld-tech <gtld-tech@icann.org> writes:
My argument is that if something’s worth doing, it’s worth doing well.
"Well" is in the eyes of the user that has to depend on the zone being functional. Sometimes operational stability when a roll of any kind is difficult is more important than ensuring the zone is continually dnssec signed. You have to consider many parameters, like the length of time it would be unsigned, the possibility of an attack during that time, and the likelihood of an operational outage due to a failure because of some parameter that will cause difficulty in ensuring a proper roll. You may recall I even wrote a draft [0] on this subject that actually had a lot more support for it than I was expecting it to get. [0]: https://datatracker.ietf.org/doc/draft-hardaker-dnsop-intentionally-temporar... -- Wes Hardaker USC/ISI
On Thu, Oct 19, 2023 at 08:40:12PM -0700, Wes Hardaker via gtld-tech wrote:
My argument is that if something’s worth doing, it’s worth doing well.
"Well" is in the eyes of the user that has to depend on the zone being functional. Sometimes operational stability when a roll of any kind is difficult is more important than ensuring the zone is continually dnssec signed. You have to consider many parameters, like the length of time it would be unsigned, the possibility of an attack during that time, and the likelihood of an operational outage due to a failure because of some parameter that will cause difficulty in ensuring a proper roll.
You may recall I even wrote a draft [0] on this subject that actually had a lot more support for it than I was expecting it to get.
[0]: https://datatracker.ietf.org/doc/draft-hardaker-dnsop-intentionally-temporar...
Indeed, a potential outage during a botched rollover needs to be one of the transition plan considerations. But I think there's a case for at least seriously considering, and at the appropriate opportunity, at least once, practicing, a more graceful transition in the case of a TLD, some of whose delegated zones could alternatively be unwitting casualties of DNSSEC being turned off (they may have operational dependencies on DNSSEC being available). The question at hand is whether this was a plausible opportunity. Perhaps not this time, but ideally before an emergency operator change is required for a more critical TLD??? -- Viktor.
Pardon my ignorance, but would such a roll at transfer not require the collaboration of the losing Registry? el On 2023-10-20 05:51, Viktor Dukhovni via gtld-tech wrote:
On Thu, Oct 19, 2023 at 08:40:12PM -0700, Wes Hardaker via gtld-tech wrote: [...] Indeed, a potential outage during a botched rollover needs to be one of the transition plan considerations.
But I think there's a case for at least seriously considering, and at the appropriate opportunity, at least once, practicing, a more graceful transition in the case of a TLD, some of whose delegated zones could alternatively be unwitting casualties of DNSSEC being turned off (they may have operational dependencies on DNSSEC being available).
The question at hand is whether this was a plausible opportunity. Perhaps not this time, but ideally before an emergency operator change is required for a more critical TLD???
-- Eberhard W. Lisse \ /Obstetrician & Gynaecologist (retired) el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht\ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> writes:
Pardon my ignorance, but would such a roll at transfer not require the collaboration of the losing Registry?
[Note: though I'm on the ICANN board, I'm both not speaking for the board and I don't have any direct knowledge of the situation of this particular event in the first place -- I'm speaking purely from a technical and personal perspective only] That's certainly the core of the problem, but the answer depends on a lot of things like the signature timing of the current records, the TTLs of those records and the DS record, etc. You can do things to minimize the impact if you don't have the original DNSKEY but it may not be trivial if the timing constraints don't let you do something safer. Certainly one thing you shouldn't do at the same time is an algorithm roll, as that would increase the complexity significantly. -- Wes Hardaker USC/ISI
EBERO kicks in when the world is on fire and the registry has failed. I don’t see how you can force a failed registry to do anything -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: gtld-tech <gtld-tech-bounces@icann.org> on behalf of Wes Hardaker via gtld-tech <gtld-tech@icann.org> Date: Friday, 20 October 2023 at 11:49 To: Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> Subject: Re: [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> writes:
Pardon my ignorance, but would such a roll at transfer not require the collaboration of the losing Registry?
[Note: though I'm on the ICANN board, I'm both not speaking for the board and I don't have any direct knowledge of the situation of this particular event in the first place -- I'm speaking purely from a technical and personal perspective only] That's certainly the core of the problem, but the answer depends on a lot of things like the signature timing of the current records, the TTLs of those records and the DS record, etc. You can do things to minimize the impact if you don't have the original DNSKEY but it may not be trivial if the timing constraints don't let you do something safer. Certainly one thing you shouldn't do at the same time is an algorithm roll, as that would increase the complexity significantly. -- Wes Hardaker USC/ISI _______________________________________________ gtld-tech mailing list gtld-tech@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.
There are of course varying degrees of failure, so what you can and can’t do will differ significantly from one event to the next, flexibility on how to act is IMHO critical here. I don’t think we want the parties involved (ICANN, The EBERO and the failed registry) to air all the details in public and therefore we have to enact a certain level of trust. Brett -- Brett Carr System Development Manager UK-DNS. From: gtld-tech <gtld-tech-bounces@icann.org> on behalf of Michele Neylon - Blacknight via gtld-tech <gtld-tech@icann.org> Reply to: Michele Neylon - Blacknight <michele@blacknight.com> Date: Friday, 20 October 2023 at 10:53 To: Wes Hardaker <wjhns1@hardakers.net>, Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> Subject: RE: [EXTERNAL] [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. EBERO kicks in when the world is on fire and the registry has failed. I don’t see how you can force a failed registry to do anything -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: gtld-tech <gtld-tech-bounces@icann.org> on behalf of Wes Hardaker via gtld-tech <gtld-tech@icann.org> Date: Friday, 20 October 2023 at 11:49 To: Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> Subject: Re: [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> writes:
Pardon my ignorance, but would such a roll at transfer not require the collaboration of the losing Registry?
[Note: though I'm on the ICANN board, I'm both not speaking for the board and I don't have any direct knowledge of the situation of this particular event in the first place -- I'm speaking purely from a technical and personal perspective only] That's certainly the core of the problem, but the answer depends on a lot of things like the signature timing of the current records, the TTLs of those records and the DS record, etc. You can do things to minimize the impact if you don't have the original DNSKEY but it may not be trivial if the timing constraints don't let you do something safer. Certainly one thing you shouldn't do at the same time is an algorithm roll, as that would increase the complexity significantly. -- Wes Hardaker USC/ISI _______________________________________________ gtld-tech mailing list gtld-tech@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. Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284 Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
On Oct 20, 2023, at 11:52, Michele Neylon - Blacknight via gtld-tech <gtld-tech@icann.org> wrote: =I don’t see how you can force a failed registry to do anything
You probably can’t. But that wasn’t the topic of conversation. The topic of conversation was whether EBERO registries should follow best practices and do clean rolls when they’re requested to by a prepared outgoing registry. The document says “should.” My argument was that if they do it when requested, it will exercise a process, and then they’ll be ready to do it when it’s most needed, regardless of their opinion of the needs of the registrants. -Bill
While the registry failed, the back-end/RSP didn't. CentralNIC/Team Internet, Nominet and ICANN could have arranged for a smoother transition DNSSEC-wise. Rubens
On 20 Oct 2023, at 11:52, Michele Neylon - Blacknight via gtld-tech <gtld-tech@icann.org> wrote:
EBERO kicks in when the world is on fire and the registry has failed. I don’t see how you can force a failed registry to do anything
-- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours.
From: gtld-tech <gtld-tech-bounces@icann.org <mailto:gtld-tech-bounces@icann.org>> on behalf of Wes Hardaker via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@icann.org>> Date: Friday, 20 October 2023 at 11:49 To: Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org <mailto:gtld-tech@icann.org>> Subject: Re: [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program
[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.
Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> writes:
Pardon my ignorance, but would such a roll at transfer not require the collaboration of the losing Registry?
[Note: though I'm on the ICANN board, I'm both not speaking for the board and I don't have any direct knowledge of the situation of this particular event in the first place -- I'm speaking purely from a technical and personal perspective only]
That's certainly the core of the problem, but the answer depends on a lot of things like the signature timing of the current records, the TTLs of those records and the DS record, etc. You can do things to minimize the impact if you don't have the original DNSKEY but it may not be trivial if the timing constraints don't let you do something safer. Certainly one thing you shouldn't do at the same time is an algorithm roll, as that would increase the complexity significantly.
-- Wes Hardaker USC/ISI _______________________________________________ gtld-tech mailing list gtld-tech@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@icann.org <mailto:gtld-tech@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.
Who has the credentials to the RZM? The backend operator maybe in practice but not by design? el -- Sent from my iPhone On Oct 20, 2023 at 12:53 +0200, Rubens Kuhl via gtld-tech <gtld-tech@icann.org>, wrote:
While the registry failed, the back-end/RSP didn't. CentralNIC/Team Internet, Nominet and ICANN could have arranged for a smoother transition DNSSEC-wise.
Rubens
On 20 Oct 2023, at 11:52, Michele Neylon - Blacknight via gtld-tech <gtld-tech@icann.org> wrote:
EBERO kicks in when the world is on fire and the registry has failed. I don’t see how you can force a failed registry to do anything
-- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845
I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours.
From: gtld-tech <gtld-tech-bounces@icann.org> on behalf of Wes Hardaker via gtld-tech <gtld-tech@icann.org> Date: Friday, 20 October 2023 at 11:49 To: Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> Subject: Re: [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.
Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> writes:
Pardon my ignorance, but would such a roll at transfer not require the collaboration of the losing Registry?
[Note: though I'm on the ICANN board, I'm both not speaking for the board and I don't have any direct knowledge of the situation of this particular event in the first place -- I'm speaking purely from a technical and personal perspective only]
That's certainly the core of the problem, but the answer depends on a lot of things like the signature timing of the current records, the TTLs of those records and the DS record, etc. You can do things to minimize the impact if you don't have the original DNSKEY but it may not be trivial if the timing constraints don't let you do something safer. Certainly one thing you shouldn't do at the same time is an algorithm roll, as that would increase the complexity significantly.
-- Wes Hardaker USC/ISI _______________________________________________ gtld-tech mailing list gtld-tech@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@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@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.
In my experience this is often split between two organisations to provide separation, but this is I think not always the case. YMMV. Brett -- Brett Carr System Development Manager UK-DNS. From: gtld-tech <gtld-tech-bounces@icann.org> on behalf of Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> Reply to: Dr Eberhard W Lisse <el@lisse.na> Date: Friday, 20 October 2023 at 14:41 To: "Hollenbeck, Scott via gtld-tech" <gtld-tech@icann.org> Subject: RE: [EXTERNAL] [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Who has the credentials to the RZM? The backend operator maybe in practice but not by design? el -- Sent from my iPhone On Oct 20, 2023 at 12:53 +0200, Rubens Kuhl via gtld-tech <gtld-tech@icann.org>, wrote: While the registry failed, the back-end/RSP didn't. CentralNIC/Team Internet, Nominet and ICANN could have arranged for a smoother transition DNSSEC-wise. Rubens On 20 Oct 2023, at 11:52, Michele Neylon - Blacknight via gtld-tech <gtld-tech@icann.org> wrote: EBERO kicks in when the world is on fire and the registry has failed. I don’t see how you can force a failed registry to do anything -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: gtld-tech <gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org>> on behalf of Wes Hardaker via gtld-tech <gtld-tech@icann.org<mailto:gtld-tech@icann.org>> Date: Friday, 20 October 2023 at 11:49 To: Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org<mailto:gtld-tech@icann.org>> Subject: Re: [gtld-tech] .DESI to Be Placed in the Emergency Back-end Registry Operator Program [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. Dr Eberhard W Lisse via gtld-tech <gtld-tech@icann.org> writes:
Pardon my ignorance, but would such a roll at transfer not require the collaboration of the losing Registry?
[Note: though I'm on the ICANN board, I'm both not speaking for the board and I don't have any direct knowledge of the situation of this particular event in the first place -- I'm speaking purely from a technical and personal perspective only] That's certainly the core of the problem, but the answer depends on a lot of things like the signature timing of the current records, the TTLs of those records and the DS record, etc. You can do things to minimize the impact if you don't have the original DNSKEY but it may not be trivial if the timing constraints don't let you do something safer. Certainly one thing you shouldn't do at the same time is an algorithm roll, as that would increase the complexity significantly. -- Wes Hardaker USC/ISI _______________________________________________ gtld-tech mailing list gtld-tech@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@icann.org<mailto:gtld-tech@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@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. Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284 Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
participants (8)
-
Bill Woodcock -
Carr, Brett -
Dr Eberhard W Lisse -
Francisco Arias -
Michele Neylon - Blacknight -
Rubens Kuhl -
Viktor Dukhovni -
Wes Hardaker