In message <CAHPuVdU-1e_7KPH9JdSvbPn-tYptaXbHrQvQz=uev+qjdse...@mail.gmail.com> , Shumon Huque writes: > > On Fri, Jul 10, 2015 at 2:53 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinm= > e...@wide.ad.jp> wrote: > > > On Tue, Jul 7, 2015 at 2:20 AM, <fujiw...@jprs.co.jp> wrote: > > [...] > > In Introduction it states: > > > > While negative (non-existence) information of DNS caching mechanism > > has been known as DNS negative cache [RFC2308], it requires exact > > matching in most cases. [...] > > This was because the NXDOMAIN response just says > > there is no such name "a.example.com" and it doesn't tell anything > > for "b.example.com". > > > > 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. > > > > 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.
Because the consensus at the time was not to support nxdomain synthesis from signed zone (speaketh the author of 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. DLV is only defined to use NSEC signed zones as I wasn't interested in having to working out all the rules for NSEC3. > Section 3 of http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 > ("Stopping Downward Cache Search on NXDOMAIN") proposed to fix this > resolver behavior. It would be great if this was standardized and adopted. > > Regarding Section 5 (possible side effect on root servers), I wonder > > about the implication of qname-minimization (which I expect will be > > deployed much sooner than this proposal). A resolver that supports > > qname-minimization would first send a query to "local." to the root > > server upon receiving a "foo.local" query, and cache the result of > > NXDOMAIN for "local.". It will suppress subsequent external queries > > for any subdomain of it. > > > > Yes, this will certainly be a very beneficial result of qname > minimization. > > Shumon. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
