[Dnsmasq-discuss] EDNS passthrough

[Simon Kelley]

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.