redis cache?

[Fredrik Pettai]

Hi Jinmei,

On 19/01/25 18:20, 神明達哉 wrote:
> At Thu, 24 Jan 2019 22:16:25 +0100,
> Fredrik Pettai via Unbound-users <unbound-users at nlnetlabs.nl
> <mailto:unbound-users at nlnetlabs.nl>> wrote:
>
> > Will unbound _only_ serve hits from redis cache for keys with expired
> > TTL if the configuration option "serve-expired: yes" is set?
> >
> > I've just tested redis cache very briefly, and it looks like keys with
> > an expired TTL didn't get updated then I asked for the same name again.
> > (If recursion happened, why not update the TTL in cachedb too?)
>
> I'm not sure if I understand your question correctly, but IIRC the
> intended behavior for the mixture of cachedb (regardless of the type
> of the backend, redis or not) and serve-expired is as follows:
>
> - when unbound finds an expired answer for a received query in
>   in-memory cache, it will still return it to the client if
>   sever-expired is yes.  it will also initiate a "prefetch" of the
>   answer to possibly update the expired answer.
> - in a prefetch, any cache including cachedb is ignored and it should
>   always cause recursive DNS resolution
> - If the recursive resolution succeeds, unbound updates its in-memory
>   cache and cachedb backend with the updated answer
>
> I've not played with this feature for some time, so something may have
> changed since then.  But I believe it worked as described above last
> time I tested the feature.  A quick read of the latest code also
> seems to suggest it's still working that way.
>
> Does this explanation answer your question?  Or are you saying that
> this is your expected behavior but unbound doesn't work this way for
> you?

Ah, my test was very brief and simple, and I didn't have prefetch enabled.

But getting the full picture it makes sense on how it all fits together.

Thanks for the explanation, I tested it again with all options enabled,
and yes now it works better.

(perhaps that should be added to the man page under cachedb)

Re,

/P


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190125/21dcb2d1/attachment.htm>