All tools

Guides Certificates

DNS-PERSIST-01: what it is, who supports it

Updated 5 min read

Short answer

DNS-PERSIST-01 lets one TXT record, at _validation-persist.example.com, authorize one certificate authority account for that name, for as long as the record stays. Renewals then need no DNS changes.

As of October 24, 2026, Google Trust Services’ public CA supports it: it announced on September 28, 2026 that it “now supports” the method. Let’s Encrypt offers it on its staging server only, and hasn’t announced a production date.

The standard is still an IETF draft, and its newest version changes the record’s format. Records written for one version may need rewriting.

However you validate, the SSL certificate checker shows the certificate your site actually serves: issuer, names and expiry date. Free, no account. Check a certificate

Where you can use it

As of October 24, 2026:

Who Status Source
CA/Browser Forum rules Allowed since November 10, 2025, as method 3.2.2.4.22, “DNS TXT Record with Persistent Value” Baseline Requirements, ballot SC088
Google Trust Services Supported on its public CA: it “now supports” the method, it said on September 28, 2026, on draft version 01 GTS announcement
Let’s Encrypt, staging Offered: a test order we created on October 24, 2026 listed it Our own request, below
Let’s Encrypt, production Not announced Let’s Encrypt’s staff, June 25, 2026

Let’s Encrypt announced its plans on February 18, 2026, aiming for staging in “late Q1 2026” and production “some time in Q2 2026”. On June 25, its staff wrote: “We will not be deploying dns-persist-01 until” a question about binding the record to the account, issue 64 in the draft’s repository, “is resolved.” That issue was closed on September 23, 2026, as resolved by the draft’s version 02, published September 20, which changed the record format. Let’s Encrypt hasn’t announced a production date since.

This is the challenge Let’s Encrypt’s staging server offered when we created a test order for boringutils.com on October 24, 2026. We didn’t answer it, so nothing was validated or issued:

{
  "issuer-domain-names": [
    "letsencrypt.org"
  ],
  "status": "pending",
  "type": "dns-persist-01",
  "url": "https://acme-staging-v02.api.letsencrypt.org/acme/chall/358318703/6051120363/sUUwsw"
}

The same order also offered dns-01, http-01 and tls-alpn-01.

What the record looks like

The record lives at _validation-persist. plus the name being validated, and its value names the CA and your account. Google Trust Services documents this example, for “example.com and subdomains” and the account https://pki.goog/acct/12345678, shown here as a zone file line:

_validation-persist.example.com.  TXT  "pki.goog; accounturi=https://pki.goog/acct/12345678; policy=wildcard"

The parts:

  • The CA’s issuer domain name comes first: pki.goog for Google Trust Services, letsencrypt.org for Let’s Encrypt. Each CA reads only the records with its own name, so you can authorize several CAs with one record each.
  • accounturi identifies the one ACME account allowed to use the record.
  • policy=wildcard, optional, extends the record to wildcard certificates and every subdomain: “example.com, *.example.com, www.example.com, and any other subdomain of example.com” (draft 02, section 5.1). Without it, the record covers only the exact name.
  • persistUntil, optional, is a Unix timestamp after which the CA must stop using the record for new validations. Certificates already issued keep working.

The CA/Browser Forum’s rule describes the same record: placed at “_validation-persist.[Authorization Domain Name]”, with an accounturi that is required and a persistUntil that is optional. It also caps how long a CA may rely on one check: “10 days as the maximum validation data reuse period” for this method. So a certificate requested more than 10 days after the CA’s last check needs a fresh look at the record, and the record has to still be there.

Which draft version

The method is defined in draft-ietf-acme-dns-persist, a working document of the IETF’s ACME working group. Its latest version, 02, is dated September 20, 2026. Two versions matter today:

  • Draft 01 (March 24, 2026) puts the account’s URL in accounturi in plain text, as in the example above. Google Trust Services implements this version and says it “will not make changes unless required by a final IETF standard.”
  • Draft 02 replaces it with a hashed value that binds the account to the domain, and states that the old form “is no longer accepted”. Its example record:
_validation-persist.example.com. IN TXT ("authority.example;"
" accounturi=https://ca.example/account-hash/"
"sha-256/5SQm7n6tPh2-PlLbCKGnViTXX5z19SCN4cPGQHSk-kw")

So a record that works with one CA today may need rewriting when that CA moves to a later version. Let your ACME client generate it, and follow your CA’s documentation for the exact format.

ACME clients

  • lego added DNS-PERSIST-01 in v5.0.0 (May 11, 2026), updated to draft 01.
  • acme.sh added it in 3.1.4 (July 17, 2026), with a --dns-persist-days option.
  • Certbot doesn’t support it as of version 5.8.0: its changelog has no entry for it.

What it changes for security

With DNS-01, a renewal needs write access to your DNS, so DNS API credentials end up on every server that renews. A persistent record needs DNS access once, at setup. Let’s Encrypt sums up the trade: “because the authorization record persists over time, protecting the ACME account key becomes the central concern.” Anyone with that account key can get certificates for the name for as long as the record exists.

To withdraw it, the draft gives two ways (section 7.11): delete the TXT record, after which new validations fail once resolver caches expire, or deactivate the ACME account, which takes effect at once. If you use persistUntil, put the date in a calendar: Let’s Encrypt warns that the record “must be updated or replaced before it expires.”

Sources

All sources were checked on October 24, 2026. The staging challenge comes from our own request on that date.

Keep reading