dns-persist-01: status and decision tree for TLS certificates

⚡TL;DR

• dns-persist-01 ties a lasting TXT record to a certificate authority and an ACME account. Since draft -02, the account appears in it as a hashed URI.
• 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 October 11, 2026, issue #64, which Let's Encrypt was waiting on, is resolved by draft -02, but no date has been announced. Google Trust Services is in production with the draft -01 format: publish the format documented by your CA.

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 October 11, 2026?

Status on October 11, 2026

TLS BR v2.3.0 permit persistent DNS validation under §3.2.2.4.22. The Datatracker lists draft-ietf-acme-dns-persist-02, published on September 20, 2026. It is a working document of the IETF ACME working group: its TXT syntax may still change.

The Let's Encrypt communications reviewed announce neither a rollout date nor support for draft -02. Google Trust Services has announced dns-persist-01 support since September 28, 2026, based on draft -01.

On June 25, 2026, Aaron Gable set a condition: "We will not be deploying dns-persist-01 until [...] is resolved." The omitted passage refers to issue #64, which called for client-computed information in the proof. This concern was about protocol security, not a simple packaging delay. The issue was closed on September 23, 2026 with this comment: "Resolved in PR #67 and published in draft-ietf-acme-dns-persist-02". The issue targeted by Aaron Gable's message has therefore been resolved on the IETF side. As of October 11, 2026, however, the Let's Encrypt communications reviewed announce no rollout date.

The Let's Encrypt Challenge Types page still does not list dns-persist-01 among active methods. Draft -01 was due to expire on September 25, 2026; draft -02 replaced it on September 20. The challenge keeps its name: -02 refers to the document version, not a new challenge. This version change is neither a launch date nor a cancellation of the BR provisions.

Google Trust Services (GTS) published a page dedicated to dns-persist-01 on September 28, 2026. It states: "Google Trust Services now supports the dns-persist-01 challenge type". The same page specifies the version it follows: "Defined in the IETF Internet-Draft draft-ietf-acme-dns-persist-01". Its example puts a plain-text account URL in accounturi, which matches the -01 format. The current draft requires a hashed URI, and the two formats are incompatible. A TXT record is therefore valid only for the CA and the format it documents.

SwissSign's sources have changed. The March 9, 2026 post announced a summer production rollout. The TLS CP/CPS version 3.0 dated August 24, 2026, still current as of October 11, 2026, 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=HASH_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.

Draft -02 changes the form of accounturi (§4.1). The parameter must be a hashed URI of the form <accountHashPrefix><hash-alg>/<base64url value>. The CA publishes the prefix in its ACME directory metadata. SHA-256 is mandatory for both clients and CAs. The hash covers four elements: the domain length, the domain where the TXT record is published (without _validation-persist), the SHA-256 thumbprint (RFC 7638) of the ACME account's public key in JSON format (JWK) and the account URL. After a key rollover, the CA must accept a hash computed with the current key or with an earlier key it has retained.

The hash provides two protections. First, the channel that gives you the account URL may be compromised and substitute another account's URL. The resulting TXT record is then unusable, because the hash also depends on the legitimate account's key. Second, the same account produces a different value for each domain. A DNS observer can therefore no longer link an account's domains just by reading TXT records. The hash does not hide the account from the CA: the CA recomputes the value and thereby finds the account URL (§7.2.3). The client can also replace the domain with *. The same value then appears in every TXT record, and those domains become linkable again.

The draft -01 form, a plain-text account URL with no cryptographic binding, "is no longer accepted" according to the -02 change log. It therefore no longer complies with the current draft. Yet it is the form Google Trust Services documents as of October 11, 2026.

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. The ACME draft remains a working document: record the draft version and the TXT format associated with any evaluation.

The account deserves as much attention as DNS. Hashed or in plain text, accounturi always designates a specific account. When a provider leaves your organization, keeping its account's TXT record 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. As of October 11, 2026, Let's Encrypt does not list dns-persist-01 among its active challenges, including for wildcards. Google Trust Services documents policy=wildcard to cover the domain, its subdomains and the wildcard; this finding applies only to that CA. 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 still shows version -03 as of October 11, 2026. 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 October 11, 2026?

The available evidence ranges from a published release to an open feature request. The matrix below describes this documentary status, checked on October 11, 2026; it does not rank authorities capable of issuance. It distinguishes draft -01 (plain-text account URL) from draft -02 (hashed URI).

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 notes for v5.5.0, v5.5.1 and v5.5.2 do not mention draft -02	Release v5.0.0, including change #2991, and lego releases	10/11/2026	Evidence for the -01 format in lego ≥ v5.0.0; no evidence of -02 support. Check the format expected by the CA. No LE availability inferred.
acme.sh	Release 3.1.4 announces dns-persist-01; mode documented; 3.1.5 and 3.1.6 do not mention draft -02, and 3.1.6 states "No functional change since 3.1.5"	Release 3.1.4, DNS persist mode wiki and acme.sh releases	10/11/2026	A documented supporting version, without claiming to establish the first compatible version; no evidence of -02 support. Wiki examples do not prove current LE availability.
Certbot	PR #10633 closed on August 3, 2026, unmerged; request #10549 open; PRs #10794 (marked as draft), #10799 and #10800 (plugin and documentation) open, unmerged	PR #10633, issue #10549, PR #10794, PR #10799 and PR #10800	10/11/2026	None of these PRs has shipped in a release. The targeted draft is not established here. No usable workflow inferred.
cert-manager	Request #8373 open	Issue #8373	10/11/2026	A request demonstrates neither a released implementation nor compatibility with a CA.
win-acme	Request #2849 open	Issue #2849	10/11/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 for draft -01: attributing the challenge's arrival to a later version would be misleading. For Certbot, the closed state of PR #10633 does not mean it was merged; the GitHub API confirms merged: false. The PRs open in October 2026 remain work in progress as long as they are neither merged nor released. These differences affect operational decisions.

Keep version references in your evaluation records, along with the draft followed by each component. 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. Finally, note the draft and TXT format the CA documents: plain-text account URL (-01) or hashed URI (-02).

If the answer is no or uncertain, keep a supported method. For Let's Encrypt, the decision is still to wait: no date has been announced as of October 11, 2026. 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 draft accepted by the CA, -01 or -02. A client that produces the -01 format does not suit a CA that requires the hashed URI, and vice versa. 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. Also plan to republish the TXT record if your CA moves from the -01 format to the hashed format.

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 October 11, 2026?

Not on that date. IETF issue #64, whose resolution Let's Encrypt was waiting for in June, has been closed since September 23, 2026: draft -02 resolves it. Yet the communications reviewed announce no rollout date, and the active challenge documentation does not offer it.

Does a TXT record in the draft -01 format still work?

At Google Trust Services, yes: it is the format that CA documents as of October 11, 2026. However, it no longer complies with draft -02, which requires a hashed account URI. Publish the format documented by your CA and plan to republish the TXT record if it adopts the hashed format.

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. Google Trust Services documents this option with policy=wildcard. Let's Encrypt does not offer it as of October 11, 2026.

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.