Unbound - Shared Cache

Paul Vixie paul at redbarn.org
Mon Feb 10 11:11:27 UTC 2020

On Monday, 10 February 2020 09:54:44 UTC Talkabout via Unbound-users wrote:
> I am using unbound on 2 different Servers (also populated bia DHCP as 2
> different Name Servers) and would like to make sure that if one Server
> already answered a query and cached it, the other does not Need to do the
> same query to the Internet again. ...
> Question is, if there is a standard way of doing this or any suggestions
> About the „best“ solution. Maybe somebody already has something like this
> working?

this question has come up every year or so. one thing to know is that if this 
is a good idea, then it would be a good multi-vendor idea, not just for 
unbound, though unbound has a track record of doing things first that turn out 
to be good ideas and end up standardized in DNS itself in some form.

some open questions that relate to discard policy:

if you had hundreds of cache misses per second which ones would you share with 
your peer recursive nameservers? (maybe only share it after its first reuse? i 
think the opendns anycast network uses a DHT for this, to inform peers of 
availability of data, so it can be fetched from a peer if it's needed.)

if your peer is sharing hundreds of cache misses per second with you, would 
you ever discard something from your own cache to make room for something from 
theirs? (generally this isn't the right thing, so you'd give your cache two 
LRU quotas, one for your own cache misses, one for those shared to you.)

when running at quota, and needing to discard something because a peer just 
told you some new thing and you don't have room for N+1, would you choose 
least recently learned (LRL) rather than least recently used (LRU) because 
when things are used they've move from your peer-cache to your own-cache?

other open questions:

when using ECS, how do you know which cache additions to share, if your peer 
or your peer's stubs don't have the same topology as you/yours do?

would you rate limit the feed to a peer so as not to flood their capacity?

this is a fascinating topic, as i hope you'll agree.


More information about the Unbound-users mailing list