<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Segoe UI Emoji";
        panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=DE link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Hi Benno,</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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 <span style='font-family:"Segoe UI Emoji",sans-serif'>😊</span>), what is the recommended way to cleanup redis?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks!</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Bye</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Gesendet von <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> für Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>Von: </b><a href="mailto:unbound-users@lists.nlnetlabs.nl">Talkabout via Unbound-users</a><br><b>Gesendet: </b>Montag, 10. Februar 2020 14:15<br><b>An: </b><a href="mailto:benno@NLnetLabs.nl">Benno Overeinder</a>; <a href="mailto:unbound-users@lists.nlnetlabs.nl">unbound-users@lists.nlnetlabs.nl</a><br><b>Betreff: </b>AW: Unbound - Shared Cache</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Benno,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>my real Name is Peter <span style='font-family:"Segoe UI Emoji",sans-serif'>😊</span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thank you very much for this hint, I will try to set up a redis Cache that distributes the entries among my servers.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Bye<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Gesendet von <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> für Windows 10<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b>Von: </b><a href="mailto:benno@NLnetLabs.nl">Benno Overeinder</a><br><b>Gesendet: </b>Montag, 10. Februar 2020 13:50<br><b>An: </b><a href="mailto:talk.about@gmx.de">Talkabout</a>; <a href="mailto:unbound-users@lists.nlnetlabs.nl">unbound-users@lists.nlnetlabs.nl</a><br><b>Cc: </b><a href="mailto:paul@redbarn.org">Paul Vixie</a><br><b>Betreff: </b>Re: Unbound - Shared Cache<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Talkabout (is this your real name?),<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thank you Paul for your answer.  Paul is correct that it is very dependent on your cache replacement algorithm and how to inform other resolvers that answers are already in cache.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>To answer your question, Talkabout, Unbound has a module for a shared cache with a Redis backend.  It works as a secondary cache, 1) first local cache lookup, 2) shared cache lookup, 3) resolve/iterate.  For configuration and use, see the unbound.conf(5) manpages, section "Cache DB Module Options".  (You may have to compile Unbound yourself with the --with-libhiredis option.)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Your suggestion to export/import the cache with unbound-control can be used for running Unbound clusters and you want to start a new Unbound instance with a hot cache.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Best regards,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>— Benno<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> On 10 Feb 2020, at 12:21, Talkabout via Unbound-users <unbound-users@lists.nlnetlabs.nl> wrote:<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> Hi Paul,<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> thank you very much for your Statement!<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> I am not that Deep into DNS logics so most likely not a very good communication Partner when the Topic becomes that complex <span style='font-family:"Segoe UI Emoji",sans-serif'>😊</span> I am using Unbound for my home Network only, there I think theoretical numbers like „hundreds cache misses per second“ are not that realistic. But I totally agree that making such a feature generic, this is something that Needs to be taken care of.<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> Maybe a solution can be to integrate a Sub layer inbetween the local Cache and external resolvers, a shared Cache. This shared Cache is updated by all Peers when a query gets resolved and every peer can ask the shared Cache for entries when local Cache does not deliver any results. Shared Cache instances are then automatically synchronized.<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> Obviously this Topic is not an easy one and it seems that there is Nothing in place I can reuse.<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> Thanks again!<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> Bye<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> Gesendet von Mail für Windows 10<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> Von: Paul Vixie<o:p></o:p></p><p class=MsoNormal>> Gesendet: Montag, 10. Februar 2020 12:11<o:p></o:p></p><p class=MsoNormal>> An: unbound-users@lists.nlnetlabs.nl<o:p></o:p></p><p class=MsoNormal>> Cc: Talkabout<o:p></o:p></p><p class=MsoNormal>> Betreff: Re: Unbound - Shared Cache<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> On Monday, 10 February 2020 09:54:44 UTC Talkabout via Unbound-users wrote:<o:p></o:p></p><p class=MsoNormal>> > I am using unbound on 2 different Servers (also populated bia DHCP as 2<o:p></o:p></p><p class=MsoNormal>> > different Name Servers) and would like to make sure that if one Server<o:p></o:p></p><p class=MsoNormal>> > already answered a query and cached it, the other does not Need to do the<o:p></o:p></p><p class=MsoNormal>> > same query to the Internet again. ...<o:p></o:p></p><p class=MsoNormal>> > Question is, if there is a standard way of doing this or any suggestions<o:p></o:p></p><p class=MsoNormal>> > About the „best“ solution. Maybe somebody already has something like this<o:p></o:p></p><p class=MsoNormal>> > working?<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> this question has come up every year or so. one thing to know is that if this<o:p></o:p></p><p class=MsoNormal>> is a good idea, then it would be a good multi-vendor idea, not just for<o:p></o:p></p><p class=MsoNormal>> unbound, though unbound has a track record of doing things first that turn out<o:p></o:p></p><p class=MsoNormal>> to be good ideas and end up standardized in DNS itself in some form.<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> some open questions that relate to discard policy:<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> if you had hundreds of cache misses per second which ones would you share with<o:p></o:p></p><p class=MsoNormal>> your peer recursive nameservers? (maybe only share it after its first reuse? i<o:p></o:p></p><p class=MsoNormal>> think the opendns anycast network uses a DHT for this, to inform peers of<o:p></o:p></p><p class=MsoNormal>> availability of data, so it can be fetched from a peer if it's needed.)<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> if your peer is sharing hundreds of cache misses per second with you, would<o:p></o:p></p><p class=MsoNormal>> you ever discard something from your own cache to make room for something from<o:p></o:p></p><p class=MsoNormal>> theirs? (generally this isn't the right thing, so you'd give your cache two<o:p></o:p></p><p class=MsoNormal>> LRU quotas, one for your own cache misses, one for those shared to you.)<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> when running at quota, and needing to discard something because a peer just<o:p></o:p></p><p class=MsoNormal>> told you some new thing and you don't have room for N+1, would you choose<o:p></o:p></p><p class=MsoNormal>> least recently learned (LRL) rather than least recently used (LRU) because<o:p></o:p></p><p class=MsoNormal>> when things are used they've move from your peer-cache to your own-cache?<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> other open questions:<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> when using ECS, how do you know which cache additions to share, if your peer<o:p></o:p></p><p class=MsoNormal>> or your peer's stubs don't have the same topology as you/yours do?<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> would you rate limit the feed to a peer so as not to flood their capacity?<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> this is a fascinating topic, as i hope you'll agree.<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> --<o:p></o:p></p><p class=MsoNormal>> Paul<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-- <o:p></o:p></p><p class=MsoNormal>Benno J. Overeinder<o:p></o:p></p><p class=MsoNormal>NLnet Labs<o:p></o:p></p><p class=MsoNormal>https://www.nlnetlabs.nl/<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>