Shreyas Zare writes:
> And all of the 3 CNAME records are within the zone cut for the
> received SOA. To make the resolver work with this issue, the
> negative cache implementation had to be removed for CNAMEs with
> NXDOMAIN case.
To be clear, and this could well be something that community was not
really clear on until after 2308 was written, just being "within the
zone cut" is not sufficient to know that it is really in the zone even
when you are at the same label depth.
Imagine an auth server that has this configuration:
$origin example.com.
. ns ns1.example.com.
. ns ns2.example.com.
foo cname bar
bar ns ns1.example.com.
bar ns ns2.example.com.
$origin bar.example.com.
. ns ns1.example.com.
. ns ns2.example.com.
. txt "record in child"
A query to {ns1,ns2}.example.com for txt could be legitimately replied
to by the auth with just the foo cname bar record, and noerror as
rcode. Can a resolver tell for sure whether that means the txt for
bar.example.com doesn't exist so that it could negative cache that?
Just having the soa in additional wouldn't be a sufficient indication.
Yes, I've acknowledged in a prior message that I didn't pick up on the
auths in question giving an nxdomain for ds, which certainly muddies
the water for the specific original example, which already had a tree
configuration problem that would erroneously lead it to nxdomain even
if it didn't have that problem with types. I'm just making clear that
the resolver implementation needs handle the lookup of the cname
target as distinct from whatever appears in the answer beyond the
first cname.
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
