The author of dnsmasq has introduced DNS-0x20 encoding in the latest release candidate (dnsmasq-2.91rc4). the latest pi-hole v6 has this dnsmasq version embedded, with the feature enabled.
I have configured unbound as upstream for dnsmasq (on the same system). The resulting queries (example for single domain): Feb 21 06:01:24 unbound[915:3] info: resolving docs.pi-hole.net. AAAA IN Feb 21 06:01:24 unbound[915:2] info: resolving docs.pi-hole.net. A IN Feb 21 06:38:09 unbound[915:0] info: resolving dOCs.Pi-hole.NEt. AAAA IN Feb 21 06:38:09 unbound[915:1] info: resolving docs.PI-HOlE.NET. A IN Feb 21 06:43:11 unbound[915:0] info: resolving DoCs.pI-hOLE.nET. AAAA IN Feb 21 06:43:11 unbound[915:2] info: resolving docS.pi-hoLE.NEt. A IN Unfortunately, the cache (using redis) saves a key for all of the queries, when the next query (from dnsmasq) uses another variation of the case variation, there will thus be no cache hit. You can see some screenshots of the keys here (https://discourse.pi-hole.net/t/embedded-dnsmasq2-91rc4-causes-upstream-problems-due-to-dns-0x20-encoding/76114/3) Currently, I have disabled the dnsmasq feature, by adding the setting “no-0x20-encode”. As a result all dnsmasq queries are lowercase, thus only 2 redis keys required for caching. I believe only the DNS resolver, sending queries to the outside world (recursive unbound in my environment) should activate this feature. This implies a feature request to implement DNS-0x20 encoding for unbound, DNS-0x20 encoding is considered a security feature. I’ve been told by a developer dnsmasq stores only lowercase entries in it’s cache, it seems logical to apply the same logic for unbound. Tx for your time and effort.
