DNS-0x20 encoding reduces cache hit count

[John Todd]

On 21 Feb 2025, at 18:37, Tuomo Soini via Unbound-users wrote:

> On Fri, 21 Feb 2025 10:29:02 +0100
> Peter Russel via Unbound-users <unbound-users at lists.nlnetlabs.nl> 
> wrote:
>
>> 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.
>
> I'd say this is a bug to fix. Cache should always be lower case.

I would agree with this statement, and I'll add some of my own hints 
into this thread.

I thought initially that this would be an error that was related to 
redis storage of cache, but I did a cursory look at one of our 
standalone caches and see that storage does indeed seem to be 
0x20-friendly:

```
[root at res310 tmp]# unbound-control lookup youtube.com
The following name servers are used for lookup of youtube.com.
;rrset 24388 4 0 8 3
yoUtube.COM.	24388	IN	NS	ns3.google.com.
yoUtube.COM.	24388	IN	NS	ns2.google.com.
yoUtube.COM.	24388	IN	NS	ns1.google.com.
yoUtube.COM.	24388	IN	NS	ns4.google.com.
[snip]
```

I have not yet looked to see if different 0x20 results (different 
capitalization patterns) causes new entries to be stored in memory cache 
to duplicate Peter's test - I don't quite have time for that right now.  
However, a quick sift through a cache dump ("unbound-control dump_cache 
 > unbound-cache.txt") shows only one instance that matches another host 
(www.youtube.com - with "-i" meaning "any capitalization") but the 
results are a bit unexpected, as it seems to me that storing as all 
lower case would be the default behavior:

```
[root at res310 tmp]# grep -i www.youtube.com dns-cache.txt |grep -v msg
WWw.yOuTUBE.cOm.	292	IN	CNAME	youtube-ui.l.google.com.
WWw.yOuTUBE.cOm. IN CNAME 0
[root at res310 tmp]#
```

Running v1.21.1 for samples above.

I have not yet looked to see if new insertions are happening on new 0x20 
variants, but based on Peter's comments and evidence above it looks like 
that may be happening.  We see many queries from downstream unbound 
systems with 0x20 turned on, and if pihole is going to start doing that 
as a default that seems like it would cause quite a bit of un-necessary 
cache churn if it is indeed causing new entries to be saved on each 0x20 
variation. For our installations, this probably isn't catastrophic since 
we have dnsdist in front of unbound and I suspect the dnsdist packet 
cache (which ignores 0x20 uniqueness when answering an existing 
in-memory item) minimizes the leakage of 0x20 issues through to the 
back-end recursive resolvers. However, if we have N front-end dnsdist 
instances pointing at a single unbound instance (I'm simplifying this 
for clarity) with clients sending 0x20 unique requests, then it would be 
the case that up to N requests with different 0x20 values would cause 
lookup events even within the cache timeout period in unbound.  That 
would be sub-optimal.

JT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20250222/96806741/attachment.htm>