DNS-Persist-01: Let's Encrypt's New Model for Permanent Certificate Validation

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 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. (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-names that 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)

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.

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

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. (Birge-Lee, H., et al. “Security Analysis of Persistent DNS Validation.” ACM CCS 2025)

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. (Slaughter, M. “Subdomain Delegation Risks in ACME.” IETF ACME Working Group Mailing List, October 2025)

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. “Multi-Perspective Issuance Corroboration.” Ballot SC-081v3, 2025)

Implementation Timeline

Let’s Encrypt deployed DNS-Persist-01 to its staging environment in Q1 2026, running against the draft-00 specification. Production availability was targeted for Q2 2026, but as of May 2026, community discussion indicates the rollout may slip to Q3. The remaining blockers are open questions in the IETF working group around how optional objects like issuer-domain-names, caaIdentities, and the accounturi privacy mechanism should be populated, plus unresolved work on wildcard validation procedures. (Let’s Encrypt. “DNS-persist-01 Deployment Status and Timeline.” Let’s Encrypt Community Forum, 2026)

The -01 revision published in March 2026 contains no breaking changes to core validation mechanics, but the outstanding optional-feature questions must reach working group consensus before Let’s Encrypt considers the spec stable enough for production.

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.

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 as of Q1 2026, running against the draft-00 specification. Production deployment was targeted for Q2 2026 but may slip to Q3, depending on how quickly remaining open issues in the spec reach consensus at the IETF ACME working group. The primary unresolved questions concern optional metadata fields 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.

Sources:

• draft-ietf-acme-dns-persist-01
• CA/Browser Forum Ballot SC-088v3
• Let’s Encrypt DNS-PERSIST-01 blog post
• Let’s Encrypt DNS-persist-01 community deployment thread
• CA/Browser Forum SC-081v3