[DNSOP] Re: SECDIR IETF LC review of draft-ietf-dnsop-ds-automation-05

[[e-mail]]

Hi Donald,

Thank you for the review. I trust the authors will follow up soon.

Adding the WG list so that DNSOP is aware of this review.

Cheers,
Med

De : Donald Eastlake <[e-mail]>
Envoyé : lundi 11 mai 2026 01:18
À : [e-mail]
Cc : secdir <[e-mail]>; [e-mail]; Last Call <[e-mail]>
Objet : SECDIR IETF LC review of draft-ietf-dnsop-ds-automation-05



I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is Ready with issues.

This Best Current Practice draft provides operational recommendations for DNSSEC DS automation. Although it concerns DNSSEC automation, this is much more of an operations BCP than a security BCP. It has an interesting structure where Sections 4, 5, 6, and 7, which are the heart of the document, each start with a number of operations questions that are addressed by that section. A copy of the recommendations in those sections is then gathered together and listed in Appendix A.

# Security

I believe there are security threats addressed by this document but it seems to mostly focus on potential operational problems of "inconsistency" and "unexpected and confusing" behavior. It might be useful to give some examples of security problems that can be caused by ignoring these recommendations or, if you are sure, to state that there are none (which I doubt). How do these recommendations interact with the compromise of various of the parties in the RRR model or with an on-path attacker?

# Minor

Section 4.2.2, last paragraph: Wouldn't there be some advantage to lowering the TTL of the old DS RRset if you did so early enough before the DS update?

Section 4.2.3, last paragraph: I found this paragraph a little hard to understand. What exactly does "Child DNS operators are held responsible for publishing contradictory information" mean? Isn't it just that when a Child DNS operator publishes contradictory information, the parent rejects it? Also, doesn't a parent always have the power to publishes whatever DS or other records it wants?

Section 5.1, point 3: Since there are specific recommendations in many other cases, can something specific be said rather than "unnecessarily frequently"? Like, for example, "a few times initially and once a day thereafter".
On the other hand, Section 5.2, next to last paragraph says "no more than twice in in a row" so maybe that is what is meant.

Section 5.2, after the numbered points: Consistent with the tone of other parts of this document, I suggest "would be justified to attempt communicating" -> "SHOULD communicate"

Section 7.1, point 1: "SHOULD" -> "MUST" ?

Section 7.2.3, 1st paragraph: I understand the basis for saying DS flapping will only occur for a limited period of time. Is that the only basis for saying it will only be a minor nuisance?

# Nits

Section 3, 2nd paragraph, first sentence. Not grammatical. Simplest change would be to delete "as" but it is also too wordy. Suggest shortening to "Recommendations in this document optimize interoperability and safety."

Section 4.1 point 1a and Appendix A.1, point 1a: "ambigious" -> "ambiguous"

Section 4.2.1, first line of last paragraph: perhaps the "may" should be "MAY".

Section 6.2.2, last line: Some superfluous waffle wording here. "It therefore appears that DS initialization and rollovers should ..." -> "DS initialization and rollovers SHOULD ..."

Section 7.1, point 5: "has declared to be performing automated" -> "has declared it performs automated"

Section 7.2.1, 1st paragraph, 2nd sentence: "the key used by for authentication" -> "the key used for authentication"

Section 7.2.2, 2nd paragraph: suggest "It is therefore advised to not follow this practice." -> "This practice is NOT RECOMMENDED."

Section 7.2.2, 4th paragraph: ends with a parenthetical where I believe the parens are not needed. Check for other cases of this in the document.

Section 11: Spell out SSAC on first use.

# .sig

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]<mailto:[e-mail]>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.