My understanding is this: If a dig command is directed to a resolver with type=CNAME specified and the resolver responds with anything other than the asked for CNAME information, this may indeed be a bug. I'm not sure of the results if the CNAME target exists in cache. Another way to see similar results would be to submit a type=ANY (default) with the +norecurse switch.
I'd be interested to see the results with the +norecurse switch on. Bob On Fri, Mar 31, 2023, 10:45 <unbound-users-requ...@lists.nlnetlabs.nl> wrote: > Send Unbound-users mailing list submissions to > unbound-users@lists.nlnetlabs.nl > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.nlnetlabs.nl/mailman/listinfo/unbound-users > or, via email, send a message with subject or body 'help' to > unbound-users-requ...@lists.nlnetlabs.nl > > You can reach the person managing the list at > unbound-users-ow...@lists.nlnetlabs.nl > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Unbound-users digest..." > > > Today's Topics: > > 1. Re: unbound replaces CNAME query with A query? (Tuomo Soini) > 2. Re: unbound replaces CNAME query with A query? (Petr Men??k) > 3. Re: unbound replaces CNAME query with A query? (Tuomo Soini) > 4. Re: unbound replaces CNAME query with A query? (Petr Men??k) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 31 Mar 2023 15:54:05 +0300 > From: Tuomo Soini <t...@foobar.fi> > To: unbound-users@lists.nlnetlabs.nl > Subject: Re: unbound replaces CNAME query with A query? > Message-ID: <20230331155405.4a433...@tuomo.foobar.fi> > Content-Type: text/plain; charset=UTF-8 > > On Fri, 31 Mar 2023 13:01:28 +0200 > Petr Men??k via Unbound-users <unbound-users@lists.nlnetlabs.nl> wrote: > > > I am using dnssec-trigger-0.17-7.fc36.x86_64 and > > unbound-1.17.1-1.fc36.x86_64 on Fedora 36. But I cannot reproduce the > > behaviour, even if I flush cache by "unbound-control flush_zone ." It > > is returning consistently CNAME with NOERROR. Does it happen only > > when the unbound does not have forwarders and is iterating itself? I > > keep getting CNAME with NOERROR. > > > $ kdig cnametest.bleve.fi. CNAME > > Try the query I just listed, should work with bind dig too. > If you query bleve.fi authoritative dns servers to get correct answer. > > cname query only fails if cname target gives NXDOMAIN. > > For example following query works correctly because destination of the > cname exists. > > kdig _443._tcp.bleve.fi. cname > > This is obviously a bug, very special case which resolver need to > handle different way than normal cname resolution. Also cloudflare, > quad9, and google resolvers seem to have same problem. Seem to be > special case not handled by most dns resolver. > > dnsmasq and bind seem to be able to handle that query correctly. > > -- > Tuomo Soini <t...@foobar.fi> > Foobar Linux services > +358 40 5240030 > Foobar Oy <https://foobar.fi/> > > > ------------------------------ > > Message: 2 > Date: Fri, 31 Mar 2023 15:57:46 +0200 > From: Petr Men??k <pemen...@redhat.com> > To: Tuomo Soini <t...@foobar.fi>, unbound-users@lists.nlnetlabs.nl > Subject: Re: unbound replaces CNAME query with A query? > Message-ID: <2d8300c7-16a7-132c-bb68-b682c04fc...@redhat.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 3/31/23 14:54, Tuomo Soini wrote: > > On Fri, 31 Mar 2023 13:01:28 +0200 > > Petr Men??k via Unbound-users <unbound-users@lists.nlnetlabs.nl> wrote: > > > >> I am using dnssec-trigger-0.17-7.fc36.x86_64 and > >> unbound-1.17.1-1.fc36.x86_64 on Fedora 36. But I cannot reproduce the > >> behaviour, even if I flush cache by "unbound-control flush_zone ." It > >> is returning consistently CNAME with NOERROR. Does it happen only > >> when the unbound does not have forwarders and is iterating itself? I > >> keep getting CNAME with NOERROR. > > > $ kdig cnametest.bleve.fi. CNAME > > > > Try the query I just listed, should work with bind dig too. > > If you query bleve.fi authoritative dns servers to get correct answer. > > > > cname query only fails if cname target gives NXDOMAIN. > > I have tried on my unbound and it never returns NXDOMAIN to me. The > result is the same with kdig or dig, that makes no difference. I get > NOERROR, not NXDOMAIN. > > $ kdig cnametest.bleve.fi. CNAME | head -2 > ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 35718 > ;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 > > > For example following query works correctly because destination of the > > cname exists. > > > > kdig _443._tcp.bleve.fi. cname > > > > This is obviously a bug, very special case which resolver need to > > handle different way than normal cname resolution. Also cloudflare, > > quad9, and google resolvers seem to have same problem. Seem to be > > special case not handled by most dns resolver. > > > > dnsmasq and bind seem to be able to handle that query correctly. > > dnsmasq does not handle CNAMEs at all. It requires upstream recursive > server to do the job and just passes the result to a client. bind can to > proper iteration job from root hints however. > > If it is a bug, I would suggest creating issue at > https://github.com/NLnetLabs/unbound/ > > But maybe more precise steps should be described when it returns > NXDOMAIN. Just flushing the cache and doing your query does not seem to > be enough for me. > > -- > Petr Men??k > Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > > > ------------------------------ > > Message: 3 > Date: Fri, 31 Mar 2023 17:09:40 +0300 > From: Tuomo Soini <t...@foobar.fi> > To: Petr Men??k <pemen...@redhat.com> > Cc: unbound-users@lists.nlnetlabs.nl > Subject: Re: unbound replaces CNAME query with A query? > Message-ID: <20230331170940.6e3d8...@tuomo.foobar.fi> > Content-Type: text/plain; charset=UTF-8 > > On Fri, 31 Mar 2023 15:57:46 +0200 > Petr Men??k <pemen...@redhat.com> wrote: > > > > cname query only fails if cname target gives NXDOMAIN. > > > > I have tried on my unbound and it never returns NXDOMAIN to me. The > > result is the same with kdig or dig, that makes no difference. I get > > NOERROR, not NXDOMAIN. > > All unbounds here without forwarders set up, is that the difference? > > > > > $ kdig cnametest.bleve.fi. CNAME | head -2 > > ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 35718 > > ;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: > > 0 > > > > > For example following query works correctly because destination of > > > the cname exists. > > > > > > kdig _443._tcp.bleve.fi. cname > > > > > > This is obviously a bug, very special case which resolver need to > > > handle different way than normal cname resolution. Also cloudflare, > > > quad9, and google resolvers seem to have same problem. Seem to be > > > special case not handled by most dns resolver. > > > > > > dnsmasq and bind seem to be able to handle that query correctly. > > > > dnsmasq does not handle CNAMEs at all. It requires upstream recursive > > server to do the job and just passes the result to a client. bind can > > to proper iteration job from root hints however. > > > > If it is a bug, I would suggest creating issue at > > https://github.com/NLnetLabs/unbound/ > > > > But maybe more precise steps should be described when it returns > > NXDOMAIN. Just flushing the cache and doing your query does not seem > > to be enough for me. > > > > > > -- > Tuomo Soini <t...@foobar.fi> > Foobar Linux services > +358 40 5240030 > Foobar Oy <https://foobar.fi/> > > > ------------------------------ > > Message: 4 > Date: Fri, 31 Mar 2023 16:45:15 +0200 > From: Petr Men??k <pemen...@redhat.com> > To: Tuomo Soini <t...@foobar.fi> > Cc: unbound-users@lists.nlnetlabs.nl > Subject: Re: unbound replaces CNAME query with A query? > Message-ID: <9935b00c-dd09-5d3c-dd13-7e202971f...@redhat.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 3/31/23 16:09, Tuomo Soini wrote: > > On Fri, 31 Mar 2023 15:57:46 +0200 > > Petr Men??k <pemen...@redhat.com> wrote: > > > > > > I have tried on my unbound and it never returns NXDOMAIN to me. The > > result is the same with kdig or dig, that makes no difference. I get > > NOERROR, not NXDOMAIN. > > All unbounds here without forwarders set up, is that the difference? > > I have tried it inside a Rawhide container. > > # unbound-control forward > off (using root hints) > > # dig @localhost cnametest.bleve.fi. CNAME > > ; <<>> DiG 9.18.13 <<>> @localhost cnametest.bleve.fi. CNAME > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55072 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ;; QUESTION SECTION: > ;cnametest.bleve.fi.??? ??? IN??? CNAME > > ;; ANSWER SECTION: > cnametest.bleve.fi.??? 7118??? IN??? CNAME??? nxdomain.foobar.fi. > > ;; Query time: 0 msec > ;; SERVER: ::1#53(localhost) (UDP) > ;; WHEN: Fri Mar 31 16:20:26 CEST 2023 > ;; MSG SIZE? rcvd: 77 > > > Just after fresh restart, it is NOERROR. As it is later. Indeed, the > query unbound sends to cnametest.bleve.fi is A? query. But the response > delivered to dig is a correct one. Tested with > unbound-1.17.1-2.fc38.x86_64. > > Frame 641: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) on > interface virbr0, id 0 > Ethernet II, Src: 7e:85:92:43:88:71 (7e:85:92:43:88:71), Dst: > RealtekU_02:bd:85 (52:54:00:02:bd:85) > Internet Protocol Version 4, Src: 192.168.122.184, Dst: 87.239.120.11 > User Datagram Protocol, Src Port: 46986, Dst Port: 53 > Domain Name System (query) > ??? Transaction ID: 0x4302 > ??? Flags: 0x0010 Standard query > ??? Questions: 1 > ??? Answer RRs: 0 > ??? Authority RRs: 0 > ??? Additional RRs: 1 > ??? Queries > ??????? cnametest.bleve.fi: type A, class IN > ??? Additional records > ??? [Response In: 719] > > It responds to it with nameservers of bleve.fi. But to those servers it > already sends CNAME query, not A? Attaching my pcap. > > When I did dig @localhost ns bleve.fi. before cnametest, it returned > SERVFAIL the first time. Only then it responded with NOERROR. So no, I > do not know how to get NXDOMAIN response from unbound. I get similar > results for the original query. > > >> $ kdig cnametest.bleve.fi. CNAME | head -2 > >> ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 35718 > >> ;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: > >> 0 > >> > >> dnsmasq does not handle CNAMEs at all. It requires upstream recursive > >> server to do the job and just passes the result to a client. bind can > >> to proper iteration job from root hints however. > >> > >> If it is a bug, I would suggest creating issue at > >> https://github.com/NLnetLabs/unbound/ > >> > >> But maybe more precise steps should be described when it returns > >> NXDOMAIN. Just flushing the cache and doing your query does not seem > >> to be enough for me. > > -- > Petr Men??k > Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: cnametest-bleve.fi-filtered.pcapng > Type: application/x-pcapng > Size: 6764 bytes > Desc: not available > URL: < > http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20230331/9844401b/attachment.bin > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Unbound-users mailing list > Unbound-users@lists.nlnetlabs.nl > https://lists.nlnetlabs.nl/mailman/listinfo/unbound-users > > > ------------------------------ > > End of Unbound-users Digest, Vol 39, Issue 12 > ********************************************* >
