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@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
