serve-expired: "yes" and cache-min-ttl: 30 unsafe?

Marc Branchaud marcnarc at
Mon Oct 29 14:14:52 UTC 2018

On 2018-10-28 3:20 p.m., Nick Urbanik via Unbound-users wrote:
> Dear Folks,
> On 25/10/18 18:10 +1100, Nick Urbanik via Unbound-users wrote:
>> I am puzzled by the behaviour of our multi-level DNS system which
>> answered many queries for names having shorter TTLs with SERVFAIL.
> I mean that SERVFAILs went up to 50% of replies, and current names
> with TTLs of around 300 failed to be fetched by the resolver, the last
> DNS servers in the chain.  What I mean is that adding these two
> configuration options (serve-expired: "yes" and cache-min-ttl: 30)
> caused an outage.  I am trying to understand why.
> Any ideas in understanding the mechanism would be very welcome.

We use 1.6.8 with both those settings, and observed prolonged SERVFAIL 

In our case, the upstream server became inaccessible for a period of 
time, but when contact resumed the SERVFAILs persisted.

We reduced the infra-host-ttl value to compensate.

(Why is infra-host-ttl's default 900 seconds?  That seems like a long 
time to wait to retry the upstream server.)


>> By multilevel, I mean clients talk to one server, which forwards to
>> another, and for some clients, there is a third level of caching.
>> So it was unwise to add:
>> serve-expired: "yes"
>> cache-min-ttl: 30
>> to the server section of these DNS servers running unbound 1.6.8 on
>> up to date RHEL 7?  Please could anyone cast some light on why this
>> was so?  I will be spending some time examining the cause.
>> If you need more information, please let me know.

More information about the Unbound-users mailing list