Bind9 shared cache

Ondřej Surý ondrej at isc.org
Sun Apr 19 18:45:36 UTC 2020


Hi,

in my experience with building yet another DNS resolver from scratch was that the gain from the shared networked cache was heavily paid in the latency.

I would encourage you to actually do a performance testing with cold and hot cache and my educated guess is that shared redis cache will help with bootstrapping, but once you reach a state where most of the answers are already in the cache there’s no or negative benefit from it.

I believe that in most scenarios the increased complexity in not worth the benefit gained.

Ondrej
--
Ondřej Surý — ISC

> On 19 Apr 2020, at 12:27, Talkabout <talk.about at gmx.de> wrote:
> 
> 
> Hi all,
>  
> I am considering to switch from Unbound to Bind9 to use as DNS Server, but I have a requirement that seems to not being possible with Bind9.
>  
> Currently I am using 2 Unbound DNS Servers configured to use Redis (KeyDB as a drop-in replacement in my case) to make sure that both Servers are sharing the same Cache. That way, when server1 resolves an address and puts it into the backend database, server2 does not Need to execute Resolution for this address any more but gets it fast from the shared Cache.
>  
> I have not found any way in the Bind9 documentation to achieve a similar Thing. So my Questions are:
>  
> Is there a way to configure a shared Cache that is used by multiple Servers?
> Is there a way to configure custom backends for Bind9?
> Are there any plans to support similar Scenarios? Maybe via a Synchronisation mechanism?
>  
> Thanks!
>  
> Bye
>  
> Gesendet von Mail für Windows 10
>  
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200419/80986634/attachment-0001.htm>


More information about the bind-users mailing list