DNS-Persist-01 is a proposed new validation method for the Automated Certificate Management Environment (ACME) protocol that allows Certificate Authorities (CAs) to verify domain control through persistent DNS TXT records rather than ephemeral challenges. This approach eliminates the need for real-time DNS updates during certificate renewals, a critical capability as the industry moves toward shorter certificate lifetimes of 47 days by March 2029 under the CA/Browser Forum’s SC-081v3 ballot. By setting a DNS record once and reusing it across multiple certificate issuances, DNS-Persist-01 addresses automation challenges in IoT deployments, multi-tenant platforms, and environments with strict change management processes.
What Is DNS-Persist-01?
DNS-Persist-01 is an Internet-Draft specification currently under development by the IETF ACME working group. The draft, authored by engineers from Fastly, Crosslayer Labs, and Amazon Trust Services, defines a new challenge type that proves domain control by confirming the presence of a persistent DNS TXT record containing CA and account identification information. (IETF. “Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation.” draft-ietf-acme-dns-persist-01, March 2026)
The CA/Browser Forum formalized the method in parallel: ballot SC-088v3, which passed 26-0 among Certificate Issuers and 3-0 among Certificate Consumers in October 2025, added “DNS TXT Record with Persistent Value” as section 3.2.2.4.22 in the Baseline Requirements, giving CAs a compliant path to implement the method ahead of full IETF standardization. The ballot took effect on November 11, 2025, meaning CAs may already use this validation method under current Baseline Requirements. (CA/Browser Forum. “Ballot SC-088v3: DNS TXT Record with Persistent Value DCV Method.” October 2025)
The core innovation of DNS-Persist-01 lies in its departure from the ephemeral nature of existing DNS-based validation. Traditional ACME challenges like dns-01 require operators to create unique TXT records for each certificate request or renewal. These records typically exist only for the duration of the validation process. DNS-Persist-01, by contrast, establishes validation records designed to persist and be reused across multiple certificate issuances over extended periods. (Heurich, S., Birge-Lee, H., and Slaughter, M. “ACME Challenge for Persistent DNS TXT Record Validation.” IETF Internet-Draft, March 2026)
The specification defines the validation record format using the issue-value syntax from RFC 8659 (CAA records), incorporating:
- An issuer-domain-name identifying the CA
- A mandatory accounturi parameter binding the validation to a specific ACME account
- An optional policy=wildcard parameter enabling wildcard and subdomain certificate issuance
- An optional persistUntil parameter specifying when the validation record expires (IETF. “DNS Certification Authority Authorization (CAA) Resource Record.” RFC 8659, November 2019)
The DNS TXT record is provisioned at _validation-persist.example.com for the domain example.com, using a standardized label that signals persistent validation intent to CAs.
How Does DNS-Persist-01 Work?
The DNS-Persist-01 validation process operates through a well-defined sequence that balances persistence with security controls:
Challenge Initiation
When an ACME client requests validation, the CA provides a challenge object containing:
- The challenge type (
dns-persist-01) - An array of
issuer-domain-namesthat the client may use - The URL for challenge response submission (IETF. “Automatic Certificate Management Environment (ACME).” RFC 8555, March 2019)
The client selects one of the provided issuer domain names and provisions a DNS TXT record at the Authorization Domain Name (formed by prepending _validation-persist to the domain being validated).
Record Structure
A basic validation record for example.com looks like this:
_validation-persist.example.com. IN TXT ("authority.example;"" accounturi=https://ca.example/acct/123")For wildcard validation support, the record includes the policy parameter:
_validation-persist.example.com. IN TXT ("authority.example;"" accounturi=https://ca.example/acct/123;"" policy=wildcard")The specification also supports time-bounded validation through the persistUntil parameter, which accepts a UNIX timestamp after which the record should no longer be considered valid. (Let’s Encrypt. “ACME Challenge Types.” Let’s Encrypt Documentation, 2026)
Just-in-Time Validation
A key optimization in the specification is the “Just-in-Time Validation” mechanism. When processing a new authorization request, the CA may perform an immediate DNS lookup for existing _validation-persist TXT records. If a valid record exists matching the requesting account, the CA can transition the authorization to “valid” status instantly without returning a pending challenge to the client. (Fastly. “DNS-Persist-01: Persistent Validation for ACME.” Fastly Blog, December 2025)
This optimization maintains the ACME state machine defined in RFC 8555 while enabling seamless renewal workflows for pre-validated domains.
Multi-Issuer Support
The specification explicitly supports multi-CA environments. A domain may authorize multiple CAs simultaneously by provisioning separate TXT records for each issuer at the same DNS label. Each CA filters for records matching its issuer-domain-name and ignores others, following a pattern similar to CAA records. (CA/Browser Forum. “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.” Version 2.0.9, 2025)
Why Does DNS-Persist-01 Matter?
The significance of DNS-Persist-01 becomes clear when examined against the backdrop of industry-wide certificate lifetime reductions and the operational challenges they create.
The Shorter Certificate Timeline
The CA/Browser Forum’s SC-081v3 ballot, passed in April 2025, establishes an industry-wide schedule for reducing both certificate validity periods and data reuse windows: (CA/Browser Forum. “Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” April 2025)
| Effective Date | Maximum Validity Period |
|---|---|
| March 15, 2026 | 200 days (now in effect) |
| March 15, 2027 | 100 days |
| March 15, 2029 | 47 days |
The first milestone in this timeline, the reduction to 200-day maximum validity, took effect on March 15, 2026. The next reduction to 100 days follows in March 2027. The ballot also mandates reduction of SAN validation data reuse from 398 days to 10 days over the same period, meaning CAs must re-validate domain control far more frequently as each phase takes effect. Organizations must demonstrate domain control more frequently as each phase takes effect, making real-time DNS updates for each validation increasingly burdensome.
Use Cases Addressed
DNS-Persist-01 specifically targets environments where traditional challenge methods prove impractical:
IoT Deployments: Devices that cannot host HTTP services or coordinate real-time DNS updates benefit from set-and-forget validation records. The IETF draft explicitly identifies IoT deployments as a primary target for the method. (IETF. “Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation.” draft-ietf-acme-dns-persist-01, March 2026)
Multi-Tenant Platforms: Edge compute environments where DNS zone management is distinct from certificate subscription can decouple these responsibilities. Platform teams migrating off ingress controllers (see ingress-nginx’s March 2026 retirement and Gateway API migration paths) will need to re-evaluate their certificate automation pipelines, making DNS-Persist-01 support a relevant migration criterion.
Batch Operations: Organizations requiring offline or delayed certificate issuance can pre-validate domains without maintaining live infrastructure connections.
Wildcard Certificates: Scenarios requiring wildcard certificates benefit from proving domain control once and reusing that validation over extended periods, with the policy=wildcard parameter providing explicit opt-in support.
Comparison with Existing Methods
| Feature | HTTP-01 | DNS-01 | DNS-Persist-01 |
|---|---|---|---|
| Validation mechanism | HTTP request to .well-known/acme-challenge/ | Ephemeral DNS TXT record | Persistent DNS TXT record |
| Real-time infrastructure required | Yes | Yes | No (after initial setup) |
| Supports wildcard certificates | No | Yes | Yes (with policy=wildcard) |
| IoT-friendly | Limited | Limited | Yes |
| Multi-tenant support | Limited | Limited | Yes |
| Account binding | Session-only | Session-only | Persistent |
| Record lifetime | Minutes | Minutes | Configurable (TTL-based) |
Security Considerations
The DNS-Persist-01 specification incorporates extensive security analysis addressing the risks inherent in persistent validation records.
Account Binding Security
The accounturi parameter provides strong binding between domain validation and specific ACME accounts. This binding persists across account key rotations, ensuring continuity without requiring DNS record updates. (IETF. “ACME Account Key Rotation.” RFC 8555 Section 7.3.5, March 2019)
Persistent Record Risks
The persistence of validation records creates extended windows of vulnerability compared to traditional methods. If an attacker gains control of a DNS zone containing persistent validation records, they can potentially obtain certificates for validated domains until those records are removed. The IETF draft’s security considerations section addresses these tradeoffs directly. (IETF. “Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation.” draft-ietf-acme-dns-persist-01, March 2026)
The specification recommends mitigation through:
- DNS providers with strong authentication and access controls
- DNSSEC implementation where possible
- Regular monitoring of DNS zones for unauthorized changes
- Periodic rotation of validation records
Subdomain Validation Risks
The policy=wildcard parameter creates significant security implications. Organizations using this feature must carefully control subdomain delegation and monitor for unauthorized subdomains, as the validation scope extends to all subdomains of the validated FQDN. The IETF draft discusses subdomain delegation risks in its security considerations.
Potential risks include:
- Subdomain takeover attacks on abandoned subdomains
- Unauthorized certificate issuance for subdomains controlled by different entities
- Confusion about authority delegation across organizational boundaries
DNS Security Measures
The specification strongly recommends DNSSEC validation on DNS-Persist-01 TXT records to ensure record integrity. For CAs subject to CA/Browser Forum requirements, Multi-Perspective Issuance Corroboration (MPIC) validates domain control from multiple network vantage points and is essential to defend against BGP hijacking and DNS spoofing attacks. (CA/Browser Forum. “Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” April 2025)
Implementation Timeline
Let’s Encrypt deployed DNS-Persist-01 to its staging environment in Q1 2026, running against the draft-00 specification. Boulder (Let’s Encrypt’s CA software) added draft-01 support to staging in late April 2026. [Updated June 2026] Production availability was targeted for Q2 2026, but community discussion as of June 2026 indicates the rollout is slipping further — a -02 revision addressing outstanding issues is expected before the spec is considered stable enough for production. The remaining blockers include how optional objects like issuer-domain-names, caaIdentities, and the accounturi privacy mechanism should be populated, plus unresolved work on wildcard validation procedures and whether to remove the TTL ceiling constraint. (Let’s Encrypt. “DNS-persist-01 Deployment Status and Timeline.” Let’s Encrypt Community Forum, 2026)
Multiple ACME client authors — including the teams behind cert-manager, Caddy, and lego — have expressed preference to wait for spec stabilization before investing significant implementation effort, citing the cost of re-implementing against a moving target.
As certificate lifetimes decrease according to the established timeline, DNS-Persist-01 will become increasingly critical for maintaining automation without requiring excessive DNS infrastructure access. The first phase of that timeline, the 200-day maximum, is now in effect as of March 2026. The 10-day SAN validation data reuse window scheduled under SC-081v3 would otherwise require frequent DNS updates for high-volume certificate operations.
Complementary Standard: ACME Renewal Information (ARI)
DNS-Persist-01 addresses the domain validation layer of certificate automation; a complementary standard covers the renewal scheduling layer. ACME Renewal Information (ARI), standardized as RFC 9773 and actively deployed by Let’s Encrypt since 2024, allows a CA to tell ACME clients precisely when to renew a certificate rather than relying on fixed percentage-of-lifetime heuristics. Let’s Encrypt published a detailed walkthrough of ARI in March 2026 as a companion to its dns-persist-01 work.
The two standards address orthogonal problems: ARI eliminates over-eager or late renewals; DNS-Persist-01 eliminates the DNS write operations those renewals require. Together they form the automation baseline that makes 47-day certificate lifetimes operationally viable for organizations managing large domain portfolios. For the most aggressive short-lifetime deployments, Let’s Encrypt also offers opt-in 6-day certificates (available since February 2025), which eliminate revocation checking (OCSP/CRL) entirely at the cost of requiring renewal at least every three days — a renewal cadence where DNS-Persist-01’s set-once model becomes nearly essential.
Frequently Asked Questions
Q: How does DNS-Persist-01 differ from the existing DNS-01 challenge? A: DNS-01 requires creating a unique, ephemeral TXT record for each certificate request or renewal, while DNS-Persist-01 uses a persistent TXT record containing account identification that can be reused across multiple certificate issuances without requiring real-time DNS updates.
Q: Is DNS-Persist-01 secure enough for production use? A: The specification design incorporates robust security measures including mandatory account binding, optional DNSSEC validation, multi-perspective issuance corroboration, and time-bounded validation through the persistUntil parameter. However, DNS-Persist-01 is not yet available for production use. The specification advanced to -01 in March 2026 and Let’s Encrypt has the challenge type available on its staging environment, with production deployment now likely in Q3 2026.
Q: When will DNS-Persist-01 be available from Let’s Encrypt? A: Let’s Encrypt has DNS-Persist-01 available on its staging environment with draft-01 support added to Boulder in late April 2026. Production deployment was targeted for Q2 2026 but has slipped; as of June 2026, ACME working group participants expect a further -02 revision before the spec is finalized. Production availability is unlikely before late 2026 at the earliest. The primary unresolved questions concern optional metadata fields, the accounturi privacy mechanism, and wildcard validation procedures.
Q: Can I use DNS-Persist-01 with multiple certificate authorities simultaneously? A: Yes, the specification explicitly supports multi-issuer environments. Domain owners can provision separate TXT records for each authorized CA at the same DNS label, with each CA filtering for records matching its issuer-domain-name.
