[Dnsmasq-discuss] Option to skip 0x20 encoding

[Geert Stappers]

On Wed, Feb 05, 2025 at 09:08:46PM -0600, Peter Tirsek wrote:
> On Mon, 3 Feb 2025, Simon Kelley wrote:
> 
> > I did wonder if this might happen.
> > Can you share with us what the misbehaving server is?
> 
> On Mon, 3 Feb 2025, wornandrew via Dnsmasq-discuss wrote:
> 
> > I don't have much info about the server.
> > It's on an enterprise intranet. No doubt something ancient.
> 
> I just upgraded,
 
Which version of dnsmasq?

Same question as yes-no-question:  Is it with dnsmasq 2.91rc1?


> saw that warning in the log after about half an hour, and started
> digging into it a little further. I tried isolating it to a certain
> upstream server, but all of them seemed to exhibit it, and my primary
> one definitely isn't ancient (BIND 9.20.5).
> 
> After some additional investigating, I discovered that it happens when
> dnsmasq is presented with more than one query for the same record in rapid
> succession. I didn't look through the source yet, but the problem can be
> reproduced by restarting dnsmasq, then issuing two queries for the same
> record in rapid succession, such as with:
> 
> $ for i in 1 2; do dig www.google.com A @10.0.0.1 & done
> 
> (10.0.0.1 is my router running dnsmasq, of course).
> 
> 
> Here's a sample tcpdump of the WAN side of the router running dnsmasq, when
> configured to use 8.8.8.8 as the upstream server, and presented with two
> such rapid queries:
> 
> 16:25:45.957031 IP xxx.xxx.xxx.xxx.41668 > 8.8.8.8.53: 10400+ [1au] A? WwW.GooGLE.CoM. (55)
> 16:25:45.957267 IP xxx.xxx.xxx.xxx.53410 > 8.8.8.8.53: 56858+ [1au] A? www.GooglE.cOM. (55)
> 16:25:46.008817 IP 8.8.8.8.53 > xxx.xxx.xxx.xxx.41668: 10400 1/0/1 A 142.250.190.68 (59)
> 16:25:46.022715 IP 8.8.8.8.53 > xxx.xxx.xxx.xxx.53410: 56858 1/0/1 A 142.250.190.68 (59)
> 
> It does not appear to make any difference whether the first or second query
> is answered first. Perhaps dnsmasq only stores the one random
> capitalization, and when the "wrong" response comes in, this is seen as a
> problem and the warning is emitted.
> 
> 
> If that's the case, a few potential ways of solving this could be:
> 
> 1) Never issue another query to the upstream server while a previous
>    query is still in flight, and when the answer comes in, respond to
>    both downstream queries
> 
> 2) Keep track of randomization per outgoing request ID instead of only
>    per name and record type
> 
> 3) Reuse the same randomization pattern for subsequent upstream
>    requests while another is still in flight.
> 
> 
> Finally, this may not be the same problem that wornandrew experienced.
> I don't have an overall problem running this version of dnsmasq.

Acknowledge on "don't have a problem".

Regarding the "potential ways of solving this":   Why?

Long version of "Why?":
Please elaborate on why there should be put effort in a code change.
Express which potential benefits you see.


> It didn't even seem to ignore the answer that triggered the warning
> in the log. At least the client received a reply to both questions,
> so maybe dnsmasq answered from the cache after ignoring the second
> answer, and what I'm seeing is purely a cosmetic problem?
> 
> Either way, I thought I'd add my 2 cents worth before this ends up in
> a lot of people's logs and causing a lot of confusion.

Appriciated.  Yes, much respect to care what people encounter.


Another compliment: Thanks for awareness "time is precious".
You make it possible that people can read in the discussion order.
The gain in time, the time saving factor, is that you make it possible
to skip, to not open at all, some emails. Such skipping is what I do to
keep up with mailinglist traffic.
 

> Peter Tirsek


Regards
Geert Stappers



P.S.

For those new to mailinglists:
Abandon the idea that others have read all previous emails.
-- 
Silence is hard to parse