[dns-operations] CNAMEs pointing off into the weeds - inconsistent behavior from different recursive codebases

[Viktor Dukhovni]

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

-- 
	Viktor.