What is the correct way to consistently change the cache settings? If I manually change /etc/dnsmasq.d/01-pihole.conf the cache settings are overwritten after every update. If I add the change to another file then it prevents the service from starting up.
It's not particularly cumbersome to modify after each update, as they are not that frequent, but I feel like I'm doing something wrong.
Why do you want to change your cache settings? Is the current setting not working for you?
There is a new cache_size parameter in /etc/pihole/setupVars.conf:
And, just in case, because it never hurts to reference this:
https://docs.pi-hole.net/ftldns/dns-cache/
and highlight this part:
There is no benefit in enlarging this number except if the DNS cache evictions count is larger than zero.
It would not be to increase the size. I have one environment that I it want consistently set to 0. I will change the setupVars.conf file. Thank you!
If I may ask, why? If you are using DNSSEC, a cache size of 0 won't work.
Ah, yes, I see that now. Perhaps will reconsider.
Note that Pi-hole cannot analyze/display the DNSSEC status (INSECURE/SECURE/BOGUS) responses in this configuration. The technical details have been discussed here (very long read, do it only if you're really interested):
I actually didn't have DNSSEC enabled on the Pi-hole side. I have a local Unbound resolver in this instance.
On caching, does it make sense / is it even possible to make cache survive a reboot?
(Happy to split this question into a new topic if desired).
I'd say no to both.
First no to the second "is it even possible" because the cache is a highly dynamical datastructure and dumping it into a suitable format for reimporting would be a lot of work and may even cost some performance.
Second no to the first "does it make sense" because you should not reboot/restart all that often. Typical Pi-hole are restarted every few months when they update to a new release. In the entire meantime, the cache stays intact. Even with me, developing FTL on a daily basis, no new queries are caused by loss of the cache as I run my own unbound instance on the same machine so queries sent upstream are actually immediately replied to from unbound's cache.
It'd be a true major undertaking and I'm not seeing any real improvements from this. But maybe I'm overseeing some aspects. The main argument against is that a healthy setup shouldn't be restarted at all outside of upgrades (which would maybe even involve incompatible changes in the cache, i.e., it'd be dropped anyway).
And, even if you lose the contents of the cache there is very little in the cache after 5 minutes. So, you don't lose much. When you restart, the few domains that had a remaining TTL in the old cache will just be reloaded, at a very small cost in time (tens of milliseconds with most upstream resolvers).
Make that 99.99999999999%, or "all but two".
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.