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:

  1. start unbound so it has an empty cache when the query reaches unbound (config is provided at the end of this bugreport)
  2. ask unbound for this existing CNAME DNS record dig _acme-challenge.bender-doh.applied-privacy.net CNAME -> NXDOMAIN
  3. 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.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

Most upvoted comments

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