> From: Matthijs Mekking <matth...@pletterpet.nl> > 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 agree. I used Shane's text. > - 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. Thanks. "closest encloser" and "next closer name" is defined in RFC 5155. I cannot find the definition of "source of synthesis". I rewrote as an NSEC3 covering wildcards of the closest encloser [[ the part may be replaced as: an NSEC3 covering the source of synthesis ]], # may be rewritten by co-author. > - 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. I agree. removed the sentence. > - 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? Section 3.2.2 of RFC 4035 states that: When the CD bit is set, the recursive name server SHOULD, if possible, return the requested data to the originating resolver, even if the recursive name server's local authentication policy would reject the records in question. aggressive negative caching may be "local authentication policy". > - 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. Yes. I agree. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
