Re: [DNSOP] Working Group Last Call

[Matthijs Mekking <[e-mail]>]

All,

I reviewed this draft and while it is shaping up nicely, I don't think 
it is quite ready for publication:

1. As John pointed out earlier, the document makes an inconsistent use 
of RFCC 2119 keywords, and we need to decide whether to use MAY or 
SHOULD. Looking at the definitions of the keywords again I am leaning 
towards MAY, but given the described benefits I could see how SHOULD 
would be appropriate. Either way, it should be consistent. Also, the 
used keyword for NSEC should not be different than that for NSEC3.

2. In addition to the first point, I don't think it is appropriate to 
use RFC 2119 keywords to dictate name server configuration. Mentioning 
it would be useful to have configuration options for enabling and 
disabling this functionality seems okay, but drop the RFC 2119 formalities.

3. In section 6 on Benefits, it says "currently around 65% of queries to 
Root Name servers result in NXDOMAIN responses." This is quickly 
outdated, so I would replace 'currently' with 'at the time of writing'. 
But more importantly, where does this number come from? A reference here 
seems appropriate.

4. There are several bikeshedding issues/nits that I have put up a PR 
for here:

   https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/pull/1

5. It seems that sections 5.2 and 5.3 only consider NXDOMAIN responses. 
Is it perhaps that at the end of section 5.1 NODATA answers are covered?
I would suggest a better structure to make more explicit the scope. 
Currently it reads as if NODATA answers should always be subject to 
aggressive use of negative cache, while NXDOMAIN answers only if the 
configuration option enables it.

Given these remarks, I suggest the following structure and text:

   If the negative cache of the validating resolver has sufficient
   information to validate the query, the resolver MAY use NSEC, NSEC3
   and wildcard records aggressively. Otherwise, it MUST fall back to
   send the query to the authoritative DNS servers.

   It is recommended that resolvers that implement Aggressive Use of
   Negative Caching provide a configuration switch to disable the
   feature. Separate configuration switches can be implemented for
   the aggressive use of NSEC, NSEC3 and wildcard records.

   5.2 NSEC

   5.2.1 No Data

   If the query has an NSEC record matching the query name, proving
   the data requested does not exist, the resolver MAY respond with an
   empty NOERROR (No Data) answer.

   5.2.2 Name Error

   If the resolver has an NSEC record covering the source of synthesis
   and an NSEC record covering the query name, it MAY respond with an
   NXDOMAIN answer.

   5.2.3 Wildcard No Data

   If the resolver has an NSEC record matching the source of synthesis
   and an NSEC record covering the query name, it MAY respond with an
   empty NOERROR (No Data) answer.

   5.2.3 Wildcard Answer

   If the resolver has an NSEC record covering the query name, but no
   NSEC record matching the source of synthesis, it MAY respond with an
   wildcard expanded answer from the cache. If the corresponding
   wildcard record is not in the cache, it MUST fall back to send the
   query to the authoritative DNS servers.

   5.2 NSEC3

   ...


A similar layout for NSEC3 should be provided, and I am willing to 
provide that if this layout is accepted.

Best regards,
   Matthijs

On 22-09-16 14:19, Tim Wicinski wrote:
> All
>
> This draft has been worked on and it seems that the Working Group is
> happy with the updates that have been made and I feel it's ready for the
> next step.
>
> 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.
>
> It's currently marked as "Proposed Standard", so if folks feel
> differently then please speak up.
>
>
> This starts a two week Working Group Last Call process, and ends at
> midnight 7 October 2016 UTC.
>
> thanks
> tim
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop