dns-persist-01: status and decision tree for TLS certificates
By CaptainDNS
Published on September 16, 2026
- dns-persist-01 ties a lasting TXT record to a certificate authority and an ACME account. Availability depends on both sides of the protocol.
- You leave the TXT record in place. The authority can rely on a lookup for only 10 days: after that, it reads the same TXT record again before issuing a certificate.
- As of September 16, 2026, the Let's Encrypt rollout remains frozen. Check your authority first, then your client, before considering an evaluation.
A TXT record that stays published can reduce the DNS writes needed for domain validation. That is the appeal of dns-persist-01 for teams that need to renew their TLS certificates more often. It does not eliminate fresh checks by the certificate authority (CA) or installation of the renewed certificate.
The topic spans several distinct things: a method permitted by the Baseline Requirements (BR), a proposed ACME challenge and software at different stages of integration. To decide, start with your actual issuance chain. A ready client does not make its server compatible.
Where does dns-persist-01 stand on September 16, 2026?
Status on September 16, 2026
TLS BR v2.3.0 permit persistent DNS validation under §3.2.2.4.22. The Datatracker still lists
draft-ietf-acme-dns-persist-01, a working document whose TXT syntax may change.Let's Encrypt is keeping its rollout frozen pending resolution of IETF ACME issue #64, which is still open. Its documentation describes HTTP-01, DNS-01 and TLS-ALPN-01 as usable methods. Neither a production date nor current staging operation is confirmed here.
The blocker is explicit. On June 25, 2026, Aaron Gable wrote: "We will not be deploying dns-persist-01 until [...] is resolved." The omitted passage refers to issue #64, which calls for client-computed information in the proof. This concern is about protocol security, not a simple packaging delay. Aaron Gable's message remains the reference for this freeze.
The Let's Encrypt Challenge Types page does not list dns-persist-01 among active methods. It also retains a historical notice about the retired TLS-SNI-01. The September 25, 2026 expiration of draft -01 concerns that version of the IETF document. It is neither a launch date nor a cancellation of the BR provisions.
SwissSign's sources have changed. The March 9, 2026 post announced a summer production rollout. The current TLS CP/CPS, version 3.0 dated August 24, 2026, now describes method 22 for Managed PKI only. Its revision history dates this addition to August 17. This documents CA practice within that scope; it does not prove that every ACME client can negotiate dns-persist-01 with that service.
What this article does not cover
This assessment helps you decide whether an evaluation makes sense for your TLS estate. It does not replace the full 47-day certificate timeline or the guide to automating TLS certificate renewal. Those topics also cover certificate scheduling, deployment and monitoring.
It is not a CAA or DNSSEC guide either: their roles are distinguished below, with dedicated resources. Finally, it is not a dns-persist-01 deployment procedure. Publishing a TXT record is not enough to make a CA accept the challenge or to handle every renewal.
What does the persistent TXT record validate, and for how long?
The TXT record expresses domain validation authorization tied to an issuer and an account. How long it remains present differs from the lifetime of the evidence obtained by the CA.
_validation-persist.[ADN]: DNS name, issuer and authorized account
The method appears in BR §3.2.2.4.22, DNS TXT Record with Persistent Value. ADN stands for Authorization Domain Name, the domain name used to obtain authorization for the requested name. It does not always mean the root domain. For a service under app.captaindns.com, do not assume the CA will necessarily look up a TXT record under captaindns.com.
The queried name takes the form _validation-persist.[ADN]. Its value uses the issue-value syntax from RFC 8659, section 4.2: issuer-domain-name; accounturi=ACCOUNT_URI. This notation describes the fields; it is not a value to publish. issuer-domain-name identifies the issuer according to its CP/CPS, and accounturi identifies the account authorized with that issuer. A CA name resembling its brand is no substitute for the identifier it declares.
The optional persistUntil parameter adds an expiration time expressed in Unix seconds. After that time, the record can no longer be used for a new validation. Without this parameter, the TXT record has no expiration defined by this syntax. Since the ACME protocol is still under discussion, retain the specification version associated with any evaluation.
The account deserves as much attention as DNS. When a provider leaves your organization, keeping its URI in the zone means retaining an authorization you may no longer want. Plan for its removal, cache delays and handling of evidence already obtained. Deleting the TXT record does not revoke certificates already issued.
A lasting TXT record, CA evidence reusable for at most 10 days
The validation data reuse limit is at most 10 days for this method, from the moment it is used. It does not wait until 2029. When a CA can no longer reuse its evidence, it must revalidate the domain before relying on this method again for issuance.
Four time spans coexist: the presence of the TXT record, its possible persistUntil deadline, the freshness of CA evidence and the certificate's validity. A TXT record published for a year can support several successive checks. That never gives the first piece of evidence a year of reuse. Conversely, the ten-day limit does not require the holder to replace the TXT record every ten days.
That is the intended operational change: the CA can reread a stable record while the client continues requesting and deploying certificates. You reduce validation-related zone changes without eliminating renewal work.
DV, OV, EV and wildcard: what is the scope?
For DV, OV and EV TLS certificates, this method validates the name. It does not verify the company's identity or replace any organizational checks required for OV or EV. Whether a certificate type is accepted remains a CA decision, subject to the rules of the relevant profile.
The BR permit the persistent method for validating wildcard names without lifting certificate profile restrictions. In the ACME draft, policy=wildcard is optional, in the normative sense of MAY. The Let's Encrypt technical post describes this scope extension; it does not represent an available service. At the status date used here, dns-persist-01 is not usable at Let's Encrypt, including for wildcards. The SwissSign CP/CPS consulted here reserves wildcard validation for other methods.
For IP addresses, §3.2.2.5.8 provides for _ip-validation-persist under the corresponding reverse zone name; this BR provision does not establish ACME availability.
S/MIME remains a gray area in the documents compared here: its mention in the SwissSign post is not enough to conclude that the challenge is supported. Code signing and VMCs are outside the scope.
DNS-01, dns-account-01 and CAA: three essential distinctions
These mechanisms address different needs, even when they use DNS or an ACME account identifier.
DNS-01 uses _acme-challenge, not the persistent TXT record
DNS-01 requires a challenge-specific value under _acme-challenge. The record contributes to a one-time proof; it is not the persistent authorization described here. Its operation is defined in RFC 8555, section 8.4.
With dns-persist-01, the queried name and expected content change. Leaving an old DNS-01 token in the zone does not turn it into a persistent TXT record. A CNAME delegation of _acme-challenge does not perform this conversion either. For an already automated estate, DNS-01 remains useful as long as the client/CA pair supports it.
dns-account-01 belongs to a different BR method
dns-account-01 separates validation names by ACME account. This makes it easier for multiple clients or providers to coexist without sharing exactly the same challenge name. The value remains tied to a validation, unlike the lasting authorization provided by dns-persist-01.
The BR reference it under §3.2.2.4.21, with a procedure tied to draft 00. The dns-account-label Datatracker page shows version -03 on the assessment date. A normative reference in the BR, IETF progress and CA support are three separate pieces of information. Simply calling it a draft would obscure the first.
accounturi in CAA has a different role
CAA expresses an issuance policy: it determines which authorities may issue and can restrict that permission to an account. The accounturi extension is defined in RFC 8657. Sharing a name with the persistent TXT parameter does not make it the same proof.
A compatible CAA policy does not establish domain control on its own. Conversely, a valid persistent TXT record does not exempt the CA from checking CAA. The role of CAA records therefore complements the chosen validation method.
Why do 47-day certificates change the situation?
More frequent renewals make repeated DNS interventions more costly, especially when each change requires human approval.
In 2029, 47-day certificates and 10-day DCV reuse
From March 15, 2029, the planned maximum validity for public TLS certificates will be 47 days, with ten days of domain validation data reuse. The 47-day TLS certificate timeline details the intermediate steps. This general timeline does not postpone the ten-day limit already attached to the persistent method.
The benefit depends on your constraints. A team whose DNS requires manual changes can avoid recurring interventions if its CA accepts a lasting authorization. A team for which DNS-01 already works with restricted permissions will weigh things differently. In both cases, the certificate still has to reach the correct service before it expires.
CNAME delegation and acme-dns: what the BR recommend
BR §3.2.2.4.7 specifically address the case where a CA, or an affiliated entity, operates a zone receiving validation CNAME delegations. This service resembles the acme-dns model. The text says SHOULD NOT operate such a service and SHOULD direct users to §3.2.2.4.22. This addition comes from ballot SC-088v3.
These are strong normative recommendations, not an absolute ban on all CNAME delegation. They address the CA or its affiliate operating the service. They are not an instruction to delete your acme-dns instance immediately, much less to migrate to a challenge unavailable at Let's Encrypt. Ask which method your authority accepts before changing a working setup.
ACME clients: what evidence of support exists on September 16, 2026?
The available evidence ranges from a published release to an open feature request. The matrix below describes this documentary status, checked on September 16, 2026; it does not rank authorities capable of issuance.
| Client | Version or change status | Exact primary source | Assessment date | CA-side scope and limitations |
|---|---|---|---|---|
| lego | Implementation present as of v5.0.0, adapted to draft -01 | Release v5.0.0, including change #2991 | 09/16/2026 | Evidence for lego ≥ v5.0.0; check the selected version's compatibility with the CA. No LE availability inferred. |
| acme.sh | Release 3.1.4 announces dns-persist-01; mode documented | Release 3.1.4 and DNS persist mode wiki | 09/16/2026 | A documented supporting version, without claiming to establish the first compatible version. Wiki examples do not prove current LE availability. |
| Certbot | PR #10633 closed on August 3, 2026, unmerged; request #10549 open | PR #10633 and issue #10549 | 09/16/2026 | The manual plugin change is not shipped by this PR. No usable workflow inferred from its former milestone. |
| cert-manager | Request #8373 open | Issue #8373 | 09/16/2026 | A request demonstrates neither a released implementation nor compatibility with a CA. |
| win-acme | Request #2849 open | Issue #2849 | 09/16/2026 | The quarter mentioned in the issue title is not a delivery date. CA acceptance must be checked separately. |
For lego, v5.0.0 already provides published evidence: attributing the challenge's arrival to a later version would be misleading. For Certbot, a closed PR does not mean it was merged; the GitHub API confirms merged: false. These differences affect operational decisions.
Keep version references in your evaluation records. A package supplied by a distribution or embedded in another product may differ from the latest upstream release. Then check the method actually offered by the CA for the authorization concerned. An option in the client does not replace this check.
DNSSEC and MPIC: why validation can fail even when the TXT record is present
A TXT answer readable from your workstation proves neither its DNSSEC validity nor its visibility from the CA's perspectives.
SC-085 also applies to persistent DNS validation
SC-085 requires DNSSEC validation of DCV queries by the CA's primary perspective. The persistent method is no exception. BR v2.3.0 consolidate these requirements under §4.2.2.2. An invalid signed chain can therefore block validation even when the TXT text is correct.
This does not make DNSSEC signing mandatory for every domain. An unsigned zone and a zone with a broken chain of trust are different cases. Changing DNS providers while an old DS remains published can cause the latter. Our article on DNSSEC validation for TLS certificates and SC-085 explains this diagnosis.
Geographically varying DNS answers can cause MPIC to fail
MPIC, Multi-Perspective Issuance Corroboration, compares observations from several network perspectives. For the persistent method, corroborating perspectives must observe valid evidence containing the same accounturi as the primary perspective. The mechanism follows BR quorum rules, not a simple local DNS lookup.
Geographically varying DNS can fail if some perspectives receive a different account or find no usable evidence. This does not rule out all GeoDNS: A answers that differ by region can coexist with a consistent validation TXT record. The question concerns the answer used for validation and the required perspectives, not the DNS service's marketing label.
Decision tree: wait, evaluate or keep the current method?
Start with the authority, then examine the client and your ability to manage the authorization. Each answer must be based on dated evidence.
Does your authority accept the method for the intended certificate?
Look for a declared practice in the CP/CPS and service documentation matching your contract. A mention of Managed PKI does not mean access for all accounts or all profiles. Also check wildcard support if you depend on it.
If the answer is no or uncertain, keep a supported method. For Let's Encrypt at the status described here, the decision is to wait. An old announcement or a staging screenshot is not enough to plan a production switchover.
Does your client have a released, compatible implementation?
Compare the installed version with the matrix, then with the specification accepted by the CA. An unmerged PR or an open request leaves this step without evidence of delivery. Depending on your context, wait or prepare a non-production evaluation using the components actually available.
Document the expected outcome: challenge negotiation, validation, issuance, then renewal. Obtaining a first certificate does not by itself demonstrate that renewal will work after the CA's evidence expires.
Are your DNS and authorization management ready?
Identify who controls the TXT record, who owns the authorized account and who can remove that authorization. Check DNSSEC and the name's visibility from several networks. Include a provider's departure or an account replacement among the situations to handle.
If all conditions are documented, a controlled evaluation with the relevant CA becomes reasonable. Keep renewal monitoring and a proven recovery method. The expected benefit is fewer DNS writes; you can measure it without assuming all future intervention will disappear.
Check the TXT record and DNSSEC without assuming CA acceptance
A TXT lookup helps you observe the actual _validation-persist name concerned. A DNSSEC check examines the domain's chain of trust. These two checks inform DNS diagnosis; they do not negotiate the challenge with your authority or guarantee certificate issuance.
DNS watch can complement this work with free monitoring of DNS changes across methods. An alert helps identify a removal or modification; it does not certify ACME compatibility. The final evidence remains the documented behavior of the client/CA pair for the requested certificate.
FAQ
Does dns-persist-01 replace DNS-01 and dns-account-01?
No. It offers lasting DNS authorization tied to an account and an issuer. DNS-01 and dns-account-01 use other proofs and remain separate choices depending on support.
Does Let's Encrypt support dns-persist-01 on September 16, 2026?
The rollout remains frozen pending IETF issue #64. The active challenge documentation does not offer it. Neither production nor staging availability is established here.
Why revalidate the domain if the TXT record stays published?
The authority can rely on a DNS lookup for at most 10 days. After that, it reads the same TXT record again before issuing a certificate; you do not have to replace it.
Does dns-persist-01 cover DV, OV, EV and wildcard certificates?
Persistent validation concerns the name for DV, OV and EV, without replacing organizational checks. The BR permit wildcard validation using this method, subject to profile rules and CA acceptance. Let's Encrypt does not offer it at the status assessed here.
Is a compatible ACME client enough to use dns-persist-01?
No. The CA must accept the method for your account and certificate. A client release proves an implementation, not the availability of the remote service.
Does a TXT record visible in a lookup guarantee successful DNSSEC and MPIC validation?
No. The result depends on the resolver and observation point. The CA must still validate DNSSEC and obtain the required corroboration from its network perspectives.
