redis cache?

Fredrik Pettai pettai at
Sun Jan 27 09:36:15 UTC 2019

On 19/01/25 22:26, 神明達哉 wrote:
> At Fri, 25 Jan 2019 21:49:24 +0100,
> Fredrik Pettai <pettai at <mailto:pettai at>> wrote:
> > 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.
> Good to know it now works, but if you had to explicitly enable
> prefetch, that actually doesn't sound right.  In my
> understanding, a prefetch should be attempted when you enable
> serve-expired and use expired answer even if prefetch itself is
> disabled in the configuration.  The most relevant part of the source
> code suggests that's the case:
>                 if((worker->env.cfg->prefetch ||
> worker->env.cfg->serve_expired)
>                     && *worker-> >=
>                     ((struct reply_info*)e->data)->prefetch_ttl) {
> [...]
>                     reply_and_prefetch(worker, lookup_qinfo,
>                         sldns_buffer_read_u16_at(c->buffer, 2),
>                         repinfo, leeway);
> So if it really required to enable prefetch, that may actually be some
> kind of bug.  But in any case...

No, your right, it works the way your describing it (even without
serve-expired and/or prefetch enabled).

There must have been something incomplete/wrongly configured then I did
the first brief test, because now I observe the expected behavior with
regards to redis updates.

However, there's a problem with cachedb then you restart unbound
(serve-expired enabled or not).

Even though there's non-expired data in redis, for example this RR :

~$ python ./unbound-1.8.3/contrib/
;; key=6E5D4AD1B127B12236AD9834A75C85B4BFE0BD0D536378E93D6778EA44DFA1D8
;; Now=1548575380, TimeStamp=1548574948, Expire=1548575548, TTL=168
id 0
opcode QUERY
flags QR RD RA
edns 0
eflags DO
payload 4096

Unbound returns SERVFAIL, and will continue to do so until the TTL in
redis expires.

~$ dig

; <<>> DiG 9.8.3-P1 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3738
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;            IN    A

;; Query time: 3 msec
;; WHEN: Sun Jan 27 08:49:38 2019
;; MSG SIZE  rcvd: 31

After the TTL has expired in redis, and if serve-expired is enabled, the
first query will still get a SERVFAIL (but now prefetch goes out in the
background and updates cachedb) and after that's done, the next query
will be given a correct answer. and after this no more SERVFAILs happens
for that RR even then the TTL expires in redis.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unbound-users mailing list