Document: draft-ietf-dnsop-ds-automation Title: Operational Recommendations for DNSSEC Delegation Signer (DS) Automation Reviewer: James Gannon Review result: Ready with Issues
DNSDIR telechat review of draft-ietf-dnsop-ds-automation-06 Hi Folks, I am the assigned DNS Directorate reviewer for this revision of the draft. Please treat these comments like any other IETF Last Call comments. Document: draft-ietf-dnsop-ds-automation-06 Reviewer: James Gannon Review Date: 2026-05-12 Review Result: Ready with Issues The document is useful, well structured, and operationally valuable. The recommendations are clear overall, and the Appendix A summary is especially helpful. Most previous Last Call review comments appear to have been addressed in `-06`; however, I think a few issues remain, primarily around the Security Considerations and some unresolved review comments from the SECDIR review. Major issues: 1. Section 10, Security Considerations, is too thin. The document is explicitly about operational practices that affect DNSSEC validation and delegation reachability. Section 10 currently says that security considerations are discussed throughout the document, but it does not summarize the threat model or provide concrete examples. I think this section should briefly discuss at least: - compromise or misbehavior of the child DNS operator; - compromise or misbehavior of registrar or registry-side automation in the RRR model; - on-path interference with CDS/CDNSKEY discovery or report/notification flows; - how consistency checks, DNSSEC validation, reporting, and audit records mitigate those risks; - residual risks when the recommendations are not followed. This would also address the main unresolved SECDIR concern. Minor issues: 1. Section 5.1 recommendation 3 says humans should not be notified “unnecessarily frequently”. This is directionally right, but vague for a BCP. Consider adding a concrete upper-bound example or guidance, such as notifying a few times initially and then no more than daily while the same condition persists. 2. Section 5.2 says that in the latter two cases, it “would be justified to attempt communicating” using RFC 9567. This seems weaker than the rest of the document’s recommendation style. If these are the reportworthy error cases, consider changing this to a `SHOULD`. 3. Section 7.1 recommendation 1 says registries and registrars `SHOULD` provide another channel for DS maintenance. Given that this is necessary for recovery when the child has lost access to signing keys, I suggest considering whether this should be `MUST`, or explaining why `SHOULD` is intentionally sufficient. 4. Section 7.2.3 characterizes DS flapping from concurrent automatic updates as a “minor nuisance”. The text explains why validation is not expected to break, but there may still be operational impact from churn, logs, notifications, rate limits, or registry/registrar side effects. Consider qualifying the statement or adding that operators should monitor and dampen repeated churn. Nits: - Section 3: “Recommendations given in this document are optimized as to maximize…” is awkward. Consider “Recommendations in this document optimize interoperability and safety.” - Section 4.2.2: “For the sake of completeless” should be “For the sake of completeness”. - Section 7.1 point 5: “has declared to be performing automated” could be “has declared it performs automated”. - Section 7.2.1: “the key used by for authentication” should be “the key used for authentication”. - Section 7.2.2: “It is therefore advised to not follow this practice” could be “This practice is NOT RECOMMENDED.” - Section 11: expand SSAC on first use. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
