On 28/01/2025 19:28, Philip Rowlands wrote:
Hello, Not a bug report so much as a query; why does dnsmasq not eagerly attempt to use EDNS when talking to upstream resolvers? Quoting https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg10449.html : EDNS (in this context) is a way for the two ends of a DNS transaction to negotiate the maximum size of reply that can be sent over UDP. Quoting RFC6891: EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is negotiated between each pair of hosts in a DNS resolution process, for instance, the stub resolver communicating with the recursive resolver or the recursive resolver communicating with an authoritative server. I was mildly surprised to find that dnsmasq will happily "pass through" EDNS, but won't try to use it otherwise if not flagged in the initial query.
This was greatly cleaned up in the current code, so the behaviour may now be different to released versions. Nevertheless, the fundamental truth is that dnsmasq passes the reply from the recursive resolver as a UDP packet bit-for-bit back to the stub resolver. If the stub resolver doesn't include EDNS, it can't accept replies bigger than 512 bytes, so it's wrong for dnsmasq to add an EDNS inviting the recursor to reply with a larger reply. Indeed if dnsmasq adds and EDNS header for other reasons (eg adding a DO bit for DNSSEC or sending the client subnet) it will set the EDP packet size in that header to 512 bytes if the downstream didn't sent EDNS, or a smaller size then 1232 if the downstream sent that.
There is an argument to do this differently. With an answer larger than 512 then wthout EDNS, the recursor replies with a truncated reply, which goes back the stub resolver which moves to TCP.
With EDNS, dnsmasq would get a good reply, cache it, then return a truncated reply, Now when the stub resolver moves to TCP, the answer has already been cached by dnsmasq and a second round trip to the recursor is avoided.
TL;DR dnsmasq is trying to match up the maximum packet size betweenthe downstream and the upstream. When I think about it, there's another way ofdoing this which is probably better, but might have problems I've overlooked.
Cheers, Simon. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
