DNS-PERSIST-01ACMEComplianceNEW

DNS-PERSIST-01 Explained: Set It Once, Renew Forever

The new ACME validation method that eliminates DNS changes from your certificate lifecycle. Approved by CA/Browser Forum (SC-088v3), with Let's Encrypt support rolling out in 2026.

14 min readFebruary 2026FIRST-MOVER

DNS-PERSIST-01 persistent ACME DNS validation — set once, renew forever

Not sure which DCV method is right for your infrastructure? The PKI Priority Planner analyzes your environment and tells you what to focus on first.

Assess Your Priorities

Watch the Video

The Problem DNS-PERSIST-01 Solves

If you've automated certificate issuance with DNS-01 validation, you already know the pain points. Every renewal cycle requires your ACME client to create a new TXT record, wait for DNS propagation, and clean up afterwards. At scale, this creates real operational friction:

Credential distribution

DNS API credentials scattered across your issuance pipeline — every server that renews needs write access to your zone

Propagation delays

Every renewal waits for DNS propagation, adding minutes (or longer) to each issuance cycle

Concurrent validation issues

Multiple servers validating the same domain can overwrite each other's challenge tokens

Change management friction

In enterprise environments, DNS changes often require approval workflows — for every single renewal

DNS-PERSIST-01 takes a fundamentally different approach. Instead of repeating the challenge-response dance on every renewal, you publish a single, persistent authorization record. Set it once, and renewals just work — no DNS changes needed.

How DNS-PERSIST-01 Works

The key insight: instead of proving domain control on every issuance via a fresh challenge token, you publish a standing authorization that says "this CA, using this specific ACME account, is authorized to issue certificates for this domain."

The DNS Record

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
)

Breaking Down Each Component

_validation-persist

The DNS label — replaces _acme-challenge from DNS-01. This is a fixed prefix, not configurable.

letsencrypt.org

The CA's issuer-domain-name — identifies which Certificate Authority this record authorizes. Each CA has its own identifier.

accounturi=...

Binds the authorization to a specific ACME account — not just "anyone using this CA" but specifically YOUR account. This is mandatory.

DNS-01 Flow (Every Renewal)

1.Request certificate
2.Generate challenge token
3.Update DNS TXT record
4.Wait for propagation
5.CA validates
6.Certificate issued
7.Repeat everything on next renewal

DNS-PERSIST-01 Flow

1.Set TXT record once
2.Request certificate
3.CA validates (reads existing record)
4.Certificate issued
Renew → Renew → Renew... no DNS changes needed

DNS-01 vs DNS-PERSIST-01 — Head-to-Head

Feature	DNS-01	DNS-PERSIST-01
DNS changes per issuance	Every time	Once (setup only)
Challenge type	Fresh token per request	Persistent standing authorization
DNS label	_acme-challenge	_validation-persist
Wildcard support	✅ Yes	✅ Yes (with policy=wildcard)
DNS API credentials at renewal	✅ Yes — in the pipeline	❌ No — only during setup
Propagation delays at renewal	✅ Yes	❌ No
Concurrent validation safe	❌ No	✅ Yes
CA binding	Per-challenge only	Persistent, account-scoped
Security focus	Protect DNS write access	Protect ACME account key
Revocation method	Stop updating DNS	Remove TXT record or deactivate ACME account
CA/B Forum section	3.2.2.4.7	3.2.2.4.22
Validation data reuse	Per CA policy	Max 10 days (per BRs), subject to TTL
Let's Encrypt status	Production ✅	Staging late Q1 2026, Production Q2 2026

Scope Controls — Wildcard, Subdomains, and Expiration

Basic FQDN Only (Default)

No policy parameter means authorization for the exact domain only.

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
)

Covers: example.com only.

Wildcard + Subdomains

Add policy=wildcard to extend scope to all subdomains:

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890;"
  " policy=wildcard"
)

Covers: example.com, *.example.com, www.example.com, app.example.com, server.dept.example.com — any subdomain.

Optional Expiration (persistUntil)

Add a UNIX timestamp to limit how long the authorization is valid:

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890;"
  " persistUntil=1767225600"
)

After the timestamp passes, the CA will not use this record for new validations.

Watch out for silent renewal failures

If you use persistUntil, you MUST monitor and update the record before it expires. Otherwise, your next renewal will fail silently. Consider whether the operational overhead of managing expiration defeats the purpose of "set it once."

Multiple CAs

