[dns-operations] CNAMEs pointing off into the weeds - inconsistent behavior from different recursive codebases
rs-lists at seastrom.com
Thu Oct 10 14:16:15 UTC 2019
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.
> 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
More information about the dns-operations