[ Top post ] Integrating these -- 'parently I'm processing emails out of order...
Thank you for your comments, I've integrated them and will post a new version soon (planning on incorporating some of Jinmei's comments before posting). On Tue, May 5, 2015 at 5:53 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > 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. > Thanks. > 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. DONE? "It is important to confirm that the comains is still under the ownership / control of the legitimate owner of the domain - this is to ensure that disabling validation for a specific domain does not direct users to an address under an attackers control. Contacting the domain owner allows the resolver operator to determine if the issue is a DNSSEC misconfiguration or an attack." I'm not really sure if this addresses your concerns? If not, do you happen to have any suggested text? > > 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. DONE. I added: "An example of a list of "top N" websites is the <xref target="Alexa">"Alexa Top 500 Sites on the Web" </xref>" Is this OK? > > 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". > DONE. I was going to add some hand-wavy bit about the fact that DNSSEC is an "added feature" and that the behavior differs based upon if you have turned validation on or not, but this didn't feel helpful, so I just used your text. Thanks. > 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." DONE. Thank you. > > 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". DONE. I'm fairly jetlagged, and it took me a silly amount of time to parse the suggested name :-) Yay autocorrect. > > 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. DONE. It had felt more "Appendixy" to me, but I don't know why. Moved it into the body of the doc. > > References to other documents are done inconsistently. For example, there is > both "from RFC4033 [RFC4033]" and "in [RFC5914]". DONE. Thank you, and apologies for the delay. W > > --Paul Hoffman > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
