Hi Oli,
On 10/15/25 12:48, Oli Schacher wrote:
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.
The current phrasing assumes that registries somehow know which registrars
support DNSSEC and what that support entails.
The text does not assume that; it says: "if it is known". In other words, if
you don't know, the recommendation is no-op.
While indeed in many cases the registry might not know, there are cases where
they actually do know. One case coming to mind is when the registry offers
publication of a DSYNC record for directing NOTIFY(CDS) to the registrar (RFC
9859 Section 3.2). In this case, the registry knows that the registrar is in
charge and can disable automation.
In my experience, that is rarely the case. Technically, every registrar can
modify the DS RRset — there is an EPP command for that.
Some registrars simply choose not to expose this functionality in their
customer interfaces, but their backend support should still be able to execute
it upon a registrant’s request.
That's true, of course; the recommendation is essentially a safety provision.
The question I think is whether the problem is large enough to warrant a safety
measure.
My view is that we should try hard to prevent situations in which DNSSEC
misconfigurations may occur or where fixes are slow -- because misconfiguration
impact on a zone is rather large, and related outages (rightly) have damaged
DNSSEC's reputation. I'm not concerned about the reputation as a goal in
itself; rather, if misconfigurations cause lots of reputational damage, then it
appears to me that users really want us to err on the side of caution.
But, there are other views, as I've just reported in another message:
https://mailarchive.ietf.org/arch/msg/dnsop/_VrBMx6rZ1YjyYtmGUDZaKencSg/
Speaking with an editor hat, I'm at a loss what to do with this recommendation
(keep, remove, or even invert?).
I’m not sure how registries could maintain an accurate list of registrars that
are unable or unwilling to process DS changes for their customers, or how such
a list could be kept up to date.
I don't think that is necessary.
In practice, we usually only discover these cases when it’s already too late —
for example, when automated DS maintenance has occurred, something breaks, and
the registrar cannot or will not assist in fixing it.
At that point, we can disable DS automation for that registrar to prevent
future issues, but we still need a process to repair existing broken
delegations. In most cases, that means the registry directly removes the DS
records at the registrant’s request.
Sure!
Here is an alternative suggestion that takes this situation into account:
"5. In the RRR model, registries SHOULD provide a process to remove DS records
at the explicit request of the registrant if the registrar is unable to remove or
update DS records.
I completely agree with this goal. However, I believe this recommendation goes
beyond the scope of this document (which is restricted to how to implement
automation, not manual interfaces), and I'm also skeptical whether it would sit
well with gTLD operators. -- I'll try to gather some feedback.
Registries SHOULD disable automated DS maintenance for any registrar that is known
to be unable to manage DS records until such support has been confirmed."
Given this suggested wording, I'm afraid I didn't quite understand what you are
trying to change / object to. Isn't this essentially the same as (the second
part of) the existing recommendation?
Thanks,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
