serve-expired: "yes" and cache-min-ttl: 30 unsafe?
Marc Branchaud
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
periods.
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.)
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.
More information about the Unbound-users
mailing list