pettai at sunet.se
Fri Jan 25 20:49:24 UTC 2019
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
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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Unbound-users