Hi Stephane, >From the upcoming unbound 1.10.0 release, serve-stale as documented in draft-ietf-dnsop-serve-stale can be configured.
A minimal configuration to achieve this is: # Enable serve-expired serve-expired: yes # Time to keep serving expired records serve-expired-ttl: <value between 86400 and 259200> # Do not reset the TTL above on failed lookups serve-expired-ttl-reset: no # default # TTL to reply with expired entries serve-expired-reply-ttl: 30 # default # Time to wait before replying with expired data serve-expired-client-timeout: 1800 Note that the previous behavior (answering directly from cache without waiting for the actual resolution) is still available by setting: serve-expired-client-timeout: 0 # default Best regards, -- George On 14/02/2020 15:43, Stephane Bortzmeyer via Unbound-users wrote: > On Thu, Jul 11, 2019 at 05:09:30PM +0200, > Wouter Wijngaards via Unbound-users <[email protected]> wrote > a message of 74 lines which said: > >> Yes that is what it does. Unbound also attempts to refresh and >> fetch the new correct value for the record, every time it is asked. >> That should bring the record back to the correct value. Once it is >> available to be fetched. > > I'm wondering about the mapping between Unbound and the future RFC > draft-ietf-dnsop-serve-stale. If I read correctly the draft, the > resolver can send expired (stale) data only if the authoritative name > servers are not reachable. If so, serve-expired does not have the > proper behaviour. Is > > serve-expired-ttl-reset: yes > serve-expired-ttl: 86400 > > more compliant with the future RFC? (I'm not sure it is possible to be > 100% compliant with Unbound.) > >
