[Dnsmasq-discuss] Forwarding UDP requests to TCP, some other concerns

[Simon Kelley]

On 19/08/2024 05:25, Corey Minyard wrote:
> I've been running with a setup with bind and the ISC DHCP server.  It
> works, but there's one feature it cannot do that dnsmasq can, and I've
> been looking to simplify my configuration from all that complexity,
> anyway.
> 
> I have dnsmasq mostly working, but I'm having one big problem.  It seems
> that requests received from UDP are only forwarded to UDP, they cannot
> be forwarded to TCP.  I'm running DNS over TLS on the server, so I have
> to be able to do TCP, but requests come in from clients on UDP and TCP.
> What can I do about this?
> 
> I also have a few suggestions/comments:
> 
> It would be really nice if filter-AAAA could take a domain name and only
> filter the given domains.  That way, for instance, if I had something
> like:
>      filter-AAAA=/test.net/
> then test.net would only return A records.  I work around this by
> forwarding the given domains to another running dnsmasq with filter-AAAA
> set, but having that built-in would be really nice.
> 
> Having DNS over TLS built-in would be nice.  stunnel works, but it's
> just one more thing to manage.
> 
> DNS over TCP is going to be a bigger thing as time goes by, and its
> support in dnsmasq seems incomplete in other ways, like caching.  Is
> this planned to be fixed in the future?
> 
> Thanks,
> 

Are we talking about DNS-over-TCP or DNS-over-TLS (aka DoT)?

The reason that a UDP query is never forwarded over TCP is party 
historical: The amount of state required for an in-flight UDP request is 
tiny: basically just enough to map the reply from upstream back to the 
original requestor. It's a fixed size entry in a small table. This means 
you can do UDP-to-UDP forwarding in a single process that doesn't have 
to manage any resources on the fast path. A quarter of a century ago, 
when dnsmasq was concieved and router with 2MB of flash and 1MB of RAM 
were a thing, that mattered. Basically all DNS was over UDP anyway. The 
TCP slow path is much more heavyweight, to the extent that each incoming 
TCP connection forks its own process, and that process can potentially 
open a connection to each of the upstream servers. Since TCP connections 
were very rare (and still pretty much are) that works fine. It would be 
simple to handle UDP queries over the slow path to turn them into TCP 
queries upstream, but pointless: you wouldn't gain anything and it would 
be slower and use more resources.

To do DNS-over-TLS you'd need to divert UDP queries to the slow path as 
above, and make it even slower by replacing TCP connection establishment 
with TLS connection establishment. It's doable, but what do you win?

Small note, caching from TCP connections is implemented in recent 
versions dnsmasq releases; it turned out to be very necessary for DNSSEC.


Simon.



> -corey
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>