DNS Persist 01: how persistent ACME validation works

DNS Persist 01: how persistent ACME validation works

DNS Persist 01 binds a persistent DNS authorization to a certificate authority and an ACME account.

The proposed dns-persist-01 challenge changes what has to happen before a certificate can be issued. Instead of publishing a fresh challenge-specific DNS value for each new authorization, a domain owner publishes a standing authorization for a named CA and account. That can remove recurring DNS writes from the issuance path. It also makes control of the authorized account a lasting security responsibility.

The current IETF working-group draft is draft-02, dated September 2026, and remains a work in progress. A protocol proposal, a trust-program permission and an implemented CA/client combination are three separate things. Operators need compatible implementation documentation before changing production certificate automation.

What persists, and what does not

For example.com, the draft places the authorization at _validation-persist.example.com. The TXT value identifies the issuer and binds the authorization to an ACME account. The draft also defines scope controls, an optional persistUntil expiry constraint and a privacy-preserving hashed account-identifier mechanism. Obtain the exact record format from the implementation you intend to use; an example from an older draft is not a stable configuration contract. Draft-02 record format and verification procedure describes the protocol details.

Traditional ACME challenges use a different proof. In dns-01, the client publishes a challenge-specific TXT value under _acme-challenge. In http-01, it serves challenge content through the expected HTTP path. The challenge values are tied to the ACME account key through the protocol’s key-authorization construction; calling them merely session-bound would hide that account relationship. (IETF. “Automatic Certificate Management Environment (ACME).” RFC 8555, March 2019)

The practical contrast is therefore the standing DNS permission, not the existence of account binding.

The existing-method details and Let’s Encrypt wildcard distinction are documented in Let’s Encrypt. “ACME Challenge Types.” Let’s Encrypt Documentation, 2026. The proposed method’s behavior comes from draft-02. The table does not claim equivalent production availability.

DNS TTL does not limit validation reuse

Section 7.9 of draft-02 makes an important distinction: DNS TTL controls resolver caching. It is not the period for which a CA may reuse validation data.

The effective authorization depends on the CA’s Validation Data Reuse Period and the expiry constraint established by persistUntil. Removing or changing a TXT record affects a future DNS lookup after resolver caches expire. It does not retroactively shorten validation data the CA already obtained before the authorization’s established expiry.

That means a five-minute DNS TTL is not a five-minute issuance permission. Likewise, deleting a standing record is not necessarily enough to end all previously validated authority immediately. An incident-response procedure needs to address the CA’s authorization state and any affected certificates, as well as the DNS record. These consequences follow from the draft’s validation-reuse and invalidation sections, rather than from ordinary assumptions about a DNS record’s lifetime.

Just-in-time validation and multiple issuers

Draft-02 Section 4.4 permits a CA to inspect the standing record when it receives a new authorization request. If the record satisfies the required checks, the CA can return a valid authorization without making the client complete a pending challenge. This is an optimization within ACME’s authorization flow, described by RFC 8555; it is not a bypass of account or policy validation.

Section 4.3 allows multiple issuer-specific TXT records at the same validation name. Each CA evaluates records matching its issuer identity. Account-specific records and wildcard policy still need deliberate management: authorizing several issuers does not make every account at those issuers an authorized subscriber.

CAA is a separate control over which CAs may issue. The CAA processing rules are defined in IETF. “DNS Certification Authority Authorization (CAA) Resource Record.” RFC 8659, November 2019. A standing account authorization should not be mistaken for a replacement for those issuer restrictions; draft-02 discusses their interaction separately.

Shorter certificates raise the value of reliable automation

The CA/Browser Forum’s CA/Browser Forum. “Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” April 2025 describes a reduction of maximum certificate validity from 398 to 47 days, beginning in March 2026 and concluding in March 2029. It also describes reducing Subject Alternative Name validation-data reuse from 398 to 10 days.

Certificate validity and validation-data reuse are different clocks. A shorter certificate may require more frequent renewal, while a shorter reuse period may require fresh domain-control validation more often. A CA’s own policies can also be more restrictive than a trust-program maximum. Use that CA’s current requirements when designing automation rather than copying a historical maximum into a renewal script.

The separate CA/Browser Forum. “Ballot SC-088v3: DNS TXT Record with Persistent Value DCV Method.” October 2025 adds a persistent DNS TXT validation method to the Baseline Requirements. That establishes a policy path for implementation. It does not establish that every CA, client or managed-certificate service supports the same IETF draft.

The account key becomes the standing permission’s critical asset

The attractive operational change is fewer recurring DNS writes. A team can provision the initial record through its normal DNS controls without distributing those credentials to every renewal process. The tradeoff is persistent authority for the bound ACME account. A compromised account key could let an attacker use that standing permission without also obtaining fresh DNS write access.

Account key rotation and ending an account’s permission are different operations. ACME can rotate a key while preserving the account identity, as described in IETF. “ACME Account Key Rotation.” RFC 8555 Section 7.3.5, March 2019. A standing authorization can therefore continue across a legitimate key rotation. Revoking access needs a procedure for the authorization itself.

The draft’s security analysis covers persistent-record risks, account-identifier privacy, wildcard and subdomain scope, DNS integrity, DNSSEC and multi-perspective validation. Scope deserves particular attention on a platform where different tenants or teams control subdomains. A parent-domain wildcard permission is a broader decision than permission for one named host.

Before a pilot, identify who owns the DNS record, account key, expiry monitoring, CA-side invalidation and certificate revocation. Test the failure path as well as issuance: an expired persistUntil, an account rotation, a removed record and a compromised credential should have documented outcomes. This is a proposed operational checklist derived from the protocol’s control surfaces, not a claim that those scenarios have been tested here.

What Let’s Encrypt has actually announced

Let’s Encrypt’s February 2026 implementation announcement said support was available in Pebble, its miniature test CA, and that a lego-cli implementation was in progress. It published staging and production targets. Those dated targets are not a current production-support guarantee, and Pebble support is not the same as support in the public production service.

The September draft revision is another reason to check the actual server and client combination. Verify the implemented draft version, account-identifier format, wildcard semantics, expiry behavior and test-environment instructions. Until that combination is documented, keep the established challenge path working. Do not treat a protocol’s potential to remove DNS writes as evidence that your present renewal stack can already do so.

Renewal scheduling is a separate improvement. Let’s Encrypt published a detailed walkthrough of ACME Renewal Information, which lets a CA guide when a client should renew. ARI addresses scheduling; DNS Persist 01 addresses domain-control validation. The SC-081v3 schedule makes dependable renewal important whether or not this particular persistent-validation proposal is the method a CA eventually ships.