<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">On 21 Feb 2025, at 18:37, Tuomo Soini via Unbound-users wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">On Fri, 21 Feb 2025 10:29:02 +0100<br>
Peter Russel via Unbound-users <a href="mailto:unbound-users@lists.nlnetlabs.nl" style="color: #777777;">unbound-users@lists.nlnetlabs.nl</a> wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;">
<p dir="auto">Feb 21 06:01:24 unbound[915:3] info: resolving docs.pi-hole.net. AAAA<br>
IN Feb 21 06:01:24 unbound[915:2] info: resolving docs.pi-hole.net. A<br>
IN Feb 21 06:38:09 unbound[915:0] info: resolving dOCs.Pi-hole.NEt.<br>
AAAA IN Feb 21 06:38:09 unbound[915:1] info: resolving<br>
docs.PI-HOlE.NET. A IN Feb 21 06:43:11 unbound[915:0] info: resolving<br>
DoCs.pI-hOLE.nET. AAAA IN Feb 21 06:43:11 unbound[915:2] info:<br>
resolving docS.pi-hoLE.NEt. A IN</p>
<p dir="auto">Unfortunately, the cache (using redis) saves a key for all of the<br>
queries, when the next query (from dnsmasq) uses another variation of<br>
the case variation, there will thus be no cache hit.</p>
</blockquote>
<p dir="auto">I'd say this is a bug to fix. Cache should always be lower case.</p>
</blockquote>
<p dir="auto">I would agree with this statement, and I'll add some of my own hints into this thread.</p>
<p dir="auto">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:</p>
<pre style="margin-left: 15px; margin-right: 15px; padding: 5px; background-color: #F7F7F7; border-radius: 5px 5px 5px 5px; overflow-x: auto; max-width: 90vw;"><code style="margin: 0 0; border-radius: 3px; background-color: #F7F7F7; padding: 0px;">[root@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]
</code></pre>
<p dir="auto">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 (<a href="http://www.youtube.com" style="color: #3983C4;">www.youtube.com</a> - 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:</p>
<pre style="margin-left: 15px; margin-right: 15px; padding: 5px; background-color: #F7F7F7; border-radius: 5px 5px 5px 5px; overflow-x: auto; max-width: 90vw;"><code style="margin: 0 0; border-radius: 3px; background-color: #F7F7F7; padding: 0px;">[root@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@res310 tmp]#
</code></pre>
<p dir="auto">Running v1.21.1 for samples above.</p>
<p dir="auto">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.</p>
<p dir="auto">JT</p>
</div>
</div>
</body>
</html>