serve-expired: "yes" and cache-min-ttl: 30 unsafe?
marcnarc at xiplink.com
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