Comment by secret-noun a day ago
> The key advantage of [DNS-PERSIST-01] is that the DNS TXT entry used to demonstrate control does not have to change every renewal.
> We expect DNS-PERSIST-01 to be available in 2026
Very exciting!
https://datatracker.ietf.org/doc/html/draft-sheurich-acme-dn...
It will help that side of the process (although, as a sibling has noted, you can CNAME your way into a better-controlled update service), but the challenge of automating cert changes for various non-HTTP services, including various virtual or physical boxes with funky admin interfaces, remains. I don't expect that vendors will do much about that, and it will end up on admins' plates, as usual. There will be much grumbling, but fewer solutions.
Why dont providers offer dns api keys restricted to txt records?
https://dns.he.net/ does. Each record can have its own secret. You can also use this for things like A records to do dynamic DNS.
desec.io allows you to create (through the api) tightly-scoped tokens that can only update the "_acme-challenge.subdomain.example.com" domain needed for DNS-01 challenges.
I switched to them from cloudflare dns for that specific functionality and it works great.
a perhaps non-obvious option is to CNAME (or NS) the `_acme_challenge` record from your main zone to another zone you can control better and can't affect production traffic the same way the main zone could. `acme-dns` is a neat little tool for exactly this, that has an https api for your ACME client to request a cert from, and a dns server to respond to dns-01 challenges from your provider.
Yeah, I have all my _acme_challenge as their own zone so that BIND can auto increment the serial number without going through the pain of locking/unlocking the entire domain and hoping you don't end up with stale data that stops syncing.
That said, I like that the current system proves that you have control of the domain at the time of renewal, and I'm not sure how setting a one-off token would achieve the same.
Yep, being able to “redirect” the “challenge record” is very handy in some cases. Did a writeup here with some examples of how it can be arranged: https://hsm.tunnel53.net/article/dns-for-acme-challenges/
This replaces an anonymous token with a LetsEncrypt account identifier in DNS. As long as accounts are not 1:1 to humans, that seems fine. But I hope they keep the other challenges.
I really would have felt better with a random token that was tied to the account, rather than the account number itself. The CA side can of course decide to implement it either way , but all examples are about the account ID.
I don't expect we'll ever remove the other validation methods, and certainly have no plans to do so.
There are pros and cons of various approaches.
Accounts are many to one email address. Each of my servers have an individual account attached to the same email address.
Thank god. The only remaining failure mode I’ve seen with LE certs recently is API key used to manipulate DNS records for the DNS-01 challenge via some provider (Cloudflare etc.) expiring or being disabled during improper user offboarding.
Big news for both the lazy homelab admin that can set a TXT once and ultimately be more secure without spraying DNS Zone Edit tokens all over their infra AND for the poor enterprise folks that have to open a ticket and wait 3 weeks for a DNS record.