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
