The record you published in the spring is spec-noncompliant now
If you've been running dns-persist-01 in staging since the draft landed, go look at the TXT record you published. As of today it's the old format. The working group merged a change that replaces the plaintext accounturi with a hashed value, and the record you copied out of a blog post in March no longer matches what the specification says a compliant record looks like.
This isn't cosmetic. The whole reason dns-persist-01 wasn't in production yet was a security hole in exactly this part of the record. The fix changes the record format, changes what your automation has to compute, and quietly makes your ACME account key a thing you now have to think about at DNS time. If you read DNS-Persist-01 Is Almost Here. Here's What It Actually Changes. when it went up, this is the other shoe dropping.
What the old record looked like
The draft-ietf-acme-dns-persist-01 text, published 24 March 2026, borrowed the issue-value syntax from RFC 8659, the same grammar CAA records use. You published a TXT record at _validation-persist under your domain, and inside it you named the CA and pasted your account URI verbatim:
_validation-persist.example.com. IN TXT "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
The CA validated it with a plain string comparison. Simple String Comparison per RFC 3986, section 6.2.1, if you want the exact reference. Your account URI is in the record, the CA checks the account making the request has that URI, done.
That is the part that broke.
The attack this closes
Picture an attacker who stands up their own ACME server at letsencyrpt.org. One transposed character. They talk a victim into pointing their client at it, which is not as far-fetched as it sounds for anyone copy-pasting a CA endpoint out of a tutorial.
When the victim registers, the malicious server hands back the attacker's real Let's Encrypt account URI in the challenge instructions. The victim's client, believing it's authorizing its own account, publishes a dns-persist-01 record containing the attacker's account URI. Now the attacker walks over to the real Let's Encrypt with their own legitimate account and asks for a certificate for the victim's domain. The standing record names their account. It validates.
The reason this works is that the old record contained nothing the attacker didn't already control. An account URI is a public string. It's in the challenge response, it's not a secret, and pasting it into DNS doesn't prove the person publishing the record has anything to do with that account. Contrast that with dns-01 or http-01, where the token is generated by the CA, tied to a specific order, and useless to any other account. Persistent validation had thrown that binding away.
What the merged record looks like
Pull request #67, titled "Replace the three accounturi modes with a single hashed account URI," was merged into the working group draft on 20 September 2026. It throws out the three ways the old text let you express an account URI and replaces all of them with one hashed form:
<accountHashPrefix>/<hash-alg>/<base64url-digest>
The CA advertises accountHashPrefix in its directory metadata, so your client learns it the same way it learns every other endpoint. The hash-alg token comes from the RFC 6920 named-hash registry, with SHA-256 mandatory, so there's room to move off SHA-256 later without another format change.
The digest is the interesting part. It's computed over four things chained together: the length of the domain, the domain name itself, your account key, and your account URL. The "key" here is the 43-octet unpadded base64url RFC 7638 JWK thumbprint of your ACME account key. That's the change that matters. The record no longer contains a public string anybody can copy. It contains a value only someone holding your account private key can produce.
Why your account key is suddenly load-bearing
Here's the thing the old format let you get away with: your DNS record and your account key had nothing to do with each other. You could rotate the key, and the standing record didn't care. You could publish the record without ever touching the key.
That's over. The digest folds in your JWK thumbprint, so the record is now a function of the exact key your account uses. Rotate the account key and the thumbprint changes, the digest changes, and the record you published no longer authorizes the new key. You have to recompute it and republish. If you can't say off the top of your head where your ACME account key even lives, that's now a production problem, and Your ACME Account Key Just Became Production-Critical. Where's Yours? is the one to read next.
The winner post predicted this, more or less, back when the fix was still theoretical: the cost of binding the key is that you reintroduce a DNS write on account-key rotation. That prediction held. The good news is that account-key rotation is genuinely rare. Most people never do it deliberately, and the ones who do can count the events per year on one hand. So you've traded a DNS write on every renewal, which was the whole problem, for a DNS write on the odd occasion you rotate a key. That's a good trade.
The draft spells out the CA side of it too. A CA has to keep the association between accounts and their keys, has to accept hashed URIs computed from both current and prior keys within whatever retention window it sets, and must never honor a hashed URI computed from the keys of a deactivated account, regardless of retention. That last rule is the kill switch: deactivate the account and every standing record built on it dies, retention or not.
The privacy angle nobody asked for
Binding the digest to the domain has a side effect the authors leaned into. Because the domain name is part of the hash input, the same account produces a different digest for every domain it validates. Your record for example.com and your record for example.net look unrelated, even though they're the same account. Under the old plaintext format, anyone scraping DNS could see the identical account URI across all your domains and stitch your certificate footprint together in an afternoon.
If you actually want one record you can reuse across domains, you set the domain component to * and opt out of the per-domain binding. You get the convenience back and give up the unlinkability. That's your call to make, not the CA's.
Don't oversell the privacy win to yourself, though. The draft is honest that this is best-effort obfuscation. A digest is not encryption. Anyone with a candidate list of account URLs and your domain can grind through hashes offline until one matches, and account URLs are sequential integers on most CAs. So it raises the cost of bulk correlation without making targeted correlation impossible. For the multi-perspective validation side of the picture, Your CA Now Validates You From Four Networks. One Blocked Region Fails Issuance. covers the mechanism that actually defends the DNS lookup itself.
What this breaks in your tooling
Everything that already implemented the old format now implements the wrong one. lego shipped dns-persist support in v5 on 11 May 2026, and it was built against the plaintext record. That code computes a record no updated CA will accept, so expect a follow-up release. cert-manager still has an open issue, #8373, with no pull request and nobody assigned, so there's nothing there to be wrong yet. certbot has nothing. acme.sh and win-acme have tracking issues and no shipped code.
If you built anything in-house against the March draft, the same warning applies with more force, because there's no maintainer to catch it for you. Your record-generation code needs to compute a SHA-256 over the domain length, the domain, your JWK thumbprint and your account URL, then base64url-encode it and stitch it behind the CA's accountHashPrefix. If you hardcoded the old accounturi= string anywhere, delete it.
What to actually do before production lands
Nothing you published in staging is worth keeping. Treat the March-format records as throwaway and plan to regenerate all of them once your CA ships the merged format and publishes an accountHashPrefix.
Find your account URL and your account key now, because you need both to compute the digest, and make sure whatever automation owns renewal can reach the key material to recompute the record on rotation. If you were counting on publishing one persistent record and never touching DNS again, adjust the mental model: it's one record per domain until rotation, not one record forever. Wire the rotation path in before you flip production, not after your first key rotation silently breaks issuance three months from now.
And keep dns-01 in your back pocket. Persistent validation is additive. The old challenge isn't going anywhere, and until the clients you depend on ship the merged format, dns-01 is the thing that actually issues your certificates. If you want a refresher on how the per-renewal version works under the hood, DNS vs HTTP Domain Validation: What Actually Happens Behind the Scenes walks the whole exchange.
The primary sources are all public: the merged change is pull request #67 on the draft repository, the CA/Browser Forum ballot is SC-088v3, and Let's Encrypt's original announcement, DNS-PERSIST-01: A New Model for DNS-Based Challenge Validation, is still the best plain-language overview. The Hacker News thread on that announcement is where a lot of the account-correlation worry got aired months before the fix landed.
Frequently asked questions
Do I have to change my dns-persist-01 record right now? Only if you were running it against a CA in staging, and only once that CA ships the merged format. The change is in the working-group draft as of 20 September 2026, but no production CA has cut over yet. Your existing dns-01 automation is untouched either way.
Why does the record now depend on my ACME account key? Because the digest is computed over your account key's JWK thumbprint, which is something only the holder of the account private key can produce. That's what stops an attacker from binding a record to an account they don't control. The side cost is that rotating your account key means recomputing and republishing the record.
Does the hashed format hide which account owns a domain? It makes it harder, not impossible. The same account produces a different digest per domain, so casual scraping won't link your domains together. But a determined attacker with a list of candidate account URLs can brute-force the hash offline, since account URLs tend to be predictable sequential integers.
What happens to standing records if I deactivate my ACME account? They stop working immediately. The draft requires a CA to reject any hashed URI computed from the keys of a deactivated account, no matter what its retention window says. Deactivation is the clean way to revoke every persistent authorization tied to an account at once.
Can I still use one record across several domains?
Yes, by setting the domain component of the digest to *, which opts out of the per-domain binding. You get a reusable record and give up the correlation resistance that the per-domain binding buys you. It's a deliberate trade-off the spec leaves to you.
