AW: Unbound - Shared Cache

[dylanfarstveet]

Please stop emailing me. Remove me from any list. You have and unsubscribe me. I do not wish to be emailed by thisSent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: Eric Luehrsen via Unbound-users <unbound-users at lists.nlnetlabs.nl> Date: 2/11/20  18:09  (GMT-07:00) To: Talkabout <talk.about at gmx.de>, Benno Overeinder <benno at NLnetLabs.nl>, unbound-users at lists.nlnetlabs.nl Subject: Re: AW: Unbound - Shared Cache 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20200211/fcca0ad4/attachment.htm>