Feature Request: DNS over TLS/HTTPS for 'resolvers'

[kelke]

This was discussed a while ago on the forums: DNS over TLS/HTTPS for 'resolvers':

For the built-in ACME server DNS queries carry special relevance, as their response decides on who gets a valid certificate.
These DNS queries are currently unencrypted, and can quite easily be modified in a local network using ARP-Spoofing etc., which could enable an attacker to actually obtain valid certificates for arbitrary domains. While I haven't tested this personally, I don't see why it would not work.

One solution is to use an external resolver like systemd-resolved and put 127.0.0.53 as the resolver in acme-server, but not every system and environment allows for this.

@francislavoie suggested that ncruces/go-dns would be good inspiration.
The syntax could either be something like
resolvers tcp://1.1.1.1:53 tls://1.1.1.1:853 https://cloudflare-dns.com/dns-query
as detavern suggested in the forum thread, or a nested approach:

... resolvers [<resolver_address>] {
	protocols <dot/doh...>
	upstreams <resolver_address>

This syntax would also allow defining bootstrap DNS servers, which are required for using domains as DNS servers, like https://cloudflare-dns.com/dns-query (more examples).
IPs can, however, also be used for DoT and as far as I understand wont need bootstrapping. If the specific issue of bootstrapping turns out to be more complicated I would still be happy if encrypted DNS would be possible using IPs.

The acme server is obviously not the only place where this could be useful, but I believe it is the most important one, as unencrypted DNS could pose some security implications as already explained.

[mohammed90]

Can you elaborate on this?

but not every system and environment allows for this.

In a critical infra as you describe, the DNS resolvers in your infra should be trusted or operated in a way they can be trusted.

[kelke]

To have secure DNS, the encrypted query has to be sent either by caddy itself or by the system resolver.
systemd-resolved is a system resolver that is capable of DoT, but such a resolver might not always be available.
In containerized environments for example, one might just have access to a caddy docker container, but not be able to change the system resolver. Some embedded systems might also be supported by caddy, but an external DoT/DoH capable resolver might be difficult to find.
If caddy itself could send encrypted DNS queries, you would not have to rely on the underlying system to support it.

[mohammed90]

Honestly, this makes me more inclined to make the resolver a module rather than pulling more deps and add more code to support cases where someone doesn't the resolver in their own infra. Today it's DoH/DoT, tomorrow it's DoQUIC.

[kelke]

Maybe I misunderstood your point, but I am indeed talking about DNS queries to a DNS server in the same infra. My point is that a DNS query should get encrypted before leaving the host caddy is running on.
Just in the same way HTTPS should be used instead of HTTP, even for resources in a LAN.

By system resolver I mean the service running on a host that sends queries out into a local network. Queries from caddy to localhost are obviously harder to intercept/modify than queries sent over the network to any dns server, as these are prone to ARP spoofing etc.

[kelke]

And with native support on all major desktop operating systems, I don't see an end to DoT and DoH anytime soon. Especially since TLS and HTTPS are so ubiquitous.