[Dnsmasq-discuss] REFUSED after dropped packets
simon at thekelleys.org.uk
Mon Sep 27 21:45:25 UTC 2021
On 21/09/2021 17:46, Johannes Stezenbach wrote:
> On Tue, Sep 21, 2021 at 09:38:41AM +0100, Simon Kelley wrote:
>> The culprit in --strict-order.
>> Comment from the code to save my re-typing:
>> /* In strict order mode, there must be a server later in the list
>> left to send to, otherwise without the forwardall mechanism,
>> code further on will cycle around the list forwever if they
>> all return REFUSED. If at the last, give up. */
>> That's not new in 2.86, but it's possible that the implementation has
>> changed subtly. There is a couple of obvious improvements to this, but
>> the work-around for you may be to remove --strict-order and configure
>> the vpn DNS servers explicitly for the VPN-only domains, which is a much
>> better way to work.
> I thought about it but I'm skeptical your suggestion would fix
> the problem (although it's a good idea not to forward unrelated
> queries to VPN).
> In my usual usage VPN is down (I'm only using it for short periods
> when needed), there is only one nameserver which is my DSL router.
> The point I do not understand (and did not find an answer to
> by trying to read dnsmasq source code): Why does dnsmasq assume
> the server is dead when one reply goes missing?
> (There is no error reply from my DSL router.)
> a) Dnsmasq should allow to forward the retry.
> b) If there are no "known good" servers, dnsmasq should forward
> retries indefinitely in hope the server comes back.
> What usage scenario would benefit from not retrying?
> FWIW, I'm not sure this behaviour actually changed in 2.86,
> but I had problems with my Wifi connection in the past but
> never saw "server not found" errors as a result.
I think that this is a 2.86 problem. There are two cases when dnsmasq
will try another server with the same query:
1) When a client retries the query.
2) When the first server returns REFUSED.
In the second case, it's important to give up when all available servers
have returned REFUSED, otherwise the query keeps bouncing forever. 2.86
got the two cases mixed up and implemented that behavior for client
retries too. That's a bug.
should fix it.
More information about the Dnsmasq-discuss