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

[Wouter Wijngaards]

Hi Nick,

The report says that you were using 1.6.8, but in 1.7.1 there is this
bugfix: - Fix #3736: Fix 0 TTL domains stuck on SERVFAIL unless manually
          flushed with serve-expired on.
The SERVFAIL must be caused by the brief outage, and that bug then
happened.  So, it could be something that is already fixed, but if not,
it would be good to get details; to reproduce and fix.

Best regards, Wouter

On 11/15/18 8:26 PM, Nick Urbanik via Unbound-users wrote:
> Dear Ralph,
> 
> On 15/11/18 11:13 +0100, Ralph Dolmans via Unbound-users wrote:
>> Sorry to hear Unbound has caused you problems. I'm trying to figure out
>> the reason of the observed SERVFAIL responses.
> 
> Thank you.
> 
>> Was the serve-expired and cache-min-ttl configured on the Unbound
>> instance that has the forward configured, or the instance the queries
>> are forwarded to? Or both?
> 
> Both.
> 
>> Any change the SERVFAILS were only for DNSSEC signed domains?
> 
> No, a particular name in our domain which is not signed often came
> back with SERVFAIL after it expired from the cache.
> 
>> Did you had a change to see the reason for the SERVFAIL responses in
>> the Unbound log? Maybe the forwarder was returning expired DNSSEC
>> signatures?
> 
> There were many SERVFAIL responses for queries for DS records.
> 
>> -- Ralph
>>
>> On 25-10-18 09:10, Nick Urbanik via Unbound-users wrote:
>>> Dear Folks,
>>>
>>> Thank you for an excellent piece of software.
>>>
>>> I am puzzled by the behaviour of our multi-level DNS system which
>>> answered many queries for names having shorter TTLs with SERVFAIL.
>>>
>>> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181126/7683d948/attachment.bin>