unbound: NXDOMAIN instead of NOERROR rcode when asked for existing CNAME record
Describe the bug
Unbound answers to a CNAME query with NXDOMAIN instead of NOERROR but includes the actual existing record as well.
Actual expected rcode: NOERROR
Also: When asked for a CNAME, unbound asks the authoritative NS for an A record.
Actual expected qtype: CNAME
To reproduce Steps to reproduce the behavior:
- start unbound so it has an empty cache when the query reaches unbound (config is provided at the end of this bugreport)
- ask unbound for this existing CNAME DNS record
dig _acme-challenge.bender-doh.applied-privacy.net CNAME
-> NXDOMAIN - ask unbound again without flushing the cache first, you will get a NOERROR rcode
Others on the mailing list have confirmed seeing the same issue.
While looking into the PCAP files from stub -> unbound and unbound -> authoritative, I also noticed that the CNAME query send to unbound results in unbound asking the authoritative for an A record - which does not existing. This mismatch in inbound and outbound qtype might be related to the root cause of the bug.
Expected behavior
unbound should ask the authoritative nameserver for a CNAME record not an A record. unbound should answer with an NOERROR rcode for existing CNAMEs - like other resolvers do (for example PowerDNS Recursor).
System:
- Unbound version:
pkg info unbound
unbound-1.17.1_2
Name : unbound
Version : 1.17.1_2
Installed on : Sat Feb 18 22:20:01 2023 CET
Origin : dns/unbound
Architecture : FreeBSD:13:amd64
- OS: FreeBSD 13.1
unbound -V
output:
Version 1.17.1
Configure line: --with-libexpat=/usr/local --with-ssl=/usr --enable-dnscrypt --disable-dnstap --with-libnghttp2 --with-dynlibmodule --enable-ecdsa --disable-event-api --enable-gost --with-libevent --disable-subnet --disable-tfo-client --disable-tfo-server --with-pthreads --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/ --build=amd64-portbld-freebsd13.1
Linked libs: libevent 2.1.12-stable (it uses kqueue), OpenSSL 1.1.1o-freebsd 3 May 2022
Linked modules: dns64 dynlib respip validator iterator
DNSCrypt feature available
Additional information
Mailing list discussions:
-
unbound-users: https://lists.nlnetlabs.nl/pipermail/unbound-users/2023-March/008049.html
-
powerdns-users: https://mailman.powerdns.com/pipermail/pdns-users/2023-March/028156.html
-
lego github issue: https://github.com/go-acme/lego/issues/1739
unbound.conf
server:
verbosity: 0
access-control: 109.70.100.0/24 allow
access-control: ::1/128 allow
access-control: 127.0.0.1/24 allow
edns-tcp-keepalive: yes
incoming-num-tcp: 200
# plain UDP
interface: 127.0.0.1@53
interface: ::1@53
interface: 109.70.100.133@53
num-threads: 2
msg-cache-size: 100m
rrset-cache-size: 200m
key-cache-size: 10m
neg-cache-size: 10m
harden-below-nxdomain: yes
minimal-responses: yes
prefetch: yes
prefetch-key: yes
aggressive-nsec: yes
use-caps-for-id: yes
hide-identity: yes
hide-version: yes
hide-trustanchor: yes
qname-minimisation: yes
# The following line will configure unbound to perform cryptographic
# DNSSEC validation using the root trust anchor.
auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
extended-statistics: yes
statistics-cumulative: no
statistics-interval: 0
remote-control:
control-enable: yes
# root on loopback
auth-zone:
name: "."
master: "k.root-servers.net"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "root.zone"
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 18 (13 by maintainers)
Commits related to this issue
- - Fix for #870: Add test case for the qname minimisation and CNAME. — committed to NLnetLabs/unbound by wcawijngaards a year ago
- - Fix #870: NXDOMAIN instead of NOERROR rcode when asked for existing CNAME record. — committed to internetstandards/unbound by wcawijngaards a year ago
The question of whether there is an ordering between RRsets in the answer sections comes up from time to time. There was a large email thread in dnsop from 2015 here:
https://mailarchive.ietf.org/arch/msg/dnsop/7KoE8Dr-SxuNToskxbvAwJ3BQLQ/
and an attempt at a specification clarification document here:
https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-ordered-answers-00