Summary

  • Revision 02 of the IETF ACME DNS persistence draft lets a CA match a persistent DNS record against the SHA-256 JWK thumbprint of any public key the ACME account has used, not only its current key.
  • Rotating the account key removes the old private key's ability to authenticate new ACME requests. It does not, by itself, retire DNS authority already associated with that public thumbprint; deleting the TXT record and shortening persistUntil have their own delayed effects.
  • Operators need an authorization-lifetime receipt that records the matched key generation, DNS observation, cache horizon, account state, CAA result and reuse expiry. Account deactivation is the draft's immediate account-wide stop.

The incident ticket says the ACME account key was rotated at 09:00 and the persistent TXT record was deleted at 09:05. The old private key can no longer sign an authenticated request. A conventional credential dashboard therefore shows two reassuring facts: the active key is new, and DNS no longer publishes the old authorization.

A certificate authority may still hold validation data obtained before either change. Under revision 02 of ACME DNS Persistent Challenge, that data may remain usable until the authorization expires. Key rotation, DNS visibility and authorization reuse are three different clocks.

The revision was posted on 20 September 2026. The Datatracker history records an active working-group Internet-Draft at I-D Exists. Its text says Standards Track, but the Datatracker has no assigned intended status, shepherd, Area Director or IESG state. It is not an RFC, an IETF Last Call or proof that any named CA has deployed the design.

The mechanism begins with a record below _validation-persist. Its value carries dns-persist-01, a 43-character unpadded base64url SHA-256 JWK thumbprint and a hash binding the domain name, that thumbprint and the ACME account URL. The construction follows RFC 7638 for the thumbprint and RFC 6920 for the digest representation. A relying CA first calculates the value for the account's current key. If there is no match, it works backwards through the public keys retained for that account.

That backwards search is the consequential change in revision 02. The difference from revision 01 requires a server supporting persistent validation to keep the SHA-256 JWK thumbprint of every public key used by an account for the lifetime of that account. The working-group repository makes the draft's development visible, but it does not turn the proposal into deployed policy.

The reason is operationally sound. ACME permits an account to roll over its key. A DNS record tied only to the current key would stop working after ordinary hygiene, forcing domain operators to revisit a record designed to be persistent. Retaining public thumbprints preserves continuity without retaining old private keys. A thumbprint can identify the key that authorised the record; it cannot sign a new order.

That distinction creates residual authority. Suppose a CA observed a valid record while key K1 was current and stored reusable validation. The account rotates to K2. K1 can no longer authenticate an ACME request, yet the CA's validation remains associated with the same live account. If a fresh lookup is required, the server can still match a record built with K1 because K1's public thumbprint remains in account history. Rotation changes the signing principal; it does not necessarily withdraw the earlier DNS grant.

Deleting the record is also not instantaneous. DNS answers can remain in recursive caches until their TTL expires. Revision 02 is careful not to confuse that TTL with the reuse window for validation data. The TTL describes how long a resolver may cache an answer. The CA's authorization expiry describes how long previously obtained validation can support later orders. The draft permits a persistUntil parameter to cap that authorization, but removing the record or later publishing a shorter value does not retroactively shorten validation already obtained.

The result is a four-clock system. There is the account-key clock, which determines which private key can authenticate now. There is the DNS clock, including authoritative publication and cache expiry. There is the ACME authorization clock, under which a CA may reuse validated control. And there is an optional persistUntil ceiling expressed by the domain operator when the record is validated. A change on one clock does not silently advance the others.

The draft supplies one immediate account-wide lever: deactivate the ACME account. A CA processing persistent validation must check that the account remains valid. Deactivation overrides the benefit of retained public-key history. This is stronger than deleting a single record, but also broader: it halts the account rather than withdrawing one domain's grant. Incident plans therefore need both actions and must not present them as equivalents.

The domain binding has an explicit escape hatch. Normally the hash includes the domain, limiting a value to one name. A record can instead use domain_name=*, which allows reuse across domains for the same account and key. The convenience expands correlation and blast radius. One persistent token can reveal that distinct names share an ACME control plane, and compromise of the associated authority can reach further.

Wildcard issuance adds another policy boundary. RFC 8555 treats identifier authorization as part of order processing, while the draft defines how persistent DNS proof can be obtained and reused. A platform should record exactly which identifier and wildcard scope were accepted rather than treating a successful lookup as generic control of a customer zone.

CAA remains independent. The accounturi parameter in RFC 8657 uses the actual ACME account URL. The persistent TXT construction hashes that URL into its value. A matching TXT record does not satisfy CAA processing, and a CAA authorization does not prove possession of the persistent DNS grant. Both decisions belong in the issuance record.

DNSSEC can strengthen the observation path, but it does not merge these controls. The draft says a CA should validate DNSSEC when available and fail the challenge if validation is attempted and fails. RFC 4033 explains the authenticity and integrity DNSSEC can add to DNS answers. It cannot decide whether a cached answer is still institutionally intended or whether an ACME account should remain active.

The proposal also supports delegated provisioning. After an authenticated POST-as-GET confirms that an account is valid, another party can be given the public account URL and public-key thumbprint needed to build the record. No private key is required. This separates the DNS operator from the ACME account controller—a useful division of labour, but another reason to record who requested, approved and installed the grant.

The IANA ACME registries do not list dns-persist-01 at the publication cutoff. The CA/Browser Forum's SC-088v3 ballot provides relevant industry context: participating certificate issuers and consumers unanimously supported an account-scoped persistent TXT validation method. That vote is not evidence that this IETF revision is deployed, nor that browser policy and the draft are identical.

The operational answer is an authorization-lifetime receipt. For each validation, retain the exact FQDN and identifier scope; the record digest and observation time; resolver and authoritative evidence; TTL and expected cache horizon; issuer identity; whether domain_name=* was used; account URL in protected form; the current or historical key generation that matched; live account status; CAA result; DNSSEC result; persistUntil; authorization expiry; and the order and issuance times that consumed the result.

That receipt makes revocation claims testable. It can show that a key was rotated but historical matching remained permitted; that deletion was visible authoritatively while a resolver could still serve the old answer; that no new validation occurred yet earlier data remained reusable; or that account deactivation invalidated the path before issuance. Without it, teams are left comparing a present-day DNS lookup with a certificate event governed by yesterday's state.

The draft may change before publication. Implementers may choose shorter reuse periods, stronger multi-perspective checks or narrower wildcard policy. The institutional lesson is already stable: persistent authorization transfers control from a single live proof into a managed history. Rotation is maintenance. Withdrawal requires an action aimed at the authorization that still exists.

Sources