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/>