Why does MaraDNS return a packet with a RCODE of 0 ONLY when the QTYPE is AAAA(0x1C)?

[mingkwind]

Hi,

Describe
When the DNS forwarder receives a dns request packet with a QTYPE of AAAA(0x2C), then it iteratively queries the upstream name server, after receiving the paket with empty answer section from the upstream DNS server, DNS forwarder returns the packet with a RCODE of 0 to the client.
But the DNS forwarder receives a dns request packet with A non-AAAA QTYPE such as A,TXT,CERT, then do the same test, DNS forwarder returns the packet with a RCODE of 2 to the client.

To reproduce

1. Start the fake upstream dns server
   https://643684107.oss-cn-beijing.aliyuncs.com/maradns/dns_server.py
   Download this file and run like so:

python3 dns_server.py

2. Start the MaraDNS, the conf are as follows:

bind_address = "127.0.0.1"
dns_port = 4444
chroot_dir = "/root/experiments/deadwood"
recursive_acl = "127.0.0.1/16"
tcp_listen = 1
timeout_seconds=1
filter_rfc1918 = 0
num_retries=0
maradns_uid=1000
maradns_gid=1000
upstream_servers = {}
upstream_servers["."]="127.0.0.1"

Then use the conmand to start it:

./Deadwood -f maradns.conf

2. Use dig comand to send the request packet to MaraDNS.

AAAA:

$ dig @127.0.0.1 cert01.example AAAA IN -p 4444

; <<>> DiG 9.16.1-Ubuntu <<>> @127.0.0.1 cert01.example AAAA IN -p 4444
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38718
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;cert01.example.			IN	AAAA

;; AUTHORITY SECTION:
cert01.example.		0	IN	SOA	z.cert01.example. y.cert01.example. 1 1 1 1 1

;; Query time: 2 msec
;; SERVER: 127.0.0.1#4444(127.0.0.1)
;; WHEN: Tue Dec 06 18:15:01 CST 2022
;; MSG SIZE  rcvd: 72

A:

$ dig @127.0.0.1 cert01.example A IN -p 4444

; <<>> DiG 9.16.1-Ubuntu <<>> @127.0.0.1 cert01.example A IN -p 4444
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31936
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cert01.example.			IN	A

;; Query time: 1082 msec
;; SERVER: 127.0.0.1#4444(127.0.0.1)
;; WHEN: Tue Dec 06 18:16:23 CST 2022
;; MSG SIZE  rcvd: 32

CERT:

$ dig @127.0.0.1 cert01.example CERT IN -p 4444

; <<>> DiG 9.16.1-Ubuntu <<>> @127.0.0.1 cert01.example CERT IN -p 4444
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 40939
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cert01.example.			IN	CERT

;; Query time: 1017 msec
;; SERVER: 127.0.0.1#4444(127.0.0.1)
;; WHEN: Tue Dec 06 18:18:01 CST 2022
;; MSG SIZE  rcvd: 32

Return packets with qtype AAAA have a RCODE of 0(status: NOERROR), but return packets with qtype A and TXT have a RCODE of 2(status: SERVFAIL).

Thanks.

[samboy]

To answer your question: Look at line 1681 in DwRecurse.c:

        if(in->len == 7 && qtype == RR_AAAA) { /* Blank packet */
                return dwx_synth_notthere(query);
        }

Why is this code here?

Because, back in 2011, if you sent an AAAA query to archive.org (and chase.com as I recall), it would respond with server fail. This server fail would gum things up when trying to resolve the domain name on a mixed IPv4 and IPv6 network, so I added the above code to make AAAA replies return not there instead in the specific case of an AAAA query when getting a bad reply upstream. This way, the downstream resolver would know the server didn’t have AAAA, and then try an A query.

This had the side effect of making AAAA queries more fragile, since Deadwood gives up trying to resolve an AAAA record when it gets a server fail, but AAAA queries were uncommon enough in 2011 that some DNS servers would give strange replies, like a blank “server fail” reply to them. RedHat Linux, at the time, would send an AAAA query every time one tried to resolve a host name, even though the majority of hosts back in 2011 had only A records, so Deadwood sent a synthetic not here instead of refused downstream so that RedHat would quickly go from trying to resolve an AAAA record (which probably didn’t exist) to trying to resolve the A record (which usually existed) instead.

For further discussion for why I added this code:

https://samiam.org/blog/20110415.html

https://github.com/samboy/MaraDNS/blob/master/deadwood-github/update/2.9.06/deadwood-2.9.05-mt_packet.patch

https://github.com/samboy/MaraDNS/blob/master/deadwood-github/update/3.0.03/deadwood-3.0.02-archive.org-problem.patch

If this code is causing any issues here in 2022, let me know. It was a fix for DNS servers handling AAAA poorly back in early 2011.

[samboy]

As an aside, since you recently asked about ANY queries: I have fixed that bug. Deadwood now responds to ANY queries in a RFC8482 compliant manner, because of the security implications with using a pre-RFC8482 response to ANY.

[samboy]

I have disabled this code in commit 83989e6 after checking to make sure the site with issues in 2010 no longer has issues with AAAA packets here in 2022 (they do not).

[mingkwind]

Thank you so much for your reply :)

[samboy]

OK, this is resolved. Locking conversation.