For the people using unbound, every update /etc/dnsmasq.d/01-pihole.conf must be changed by setting cache-size to 0. If a CACHE_SIZE variable could be added in setupVars.conf this would make updating a whole lot easier.
Why are you disabling the cache while running unbound?
We don't instruct users to disable the cache in our Unbound installation guide. Redirecting...
Correct, but a double cache is pointless and all other/performance guides recommend disabling the cache in Pi-hole if used in combination with Unbound. A simple option in setupVars would solve this completely.
We don't recommend disabling the cache.
Edit: But the feature request should stay open. If others think this is useful and vote for it then it will be considered.
Can you provide a few examples of these guides?
Both of those posts are in conflict with the developers recommendation for use of Pi-hole cache with unbound. Given a choice, I would follow the recommendation of the people who write the Pi-hole software.
That may be true but I needed to follow the guide on reddit because the response times were otherwise horrible. Since I've made these changes the Pi-hole + Unbound combination is very fast 
I feel that whether or not we recommend to disable the cache, there are instances where some users would benefit from the ability to easily disable the cache. We don't recommend that users throw as many lists as they can possibly find, ending with blocklists sizes in the millions, but they still do it...
Personally, I don't see the harm in adding it as something like a user-configurable flag to the FTL config file. With a suitable "HERE BE DRAGONS" message in the documentation.
3 Likes
I run Unbound and have tried it both ways; running with and without Pi-Hole's cache. In my situation, things are faster with cache enabled on Pi-hole.
That being said, I think it's good to have the option to change it in the GUI or CLI. If nothing else, it's easier to test.
I'll defer to DL and his knowledge of what needs to be enabled to allow our FTL features to work. And for planned features that may need it.
PR's accepted as always. Seems like a great first issue for a new contributor.
2 Likes
If you enable prefetch in Unbound then a local cache in pi-hole / dnsmasq prevents Unbound from knowing which records are popular and which aren't (and can then be removed from cache once full).
Interesting. My thoughts are that clients speak to Pi-hole for queries. It would seem that the fastest and highest performance would come from Pi-hole only needing to use its own internal cache to find answers to give to clients. Pi-hole having to use an external application for every query sounds like a slower option?
There’s enough cache in Unbound that I’ve never seen it fill. About 75% of Unbound’s replies come from cache in my setup probably because I have it set to serve expired.
I’ve found that the TTL on most DNS records are set low enough that Pi-Hole has to ask Unbound for an answer frequently enough that it still learns what is popular.
An answer from Pi-Hole cache is always slightly faster than one from Unbound cache in my informal testing.
That's correct, there's an additional application to go through, but Unbound can prefetch queries before they expire and thereby always serving up-to-date (ish) records. If you enable caching in dnsmasq then only a limited number of requests is sent to it and it doesn't really know what is popular and what isn't. I don't have a lot of RAM for pihole + unbound and it's running in a busy network so records need to be purged from cache regularly.
@sawsanders Yes, an answer from pihole cache is indeed faster but it's not much of an improvement. With pihole caching enabled an answer from cache is returned in 1.9ms, with Unbound as cache it's 1.95ms. This 0.05ms is easily worth the tradeoff of having a more reliable prefetch for me. Tested using namebench.
I'll see if I can get something going to add this.
I don't know if this is true, but I read several times that the prefetch in Unbound only works if the requests come from multiple and different clients - which is not the case with Pi-hole (= 1 client).
In my home environment Unbounds cache hit ratio with prefetch: yes & serve-expired: no is extreme low (<10%).
It works fine for me with one client (pihole), cache hit ratio is usually around 40% here. Nowhere in the Unbound documentation says it works any differently either. Even after a manual unbound restart it quickly picks up and prefetches stuff.
total.num.cachehits=60
total.num.cachemiss=59
total.num.prefetch=50
Are those values in percentages or actual queries/records. 60% cache hit is significant, 60 actual cache record hits is statistically insignificant.
Those numbers are actual queries. It's showing 50% cache hit.
Here's my Unbound statistics from 6 days of uptime:
total.num.queries=113770
total.num.cachehits=100633
total.num.cachemiss=13137
total.num.prefetch=83041
total.num.recursivereplies=13137