On Fri, Jan 30, 2015 at 12:54 PM, Ingo Schwarze <[email protected]> wrote: > Hi, > > Maxim Khitrov wrote on Fri, Jan 30, 2015 at 10:22:23AM -0500: > >> I wrote two simple functions for rc.shutdown and rc.login that >> save/restore unbound cache when the system is restarted. Since each >> record has a relative TTL field, the cache can only be restored within >> a short time window to avoid serving stale data to clients. I set this >> window to 10 minutes; enough to survive a reboot, but not for any >> extended downtime. Is there any interest in including this >> functionality in the base OS (moved to /etc/rc)? > > The purpose of rebooting is to reset the system to a clean state, > so clearing caches looks like a feature rather than a bug. Given > that even "unbound-control reload" flushes the cache, a reboot > should certainly do that, too. So i wouldn't even recommend showing > this to people as something they might add to their local scripts > if they want to. It just seems wrong. > > Also note that the unbound-control(8) manual explicitly marks > load_cache as a debugging feature and warns that it may cause wrong > data to be served. On top of that, the version of unbound(8) running > after the reboot might be newer than the version running before, > so compatibility is questionable as well, so your proposal is very > fragile at best. > > Besides, even if the goal would be desirable, which it is not, my > feeling is that this code is too specialized for adding to the boot > scripts.
Fair enough, though I would note that this feature is available in pfSense, which is also using unbound. Some resolvers persist their cache to disk automatically, so it's not that strange of an idea. I wanted to share the code anyway for others who might be interested in doing the same thing. My thinking on this is that if the cache was valid before the reboot, there is no good reason to clear it two minutes later just because the kernel was upgraded. It creates a traffic spike and a noticeable performance hit for the clients, especially with DNSSEC enabled. An explicit "reload" is different because you do it when you change the unbound configuration. Version upgrades are easily handled and I've now added that to my scripts, so thanks for the suggestion.
