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

Nick Urbanik nick.urbanik at
Tue Oct 30 05:50:29 UTC 2018

Dear Marc,

Thank you for your reply.

On 29/10/18 10:14 -0400, Marc Branchaud via Unbound-users wrote:
>On 2018-10-28 3:20 p.m., Nick Urbanik via Unbound-users wrote:
>> 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.

This behaviour was quite catastrophic, and to me, unexpected.

Do you have any idea of the mechanism behind this failure?

Is there a way to deal better with zero TTL names?

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

Did that bring your system to a functioning condition?

>(Why is infra-host-ttl's default 900 seconds?  That seems like a long 
>time to wait to retry the upstream server.)
>		M.
>>> 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.
Nick Urbanik 808-71011 nick.urbanik at
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24  ID: BB9D2C24
I disclaim, therefore I am.

More information about the Unbound-users mailing list