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!