unbound replaces CNAME query with A query?
Petr Menšík
pemensik at redhat.com
Fri Mar 31 13:57:46 UTC 2023
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
More information about the Unbound-users
mailing list