[Dnsmasq-discuss] SERVFAIL and all-servers

[Simon Kelley]

On 06/03/2022 15:16, Matus UHLAR - fantomas via Dnsmasq-discuss wrote:
> On 02.03.22 19:24, Simon Kelley wrote:
>> 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.
> 
> I would expect a bit more reliability in this case just as the OP.
> 
> How does dnsmasq reply if all-servers is not set and first server 
> returns SERVFAIL?

If it sends to a single server, and that returns SERVFAIL, it will retry 
the query to all servers (as if all-servers was set.) This doesn't avoid 
the problem that the same "rogue" server could reply SERVFAIL again.

I guess there's an argument to omit the already-failed server on the retry?


Simon.
> 
> Could retrying with another server with timeout shorter than standard 
> could increase reliability?
> 
>> On 28/02/2022 22:38, Tobias via Dnsmasq-discuss wrote:
>>> 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.
>