At Tue, 13 Dec 2016 14:13:27 -0500, tjw ietf <tjw.i...@gmail.com> wrote:
> We felt another formal Working Group Last call was needed, though hopefully > shorter. > > This starts a Working Group Last Call for: > "Aggressive use of NSEC/NSEC3" > draft-ietf-dnsop-nsec-aggressiveuse > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ [...] > Please review the draft and offer relevant comments. Also, if someone feels > the document is *not* ready for publication, please speak out with your > reasons. > > This starts a *one* week Working Group Last Call process, and ends at > midnight 20 December 2016 UTC. A bit belated, but I've read the 07 version. I'm not necessarily opposed to advancing it, but I personally it's better to spend some more time to bake it. The main reason is because the latest change to describe the aggressive use of deduced wildcards with an equal weight is quite substantial while I suspect many of the reviewers now only gave a quick sanity check to confirm whether specific technical details are addressed. On a relatively fresh read after some period, I found the 07 version somewhat awkward in some places due to the latest change (specific comments follow). Similarly, it's not clear to me whether it now includes the idea of aggressive use of NSEC/NSEC3 for returning NOERROR/NODATA? I see a new sentence in Section 4: Proof that a type does not exist is accomplished by providing a (DNSSEC secured) record containing the queried for name, and a type bitmap which does not include the requested type. but, overall, it still seems to only assume the NXDOMAIN type of negatives (see, e.g, a comment on Section 6 below). If the intent is to also support NOERROR/NODATA, I think we need another round of overall updates (mostly an editorial effort, but not trivial). Another reason for the wish of having some more discussion is that I think the described justification for changing the recommendation in RFC4035 is still weak (although I don't disagree with the change itself). Section 4 states: We believe this recommendation can be relaxed because, in the absence of this technique, a lookup for the exact name could have come in during this interval, and so a negative answer could already be cached (see [RFC2308] for more background). But this argument has always been the case including when RFC4035 was written. As RFC4035 still made this recommendation... In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace. ...I'd logically expect some new argument that was not true or not recognized at the time of RFC4035 if we wanted to revise the recommendation. Examples of such a new argument include: - some statistics that shows "a lookup for the exact name comes in during this interval" more often than previously expected, so it turns out the old recommendation really doesn't help much. - the benefits of the aggressive use of NSEC(3)/deduced wildcards are now considered so big that they outweigh the prudence recommended in RFC4035. I'd like to see something like these with convincing facts or rationale in Section 4. Specific comments: - Title: "Aggressive use of NSEC/NSEC3" I think this should now be e.g., "Aggressive use of DNSSEC-validated cache" because of the equal weight given to the aggressive use of deduced wildcards. Even if the aggressive use of NSEC/NSEC3 can be used as part of steps to use a deduced wildcard aggressively (i.e., to confirm the query name wouldn't exist without the wildcard), the aggressive use of deduced wildcard has its own "aggressiveness" with its own caveats. For example, in addition to the case where the wildcard-matched name is added to the zone, we also take the risk of not returning a negative answer sooner when the wildcard is removed. So I think this document should now use both NSEC/NSEC3 (for negative) and wildcard (for positive) equally when it says "aggressive use of XXX". The above example suggestion is one attempt to do this. And, if this suggestion makes sense, it should apply throughout the document (this is one reason why it's better to spend some more time before shipping it). - Section 4 queried for name. In the first example above, if the (DNSSEC validating) recursive server were to query for dog.example.com it In this context I don't see why this has to be a recursive server. I also found some other occurrences of "recursive" when it doesn't necessarily have to be a recursive in that context. It would be nice to clean up the terminology issue, but maybe it's too minor and/or too subtle. Since they are now only in examples, the additional clarity may not be worth the additional editorial effort. - Section 6 Reduced latency: By answering directly from cache, validating resolvers can immediately inform clients that the name they are looking for does not exist, improving the user experience. This only seems to assume the NXDOMAIN type of negative response. It's not necessarily incorrect as it just shows an example benefit, but, overall, text like this makes me wonder whether this doc also intends to cover the NOERROR/NODATA type of negative. - Section 11 Thanks to Mark Andrews for providing the helpful notes for implementors provided in Appendix B. ... [...]. Mark Andrews also provided the helpful notes for implementors (https://www.ietf.org/mail- archive/web/dnsop/current/msg18332.html) which we made into Appendix B. I'm not sure if it's intentional (if it is, that's fine for me), but these two sentences are almost a duplicate and can be unified. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
