[Dnsmasq-discuss] SERVFAIL and all-servers

Simon Kelley simon at thekelleys.org.uk
Wed Mar 2 19:24:34 UTC 2022


The behaviour on this alternated between what you observed and what you 
advocate a few times before settling.

The problem with waiting for all replies is that a common source of 
SERVFAIL returns is domains with broken DNSSEC. In that case all the 
servers will return SERVFAIL, which is a bit of a pain if you have to 
wait for the slowest one, but a disaster if one server is not 
responding: in that case all you can do is wait for the timeout.

Defining SERVFAIL as the response to DNSSEC validation failure has 
always seemed odd to me.

all-servers is not necessarily more reliable: the default dnsmasq 
behaviour does a reasonably good job in most circumstances.


Cheers,

Simon.

On 28/02/2022 22:38, Tobias via Dnsmasq-discuss wrote:
> Hi,
> 
> when using multiple upstream servers with "all-servers", and one
> upstream is sending SERVFAIL very fast (e.g. because the upstream has a
> dead upstream itself), dnsmasq uses this SERVFAIL as answer, probably
> because it's the fastest one. This breaks the intended redundancy, but
> is even worse, as other working upstreams are effectively not used
> anymore. (Tested with v2.85 and v2.86.)
> 
> I'm not sure if that behavior has a valid use case, but at least for my
> case it seems much better to only give a SERVFAIL if all upstream
> servers answer with SERVFAIL.
> 
> Together with the other "all-servers" issue I reported ("DNSSEC and
> all-servers"), the "all-servers" setup unfortunately is much less
> reliable than I was hoping.
> 
> Thanks!
> 
> Tobias
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> 



More information about the Dnsmasq-discuss mailing list