AW: Unbound - Shared Cache

Eric Luehrsen ericluehrsen at
Wed Feb 12 01:09:10 UTC 2020

On 2/11/20 1:53 PM, Talkabout via Unbound-users wrote:
> Hi Benno,
> I have set up Unbound with redis Cache now and will check how well this 
> works. I have one Question left: documentation states that unbound does 
> NOT invalidate keys in the redis Cache even if they expire. Question 
> from my side is why is unbound not simply using the „EXPIRE“ function of 
> redis to set the TTL to the same time that unbound receives from an 
> authority dns Server? That way no other maintenance Needs to be done. If 
> there still is a valid reason (which I am sure there is 😊), what is the 
> recommended way to cleanup redis?

If you want two truly independent recursive servers to share cache 
results, then you should configure one as "primary" and the other as 
"secondary". The primary is configured normally to recurse. The 
secondary is configured to forward to the primary (clause 
forward-zone:), but not exclusively (option forward-first: yes). Neither 
has a dependency on a central database, so no single point failure. 
Queries to the secondary will need to bounce through the primary. On a 
whole network cold boot, the cache fill will demonstrate some delay. 
Once rolling for an hour, no user will notice the difference. If the 
primary fails, the secondary can just switch over to recursion itself 
(forward-first: falls through).

If you wanted to experiment with a more corporate like configuration, 
then you would set those two Unbound instances in a firewall-DMZ. These 
two only listen to specific Unbound instances from within the firewall 
intranet (clause server: option access-control:). The intranet Unbound 
instances or dnsmasq if small office suites may only forward to the DMZ. 
You prevent all clients from being able to use DNS (port 53/853) 
externally. Their DHCP configuration only offers "nearest" two or three 
intranet DNS servers, never DMZ, and never external access.

Anyway just a quick scratch of multi server configuration which is by no 
means complete.
- Eric

More information about the Unbound-users mailing list