I have some small concerns on 5.4. Consideration on TTL I think the language needs to be clearer that if you are in the position of reading the NSEC3 state and the TTL you receive is value <x> that the TTL you assert cannot be longer than <x> and needs very probably to be <x> minus some period of time.
the 'maximum 3 hours' thing I worry implies you can span over the NSEC3 projected gap by any time you like. If you get told "for the next 20 seconds nothing exists betwewn a and b" then I don't think this TTL can be longer than 20 seconds. -G 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.) > > ~~~ > (nit) missing whitespace in Section 5.4. third paragraph: > s/RFC2308]also/RFC2308] also/ > > ~~~ > Section 5.4, fourth paragraph, first line: should or SHOULD to match > RECOMMENDED in second paragraph same section? > ~~~ > (nit) Section 6: s/authorative/authoritative/ > > ~~~ > 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. > > ~~~ > (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? > > Also 'ENT' is a abbreviation neither defined anywhere else nor explained in > this > document. > > ~~~ > 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. > > ~~~ > 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. > > 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 > > _______________________________________________ > 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
