Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

[Paul Hoffman <[e-mail]>]

This document has progressed very well and is nearly ready for publication.

Related to an earlier thread about intended status: "Informational" is most appropriate here because the document is all about proposed operations but no "best current practice". There is no problem with WGs producing Informational RFCs, and Informational RFCs can have RFC 2119 language.

In Section 2, there should be a new paragraph after the first paragraph that describes why the "reasonable attempt" in the first paragraph is needed to determine whether the attacker has partial control of the zone, or is just mounting an on-path attack between all the nameservers and the recursive.

In Section 2, it talks about "a popular domain name" but don't say how to determine that. Giving examples of sources of that data would be valuable.

Section 5 is one paragraph too short. It says what other misconfigurations should not be fixed by recursive resolver operators, but it does not say why likely DNSSEC validation errors should be. The (missing) second paragraph should say something to the effect of "with DNSSEC breakage, it is often possible to tell that there is a misconfiguration by looking at the data and not needing to guess what it should have been".

In Section 6, add a second sentence to the second paragraph: "Such additions are prevented by the requirement that the operator attempt to contact the administrators for the zone that has broken DNSSEC."

In Section 7.1, the second paragraph is *not* a security consideration, it is a proposal for how NTAs should be implemented. Please make this its own section earlier in the document, possibly called "Altering Users of NTA Use".

There is no stated reason for Appendix B to be an appendix. It is just as important as other sections in the main body of the text, and should be moved there.

References to other documents are done inconsistently. For example, there is both "from RFC4033 [RFC4033]" and "in [RFC5914]".

--Paul Hoffman