Hi, This document looks almost good to me. I have some nit comments.
- Page 3, Section 1, says a DNS negative cache is used to cache the fact that a name does not exist. But it also caches if the name is valid but there are no records for the type. Perhaps: "..., and is used to cache the fact that a RRset does not exist." - On Page 4, Section 3: Now, assume that the (DNSSEC signed) "example.org" zone contains: The "Now" reads as, "Now what if". Perhaps: "Another example: assume that the..." - Page 5, Section 4 and 5 has a lot of duplication: It both quotes RFC the same section of 4035 and both relaxes the recommendations given there. It is even repeated a third time in Section 7. I think this redundancy can be removed - Page 9, Section 9, has another recommendation for implementations with respect to configurations (for maximum ttl of NSEC records in the NCACHE). Either remove the line or relax it. - Page 15, Appendix B has acknowledgements to Mark which I believe belong in Section 11 which is appropriately titled "Acknowledgements". Also this section only gives guidance on NSEC. I have made a PR that deals with these nits. Feel free to merge or cherry pick: https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/pull/5 Best regards, Matthijs On 16-11-16 03:41, internet-dra...@ietf.org wrote: > > 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 > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
