Is this a bug? (.. at least not what I expected..)

[bcookatpcsd]

[2022-04-21 15:45:18] 10.20.0.70 tdupdater A SYNTH 0ms -
[2022-04-21 15:45:25] 10.20.0.70 tdupdater TXT PASS 0ms -
[2022-04-21 15:48:59] 172.16.254.253 tdupdater TXT PASS 0ms -
[2022-04-21 15:49:29] 172.16.254.253 tdupdater TXT NXDOMAIN 7ms cleanbrowsing-doh

So I happened to be looking for something else and came across this..

The A record is SYNTH'd as it should be.. but the TXT, LOC, HINFO, etc records was passed as is everything else..

[2022-04-21 15:57:45] 10.20.0.70 tdupdater NS PASS 0ms -
[2022-04-21 15:57:51] 10.20.0.70 tdupdater LOC NXDOMAIN 19ms cleanbrowsing-dnscrypt
[2022-04-21 15:57:58] 10.20.0.70 tdupdater HINFO NXDOMAIN 8ms cleanbrowsing-doh
[2022-04-21 15:58:08] 10.20.0.70 tdupdater A SYNTH 0ms -

(we subscribe to cleanbrowsing..)

Is that as expected?

Output of the following commands:

)# dnscrypt-proxy -config /etc/dnscrypt-proxy.toml -check -list
[2022-04-21 16:09:30] [NOTICE] dnscrypt-proxy 2.1.1
[2022-04-21 16:09:30] [NOTICE] Source [public-resolvers] loaded
[2022-04-21 16:09:30] [NOTICE] Source [relays] loaded
cleanbrowsing-dnscrypt
cleanbrowsing-doh

(built against go 1.18)

Expected behavior (i.e. solution)

Should the block_unqualified block more than A / AAAA records?

Thank you in advance.

[jedisct1]

People use resolvers such as dnsmasq or unbound in front of dnscrypt-proxy.

If query types such as DNSKEY, DS or NS are blocked, everything's going to fail.

A and AAAA are pretty safe to block without breaking too many setups (still incorrect, though -- some root zones have IP addresses, but this is more of a curiosity than something people actually use).

So, blocking A and AAAA is a balance between avoid breaking things, and blocking the vast majority of queries that won't get any meaningful responses.