Authorize more than one CA by adding multiple TXT records at the same label:

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123;"
  " policy=wildcard"
)
_validation-persist.example.com. IN TXT (
  "ca2.example;"
  " accounturi=https://ca2.example/acme/acct/456;"
  " persistUntil=1767225600"
)

Each CA only evaluates the records matching its own issuer-domain-name.

Security Tradeoffs — What Changes

Critical framing: DNS-PERSIST-01 doesn't eliminate risk — it shifts where the risk lives. Your primary asset to protect changes from DNS write credentials to your ACME account private key.

The Security Shift

Scenario	DNS-01	DNS-PERSIST-01
Primary asset to protect	DNS write access (credentials in pipeline)	ACME account private key
Attack window	Brief (during each validation)	Persistent (as long as record exists)
If attacker compromises DNS	Can get certs during validation window	Can add persistent authorization
If attacker compromises ACME key	Limited to one validation cycle	Can use ALL existing persistent authorizations
Revocation speed	Remove DNS token	Remove TXT record AND/OR deactivate ACME account

Best Practices

Treat your ACME account key like a CA signing key

It now persistently authorizes certificate issuance for all domains with a _validation-persist record.

Use policy=wildcard sparingly

Only when you genuinely need subdomain coverage. Default FQDN-only scope limits blast radius.

Monitor your _validation-persist records

Unauthorized additions = unauthorized certificate issuance capability. Include these in your DNS monitoring.

DNSSEC recommended

Cryptographic authentication of DNS records adds integrity protection to your persistent authorizations.

Account key rotation doesn't break records

The accounturi is stable across key rotations (RFC 8555 §7.3.5) — you can rotate without updating DNS.

Know your revocation playbook

To emergency-revoke, deactivate the ACME account (RFC 8555 §7.5.2) — this is immediate and irrevocable.

For a deeper dive into the security tradeoffs, read our companion analysis

DNS-PERSIST-01 Is Great. Your Threat Model Needs Updating. →

Implementation Timeline

October 2025

CA/B Forum Ballot SC-088v3 passes unanimously

Complete

November 2025

IETF ACME WG adopts draft-ietf-acme-dns-persist-00

Complete

February 2026

Let's Encrypt announces DNS-PERSIST-01 support

Announced

Now

Pebble (test CA) support available

Available

Late Q1 2026

Let's Encrypt staging environment

Planned

Q2 2026

Let's Encrypt production rollout

Targeted

TBD

ACME client support (certbot, lego, acme.sh, etc.)

In Progress

Making a decision right now? The PKI Priority Planner scores your environment and recommends which validation method to adopt — including whether DNS-PERSIST-01 fits your setup.

Assess Your Priorities

When Should You Use DNS-PERSIST-01?

Use DNS-PERSIST-01 when:

Your servers aren't exposed to the public internet (private infrastructure, geo-locked access)
You have strict change management and DNS changes require approval workflows
You manage a large certificate estate and DNS propagation delays are a bottleneck
You want wildcard certificates without recurring DNS automation complexity
You're running IoT or edge deployments that can't coordinate DNS updates in real-time
You want to keep DNS API credentials OUT of your issuance pipeline

Stick with DNS-01 when:

You need fresh proof of control for every issuance (regulatory or internal policy requirement)
Your ACME account key management isn't mature enough for persistent authorization
You're waiting for your ACME client to add support (check certbot/lego/acme.sh status)

Consider HTTP-01 or TLS-ALPN-01 when:

Your servers ARE publicly accessible and you don't need wildcards

Full decision framework: Which DCV Method Should You Automate?

What's Next — Related Standards

DNS-ACCOUNT-01

Solves concurrent DNS-01 validation by binding challenges to ACME accounts. Different from DNS-PERSIST-01, which eliminates challenges entirely. DNS-ACCOUNT-01 still requires DNS changes on each renewal.

47-Day Certificates (SC-081)

Shorter certificate lifetimes make "set it once" even more valuable — you'll be renewing far more frequently, making the case for persistent validation even stronger.

DCV Methods Sunset (SC-090)

Email and phone-based validation methods are being phased out, making DNS-based methods increasingly important. DNS-PERSIST-01 arrives just as other methods sunset.

References & Further Reading

Let's Encrypt Announcement: DNS-PERSIST-01

Official announcement with implementation timeline and technical details

IETF Draft: draft-ietf-acme-dns-persist-00

The IETF specification defining the DNS-PERSIST-01 challenge type

CA/B Forum Ballot SC-088v3

The ballot that added Section 3.2.2.4.22 to the Baseline Requirements

Baseline Requirements (Section 3.2.2.4.22)

The normative requirements for DNS TXT Record with Persistent Value validation