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
Indeed, it were just the total numbers immediately after a restart (< 1m uptime). After running for 2 hours (still nothing compared to previous stats):
total.num.queries=2553
total.num.cachehits=2095
total.num.cachemiss=458
total.num.prefetch=1413
Caching + prefetching is working well (as it did before 
). Since I've added Unbound the dns response times have been greatly reduced. Of course that's mostly for repeatedly visited websites, but that's what matters to me as I don't really browse that many new pages on a daily basis.
I know the Devs don't recommend disabling the cache - I would like to know why you don't recommend it. Is there a specific reason except for answers might a bit faster coming from pihole's cache than unbound's cache?
You assume everyone uses Unbound.
To expand. A properly functioning cache will store for the life of the TTL value. Doesn't matter who caches it. If Pi-hole is directly querying Unbound then both Pi-hole and Unbound will have the same data for the same amount of time.