Shane, On 04/28/2016 10:28 PM, Shane Kerr wrote: > Matthijs, > > At 2016-04-26 10:11:13 +0200 > Matthijs Mekking <[email protected]> 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.
Reading over RFC 2119 I think MAY is more applicable. The quotes from that RFC that convince me so: One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that *it enhances the product* while another vendor may omit the same item. and An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, *though perhaps with reduced functionality.* Also I don't think the key words need to be different for NSEC and NSEC3. > 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? That works, but my argument is that one should be careful with the assumption that a zone is either uses NSEC or NSEC3, while that may be true at one point in time, a zone may change its DNSSEC policy and switch to the other. >> - 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? I am still hoping that someone could response to this :) >> - 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, Thanks. Best regards, Matthijs > -- > Shane > > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
