I have read through the draft and sent a pull request with some minor
editorial fixes.

Here are some more substantial suggestions / questions. Sorry for being so
late in the process.


Would it make sense to be more specific about how to match queries to
cached NSEC/NSEC3 records? By cross-referencing to the relevant part of
the NSEC and NSEC3 specs, rather than repeating.

The draft seems to imply that only one NSEC record is needed for denial of
existence, and that wildcards are only problematic for NSEC3 - but
wildcards can also trip up NSEC, if the covering NSEC does not also cover
a relevant wildcard.

eg (modified text) ...

5.1.  NSEC

   Implementations which support aggressive use of NSEC SHOULD enable
   this by default.  Implementations MAY provide a configuration switch
   to disable aggressive use of NSEC and allow it to be enabled or
   disabled per domain.

   The validating resolver needs to check the existence of an NSEC RR
   matching/covering the source of synthesis and an NSEC RR covering the
   query name.

   If denial of existance can be determined according to the rules set out
   in RFC 4035 section 5.4, using NSEC records in the cache, then the
   resolver can immediately return an NXDOMAIN or NODATA response.

5.2.  NSEC3

   A validating resolver implementation MAY support aggressive use of
   NSEC3.  If it does aggressive use of NSEC3, it MAY provide a
   configuration switch to disable aggressive use of NSEC3 and allow it
   to be enabled or disabled for specific zones.

   NSEC3 aggressive negative caching is more difficult.  If the zone is
   signed with NSEC3, the validating resolver needs to check the
   existence of non-terminals and wildcards which derive from query
   names.

   If denial of existance can be determined according to the rules set out
   in RFC 5155 sections 8.4, 8.5, 8.6, 8.7,, using NSEC3 records in the
   cache, then the resolver can immediately return an NXDOMAIN or NODATA
   response.


TTLs

Both NSEC and NSEC3 records are supposed to have a TTL matching the SOA
MINIMUM field. This is not quite the same as RFC 2308 negative cache entry
TTL, which is the minimum of the SOA MINIMUM and SOA TTL.

Should there be text along the lines of:

5.3.  Consideration on TTL

   The TTL value of negative information is especially important,
   because newly added domain names cannot be used while the negative
   information is effective.

   Section 5 of RFC 2308 states that the maximum number of negative cache
   TTL value is 3 hours (10800).  It is RECOMMENDED that validating
   resolvers limit the maximum effective TTL value of negative responses
   (NSEC/NSEC3 RRs) to this same value.

   Section 5 of RFC 2308 also states that a negative cache entry TTL
   is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
   This can be less than the TTL of an NSEC or NSEC3 record, since their
   TTL is equal to the SOA.MINIMUM field. (See RFC 4035 section 2.3 and
   RFC 5155 section 3.)

   A resolver that supports aggressive use of NSEC and NSEC3 should reduce
   the TTL of NSEC and NSEC3 records to match the TTL of the SOA record in
   the authority section of a negative response, if the SOA TTL is
   smaller.


Wildcards

Should the box in section 7 say "positive responses" instead of "negative
responses"?

If so, there should probably also be a cross-ref to RFC 4035 section 5.3.4
and RFC 5155 section 8.8 which both discuss validating positive wildcard
responses. Similar to my suggestions for 5.1 and 5.2 above. I can provide
text if you want.


Security Considerations

This should mention the impact of replay attacks. Something like,

	Although the TTL of NSEC/NSEC3 records is typically fairly short
	(minutes or hours), their RRSIG expiration time can be much
	further in the future (weeks). An attacker who is able to
	successfully spoof responses might poison a cache with old
	NSEC/NSEC3 records. If the resolver is NOT making aggressive use
	of NSEC/NSEC3, the attacker has to repeat the attack for every
	query. If the resolver IS making aggressive use of
	NSEC/NSEC3, one successful attack would be able to suppress many
	queries for new names, up to the negative TTL.


Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Wight, Portland, Plymouth: East 5 to 7, occasionally 4 later. Moderate or
rough. Showers later. Good.