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

[Rob Seastrom]

Thanks everyone for the useful feedback and filling in the gaps for me.

We’ve now gone full circle since the easiest solution is to destroy and re-create a few VMs and a Raspberry Pi with the latest and greatest release and pkgsrc/apt (Viktor - I checked and latest Raspbian gets me Unbound 1.9.x)…  and conveniently they’re all defined in Ansible and I’ve done this multiple times before so it’s a quick and easy lunchtime endeavor.

cheers,

-r


> On Oct 9, 2019, at 3:49 PM, Dave Lawrence <tale at dd.org> wrote:
> 
> Viktor Dukhovni writes:
>> Yes, the expected behaviour when you explicitly request a CNAME
>> record is that (modulo 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.
> 
> Spot on.  I'd briefly considered the possibility that this was an
> amusing underspecified edge-case involving language about restarting
> the query when a CNAME is encountered, but even in 1980s RFC-speak,
> RFC 1034 section 3.6.2 was pretty clear on this:
> 
>    "When a name server fails to find a desired RR in the resource set
>    associated with the domain name, it checks to see if the resource
>    set consists of a CNAME record with a matching class."
> 
> So, looking up qtype CNAME finds the desired RR and the subordinate
> clause is not triggered.  But just to make it crystal clear, it goes
> on to say, regarding an example of a USC-ISIC.ARPA alias pointing to
> C.ISI.EDU with an address record:
> 
>    "Both of these RRs would be returned in the response to the 
>    type A query, while a type CNAME or * [ANY] query should return
>    just the CNAME."
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations