Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

[神明達哉 <[e-mail]>]

At Mon, 13 Jul 2015 22:01:29 -0400,
Shumon Huque <[e-mail]> wrote:

> > 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.

Ah, yes, thanks for pointing it out.  I don't know or didn't check
other resolver implementations, but BIND 9 certainly behaves that way.
I should have known this, but I guess I was confused about the
"meaning of NXDOMAIN", the behavior of authoritative server
implementations and the behavior of recursive server implementations.

> 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.

And the same remark should apply here, too.  We'd need "Stopping
Downward Cache Search on NXDOMAIN" in addition to qname minimization
for this to work.

--
JINMEI, Tatuya