Dear WG,
I presented this draft at the CENTR Tech meeting today. With respect to the
recommendation quoted below, something interesting was proposed by participants
(paraphrasing):
"If a registrar does not support DS management at all, perhaps that's an
*extra* reason for the registry to perform DS automation, so that the
zone owner can turn it on despite the registrar's lack of support!"
So, while in this case you can get stuck*, you get DNSSEC enrollment even for
registrars with zero DNSSEC support. The price is that you loose the emergency
exit when you need to go insecure.
These proposals are pretty much the opposite of each other. Which goal is more
important?
Do we need to favor one proposal because of interoperability arguments? (I
guess such can be made for both proposals.)
Thanks,
Peter
* stuck: may not be able to disable DNSSEC, e.g., if you lost access to your key so you
can't sign a CDS "delete" signal.
On 10/13/25 20:17, Peter Thomassen wrote:
Hi,
One more discussion point spun up last week at OARC, namely about the following
recommendation in draft-ietf-dnsop-ds-automation. I'd again be delighted to
learn your views.
Section 5.1:
5. In the RRR model, registries SHOULD NOT perform automated DS
maintenance if it is known that the registrar performs this
function, or does not support DNSSEC at all.
It was argued that this recommendation -- especially the last part -- is
unnecessary, and if the registrar doesn't provide a DS interface, then the
registrant should switch registrars.
However, consider the following draft text:
5.2.1. Necessity of Non-automatic Updates
[...] when the registrar is known to not support DNSSEC (or to
lack a DS provisioning interface), it seems adequate for registries
to not perform automated DS maintenance, in order to prevent
situations in which a misconfigured delegation cannot be repaired by
the registrant.
A practical example is the following list of events:
a) Registrant opted into DNSSEC service with an operator that publishes
CDS/CDNSKEY records;
b) Registry has seen those records and provisioned a DS RRset;
c) DNS operator goes into hiding (does not respond to customer requests, but
DNS service still works).
In this case, the registrant
- can't do a secure transition, because keys change;
- also can't publish a CDS-delete record to go insecure.
The last resort then is to turn off DNSSEC through the registrant's manual
interface.
But if that doesn't exist, not even a "turn it all off" button: should we tell
the registrant to change registrars? or should the DS automation in step (b) perhaps not
have occurred?
What do you think?
Thanks,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Möckernstraße 74
10965 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
