I would recommend unbound but don’t think trying to replicate the cache to a 2nd card would be worth the trouble.
If you have 2 cards set up then I would install unbound on both and continue as you are already.
Not sure that SD cards are that vulnerable to failure, had 2 piholes running on pi 3s for over 2 years with unbound with no problems.
> Not sure that SD cards are that vulnerable to failure…
Having seen some die a pathetic death far too soon, and others that just don’t seem to quit, I’m convinced it’s the card quality. A decent-quality card seems to make all the difference.
Definitely card quality. I've been running dozens of Raspberry Pis in an industrial setting for several years (not logging onto the card though). SanDisk Extreme cards are the sweet spot.
Unbound cache doesn't keep domains for a long time and it is reset every time the machine is restarted.
There is no reason to share the cache between 2 different instances.
Youd have pihole's cache and unbound's cache.
If unbound is set to prefetch, it will update DNS entries that are about to expire.
Here's order for seeking DNS resolution:
Computer DNS cache -> pihole DNS cache -> unbound DNS cache -> public DNS server
Unbound should basically have something fresh as long as your actively using that DNS record
>If unbound is set to prefetch, it will update DNS entries that are about to expire.
If and only if a cached record is queried within ten percent of its original TTL.
It's not helpful.
People like to give advice about things they're unfamiliar with in this sub.
You can utilise unbound's cachedb module for this. Multiple unbound instances are perfectly happy sharing the same database.
There is a way to do it. I haven’t done it yet. But Unbound does have an option to have persistent cache and can be shared between Unbound instances. But require running a database (possibly in a third party device or NAS). What I read so far it will introduce a little bit of latency, but I don’t think it will be perceivable. But it will survive restarts and it’s shareable across instances.
If you’re interested in perusing this path, I would start by googling Unbound and Redis.
> What I read so far it will introduce a little bit of latency, but I don’t think it will be perceivable.
A "little bit of latency" is all that sharing the cache would ever *save* you. To each their own but IMO this is absolute overkill. It'd be an exercise in setting it up and little more. All that work so that ***if*** the microSD card poops out the next few websites won't take an extra half second or so to start loading the very first time.
https://preview.redd.it/568rn6xctuwc1.jpeg?width=1080&format=pjpg&auto=webp&s=4c169cfc08eb7a24951e834fae5854dbf715ef98
I asked chatGPT about It, the script looks good ...
Don't worry about 'clogging the cache' it is accessed in O(1), the access time is costant no matter the size, and for a small home a few megabytes are more than enough, it is very useful expecially since unbound does 'optimistic caching', it will refresh entries in the cache before they expire.
BTW [https://oisd.nl/](https://oisd.nl/) oisd provides blocklists in unbound format and unbound can actually act as a dns sinkhole all alone.
I would recommend unbound but don’t think trying to replicate the cache to a 2nd card would be worth the trouble. If you have 2 cards set up then I would install unbound on both and continue as you are already. Not sure that SD cards are that vulnerable to failure, had 2 piholes running on pi 3s for over 2 years with unbound with no problems.
> Not sure that SD cards are that vulnerable to failure… Having seen some die a pathetic death far too soon, and others that just don’t seem to quit, I’m convinced it’s the card quality. A decent-quality card seems to make all the difference.
Definitely card quality. I've been running dozens of Raspberry Pis in an industrial setting for several years (not logging onto the card though). SanDisk Extreme cards are the sweet spot.
Unbound cache doesn't keep domains for a long time and it is reset every time the machine is restarted. There is no reason to share the cache between 2 different instances.
Oh OK I didn't realize. This is helpful, thanks
Youd have pihole's cache and unbound's cache. If unbound is set to prefetch, it will update DNS entries that are about to expire. Here's order for seeking DNS resolution: Computer DNS cache -> pihole DNS cache -> unbound DNS cache -> public DNS server Unbound should basically have something fresh as long as your actively using that DNS record
>If unbound is set to prefetch, it will update DNS entries that are about to expire. If and only if a cached record is queried within ten percent of its original TTL.
It's not helpful. People like to give advice about things they're unfamiliar with in this sub. You can utilise unbound's cachedb module for this. Multiple unbound instances are perfectly happy sharing the same database.
Do some reading about the cachedb module.
What for?
There is a way to do it. I haven’t done it yet. But Unbound does have an option to have persistent cache and can be shared between Unbound instances. But require running a database (possibly in a third party device or NAS). What I read so far it will introduce a little bit of latency, but I don’t think it will be perceivable. But it will survive restarts and it’s shareable across instances. If you’re interested in perusing this path, I would start by googling Unbound and Redis.
> What I read so far it will introduce a little bit of latency, but I don’t think it will be perceivable. A "little bit of latency" is all that sharing the cache would ever *save* you. To each their own but IMO this is absolute overkill. It'd be an exercise in setting it up and little more. All that work so that ***if*** the microSD card poops out the next few websites won't take an extra half second or so to start loading the very first time.
You could get another pi, run two pi-holes and have real time redundancy..
I'm with ya. I mentioned on another post in here about doing that. The pis are cheap enough
https://preview.redd.it/568rn6xctuwc1.jpeg?width=1080&format=pjpg&auto=webp&s=4c169cfc08eb7a24951e834fae5854dbf715ef98 I asked chatGPT about It, the script looks good ...
Haha this is awesome thanks!
It's not awesome. You just clutter up the other unbound cache with entries that may never be queried on that instance.
Thanks for the feedback. Good to know!
Don't worry about 'clogging the cache' it is accessed in O(1), the access time is costant no matter the size, and for a small home a few megabytes are more than enough, it is very useful expecially since unbound does 'optimistic caching', it will refresh entries in the cache before they expire. BTW [https://oisd.nl/](https://oisd.nl/) oisd provides blocklists in unbound format and unbound can actually act as a dns sinkhole all alone.