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 <[email protected]> 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 > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
