[dns-operations] CNAMEs pointing off into the weeds - inconsistent behavior from different recursive codebases
ietf-dane at dukhovni.org
Wed Oct 9 04:10:43 UTC 2019
> On Oct 8, 2019, at 10:06 PM, Rob Seastrom <rs-lists at seastrom.com> wrote:
> The expected behavior is that I would get back the CNAME record and NOERROR when asking for a CNAME even if it points somewhere that has no data. Indeed this is what I get from a recent version of BIND, Power, Google DNS, and Windows 2016 Server.
Yes, the expected behaviour when you explicitly request a CNAME record is
that (module DNAMEs in some parent zone) the qname is resolved without
further indirection, returning a CNAME if present there, NXDOMAIN if
the qname does not exist, or else NODATA.
> It seems that Unbound is the outlier here in that it returns *both* an ANSWER section *and* NXDOMAIN, which is behavior I'm not sure I've ever seen before.
That's expected *only* when you're requesting some *other* RRtype
for a qname with a CNAME that ultimately (within reasonable
recursion depth) expands to a non-existent name. Thus an "A"
query for a qname must indeed produce both an NXDOMAIN and
an answer, but the CNAME query must not.
> Qname minimization is in my standard Unbound config.
What version of unbound is this?
> This behavior goes away if I turn off qname minimization and restart
> Unbound, despite the fact that tcpdump offers no evidence that there's
> actually an attempt being made to crawl the name returned in the right
> hand side of the original CNAME record regardless of whether qname
> minimization is on or off.
This sure feels like a bug, but keep in mind that with
qname minimization one might discover NSEC or NSEC3
records that "prove" the non-existence of the qname.
So it is possible that your zone, (if signed) has dodgy
NSEC records. Lack of any evidence of recursion tends
to suggest that's the case, but a bug is also possible.
> I don't have a BIND-9.13 server handy to test out and see if it's a
> fundamental failing in my understanding of how qname minimization works,
> but in any event ANSWER + NXDOMAIN doesn't feel right to me.
Well, a chain of CNAMEs + NXDOMAIN is quite correct for
non-CNAME qTypes, but that's not the case here.
> Popping back up the stack to the code I was debugging, dnspython sees the
> NXDOMAIN and returns it as the status. My role fails (intentionally - I
> want to bomb out when there is no CNAME).
FWIW, my DANE survey code does handle CNAME chains leading
to NXDomain. Here's an example:
mail.mpz.nl. IN CNAME mx1.bit.org.
mx1.bit.org. IN A ? ; NXDomain AD=1
A recursive query to a modern nameserver will return RCODE=NXDOMAIN
the CNAME in the answer section, and the "bit.org" SOA in the auth
section, with various RRSIGs if you also set the DO bit.
More information about the dns-operations