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 > > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
