<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 19/01/25 22:26, 神明達哉 wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJE_bqdRLYkhtenjmz8wVpCuA8khBocfpKqv==Q8SiedOVZbVQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">At Fri, 25 Jan 2019 21:49:24 +0100,<br>
          Fredrik Pettai <<a href="mailto:pettai@sunet.se"
            moz-do-not-send="true">pettai@sunet.se</a>> wrote:<br>
          <br>
          > Ah, my test was very brief and simple, and I didn't have
          prefetch enabled.<br>
          > But getting the full picture it makes sense on how it all
          fits together.<br>
          > <br>
          > Thanks for the explanation, I tested it again with all
          options enabled,<br>
          > and yes now it works better.<br>
          <br>
          Good to know it now works, but if you had to explicitly enable<br>
          prefetch, that actually doesn't sound right.  In my<br>
          understanding, a prefetch should be attempted when you enable<br>
          serve-expired and use expired answer even if prefetch itself
          is<br>
          disabled in the configuration.  The most relevant part of the
          source<br>
          code suggests that's the case:<br>
          <br>
                          if((worker->env.cfg->prefetch ||
          worker->env.cfg->serve_expired)<br>
                              && *worker->env.now >=<br>
                              ((struct
          reply_info*)e->data)->prefetch_ttl) {<br>
          [...]<br>
                              reply_and_prefetch(worker, lookup_qinfo,<br>
                                  sldns_buffer_read_u16_at(c->buffer,
          2),<br>
                                  repinfo, leeway);<br>
          <br>
          So if it really required to enable prefetch, that may actually
          be some<br>
          kind of bug.  But in any case...<br>
        </div>
      </div>
    </blockquote>
    <p>No, your right, it works the way your describing it (even without
      serve-expired and/or prefetch enabled).<br>
    </p>
    <p>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.<br>
    </p>
    <p><br>
    </p>
    <p>However, there's a problem with cachedb then you restart unbound
      (serve-expired enabled or not).</p>
    <p>Even though there's non-expired data in redis, for example this
      wikipedia.org RR :</p>
    <p>~$ python ./unbound-1.8.3/contrib/unbound-querycachedb.py
      wikipedia.org<br>
      ;; query=wikipedia.org/IN/A<br>
      ;;
      key=6E5D4AD1B127B12236AD9834A75C85B4BFE0BD0D536378E93D6778EA44DFA1D8<br>
      ;; Now=1548575380, TimeStamp=1548574948, Expire=1548575548,
      TTL=168<br>
      id 0<br>
      opcode QUERY<br>
      rcode NOERROR<br>
      flags QR RD RA<br>
      edns 0<br>
      eflags DO<br>
      payload 4096<br>
      ;QUESTION<br>
      wikipedia.org. IN A<br>
      ;ANSWER<br>
      wikipedia.org. 600 IN A 91.198.174.192<br>
      ;AUTHORITY<br>
      ;ADDITIONAL</p>
    <p>Unbound returns SERVFAIL, and will continue to do so until the
      TTL in redis expires.<br>
    </p>
    <p>~$ dig wikipedia.org<br>
      <br>
      ; <<>> DiG 9.8.3-P1 <<>> wikipedia.org<br>
      ;; global options: +cmd<br>
      ;; Got answer:<br>
      ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id:
      3738<br>
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL:
      0<br>
      <br>
      ;; QUESTION SECTION:<br>
      ;wikipedia.org.            IN    A<br>
      <br>
      ;; Query time: 3 msec<br>
      ;; SERVER: 100.64.1.10#53(100.64.1.10)<br>
      ;; WHEN: Sun Jan 27 08:49:38 2019<br>
      ;; MSG SIZE  rcvd: 31<br>
    </p>
    <p>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>
    <p><br>
    </p>
    <p>/P<br>
    </p>
  </body>
</html>