[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