If you were to implement this in dnsmasq, by far the best way would be
to put proxy in front of dnsmasq.
The existing dnsmasq concurrency model just doesn't support the
implementation. If relies on most queries happening over UDP, and the
context for such queries being very minimal. Anything that happens over
TCP (like TLS or HTTPs) is the opposite extreme, with a new dnsmasq
process being spawned for each request. That's not scalable when you're
going to run everything upstream over TCP.
Given that the preferred architecture is a proxy in front of dnsmasq,
the next question is, do we have to implement that, or does it already
exist? A quick Google reveals several potential candidates and the one
that I've most heard people are using is dnscrypt-proxy.
I have no personal experience with dnscrypt-proxy or any of the other
options, but before thinking about writing another one, I'd like to be
sure that none of the existing options are suitable, and that I couldn't
persuade someone else to do the work rather than making it part of the
dnsmasq effort.
Simon.
On 27/02/2023 18:06, Curzon Dax via Dnsmasq-discuss wrote:
Greetings,
I checked through the last 1-2 years of the mailing list, and I hadn't
seen anything regarding DoT/DoH. If this has come up before and I missed
it, apologies in advance.
Thought I'd add a feature request for DNS over TLS or DNS over HTTPS
when dnsmasq is used as a DNS forwarder.
BIND is about to implement this in the next version, and I believe
Windows DNS is the last to the party among the other major DNS
recursors/forwarders.
I realize that this could add considerable size, scope, and complexity
to something which is inherently light weight and used on a lot of
embedded devices with very minimal storage. Perhaps something optional
at build time to avoid bundling large libraries/dependencies. embed-TLS
could be something to look at to ensure this feature could be built on
very-low-storage, embedded devices.
I know that many embedded devices (modems/routers) have some form of an
SSL library already, as many offer admin control over https://.
If there is interest by the developers/maintainers, perhaps we could
make a call for financial support from the major recursive providers
(Google, Quad9, Cloudflare, etc). I know a few of the DNS folks at these
organizations, and while I'm not making any promises or claims, it's
something I'd be happy to reach out to them about.
Thanks in advance.
-Curzon
_______________________________________________
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
