[Dnsmasq-discuss] [PATCH] Retry queries only after giving the upstream server some time to respond

Simon Kelley simon at thekelleys.org.uk
Mon Apr 5 20:38:14 UTC 2021


On 05/04/2021 21:30, Dominik Derigs wrote:
> To be even more precise:
> 
> On Mon, 2021-04-05 at 22:16 +0200, Dominik Derigs wrote:
>> This is the issue I'm concerned about. Some clients send the same
>> query
>> multiple times (they don't seem to have a local cache).
> 
> These clients don't even intend them as retries. Wireshark confirms
> they send them as individual queries (they have different IDs). Later
> retries (which really rarely happen) have the same ID - as they should.
> 
> So maybe the fix could be distinguishing retries from the same source
> as identified by the same ID and new queries for the same type/domain
> (different ID).

Except that this all started because some clients don't retry from the
same ID/source port and treating them as a new query that can be
answered when the existing query for the same name completes fails
because that means dnsmasq never sees retries from this type of client,
and it relies on those retries to work in the face of packet loss.

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014697.html


> 
> In the latter case, we may be safe to skip forwarding again because
> this is not meant as a retry from the client? My understanding is that
> we can use the same argument for other clients requesting the same
> type/domain at the same time. As long as no client sends a "real" retry
> (same ID), we should be safe waiting on the first forwarded to appear.
> So like 2.83/2.84 behavior but with a possibility for the clients to
> actually trigger re-forwarding.
> 

What's a "real" retry. I'm not sure there's an RFC that says it has to
be from the same source port and query-ID, and we have counterexamples
above where it isn't.


Simon.

> Best,
> Dominik
> 
> 




More information about the Dnsmasq-discuss mailing list