Oh yes, but you see there also the reason for why it still wasn't changed - I put it on some paper and then forgot. Problem is that I'm traveling as well now. If you want to submit a docs PR I'd be happy approving and merging it.
Is this a also starting from an empty Redis database?
I'm repeating myself here, but I still don't see what Redis effectively brings into play with serve-expired: yes besides a possible restarting resistance.
For me that is already a reason or advantage.
I noticed another, probably important sentence in the unbound documentation:
The thread waiting for a response from the Redis server cannot handle other DNS queries.
To my understanding, this means a change to the num-threads setting will also be required, this to avoid delays
num-threads: 2
anybody agrees / disagrees?
Where can I find instructions on how to do that without causing problems?
To ensure I don't need to troubleshoot Redis problems, I've added the following:
#!/bin/bash
redis-cli FLUSHALL
ExecStartPre=/etc/unbound/clearRedisDB.sh
This empties the Redis cache whenever unbound starts, so both caches where empty before this log entries where entered.
Indeed "prefetch: yes" is in my unbound config, but the serve-expired rows are not present.
What is the best config to adhere to the RFC's?
Answering my own question here. Found this document on how to optimize unbound
On a raspberry pi 3B and 3B+, this would imply the correct setting on a 3B would be num-threads: 4
With the great help of @mibere (hank you for this), I've made some changes to my unbound config. This implies unbound needs to be compiled with an additional option: --with-libevent, which requires the installation of libevent-dev (sudo apt-get -y install libevent-dev).
I've already applied some of the proposed settings, not all (yet), and have updated my GitHub repository to reflect the changes.
Feel free to comment on / discuss the settings in these configuration files.
Not sure, but I don't expect Redis to have a great impact (if any), when these settings are not present. To verify this, you could increase the verbosity of unbound, and check the unbound log for entries containing redis_lookup found (sudo cat /etc/unbound/unbound.log | grep redis - use the correct location). It's a lot of logging (verbosity 5), so ensure you have sufficient disk space...
I'm still using my initial settings, evaluating this and keeping the proposed settings from @mibere in mind (see above).
Fork GitHub - pi-hole/docs: The official Pi-hole documentation and submit a PR against master (there is no development branch on this repo). After the PR has been merged, the changes will be automatically deployed to https://docs.pi-hole.net
Thanks for this information. It is useful
Hi guys,
wanted to share some experience with unbound and redis on my end. I was searching for a way to have a shared cache across multiple unbound instances. Out of the box there is no way to do this and also redis is not able to provide such a functionality. But fortunately there is an alternative: KeyDB. This tool is 100% Redis compatible and also provides active replication. With that, setting up KeyDB on 2 servers together with unbound, it is possible to have 2 DNS servers sharing same data and provide fallback mechanism in case, one of the servers crashes.
Additionally I was not very happy about the fact that unbound is not setting the expiry date on redis records although the ttl is known at that point of time where those are written to the database. Because of that I changed the unbound code slightly with the help in this thread:
My fix is not a final one and I am pretty sure it can be optimized, but with the fix it is not necessary any more to deal with eviction policies, as redis/keydb now automatically removes the expired records. For everybody interested in the code I have attached the changed files that need to be extracted to the subfolder "cachedb" of the unbound source.
Bye
cachedb.zip (13.2 KB)
P.S. Source code is based on Unbound 1.9.6
Pull Request
I realize this is older, but I am trying to do exactly what you've described.
Could you please help me by showing me your modified KeyDB conf and your relevant Unbound conf settings?
Is there an unbound statistic that can verify the cachedb status?
The GitHub repository has been removed, since it contained outdated / misleading information. It's impossible to provide the settings you need to use, since a lot of them are hardware dependent. Read this document to find the proper settings for your system.
My question was directed to Talkabout, if you could mention him that would be great as I'm not permitted as a new member
Hi @ctrlbrk ,
the fix mentioned in the first post has been merged to the master of unbound and released with version 1.13.0.
On KeyDB side you "only" need to add following lines to each instance:
active-replica yes
replicaof XXX.XXX.XX.XX 6379
The "replicaof" needs to be the IP address of the instance to sync with.
On Unbound side you need to configure:
cachedb:
backend: "redis"
redis-server-host: XXX.XXX.XX.XX
redis-server-port: 6379
redis-timeout: 500
redis-expire-records: yes
Important here is that you need to build Unbound with redis and cachedb support. To do so add following arguments to "configure"-command:
--with-libhiredis --enable-cachedb
and install all dependencies.
With this configuration your Unbound instances should put the resolved domains into KeyDB and KeyDB takes care of synching them to all other KeyDB instances.
On Raspbian you can use these command lines after you have checked out Unbound code and navigated into the folder:
sudo apt-get install -y libhiredis-dev libssl-dev libevent-dev libexpat1-dev bison
./configure --prefix=/usr --sysconfdir=/etc --disable-static --with-libevent --with-libhiredis --enable-cachedb --with-pidfile=/run/unbound.pid
make
sudo make install
Hope that helps!
Sorry for necroing this thread, the topic came just up our end, and I was wondering about the use case for a secondary Unbound cache in general.
Why not adjusting parameters of the primary Unbound cache instead? With cachedb, Unbound first checks its own cache, then checks the secondary/external cache, so it naturally is slower, compared to aligning the primary cache parameters.
And with Pi-hole, you do already have an additional cache in front of Unbound, that can again be configured to own needs. Adding Redis hence means 3 caches 
.
While this is true, we are talking about a single request (per host) that takes a little longer. Is speeding up the very first request of each hostname worth the hassle of setting up a secondary (with Pi-hole tertiary) cache? And Unbound is not regularly restarted, unless some openresolv auto-(mis)configuration messes with it, which luckily was removed from Debian's openresolv package.
I see, basically @DL6ER asked all that already, looping through the thread I could not find a good answer so far, but also some links are down. Would be interested in hearing some use case 
.
In any case, Debian Trixie's Unbound has cachedb with Redis backend support builtin. For older Debian versions, we started to compile own packages, currently here (also available for Bullseye), later in the parent dir, adding them eventually to our APT repository, after some little more time of testing. It is latest upstream Unbound, with cachedb and Redis-backend enabled as well. While compiled mainly for DietPi users, it is mostly compatible with the original Debian package. No Python module support though (optionally adding Python scripts into Unbound query and answer processing), and we removed all the resolvconf cross-configuration stuff causes Pi-hole users headache:
unbound-resolvconf.service which forcefully adds Unbound to the local /etc/resolv.conf, even that IMO this is not recommended, at least not a default./etc/resolvconf/update.d/unbound, which is even worse, adding all external nameservers from /etc/resolv.conf to the Unbound forward zone, effectively disabling recursive resolving and in case allowing to bypass upstream DoT. Same nonsense openresolv used to do. It was disabled (missing executable bit) in earlier Debian versions, even explaining in the script why it is a bad idea, but is now enabled and effective by default, no idea why. Someone too keep in mind for the Pi-hole team. Documented way to disable this, and the way it was in earlier Debian versions:chmod -x /etc/resolvconf/update.d/unbound