Thanks to Jinmei, Shumon and Mark. > From: 神明達哉 <jin...@wide.ad.jp> > While I see what it tries to say and don't disagree with it, I think > this is not very accurate. In fact, NXDOMAIN for "a.example.com" says > there is no such name *or any subdomain of it*. So it would still be > usable to suppress unnecessary external query for, e.g., > foo.a.example.com.
I will add some text in next revision. > From: Shumon Huque <shu...@gmail.com> > That's indeed the literal meaning of NXDOMAIN, but it turns out most > current resolver implementations don't treat it that way. The wording in > RFC2308, Section 5 is not entirely precise, but it seems to say that > negative answers should be cached only for the exact qname, and not > (necessarily) for anything below it. > From: Mark Andrews <ma...@isc.org> > Because the consensus at the time was not to support nxdomain > synthesis from signed zone (speaketh the author of RFC 2308). I will add texts to update RFC 2308. > Extreme care needs to be taken with nxdomain synthesis. You need > to choose the correct NSEC records especially for qnames which are > the subdomain of the NSEC owner name. The NS bit MUST NOT be set > in this case as the presence of the NS bit indicates a delegation. > > NSEC3 is even more complicted. YES. > DLV is only defined to use NSEC signed zones as I wasn't interested > in having to working out all the rules for NSEC3. I think the procedure is the same as NSEC3 validation. # and qname minimization discussion is interesting. # It may be listed in draft-ietf-dnsop-root-loopback # as a different approach. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
