> The problem with dns-01 is that it much of the time, it requires granting far too much privilege to the system that requests the certificate. This is because the great majority of DNS hosts do not provide sufficiently granular permissions to only allow changes to _acme-challenge RRs.
There's a cool solution to this that I learned from someone else on the Let's Encrypt forums (where I often help do support). The Let's Encrypt DNS-01 validator will follow CNAMEs. Therefore, you can make _acme-challenge be a CNAME to an arbitrary text record which can be in another zone (including a zone dedicated for this purpose). For example, you could say
_acme-challenge.example.com. IN CNAME foo.acmevalidation.example.net.
Now an application can just have API keys to update RRs under acmevalidation.example.net, which does not need to be used for any other purpose (or even necessarily hosted on the same infrastructure as example.com's own DNS). The CNAME can be created manually at the outset and does not need to be updated for renewals.
This has been possible for a long time, but if it becomes more widely known and more widely supported by client applications and DNS providers, it should make use of DNS-01 authentication much more practical, and safer, for a pretty wide range of people.
Another similar option would presumably be to delegate _acme-challenge.example.com to different nameservers with an NS record, then give your application the required privileges to control solely that nameserver.
Yes. Or even to the same name server, breaking out each whole label starting with _acme-challenge as its own independent zone, with its own access policies.
Yes, but there’s no need to have separate zones; you can grant update access to subdomains and have the CNAMES point into one zone with a subdomain dedicated to each separate actor which needs access.
Like so: Assume that Actor 1 has example.com and example.net. You then add this to the example.com and example.net zones, respectively:
Then you give update access to Actor 1, but not to the whole “your-special-domain.com” zone, but to the “_.actor1._.your-special-domain.com” subdomain. The ACME system would then be configured to send updates to the correct subdomains of that subdomain. Or “your-special-domain.com” could even be a subdomain itself of another domain; it doesn’t matter.
The ISC BIND DNS server allows cryptographic authentication for updates with ACLs that let you get as granular as only being able to add/delete TXT records within this branch of zone X.
In the alternative, you can place static CNAME records in your real DNS zone that would refer out the _acme_validation queries to another zone entirely. Run that zone with entirely different credentials.
You are exactly correct. It's honestly pathetic that we've let cloud DNS providers (not to mention most alternative resolvers) get away with providing such inadequate interfaces compared to BIND. It's not actually difficult to admin, it's incredibly capable, and it fucking accepts AXFR/IXFR. It's insane to me that anyone puts up with such standards-hostile software.
This is because the great majority of DNS hosts do not provide sufficiently granular permissions to only allow changes to _acme-challenge RRs.
e.g. Cloudflare, as far as I can tell, only gives you one API key which grants all access to all zones.
e.g. Most domain registrars who offer DNS hosting who provide an API grant access to all sorts of management functions, not just DNS zone changes.
e.g. Route53 IAM doesn't let you restrict to a single RR, you expose modifications to the entire zone.
I am really not comfortable giving my web application these kinds of powers.
TLS-SNI was useful because it was relatively protocol agnostic, so some of that flexibility is now gone.