I was wondering recently if there would be any way to optimize the cache performance of the combination of Pi-Hole and Unbound.
In Unbound, you can tweak the use of cache quite extensively (cache size, min and max TTL, prefetch of queries, ...) and also Pi-Hole has a number of settings and defined parameters.
Is there a way we can optimize way Pi-Hole PLUS Unbound do caching (and are configured for cache) to optimize the overall performance?
(to be clear, I am not trying to re-open the discussion on the setting of Pi-Hole cache size to 0...)
An example for what I was thinking: on today, a query that is in Pi-Hole's cache will not hit Unbound when it comes up, but if it is within the last 10% of its TTL, it would cause a prefetch in Unbound when prefetching is enabled if it would hit Unbound.
That's exactly where the discussion will end up, though, because it is really only prefetching that is missing from Pi-hole. Pi-hole will simply cache the responses as it gets them from unbound, so you can do all your optimisations in regards to cached TTLs in unboundand they will transfer over to Pi-hole.
To get unbound to perform a prefetch, however, you need to query it when there is little TTL left in cache, and that won't happen because Pi-hole will also have the response in cache and Pi-hole won't query unbound in that case.
And so the only reliable way to make unbound prefetch DNS records is to disable Pi-hole's cache to force it to query unbound. Everything else you can optimise in unbound and Pi-hole will cache the optimised responses it gets from unbound.
If you really believe that client-side caching is a problem, you'd have to go ahead and disable or tweak all DNS caches on each and every client in your network.
DNS provides a TTL for records answered, and any client (not just Pi-hole) is free to hold on to those results until that TTL expires before requesting it anew.
Pi-hole has an impact on unbound, but it's not from Pi-hole caching - unbound has to assume that any client would cache DNS answers anyway.
Pi-hole's impact is caused by the fact that unbound will see only one request for a domain from Pi-hole where Pi-hole potentially sees multiple requests from several software installations on multiple clients, and that may influence what domains are rated as popular enough for prefetching by unbound. TTLs themselves are irrelevant in that regard.
If you worry about this, you'd have to eliminate Pi-hole from your network.
If you prefer to keep Pi-hole, I am very confident that unbound is already optimising DNS traffic originating from Pi-hole (and potentially other clients) as is adequate and possible in such a constellation.
