[Dnsmasq-discuss] TCP optimization regressions

[Simon Kelley]

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
>