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 45 days by 2028. 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.¹

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—records that 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.²

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³

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⁴

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.⁵

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.⁶

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.⁷

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

In December 2025, Let’s Encrypt announced a phased reduction of certificate validity periods from 90 days to 45 days by 2028, with the authorization reuse period shrinking from 30 days to 7 hours.⁸ The CA/Browser Forum’s SC-081v3 ballot, passed in 2025, establishes an industry-wide schedule:

This timeline creates urgent operational requirements. Organizations must demonstrate domain control more frequently—potentially every 7 hours in the final phase—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.⁹

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.¹⁰

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.¹¹

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 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.¹³

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)—validating domain control from multiple network vantage points—is essential to defend against BGP hijacking and DNS spoofing attacks.¹⁴

Implementation Timeline

Let’s Encrypt has indicated that DNS-Persist-01 is expected to become available in 2026.¹⁵ The feature is being developed in coordination with the CA/Browser Forum and IETF to ensure alignment with evolving baseline requirements.

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 7-hour authorization reuse period scheduled for February 2028 would otherwise require near-constant 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: Yes, the specification incorporates industry best practices including mandatory account binding, optional DNSSEC validation, multi-perspective issuance corroboration, and time-bounded validation through the persistUntil parameter. However, organizations must protect their ACME account keys with the same rigor as certificate private keys.

Q: When will DNS-Persist-01 be available from Let’s Encrypt? A: Let’s Encrypt expects DNS-Persist-01 to be available in 2026, though the exact date depends on finalization of the IETF specification and implementation in their Boulder CA software.

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.