The reason I don't want to use "DNS-0x20 encoding"
TLDR; the upstream cache (unbound / redis) has an entry for every case variation, this implies dnsmasq needs to request a previously used variation, in order to get a cache match.
- I enabled "DNS-0x20 encoding" by deleting the setting
no-0x20-encode
and restarting pihole-FTL. - I than browsed to docs.pi-hole.net, the unbound log now shows (notice the case variations):
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:01:24 unbound[915:3] info: response for docs.pi-hole.net. AAAA IN
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: response for docs.pi-hole.net. A IN
Feb 21 06:01:24 unbound[915:2] info: resolving docs.pi-hole.net. A IN
Feb 21 06:01:24 unbound[915:3] info: response for docs.pi-hole.net. AAAA IN
Feb 21 06:01:24 unbound[915:2] info: response for docs.pi-hole.net. A IN
Feb 21 06:01:24 unbound[915:3] info: response for docs.pi-hole.net. AAAA IN
Feb 21 06:01:24 unbound[915:2] info: response for docs.pi-hole.net. A IN
Feb 21 06:01:24 unbound[915:3] info: response for docs.pi-hole.net. AAAA IN
Feb 21 06:24:04 unbound[915:2] info: resolving docs.pi-hole.net. A IN
Feb 21 06:24:04 unbound[915:2] info: resolving docs.pi-hole.net. A IN
Feb 21 06:24:04 unbound[915:2] info: response for 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: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:38:09 unbound[915:1] info: resolving docs.PI-HOlE.NET. A IN
Feb 21 06:38:09 unbound[915:0] info: response for dOCs.Pi-hole.NEt. AAAA IN
Feb 21 06:38:09 unbound[915:1] info: response for docs.PI-HOlE.NET. A IN
Feb 21 06:38:09 unbound[915:0] info: response for dOCs.Pi-hole.NEt. AAAA IN
Feb 21 06:43:11 unbound[915:0] info: resolving DoCs.pI-hOLE.nET. AAAA 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
Feb 21 06:43:11 unbound[915:2] info: resolving docS.pi-hoLE.NEt. A IN
Feb 21 06:43:11 unbound[915:0] info: response for DoCs.pI-hOLE.nET. AAAA IN
Feb 21 06:43:11 unbound[915:2] info: response for docS.pi-hoLE.NEt. A IN
Feb 21 06:43:11 unbound[915:0] info: response for DoCs.pI-hOLE.nET. AAAA IN
- I than checked the redis (unbound cache) content and found there are multiple entries, one for each case variation. The process to look at the redis cache content is dirty, only showing screenshots of the relevant portion.
docS.pi-hoLE.NEt
DoCs.pI-hOLE.nET
docs.PI-HOlE.NET
dOCs.Pi-hole.NEt
docs.pi-hole.net
docs.pi-hole.net
Some unbound users have opted for dnsmasq cache-size=0
, relying on the upstream unbound cache. Since it will take some time before there is a match for the DNS-0x20 encoded query (case sensitive in cache), a lot more queries require resolving, using the actual DNS servers, thus resolving becomes slow, the number of cache hits decrease dramatically.
I don't know any method to look at the dnsmasq cache, thus cannot confirm / deny the dnsmasq cache stores the individual queries. Needs to be verified?
I agree that "DNS-0x20 encoding" is (can be) a valuable feature for added security, however, in my opinion, it would be best applied on the instance that actually talks to the outside world (unbound), with the added assumption the cache is storing everything in lower case, thus minimizing the number of cache entries and achieving an acceptable number of cache hits.
If the dnsmasq upstream server is something like 8.8.8.8 (external) using "DNS-0x20 encoding" is a good idea, however the cache behavior still needs looking into.
My 2 cents...