Matthijs, At 2016-04-26 10:11:13 +0200 Matthijs Mekking <matth...@pletterpet.nl> wrote:
> Late to the party, but FWIW: I also support adoption and am willing to
> discuss and review this work.
>
> Some comments:
>
> - Section 4.1 relaxes the restriction for resolvers from RFC 4035 to MAY
> do aggressive NSEC/NSEC3 usage, while section 4.2 says that a resolver
> SHOULD support aggressive NSEC usage and enable it by default. This to
> me seems inconsistent use of the key words.
I think it's that:
4.1 applies to any use of aggressive NSEC/NSEC3 (MAY)
4.2 applies to NSEC (SHOULD)
4.3 applies to NSEC3 (MAY)
I agree it looks a bit confusing. I think the main issue is whether
NSEC should be recommended. I kind of like it, because of the overall
benefits to the network. Without the SHOULD, people building software
from checklists will likely drop this optimization.
Perhaps 4.2 could be changed to something like:
"If a full-service resolver implementation supports aggressive
negative caching, then it SHOULD support aggressive use of NSEC and
enable it by default. It SHOULD provide a configuration knob to
disable aggressive use of NSEC."
?
> - In section 4.3 I suggest to replace the second paragraph with:
>
> If the full-service resolver's cache contains an NSEC3 matching
> the closest encloser, an NSEC3 covering the next closer name, and
> an NSEC3 covering the source of synthesis, it is possible for the
> full-service resolver to respond with NXDOMAIN immediately.
>
> Also, what exactly defines a full-service resolver? I think we care
> about caching and validating only here.
"Full-service resolver" is in our brand-new terminology RFC 7719:
Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this
term to mean a resolver that acts in recursive mode with a cache
(and meets other requirements).
> - Section 4.3 suggests to build a separate cache of NSEC and NSEC3
> resource records for each signer domain name. This to me seems like an
> implementation detail and is not necessarily required. In fact, a zone
> may switch from NSEC to NSEC3 and vice versa, so you will need to check
> them both if you implement it as a separate cache.
Perhaps the words "need to" can be replaced with "may" to make it clear
that this is not a requirement, but one possible approach?
> - I don't see why setting the CD bit is an indication that NSEC(3)
> aggressive usage should not be used. Could you elaborate on that?
>
> - My body shivers when reading that resolvers MAY use NSEC(3) records in
> a NXDOMAIN response without validating them. Luckily the draft already
> highly recommends that it should do validation. I would like to make it
> even stronger and remove the MAY key word here, and perhaps use the
> formal key word SHOULD do validation.
Cheers,
--
Shane
pgpP2ULxnAoSE.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
