CertKit
Abstract
With the ACME protocol, to issue a certificate you have to prove you control the domain. The CA gives you a challenge, you complete it, and they issue your cert.
The trouble is that every validation method has tradeoffs. And as certificate lifetimes get shorter, those tradeoffs will get more painful. DNS-PERSIST-01 is a new approach coming in 2026 that trades proof-of-freshness for easier operations.
ACME validation methods
HTTP-01 is the easiest to understand. The CA gives you a token, you host it in a file at http://example.com/.well-known/acme-challenge/, and the CA fetches it. Proof of control. Done.
But HTTP-01 means opening port 80 to the public internet, and that can be scary. Not everyone wants their certificate validation infrastructure exposed to the world.
DNS-01 lets you hide your internal systems. Instead of serving a file, you create a DNS TXT record at _acme-challenge.example.com. The CA queries DNS, finds your token, and you’re validated. No open ports.
The problem is that changing DNS records can be unreliable at best and risky at worst. DNS is famously problematic due to its slow refresh and caching cycles. Nine times out of ten with any major outage, it comes down to DNS.
For your systems to create DNS validation records, they need API credentials, often with broad permissions. For better or worse, DNS has become a skeleton key can unlock everything and cause lots of trouble if compromised. I really don’t want every system in my infrastructure to have my DNS keys.
What is DNS-PERSIST-01?
DNS-PERSIST-01 is a new ACME challenge type that eliminates the DNS-01 “change DNS on every renewal” problems. Instead of creating a fresh TXT record for each validation, you create one persistent record that authorizes a specific CA and account indefinitely.
_validation-persist.example.com. IN TXT
"letsencrypt.org; accounturi=https://letsencrypt.org/acme/acct/123456; policy=wildcard"
That’s it. You’re telling Let’s Encrypt (or whatever CA you specify) that ACME account 123456 is authorized to get any certificate it needs for example.com. Forever, or at least until the optional persistUntil timestamp expires.
The honest tradeoff
DNS-PERSIST-01 is a different approach to validation than the other methods. It trades real-time validation for operational efficiency.
Aaron Gable, an engineer at Let’s Encrypt, described the tradeoff on the CAB Forum mailing list:
The [DNS-PERSIST-01] security model is sound and has real advantages; but the ergonomics and optics are bad.
While the spec still requires a “random value” in the traditional sense (your account URI is effectively that value), Gable admits that because it doesn’t change this feels like theater:
The fact that it still involves a Random Token even though checking for the presence of that random token achieves nothing feels like pulling the wool over one’s eyes.
This is refreshingly honest for a standards discussion. The people building DNS-PERSIST-01 aren’t pretending it’s a strict improvement. It’s a tradeoff. You get massive operational simplification. You lose proof-of-freshness.
The security model does work. Your ACME account is cryptographically bound to a keypair. If someone compromises that keypair, they can issue certificates for any domain where you’ve set up persistent validation. But that was already true with DNS-01 if they got your DNS credentials. The attack surface is just different, not necessarily larger.
When is DNS-PERSIST-01 coming?
The regulatory path for DNS-PERSIST-01 is already clear. CA/Browser Forum ballot SC-088v3 passed in October 2025 with unanimous support from 26 Certificate Authorities. Chrome, Mozilla, and Cisco all voted yes. The IETF ACME working group formally adopted the draft in October 2025.
Let’s Encrypt committed to implementing DNS-PERSIST-01 in 2026. No specific quarter or month yet, just “2026” with “more to announce soon.” Let’s Encrypt explicitly sees this as an enabler for shorter certificate lifetimes.
When certificate lifetimes drop to 47 days (coming in 2029), you’ll be revalidating constantly. Manual DNS changes won’t cut it. Half-baked automation will break. DNS-PERSIST-01 is designed to make that future survivable.
How CertKit will use DNS-PERSIST-01
Right now, CertKit proxies DNS-01 validation so you don’t have to hand over your DNS credentials. DNS validation will follow CNAMEs, so we can host and update the TXT records for you. That already solves the “skeleton key” problem. But you still need to authorize each certificate request through our system.
With DNS-PERSIST-01, you authorize CertKit once per domain. You can point _validation-persist.example.com to a record we control, and we handle the TXT record on your behalf. We handle every renewal automatically. No per-certificate approval, just create certificates when you need them.
CertKit will support it shortly after Let’s Encrypt does.
CertKit automates certificate lifecycle management so you don’t have to.
Comments