Indeed, it were just the total numbers immediately after a restart (< 1m uptime). After running for 2 hours (still nothing compared to previous stats):
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.
This is what I expected - and that makes it so confusing for me. Still don't know how prefetching should work if another cache answers all queries within TTL.
prefetch:<yesorno>
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.
In my opinion your observation what's in the source code does not match the explanation given in the link (I believe the explanation is wrong/outdated, not the code ).
The source code suggests that all DNS queries are prefetched. This in line with what I see because a lot gets prefetched.
--> 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)
Just to put this here: The minimum cache size enforced in conjunction with DNSSEC is 150. You will not gain much by reducing the cache to a very low value (a lot of cache evictions will appear). I don't know if you want to play around with it. I wouldn't do it.
Popular means a query arrived during the last 10% of the TTL of the
message. In general this would be domains that get more than 10 queries
per their TTL. In general this would add a limited load to the system
and traffic to authorities.
This also means that if no queries are received, the cache times out
normally.