[Dnsmasq-discuss] [PATCH] Make use-stale-cache configurable

[Simon Kelley]

On 24/11/2022 19:22, Dominik Derigs wrote:
> Hey Simon,
> 
> We observed a few cache oddities with the current release-
> candidate of dnsmasq and have been able to pin this down to the
> use of the new use-stale-cache option. The issue happens with
> cached content being served when the actual domain data has moved
> on. This is, of course, unavoidable with this option, however, it
> made me wanting a way to configure "serve stale data but only if
> it is not too old". This is added by this patch adding an
> optional argument:
> 
> --use-stale-cache[=<max TTL excess in s>]
> 
> In fact RFC 8767 "Serving Stale Data to Improve DNS Resiliency"
> even states that
> 
>> The maximum stale timer should be configurable
> 
> The RFC suggests a "value is between 1 and 3 days" and later
> states that "Shorter values, even less than a day, can
> effectively handle the vast majority of outages." Hence, my patch
> also changes the current (so far, unreleased) behavior from
> serving expired content forever to a default value of one day.
> This is freely configurable (I will set it down to one hour on
> our systems) and can even be made serving forever, just as before
> by explicitly setting the optional value to 0.
> 
> Best,
> Dominik
> 

Thanks for that. What problems were you seeing? I'd hoped that the 
strategy of continuing the query even after answering with stale data 
would avoid problems: as long as the upstream server is up and 
reachable, only one (or a very few) answers should be old data.


I think this is a sensible enhancement. I very nearly put in a 
hard-coded limit when I first did this, so I like the default too.

Patch applied unaltered.


Cheers,

Simon.

> 
> Internal tracking is happening here:
> https://github.com/pi-hole/dnsmasq/pull/11