serve-expired-ttl

[George Thessalonikefs]

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 <unbound-users at nlnetlabs.nl> 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.)
> 
>