Hi, On 07.08.25 20:04, Hollenbeck, Scott wrote:
-----Original Message----- From: Peter Thomassen <[email protected]> Sent: Thursday, August 7, 2025 1:25 PM To: Q Misell <[email protected]>; dnsop <[email protected]> Subject: [EXTERNAL] [DNSOP] Re: serverUpdateProhibited and draft-shetho- dnsop-ds-automationCaution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Q, On 7/25/25 12:05, Q Misell wrote:Dearest fellow DNS sufferers,:-)My issue with the draft is on its recommendations for registry lock,particularly:"Automated DS maintenance SHOULD be suspended when a registry lock isset (in particular, EPP lock serverUpdateProhibited)"I don't like this. serverUpdateProhibited is normally utilised to preventchanging the registrant of a domain, or changing (non-DNSSEC) nameservers - primarily in the case of a malitious party getting access to a registar's EPP connection. However, in the case of a CDS key rollover we know the key rollover is intentional, as it is cryptographically signed. This may be an option, if the automation is performed by the registry. However, do you think DS automation done by the registrar is compatible with a registry lock à la serverUpdateProhibited?[SAH] It may help to review what RFC 5731 says about the status: "Requests to update the object (other than to remove this status) MUST be rejected." The intention is to ensure that no one but the EPP server operator is able to update the domain object. This can happen for protection reasons (such as described above), but it can also happen for other reasons, like non-payment of fees. If the EPP server operator says "no updates", the best approach is to honor that. Work with the server operator to remove the status if it's an issue for a CDS key rollover.
PK> I assume this comment applies to the EPP interface and I agree if the server applies a lock it would be bad to add another interpretation to it, like that the registrar can still make changes to some parts. Registry lock is typically a mitigation method to prevent unintended changes to the domain configuration even by the registrar, or is related with some other workflows to perform such change.
For the situation if the DNSSEC automation is done by the registry, such limitation shall not apply however the behaviour is also not warranted in any way. Unless it is regulated by some other policies, the operator may decide to perform automation despite lock applied, or not. Some may tell "yes, but..." and apply the same workflow as with any other change, for example with off-band confirmation of other second factor.
From this perspective I would agree with Q that the first recommendation in 4.1 is not needed if the automation is done by the registry, unless the intention of this text is to say very conservative approach that the behaviour cannot be guaranteed so better do rollover "old style" manually, which would also mean removing the reason of the lock. In practice it would mean more to stop key rollover, rather than just the DNSSEC automation.
On the other hand it would be more useful for this draft to recommend for the registry operators to allow for DNSSEC automation (bootstrapping excluded) even if registry lock applied. It would be at least interesting to see if there could be consensus around such recommendation.
Kind
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
