Tony,
On 06-10-16 13:18, Tony Finch wrote:
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.
That would make total sense (at least for me). I tried to achieve that
with my suggested text by repeating it, perhaps it's good enough to
cross-reference. I am a bit worried though that the process for
returning NSEC(3) records by an authoritative name server is slightly
different than the process of for searching NSEC(3) records by a
validating caching resolver, so that may be an argument for the
repeating proposal.
Best regards,
Matthijs
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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
