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