On Thu, Sep 22, 2016 at 08:19:17AM -0400, Tim Wicinski <tjw.i...@gmail.com> wrote a message of 31 lines which said:
> This starts a Working Group Last Call for: > "Aggressive use of NSEC/NSEC3" > draft-ietf-dnsop-nsec-aggressiveuse I like the basic idea and I think the document is good but I would not like it to be published as it is (-02). My biggest concern is that it seems the original idea was to mention only the synthesis of _negative_ replies (NXDOMAIN), _positive_ replies (synthesis from a wildcard) were mentioned for a long time in the draft but never fully integrated. Section 7 mentions this synthesis of positive answers but, for instance, the abstract, the section 1, section 3, the first paragraph of section 5.5, and the first paragraph of section 9 do not mention the positive answers, but they should (they seem to assume that only negative caching matters). Either we need to match the document to put the synthesis of negative and positive answers on an equal footing, or we should delete the synthesis of positive answers from wildcards. Related to this issue is the fact that the proposed updated text for RFC 4035 is not the same in section 5.1 and in section 7... Another concern is section 9 which says "Aggressive use of NSEC / NSEC3 resource records without DNSSEC validation may cause security problems. It is highly recommended to apply DNSSEC validation." Not only it fails to use RFC 2119 but allowing NXDOMAIN synthesis without DNSSEC validation seems dangerous. Why not a MUST instead of the current "informal SHOULD"? Details ******* IMHO, it should say from the beginning that this document is only for validating resolvers. (It is not in section 1, for instance.) Editorial ********* Section 1 says "This document updates RFC 4035 to allow recursive resolvers to use NSEC/NSEC3 resource records to aggressively cache negative answers." It would be more descriptive, IMHO, to say "This document updates RFC 4035 to allow recursive resolvers to use NSEC/NSEC3 resource records to synthetize negative answers from the information they have in the cache." (It is an aggressive use of the cache, not aggressive caching.) Bikeshedding ************ Section 5.2 says "Implementations SHOULD provide a configuration switch to disable aggressive use of NSEC and allow it to be enabled or disabled per domain." Such as switch (the per-domain one) seems costly and I would prefer a MAY here. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
