caddyserver
Feature Request: DNS over TLS/HTTPS for 'resolvers'
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.
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.
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.
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.
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.
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.