serve-expired-ttl

Unbound
1

Hello,

I run an unbound instance with "serve-expired: yes"
Today I notices a record I deleted hours ago is still served by unbound. Domains SOA negative ttl is 1h, too.
The I found "serve-expired-ttl" with a default value of 0 meaning no expiration.

So will unbound happily serve a deleted record for a very very long time
unless unbound has to kick it from it's cache for some reasons that are not really visible to me?

In that case the default "0 / no expire" is questionable.

Andreas

2

Hi Andreas,

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.

That makes the 0 value possible as a default, it is used until a better
value becomes available.

Best regards, Wouter

3

but I felt, unbound ignored the auth's NXDOMAIN

Andreas

4

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.)

5

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