DNS over TLS/HTTPS for 'resolvers'

[kelke]

I just recently played around with the acme_server directive and really enjoy it so far.
One problem i encountered, however, was that i would like to use DNS over TLS or DNS over HTTPS for ACME challenges.

I realize most people don’t pay much attention to encrypted DNS, but when setting up a private ACME infrastructure i feel like using unencrypted DNS feels a bit of an oversight.
In an infected private network an attacker could pretty easily spoof a DNS response, which should enable arbitrary certificate generation of the ACME-server’s CA right?

Since basically the whole concept of ACME challenges is proving ownership of domains I personally would feel much better knowing DNS connections are encrypted.

Obviously using a domain, such as https://cloudflare-dns.com/dns-query (docs) for a DNS-server you would simply add a new problem of bootstrap DNS servers, but tls://1.1.1.1:853 (docs) or https://1.1.1.1/dns-query should work without one

The resolvers directive is used not only in acme_server, but in tls and probably many others as well, so I don’t know how big this implementation would be. But even though it’s pretty niche, I would enjoy this feature. (Even though completely different, Adguard Home solves it quite elegantly syntax, providers)

I haven’t personally tested whether spoofing DNS responses works with caddy, but I don’t currently see why it shouldn’t.

What do you guys think? Is this worth a Github-Issue?

Example config that might possibly generate a spoofable unencrypted DNS:

{
	pki {
		ca home {
			name "My Home CA"
			resolvers 192.168.1.1
		}
	}
}

acme.example.com {
	acme_server {
		ca home
	}
}

[francislavoie]

I think probably easiest is just to run a DNS forwarder program alongside Caddy (something like CoreDNS or https://github.com/mikispag/dns-over-tls-forwarder) that would then do the actual DoT or DoH. That way Caddy can stay simple from that standpoint.

A Github issue for this would probably be most appropriate to track the feature request. From a quick google, seems like GitHub - ncruces/go-dns: net.Resolvers with caching, opportunistic encryption, and DoT/DoH would be a good inspiration (if not an ideal dependency) to implement this.

[Detavern]

Meet same problem but from another aspect here.

One of our server is behind a strict firewall device that will hijack all udp based dns lookups. Any TXT lookup will get a NXDOMAIN response.

Currently we use a internal DNS forwarder inside container network to pass the caddy dns challenge. But a built-in DNS over TCP, DoT, DoH support for the resolvers directive would be a help.

Example config:

tls admin@example.com {
	resolvers tcp://1.1.1.1:53 tls://1.1.1.1:853 https://cloudflare-dns.com/dns-query
}