On 19/01/25 22:26, 神明達哉 wrote: > At Fri, 25 Jan 2019 21:49:24 +0100, > Fredrik Pettai <[email protected] <mailto:[email protected]>> 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->env.now >= > ((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 wikipedia.org RR : ~$ python ./unbound-1.8.3/contrib/unbound-querycachedb.py wikipedia.org ;; query=wikipedia.org/IN/A ;; key=6E5D4AD1B127B12236AD9834A75C85B4BFE0BD0D536378E93D6778EA44DFA1D8 ;; Now=1548575380, TimeStamp=1548574948, Expire=1548575548, TTL=168 id 0 opcode QUERY rcode NOERROR flags QR RD RA edns 0 eflags DO payload 4096 ;QUESTION wikipedia.org. IN A ;ANSWER wikipedia.org. 600 IN A 91.198.174.192 ;AUTHORITY ;ADDITIONAL Unbound returns SERVFAIL, and will continue to do so until the TTL in redis expires. ~$ dig wikipedia.org ; <<>> DiG 9.8.3-P1 <<>> wikipedia.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3738 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;wikipedia.org. IN A ;; Query time: 3 msec ;; SERVER: 100.64.1.10#53(100.64.1.10) ;; 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. /P
