serve-expired seems to break flush_zone

[Marc Branchaud]

On 2018-04-09 03:40 AM, W.C.A. Wijngaards wrote:
> Hi Marc,

I can confirm that the patch fixes my test case (in 1.6.7).

The documentation update also looks good.

Thanks for the quick response!

		M.


> On 06/04/18 17:05, Marc Branchaud wrote:
>> 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."
> 
> Yes, I'll fix that!  It doesn't set the TTL to 0, but I'll phrase it
> like, it sets the item to TTL expired.
> 
>>
>>> 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.
> 
> Yes that is a bug!  Fixed it (patch included below).  Thanks for the report!
> 
> The bug was that it did not set the prefetch_ttl to expired.
> 
> Best regards, Wouter
> 
> Index: daemon/remote.c
> ===================================================================
> --- daemon/remote.c	(revision 4608)
> +++ daemon/remote.c	(working copy)
> @@ -1649,6 +1649,7 @@
>   		struct reply_info* d = (struct reply_info*)e->data;
>   		if(d->ttl > inf->expired) {
>   			d->ttl = inf->expired;
> +			d->prefetch_ttl = inf->expired;
>   			inf->num_msgs++;
>   		}
>   	}
> 
> 
>>
>> Thanks,
>>
>>          M.
> 
>