serve-expired seems to break flush_zone

[W.C.A. Wijngaards]

Hi Marc,

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.


-------------- 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/20180409/f2952772/attachment.bin>