After having to deal with VM hosts that do GeoIP blocking, which unintentionally blocks Let's Encrypt and others from properly verifying domains via http-01/tls-alpn-01, I settled on a DIY solution that uses CNAME redirects and a custom, minimal DNS server for handling the redirected dns-01 challenges. It's essentially a greatly simplified version of the acme-dns project tailored to my project's needs (and written in node.js instead of Go).
Unfortunately with dns-persist-01 including account information in the DNS record itself, that's a bit of a show stopper for me. If/when account information changes, that means DNS records need changing and getting clients to update their DNS records (for any reason) has long been a pain.
Key rotation doesn't change the account URI โ ACME key rollover (RFC 8555 ยง7.3.5) replaces the key pair but keeps the same account URL, which is one of the reasons the draft uses account URI rather than a public key. Your DNS record stays unchanged through key rotations.
The only case that requires a DNS update is creating an entirely new account, and that's deliberate โ the record binds a specific account to the domain so a stolen record can't be used by someone else.
For your setup with CNAME delegation to a custom DNS server, this should actually be simpler than dns-01. You would point _validation-persist instead of _acme-challenge, and the target record is static. No per-issuance dynamic updates at all.
Unfortunately with dns-persist-01 including account information in the DNS record itself, that's a bit of a show stopper for me. If/when account information changes, that means DNS records need changing and getting clients to update their DNS records (for any reason) has long been a pain.