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
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
