Hi Murray,
if foo.example does not exist and DNSSEC is in place, than the resolver
actually, even with the queries "in reverse order", obtains and NSEC(3),
proving non-existence for much more.
For example, the query is bar.foo.example, and the authoritative returns
an NSEC proving that there is nothing between fa.example and fz.example.
Thus, the resolver can later deduct nonexistence not only for
foo.example, but also for fun.example and bar.fun.example, etc...
Without DNSSEC, this deduction (called "aggresive NSEC caching") is not
possible.
Cheers,
Libor
Dne 06. 04. 21 v 20:11 Murray S. Kucherawy napsal(a):
I'm wondering something about tree walks, which John Levine asked
about in November, as it's a topic of interest to the evolution of DMARC.
I've read RFC 8020 which says an NXDOMAIN cached for "foo.example"
also covers later queries for "bar.foo.example". Makes sense.
Can this be used (or maybe amended) to cover the queries if they come
in the reverse order? For instance, if "bar.foo.example" arrives
first, but the authoritative server can determine that the entire
"foo.example" tree doesn't exist, could it reply with an NXDOMAIN for
the question plus a cacheable indication about the entire tree instead
of just the name that was in the question?
This would make an ascending tree walk even for something crazy like
"a.b.c.d.....y.z.foo.example" extremely cheap as the cached NXDOMAIN
for "foo.example" covers the entire subtree, for a caching nameserver
implementing RFC 8020.
Maybe this is discussed somewhere that I missed in the references.
I'm happy to take a "go read this for the answer" if that's the case.
Thanks,
-MSK
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
