On Wed, Nov 16, 2016 at 5:51 PM, Matthijs Mekking <matth...@pletterpet.nl> wrote: > Hi Ondřej, > > On 16-11-16 07:09, Ondřej Surý 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.) > > > I am in favor of dropping the paragraph, though it is already better than it > was before (with RFC 2119 keywords). >
Ask and ye shall receive! DONE (as part of the Ondrej set above). W > See these messages for a previous discussion on this topic: > > https://www.ietf.org/mail-archive/web/dnsop/current/msg18252.html > https://www.ietf.org/mail-archive/web/dnsop/current/msg18254.html > https://www.ietf.org/mail-archive/web/dnsop/current/msg18254.html > > > Best regards, > Matthijs > > > > >> ~~~ >> (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 -- 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
