Dominik,

Thanks for the report.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3a052d55fbfca49d8d435cdd2110fb2667594c61

Should fix this.

Cheers,

Simon.

On 04.03.2026 18:14, Dominik Derigs wrote:

Hey Simon,

during our automated CI testing, we discovered two regressions of the recent TCP buffer use optimization: https://thekelleys.org.uk/gitweb/? p=dnsmasq.git;a=commit;h=729c16a8ace49d472bc29cc37f87ca39ade920b6

The first one may be reproduced easily in the following way:

1. Start dnsmasq like:

dnsmasq -d --log-queries=proto --server=127.0.0.1#5000 --no-resolv

Note that the configured server does intentionally NOT exist.

2. Initiate a zone transfer to produce a non-query (an exemplary python script doing this is attached)

3. See the following log lines:

dnsmasq: TCP 1 127.0.0.1/41420 non-query opcode 5 from 127.0.0.1
dnsmasq: TCP 1 127.0.0.1/41420 config error is REFUSED (EDE: network error)

We see an exception in the python script:

>>> dns.query.BadResponse: A DNS query response does not respond to the question asked.

The reason is that the reply ID is 0 instead of being the same as the request ID. You may also check recording.pcap handy to see the effect.

I also found another, related issue when running the same script this time with an existing upstream server. We get the following log lines:

dnsmasq: TCP 1 127.0.0.1/36338 non-query opcode 5 from 127.0.0.1
dnsmasq: TCP 1 127.0.0.1/36338 forwarded example.com to 127.0.0.1#5555
dnsmasq: TCP 1 127.0.0.1/36338 reply error is not implemented

We get again the python exception. This time, we observe that the ID is correct, however, while query has opcode 5 (update), the reply has opcode 0 (query), which obviously doesn't match. Looking into recording2.pcap, we see that it is actually the upstream server which is changing the opcode and dnsmasq just passing this along. Previous versions of dnsmasq (pre-v2.93test2 to be precise) did not bother forwarding such non-queries at all and replied with the same opcode . I think this behavior should be restored.

Best,
Dominik

_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss