serve-expired seems to break flush_zone

[Marc Branchaud]

On 2018-04-06 02:47 AM, W.C.A. Wijngaards via Unbound-users wrote:
> Hi Marc,
> 
> On 04/04/18 20:29, Marc Branchaud via Unbound-users wrote:
>> Hi all,
>>
>> I have a simple forward-everything setup with serve-expired enabled:
>>
>>      server:
>>          serve-expired: yes
>>      forward-zone:
>>          name: .
>>          forward-addr: X.X.X.X
>>
>> If I use "flush_zone ." to clear the cache, I still get cache hits for
>> supposedly-absent entries (dump_cache shows that the cache is empty).
>>
>> When I turn serve-expired off, "flush_zone ." results in cache misses
>> for flushed entries.
>>
>> With serve-expired on, I can only seem to force a cache miss by
>> explicitly flushing a name (e.g. "flush google.com").  I really want to
>> clear the entire cache, though.
>>
>> Is this an intended effect of serve-expired, or is it a bug?
> 
> Right now this is the design of flush-zone, it iterates over the cache
> contents.  And it sets every element of the flushed zone to the expired
> state.  I couldn't really delete the element at that time, because the
> iterator would become invalid.

I figured it was something like that.  Perhaps the man page could 
mention this?  The entry for flush_zone says "Remove all information at 
or below the name from the cache" but maybe instead something like "Set 
the TTL to 0 for all cache entries at and below the name."

> I could however, set other flags or things to the expired data.  Eg
> SERVFAIL.  But then the customer receives servfail and the prefetch
> happens, instead of the customer receiving the old data and a prefetch
> happens, which is what there is now.

I prefer that serve-expired still actually serves expired entries if 
they're in the cache.  I was confused because I thought I had flushed 
the cache, that's all.

However, there seems to be a related-but-different bug:  I'm not seeing 
any prefetching.  After the flush, no upstream query appears until after 
the flushed entry's original TTL elapses.

Thanks,

		M.