unbound replaces CNAME query with A query?
Bob McDonald
bmcdonaldjr at gmail.com
Fri Mar 31 16:22:00 UTC 2023
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-request at lists.nlnetlabs.nl>
wrote:
> Send Unbound-users mailing list submissions to
> unbound-users at 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-request at lists.nlnetlabs.nl
>
> You can reach the person managing the list at
> unbound-users-owner at 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 <tis at foobar.fi>
> To: unbound-users at lists.nlnetlabs.nl
> Subject: Re: unbound replaces CNAME query with A query?
> Message-ID: <20230331155405.4a433d05 at 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 at 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 <tis at 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 <pemensik at redhat.com>
> To: Tuomo Soini <tis at foobar.fi>, unbound-users at lists.nlnetlabs.nl
> Subject: Re: unbound replaces CNAME query with A query?
> Message-ID: <2d8300c7-16a7-132c-bb68-b682c04fc06d at 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 at 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 <tis at foobar.fi>
> To: Petr Men??k <pemensik at redhat.com>
> Cc: unbound-users at lists.nlnetlabs.nl
> Subject: Re: unbound replaces CNAME query with A query?
> Message-ID: <20230331170940.6e3d8a7f at tuomo.foobar.fi>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, 31 Mar 2023 15:57:46 +0200
> Petr Men??k <pemensik at 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 <tis at 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 <pemensik at redhat.com>
> To: Tuomo Soini <tis at foobar.fi>
> Cc: unbound-users at lists.nlnetlabs.nl
> Subject: Re: unbound replaces CNAME query with A query?
> Message-ID: <9935b00c-dd09-5d3c-dd13-7e202971f535 at 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 <pemensik at 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 at lists.nlnetlabs.nl
> https://lists.nlnetlabs.nl/mailman/listinfo/unbound-users
>
>
> ------------------------------
>
> End of Unbound-users Digest, Vol 39, Issue 12
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20230331/833a218e/attachment-0001.htm>
More information about the Unbound-users
mailing list