On Wed, Nov 16, 2016 at 3:09 PM, Ondřej Surý <ondrej.s...@nic.cz> wrote: > Hi, > > I read the document and I believe that the document goes to far > to recommend the vendors how to implement the knobs in their > software here: > > It is recommended that resolvers that implement Aggressive Negative > Caching provide a configuration switch to disable the feature. > Separate configuration switches may be implemented for the aggressive > use of NSEC, NSEC3 and wildcard records, and it is recommended to > enable aggressive negative caching by default. > > I would recommend (not strongly) dropping this paragraph. And if not > dropping provide a rationale for such recommendation. (And I am sorry > if this has been rehashed and the rational can be found in the archive. > In that case, the msg-id would be appreciated.) >
Ok (I read further downthread as well, and multiple people support this). DONE. > ~~~ > (nit) missing whitespace in Section 5.4. third paragraph: > s/RFC2308]also/RFC2308] also/ Thank you. DONE > > ~~~ > Section 5.4, fourth paragraph, first line: should or SHOULD to match > RECOMMENDED in second paragraph same section? SHOULD seems right (based upon other comments too) DONE > ~~~ > (nit) Section 6: s/authorative/authoritative/ Also caught by someone else. DONE > > ~~~ > I think a small text to recommend signing domains because of increased > protection would be nice in Section 6. I am happy to provide text if > the authors poke me when I am not jet-lagged. I just added: "As these benefits are only accrued by those using DNSSEC, it is hoped that these techniques will lead to more DNSSEC deployment." Additional / other suggestions welcome. DONE > > ~~~ > (nit) Appendix B: s/NXDOMAN/NXDOMAIN/ > > ~~~ > It's unclear what Appendix B means by "discard it". Does it mean "proceed as > normal" > or "delete it from cache and proceed as normal"? Could you please clarify > the text > in the draft? This is originally MarkA's text (CCed). I'm assuming what was meant was: If the NSEC record has not been verified as secure it should be discarded, and not placed in the cache. (as far as I can tell, non-secure NSECs should never make it into cach.... oh, huh, an NSEC in a non-signed zone is still a valid RR, and so it could be in the cache... so I guess it should simply be ignored... so, proceed an normal?! I've confused myself.... Now I think it should be "If the NSEC record has not been verified as secure it should be ignored". Mark? > > Also 'ENT' is a abbreviation neither defined anywhere else nor explained in > this > document. How is: This procedure outlines how to determine if a given name does not exist, or is an ENT (Empty Non-Terminal, see "RFC5155" Section 1.3) > > ~~~ > I would also welcome if Sections 5.1, 5.2 and 5.3 had specific examples, > either > in the respective sections or in separate Section or as a part of Appendix B. This seems like it would be really hard to capture in a readable form. I'd welcome any assistance that people might have here (i could say something like "Referring to the first example in Section 3, if the resolver were to get a query for ball.example.com, and already had an NSEC record covering albatross.example.com to elephant.example.com it should use this information to synthesize a negative answer", but this is a: imprecise, b: wordy and c: not (IMO) particularilty helpful). Happy to take any donated text. not done. > > ~~~ > Otherwise the rest of the document is in good shape (if not I blame lack of > sleep) > and I would be happy to review next revision. In case I am silent bug me > until > I do the review. Thank you. I have integrated these and posted a new version on Github: https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse I have not yet pushed a new version to the IETF as I'm trying to integrate suggestions as I get them. Please let me know if these work for you, and I'll push a new version once I've incorporated more comments. W > > Cheers, > -- > Ondřej Surý -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.s...@nic.cz https://nic.cz/ > -------------------------------------------- > > ----- Original Message ----- >> From: internet-dra...@ietf.org >> To: i-d-annou...@ietf.org >> Cc: "dnsop" <dnsop@ietf.org> >> Sent: Wednesday, 16 November, 2016 03:41:29 >> Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations of the IETF. >> >> Title : Aggressive use of NSEC/NSEC3 >> Authors : Kazunori Fujiwara >> Akira Kato >> Warren Kumari >> Filename : draft-ietf-dnsop-nsec-aggressiveuse-06.txt >> Pages : 16 >> Date : 2016-11-15 >> >> Abstract: >> The DNS relies upon caching to scale; however, the cache lookup >> generally requires an exact match. This document specifies the use >> of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers >> to generate negative answers within a range, and positive answers >> from wildcards. This increases performance / decreases latency, >> decreases resource utilization on both authoritative and recursive >> servers, and also increases privacy. It may also help increase >> resilience to certain DoS attacks in some circumstances. >> >> This document updates RFC4035 by allowing validating resolvers to >> generate negative based upon NSEC/NSEC3 records (and positive answers >> in the presence of wildcards). >> >> [ Ed note: Text inside square brackets ([]) is additional background >> information, answers to frequently asked questions, general musings, >> etc. They will be removed before publication.This document is being >> collaborated on in Github at: https://github.com/wkumari/draft-ietf- >> dnsop-nsec-aggressiveuse. The most recent version of the document, >> open issues, etc should all be available here. The authors >> (gratefully) accept pull requests.] >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-aggressiveuse-06 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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
