Abstract
In February, Let’s Encrypt announced that DNS-PERSIST-01 was coming, “some time in Q2 2026.”
It’s October, and it’s nowhere close to ready.
We’ve been waiting for DNS-PERSIST-01 since January, along with every other ACME client and lots of organizations. DNS-PERSIST-01 promised to simplify domain validation and make automation easier, but we had to wait on Let’s Encrypt. Let’s Encrypt is waiting on a redesign, a standards body, and maybe one more vote. Even then, there is some ambiguity about what will actually ship.
Here’s what happened, where it stands today, and why it probably won’t be ready until mid-2027.
How to prove you control a domain for certificates
Before a Certificate Authority will sign a certificate for example.com, you have to prove you control example.com. The ACME protocol that Let’s Encrypt and most other CAs use calls this a challenge.
A popular challenge for automation, and the only one that works for wildcards, is DNS-01. Your ACME client asks for a certificate, and the CA responds with a challenge token. Your client combines that token with a fingerprint of its own account key in a hash and publishes it as a TXT record. The CA looks up the record, and if the value matches, you’ve proven control.
_acme-challenge.example.com. IN TXT "gfj9Xq3ARbgZdTd9_XzJeRc3uJ2bZ8Rg85nMLwj6J8M"
The annoying part of DNS-01 is that you have to do it for every SAN on every certificate. Delegating the challenge with a CNAME keeps DNS credentials off your servers, but you still need a record for every name. And as certificate lifetimes shrink to 47 days and the window for reusing a validation shrinks to 10 days, you’ll be doing it constantly.
What DNS-PERSIST-01 was supposed to be
Amazon found a shortcut years ago. Since 2017, AWS Certificate Manager has asked you to create a CNAME record for each name, pointing into a DNS zone Amazon controls. As long as that record exists, Amazon can re-validate your domain whenever it needs to, and you never touch DNS again. Google Cloud does the same thing. For years the catch was that it only worked for certificates used in their cloud.
DNS-PERSIST-01 was the plan to standardize that shortcut for everyone. Instead of validating every certificate, you publish one TXT record that names your CA and your ACME account.
_validation-persist.example.com. IN TXT "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456; policy=wildcard"
That record says Let’s Encrypt account 123456 may get certificates for example.com. Add policy=wildcard and it covers every subdomain at any depth, plus wildcard certificates. www.example.com, mail.internal.example.com, and *.example.com all validate with the same record.
That’s why everyone got excited. No DNS credentials on your servers. No waiting for DNS to propagate. Nothing to change when lifetimes shrink again. For CertKit, it meant customers could authorize us once per domain instead of once per SAN.
Blocked until lifetimes shrank
Getting persistence into the rules started with a fight in the CA/Browser Forum, the group of CAs and browsers that writes the Baseline Requirements every public CA has to follow. That’s the same group that brought the 47-day certificate ultimatum.
In November 2024, before the lifetime reduction, Michael Slaughter of Amazon Trust Services proposed Ballot SC-082. It would have written Amazon’s CNAME trick into the rules as an approved form of DNS validation. The CAs voted for it, but Apple voted no, and Google and Mozilla abstained.
Clint Wilson, who runs Apple’s root program, explained their objection on the voting thread:
Instead of a certificate representing the authorization of a key, it represents the authorization of a business relationship. The risks associated with that shift are strongly — but not solely — tied to (shorter) certificate lifetimes and validation data reuse periods.
Apple wanted shorter certificate lifetimes before persistent validation. Clint wrote that passing SC-082 “would further emphasize the need for SC-081.” SC-081 was Apple’s ballot that cut certificate lifetimes to 47 days and the validation reuse window to 10 days. In 2024, a CA could reuse a domain validation for up to 398 days. A permanent DNS authorization on top of that meant nobody had to re-check anything for a very long time.
When Apple succeeded in pushing for shorter lifetimes in April 2025, persistence came back as its own method in Ballot SC-088. It passed in October 2025 with no votes against.
The ballot also discouraged Amazon’s CNAME approach.
A CA or Affiliate of a CA SHOULD NOT operate such a service, and SHOULD direct any Applicants using such a service to use the method described in Section 3.2.2.4.22 instead.
“Such a service” is a CNAME zone run by the CA, which is exactly what Amazon does. SHOULD NOT discourages it, but it’s still allowed. Amazon and Google still do it.
The DNS-PERSIST missing key
The work moved to the IETF, which controls the ACME protocol. The ACME working group adopted the draft standard in October 2025. Let’s Encrypt started building it into Boulder, its CA software, and published the plan.
Staging rollout is planned for late Q1 2026, with a production rollout targeted for some time in Q2 2026.
But in April 2026, Max Hearnden, an independent reviewer, posted to the ACME mailing list.
I’m somewhat concerned about the lack of binding between an account’s key, the challenge and the certificate request.
The original DNS-PERSIST record held your CA account URL, in plain text, and your ACME client got that URL from the server. If a compromised ACME proxy or a corporate TLS inspection box between your ACME client and the CA passed on an attacker’s account URL instead of the real one, your client would publish it to DNS.
From then on, the attacker could get certificates for your domain, straight from your CA, for as long as that record stayed in DNS. Nobody would notice, because the record names the right CA. DNS-01 never had this problem, because your client mixes its own key into the value it publishes, so that value only works for your account.
It’s a narrow attack, but it’s a step backward from what ACME already guarantees, and the people writing the standards don’t like moving backwards. They have poor balance. It needed to be fixed, and the obvious way to do that was to put your account key in the record, the way DNS-01 does.
The argument over how played out in issue #64, the longest thread in the project. In June, Aaron Gable of Let’s Encrypt made it the blocker.
We will not be deploying dns-persist-01 until [issue #64] is resolved.
Let’s Encrypt’s Q2 deadline came and went.
The revised DNS-PERSIST
The fix landed on September 20 in a revised draft, built on a design from Henry Birge-Lee, a security researcher and one of the draft’s three authors. The record no longer carries your account URL in the clear. It carries a hash.
_validation-persist.example.com. IN TXT "ca.example; accounturi=https://ca.example/account-hash/sha-256/{HASH_VALUE}; policy=wildcard"
Your client computes that hash from the domain, the key fingerprint, and its account URL. A tampered account URL now produces a record that doesn’t work. The attacker can’t attach your key to their account either, because that takes your private key. It’s the same protection DNS-01 has always had, back in the record.
This fixes a privacy problem too. With a plain account URL, anyone could look up your TXT records and see which domains share an ACME account. You could enumerate all the domains controlled by a common account. The hash makes that much harder.
The fix also introduced complexity. Because the hash includes your account key, the revised draft makes CAs remember every key an account has ever used, and people are still arguing over whether they should.
The pending wildcard question
The revised standard keeps policy=wildcard, so on paper one record covers a whole domain. Whether Let’s Encrypt will honor that is a different question.
When Let’s Encrypt added DNS-PERSIST to Boulder, it left subdomain validation out on purpose. Its version uses policy=wildcard to allow *.example.com, but a record at example.com won’t validate www.example.com or bar.foo.example.com on their own. The pull request explains why.
The draft has no mechanism for the subscriber to indicate which Authorization Domain Name (ADN) they want to validate at, so the server would have to walk up the domain tree. We’ve proposed that clients include an ADN field in their challenge POST payload to solve this. We’ll wait to see if the draft adopts some form of ADN negotiation before implementing this functionality.
When you ask for mail.internal.example.com, where does the authorization live? At internal.example.com or at example.com? Let’s Encrypt wants your client to say where the record lives. The revised draft doesn’t specify that, and the CA/B Forum rules don’t mention policy at all.
The lack of clarity on this is in issue #676. Without it, DNS-PERSIST needs a record for every SAN, and that’s not really any better than DNS-01 with a delegated CNAME. For CertKit, and for most of the people we’ve heard from, the wildcard is the reason to want DNS-PERSIST in the first place.
Commercial CAs implemented it anyway
While the protocol stalled, the commercial CAs went ahead. The method had been in the Baseline Requirements since November 2025, and nothing says a CA has to wait for the IETF. Tim Hollebeek of DigiCert put it bluntly.
IETF does not have any jurisdiction over the WebPKI.
DigiCert and Sectigo both shipped it in their portals this year. Amazon added ACME to AWS Certificate Manager, still built on its original CNAME method. You validate a domain once in AWS, with subdomains and wildcards if you want them, and every ACME order after that comes back pre-approved. No challenge at all.
They could all ship persistent validation because they have a customer portal. Let’s Encrypt doesn’t have a portal to validate with. It all has to be in ACME. Persistence has to live inside the protocol, which means it has to be right for everyone, in public, before it ships. That’s what we’re waiting for.
Where it stands
- Nov 2024: SC-082 (Amazon’s CNAME method) fails. Apple votes no.
- Apr 2025: SC-081 (47-day certs) passes, pushed by Apple.
- Oct 2025: SC-088 passes. The IETF adopts the DNS-PERSIST draft.
- Feb 2026: Let’s Encrypt targets production in Q2.
- Apr 2026: The account substitution attack is reported.
- Jun 2026: Let’s Encrypt blocks DNS-PERSIST until it’s fixed.
- Sep 2026: The revised DNS-PERSIST closes the hole and breaks every earlier record.
Three things still have to happen:
- The revised draft needs review. It’s two weeks old, and people are already objecting to parts of it.
- The CA/Browser Forum may need one more ballot, because the rules say the record holds a URI “identifying the account,” and the Forum hasn’t formally said whether a hash counts. The draft’s authors say it does. Slaughter says he’s drafting a ballot to clean up the related open issues.
- Let’s Encrypt has to build it into Boulder and release it.
Let’s Encrypt might not need a finished RFC to ship. It ran ACME Renewal Information in production for years before that became a standard. But Boulder’s last DNS-PERSIST change was back in April, and there’s no sign of the revised design in the repository today. The engineers who would build it have spent the summer on Merkle Tree Certificates instead.
So it’s going to be a while yet. Our guess is mid-2027.
What to do until then
If a DNS record for every name is the problem, you don’t have to wait for Let’s Encrypt.
CertKit’s delegated DNS validation works with every ACME CA today. You add one CNAME per name pointing to CertKit, and we handle every DNS-01 challenge after that. No DNS credentials on your servers.
Amazon’s CA is now one of CertKit’s integrated issuers too. Set up an ACME endpoint in AWS Certificate Manager and validate your domains there once, including subdomains and wildcards. Then add the endpoint’s EAB credentials to CertKit. CertKit becomes your ACME client and issues, deploys, and renews your certificates everywhere you need them, not just inside AWS. You never touch DNS again.
You still have to buy the certificates from Amazon, and AWS bills you directly. Amazon charges $1 per name per renewal, about $12 a year per name. Wildcards are $5, and both get cheaper at volume. CertKit doesn’t add anything to that.
When Let’s Encrypt ships DNS-PERSIST, we’ll support it too.
CertKit automates certificate lifecycle management, so you’re not waiting on the standards bodies.