On Mon, Aug 19, 2024 at 10:33 AM Simon Kelley <si...@thekelleys.org.uk> wrote: > > Are we talking about DNS-over-TCP or DNS-over-TLS (aka DoT)?
The eventual goal is DNS over TLS, but I can do the TLS part separately. > > 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. Yes, I assumed all the above was true and that was the original design. > 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. The only resource difference between TCP and UDP is that you require a buffer to collect all the TCP data until you have a full packet and a buffer for sending TCP data. Outside of that, there is no difference. And forking a new process to handle each connection actually makes things worse, you have to have those buffers and the overhead of an entire process. There are a few handling differences, you have to accept connections, handle connections dropping, and handle partial sends and receives. If it was designed to work inside the UDP framework instead of forking, I think you would find that the code would be much simpler. > > 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? Well, you win DNS-over-TLS. That's not a small thing. No DNS spoofing, no ISP watching what you are doing. And it's not as uncommon as you might think, pretty much all browsers now are using their own DNS-over-TLS or DNS-over-HTTPS for name services instead of local DNS services. I'm working on a secure system product at work where I am using dnsmaq with stunnel, in fact I just implemented that. It's working, but everything internal and external is DNS-over-TLS. I thought I would implement it at home in my gateway to simplify the big mess I have now with bind/isc/tftp. Then I discovered this issue. At work, if I had to take in a system behind the gateway that could only do DNS-over-UDP, I'd be stuck. So now I have to rethink this. > > Small note, caching from TCP connections is implemented in recent > versions dnsmasq releases; it turned out to be very necessary for DNSSEC. Yeah, I saw that code, but I haven't looked at how it works. I'm not terribly interested in DNSSEC, as it doesn't provide any secrecy, but I can see that caching would make a big difference. It would in general, anyway. Thanks for the response. -corey > > > Simon. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
