DNS-PERSIST-01 Explained : Persistent Authorization for ACME SSL Certificate Validation
Samantha ClarkShare
The Automatic Certificate Management Environment (ACME) protocol has long defined three challenge types for proving you control a domain when requesting an SSL Certificate. A new fourth method, DNS-PERSIST-01, is making its way through the standards process and promises to change how Domain Name System (DNS) based validation works at scale.
Where existing DNS-01 validation requires a fresh challenge every single time a new SSL Certificate is requested, DNS-PERSIST-01 replaces that pattern with a persistent authorization record that can be reused across many issuances and reissues.
The result is a model that removes Domain Name System (DNS) updates from the critical path of SSL Certificate issuance. For large deployments where SSL Certificates are reissued frequently, this represents a substantial operational change. For deployments where Domain Name System (DNS) Application Programming Interface (API) credentials are considered sensitive infrastructure, DNS-PERSIST-01 also changes which assets need to be most tightly protected.
This article explains what DNS-PERSIST-01 is, how it differs from the existing DNS-01 challenge type, the format of the persistent authorization record, the security tradeoffs involved, and where the specification currently sits in the standards process. Explore the protocol fundamentals in our article on The ACME Protocol 🔗
The Operational Cost of DNS-01 Validation
To understand why DNS-PERSIST-01 matters, it helps to look at what the existing DNS-01 challenge type requires. With DNS-01, the Certificate Authority (CA) generates a one-time token and your ACME client publishes a TXT record containing that token at _acme-challenge.<your-domain>. The Certificate Authority (CA) then queries Domain Name System (DNS) to confirm the value matches what it issued.
Each new SSL Certificate request produces a new token, which means new Domain Name System (DNS) updates every time.
In practice this has several operational consequences. Domain Name System (DNS) Application Programming Interface (API) credentials must live somewhere in the issuance pipeline so the ACME client can write records when needed.
Validation attempts often involve waiting for Domain Name System (DNS) propagation across recursive resolvers. In large deployments, Domain Name System (DNS) changes happen frequently, sometimes many times per day. Discover how clients handle these challenges in our article on ACME Client Configuration Options 🔗
The benefit of this model is that every successful validation provides fresh proof of current control. The cost is that this fresh proof comes with the operational overhead of repeated Domain Name System (DNS) writes and the security exposure of distributing credentials across automation systems. Many operators accept this tradeoff, but others would prefer to keep Domain Name System (DNS) updates and sensitive credentials out of the issuance path entirely.
DNS-PERSIST-01 and the Persistent Authorization Model
DNS-PERSIST-01 takes a fundamentally different approach to validation. Instead of publishing a new challenge record for each issuance, you publish a standing authorization record that names both the Certificate Authority (CA) you trust to issue SSL Certificates for the domain and the specific ACME account you authorize to make those requests.
Once that record exists, it can be reused for the initial issuance and for all subsequent reissues without further Domain Name System (DNS) changes.
The persistent record sits at a different Domain Name System (DNS) label from the one used by DNS-01. Where DNS-01 uses _acme-challenge.<your-domain>, DNS-PERSIST-01 uses _validation-persist.<your-domain>. The two labels exist independently and serve different validation flows.
The conceptual shift here is significant. DNS-01 demonstrates current control at every issuance. DNS-PERSIST-01 demonstrates control once and then relies on the persistence of the authorization record as ongoing evidence.
The CA/Browser Forum ballot describing this method specifies that the record's continued presence in Domain Name System (DNS) constitutes ongoing authorization, with the assumption that anyone who can publish or remove a TXT record on the domain has demonstrable control over that domain.
The DNS Record Format for Persistent Validation
The persistent authorization record is a Domain Name System (DNS) TXT record at the _validation-persist subdomain of the domain being authorized. The record contains two required fields : the issuer-domain-name of the Certificate Authority (CA) you authorize, and the ACME account Uniform Resource Identifier (URI) of the account permitted to request SSL Certificates against that authorization.
A minimal record authorizing a specific Certificate Authority (CA) and ACME account for the domain example.com looks as follows.
_validation-persist.example.com. IN TXT ( "ca.example.com;" " accounturi=https://acme.example.com/acme/acct/1234567890" )
The first string identifies the Certificate Authority (CA) by its issuer-domain-name, terminated with a semicolon. The second string carries the ACME account Uniform Resource Identifier (URI) preceded by the accounturi= parameter. Both fields are mandatory in a valid record. Discover how Domain Name System (DNS) records influence Certificate Authority (CA) selection in our article on CAA Records and SSL Certificates 🔗
It is worth noting that DNS-PERSIST-01 records are conceptually related to but distinct from Certification Authority Authorization (CAA) records. A Certification Authority Authorization (CAA) record tells Certificate Authorities (CAs) which of them are permitted to issue SSL Certificates for a domain. A DNS-PERSIST-01 record goes further by also binding that authorization to a specific ACME account at the named Certificate Authority (CA).
Scope Controls and Optional Expiration
Without additional parameters, a DNS-PERSIST-01 record authorizes issuance only for the exact Fully Qualified Domain Name (FQDN) where the record is published, and remains valid indefinitely. Two optional parameters extend this default behavior in ways that matter for production deployments.
Wildcard Authorization Through the Policy Parameter
Adding policy=wildcard to the record broadens the authorization scope. With this parameter set, the authorization applies to the validated Fully Qualified Domain Name (FQDN), to Wildcard SSL Certificates such as *.example.com, and to subdomains whose suffix matches the validated Fully Qualified Domain Name (FQDN). This makes DNS-PERSIST-01 suitable for Wildcard SSL Certificate workflows where the existing DNS-01 challenge has always been required.
_validation-persist.example.com. IN TXT ( "ca.example.com;" " accounturi=https://acme.example.com/acme/acct/1234567890;" " policy=wildcard" )
The policy=wildcard parameter must be evaluated by the Certificate Authority (CA) at the time of each issuance, so changing or removing this parameter takes effect on the next request rather than retroactively affecting previously issued SSL Certificates. Learn About Wildcard SSL Certificates 🔗
Optional Expiration Using the PersistUntil Parameter
Operators uncomfortable with indefinite authorization can include a persistUntil parameter expressing an expiration time as Coordinated Universal Time (UTC) seconds since the Unix epoch of 1970-01-01. After the specified time passes, the Certificate Authority (CA) will refuse to use the record for new validations, which means the record must be updated or replaced before its expiration to maintain continuous SSL Certificate issuance.
_validation-persist.example.com. IN TXT ( "ca.example.com;" " accounturi=https://acme.example.com/acme/acct/1234567890;" " persistUntil=1767225600" )
Anyone using the persistUntil parameter should ensure adequate monitoring or calendar reminders are in place so that authorization does not expire unexpectedly. Allowing the parameter to lapse without being refreshed will cause subsequent issuance attempts to fail until a fresh record is published.
Authorizing Multiple Certificate Authorities (CAs) Simultaneously
Many organizations want to maintain the ability to obtain SSL Certificates from more than one Certificate Authority (CA), either for redundancy, for testing alternative providers, or to avoid lock-in to a single issuer. DNS-PERSIST-01 supports this naturally by allowing multiple TXT records at the same _validation-persist label.
Each Certificate Authority (CA) that queries the label evaluates only the records that name its own issuer-domain-name and ignores any record naming a different Certificate Authority (CA). This means an organization can publish parallel authorization records for multiple Certificate Authorities (CAs) at the same Domain Name System (DNS) label without either record interfering with the other. Explore the importance of Choosing Trusted Certificate Authorities (CAs) 🔗
The same principle applies in reverse. Removing one Certificate Authority (CA) from your authorization is as simple as deleting the corresponding TXT record, with no effect on records naming other Certificate Authorities (CAs) at the same label.
Security Tradeoffs Between DNS-01 and DNS-PERSIST-01
The two challenge types make different assumptions about which assets matter most for security. Understanding those assumptions is essential before choosing which method to use.
With DNS-01, the sensitive asset is Domain Name System (DNS) write access. Anyone who can publish TXT records at _acme-challenge can pass validation for the parent domain, so Domain Name System (DNS) Application Programming Interface (API) credentials must be tightly controlled wherever they live. In practice, many deployments distribute these credentials across issuance and reissue pipelines, which broadens the attack surface.
Important : With DNS-PERSIST-01, the sensitive asset shifts from Domain Name System (DNS) write access to the ACME account key itself. Because the persistent record names a specific ACME account as authorized, anyone who controls that account key can request SSL Certificates against the authorization. Protecting the ACME account key becomes the central security concern after initial setup. Learn About External Account Binding Credentials 🔗
This tradeoff is not better or worse in absolute terms, but it does suit different operational environments.
Deployments where Domain Name System (DNS) Application Programming Interface (API) credentials are difficult to compartmentalize may prefer the DNS-PERSIST-01 model, which allows Domain Name System (DNS) write access to remain tightly controlled after the initial authorization record is published.
Deployments where ACME account keys are difficult to protect at scale may prefer to keep the existing DNS-01 model, where credentials must be exercised for every issuance but a compromised account key has less standing authorization to abuse.
Practical Applications of Persistent DNS Validation
The CA/Browser Forum ballot that defined this method specifically identified environments where traditional challenge methods are operationally awkward. Three categories stand out.
The first is Internet of Things (IoT) deployments, where individual devices need SSL Certificates but cannot reasonably hold Domain Name System (DNS) Application Programming Interface (API) credentials or initiate Domain Name System (DNS) updates. A persistent authorization record established once at the domain level allows an issuance service to obtain SSL Certificates on behalf of many devices without touching Domain Name System (DNS) for each one. Discover the security considerations involved in our article on IoT Device Certificates 🔗
The second is multi-tenant platforms, where many customer-owned domains may be hosted on shared infrastructure. With DNS-01, the platform either needs Domain Name System (DNS) write access to each customer's zone or needs to involve the customer in every validation. DNS-PERSIST-01 lets each customer publish a one-time authorization for the platform's ACME account, after which the platform can issue and reissue SSL Certificates without further customer involvement.
The third is batch SSL Certificate operations, where many SSL Certificates are issued or reissued together as part of an infrastructure update. Under DNS-01, each SSL Certificate requires its own Domain Name System (DNS) round trip, which can be slow when issuing hundreds or thousands at once. Under DNS-PERSIST-01, the Domain Name System (DNS) layer is consulted once per domain rather than once per issuance, which substantially reduces propagation delays in batch workflows.
Industry Adoption Through CA/Browser Forum and IETF Channels
DNS-PERSIST-01 has progressed through two parallel standards tracks. The CA/Browser Forum ballot SC-088v3, titled "DNS TXT Record with Persistent Value", passed unanimously in October 2025 as a new Domain Control Validation (DCV) method recognized by the Baseline Requirements. This is the document that gives publicly trusted Certificate Authorities (CAs) the formal basis for offering the method.
In parallel, the IETF ACME working group adopted the draft specification draft-ietf-acme-dns-persist-00 in the same month. While the specification remains a working draft as of this writing, the core mechanisms described above are not expected to change substantially before the document is finalized as a Request for Comments (RFC).
What this means in practical terms is that the standard is far enough along for early implementations to begin, but production rollouts at major Certificate Authorities (CAs) are still ahead. Several reference implementations are under development, and adoption by individual Certificate Authorities (CAs) is expected to follow as the draft matures and as ACME client support becomes widespread. Explore the broader landscape of available ACME Clients 🔗
Trustico® and the Path to Persistent Validation
Trustico® follows industry standards closely and pays particular attention to changes in the ACME ecosystem given how central automated SSL Certificate management has become to modern infrastructure. DNS-PERSIST-01 is one of the more substantial additions to the validation toolkit in several years, and its eventual adoption will affect how SSL Certificates are issued at scale across the entire industry.
Note : DNS-PERSIST-01 is currently an IETF draft specification and is not yet available for production SSL Certificate issuance through commercial Certificate Authorities (CAs). The information in this article is provided for educational purposes so that operators planning future automation strategies understand what the method offers and where it sits in the standards process.
Customers operating large estates of SSL Certificates today through Certificate as a Service (CaaS) are already well-positioned for whatever validation methods become available, because the underlying automation does not change based on which challenge type the Certificate Authority (CA) uses internally. Discover how Certificate as a Service 🔗 abstracts these details away from operators.
Closing Thoughts on Persistent DNS Validation
DNS-PERSIST-01 represents a meaningful evolution in how Domain Name System (DNS) based validation can work. The existing DNS-01 method will not be going away, and many deployments will continue to prefer its model of fresh proof at every issuance. For other deployments, particularly those involving Internet of Things (IoT) devices, multi-tenant platforms, or high-volume batch SSL Certificate operations, the persistent authorization model offers operational benefits that the current standard cannot match.
The standards work is advanced enough that practitioners planning long-term automation strategies should be aware of what is coming. The CA/Browser Forum has unanimously ratified the underlying Domain Control Validation (DCV) method, and the IETF specification continues to mature. Whether DNS-PERSIST-01 supplements DNS-01 for specific use cases or eventually displaces it for most workflows will depend on how Certificate Authorities (CAs), ACME clients, and Domain Name System (DNS) providers all evolve in response.
Trustico® will continue to monitor the standard as it moves through the IETF process and as individual Certificate Authorities (CAs) announce production support. In the meantime, customers can prepare by ensuring their existing ACME automation is in good shape and by understanding which validation patterns their workloads currently depend on.
