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.
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?
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.
Ok, I wasn't specific enough - as you pointed out: why don't you recommend disabling the cache in conjunction with Unbound? (I assumed this limitation was obvious as this whole topic was about pihole together with unbound.)
So you still wouldn't recommend it - but it also wouldn't harm any function of pihole?
What I don't get then is the recommended setting for Unbound prefetch: yes.
If both caches contain the same data for the same amount of time queries will be answered by pihole's cache until TTL expires and only afterwards forwarded to Unbound where TTL has also expired. But prefetch: yes will only work if Unbound gets queried for a cached hostname which is going to expire in less than 10% of its TTL. But this would never happen as with >10% TTL the query will be answered by pihole. However I see Unbound does prefetch domains (with both caches enabled) - but where do the necessary queries come from? Does pihole generate those requests as part of a prefetch algorithm?
No. Pi-hole does not perform any pre-fetching. It answers DNS queries as they arrive. If the answer is in cache, the cached answer is served. If not, then Pi-hole goes to the upstream resolver and gets the answer.
If yes, message cache elements are prefetched before they expire
to keep the cache up to date. Default is no. Turning it on
gives about 10 percent more traffic and load on the machine, but
popular items do not expire from the cache.
There is no explanation of "popular items". This is always the time where you'll have to look into the source code (so I did this). It's not simple to say this as the situation between "ordinary" DNS and "mesh" DNS is somewhat different, however, at first glance, it seems that all DNS queries are prefetched when they are close to TTL expiration. One could consult total.num.prefetch and compare it to total.num.queries to get some experimental data (unbound-control).
edit See also: [Unbound-users] About the prefetch switch used in the unbound.conf.
This explanation makes it clear that prefetching might not have an effect with caching enabled. It may be a valid point to argue for disabling Pi-hole's cache. However, mind that DNSSEC will not be available without a cache as the cache is integral to DNSSEC validation. The validation requires the use of a whole set of RRsets. The only way to have all those RRsets is to put them in the cache or you'd generate a ton of requests each time. This would surely be disadvantageous.
--> Disabling Pihole's cache is not necessary, prefetching happens anyway.
The deeper explanation given in the link is in line with unbound.conf man where 10% more traffic is expected as
If a client requests the dns lookup and the TTL of the cached hostname is going to expire in less than 10% of its TTL, unbound will (1st) return the ip of the host to the client and (2nd) pre-fetch the dns request from the remote dns server. This method has been shown to increase the amount of cached hits by local clients by 10% on average."
--> Disabling Pihole's cache might be beneficial as Unbound would be queried already for "close-to expiring" entries and not only for "already expired" entries
As I actually see 1) it leads me to the conclusion that the explanation given in 2) is wrong/outdated (they might have changed the behavior at some point).
Conclusion: Prefetching works also with Pihole's cache enabled and aside from a theoretical tiny tiny speed improvement there are no additional benefits from disabling it (but negative side effects on DNSSEC might occur)