Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation

1.1. Robustness and Alignment with Industry Best Practices

This validation method is designed to provide a robust and persistent mechanism for domain control verification within the ACME protocol. Its technical design incorporates widely adopted security principles and best practices for domain validation, ensuring high assurance regardless of the specific CA policy environment. These principles include, but are not limited to:¶

1. The use of a well-defined, unique DNS label (e.g., "_validation-persist") for persistent validation records, minimizing potential conflicts.¶

2. Explicit binding of the domain validation to an ACME account through a unique identifier, establishing clear accountability and enhancing security against unauthorized use.¶

Certification Authorities operating under various trust program requirements will find this technical framework suitable for their domain validation needs, as its design inherently supports robust and auditable validation practices.¶

3.1. Challenge Object

The challenge object for "dns-persist-01" contains the following fields:¶

• type (required, string): The string "dns-persist-01"¶

• url (required, string): The URL to which a response can be posted¶

• status (required, string): The status of this challenge¶

• issuerDomainNames (required, array of strings): A list of one or more Issuer Domain Names. The client MUST choose one of these domain names to include in the DNS TXT record. The challenge is successful if a valid TXT record is found that uses any one of the provided domain names.¶

  Each string in the array MUST be a domain name that complies with the following normalization rules:¶

  1. The domain name MUST be represented in A-label format (Punycode, [RFC5890]).¶

  2. All characters MUST be lowercase.¶

  3. The domain name MUST NOT have a trailing dot.¶

  The server MUST ensure the array is not empty. Servers MUST NOT send more than 10 issuer domain names. This limit serves as a practical measure to prevent denial-of-service vectors against clients. Clients MUST consider a challenge malformed if the issuerDomainNames array is empty or if it contains more than 10 entries, and MUST reject such challenges. Each domain name MUST NOT exceed 253 octets in length.¶

The following shows an example challenge object:¶

{
  "type": "dns-persist-01",
  "url": "https://ca.example/acme/authz/1234/0",
  "status": "pending",
  "issuerDomainNames": ["authority.example", "ca.example.net"]
}

3.2. Directory Metadata for Issuer Domain Names

A CA offering the dns-persist-01 challenge type MUST advertise an issuerDomainNames array in the meta object of its directory ([RFC8555], Section 7.1.1). This directory-level array lets a client discover Issuer Domain Names before opening any authorization, so it can pre-provision _validation-persist records per Section 4.6 without an interactive order.¶

The directory issuerDomainNames array MUST use the same normalization and length rules as the challenge object's issuerDomainNames array (Section 3.1): each entry MUST be a lowercase A-label domain name with no trailing dot and MUST NOT exceed 253 octets. The array MUST NOT be empty and MUST NOT contain more than 10 entries.¶

Let D be the set of values in the directory issuerDomainNames array, and let I be the set of values in the directory caaIdentities array ([RFC8555], Section 7.1.1), represented as lowercase A-label domain names with no trailing dot. This document does not require a CA to advertise caaIdentities; a CA that does not perform CAA validation has no names to disclose there. For each dns-persist-01 challenge object the CA issues, let C be the set of values in that challenge's issuerDomainNames array. The CA MUST satisfy these requirements:¶

• Every value in D MUST appear in C. A client that pre-provisions a record using a name from D is therefore guaranteed that the name will satisfy the issuer-domain-name requirement of any dns-persist-01 challenge that CA issues later, without first opening an authorization.¶

• C MAY include values beyond D while remaining within the 10-entry maximum in Section 3.1, so a CA can offer challenge-specific names in addition to its pre-provisioning baseline.¶

• If the CA advertises caaIdentities, every value in C MUST also appear in I. This prevents a CA that participates in CAA validation from accepting an issuer-domain-name it has not also disclosed through caaIdentities.¶

For these subset comparisons, the CA MUST compare caaIdentities values, when advertised, after applying the same lowercase A-label and trailing-dot rules used for D and C.¶

caaIdentities values of publicly trusted CAs are kept distinct by the CA/Browser Forum disclosure and audit regime. Identities of CAs outside that regime have no equivalent protection against another CA recognizing the same name, so a domain owner who adds such an identity to a CAA policy accepts that reuse caveat.¶

A client MUST treat a missing or nonconforming directory issuerDomainNames array as unavailable for pre-provisioning. A missing or nonconforming caaIdentities array does not affect pre-provisioning; it only makes the I comparisons unavailable. A client MAY still process an interactive dns-persist-01 challenge. When D is available, the client MUST consider a challenge malformed if any value in D is absent from C. When I is available, the client MUST consider a challenge malformed if any value in C is absent from I.¶

4.1. Validation Record Format

The RDATA of this TXT record MUST fulfill the following requirements:¶

1. The RDATA value MUST conform to the issue-value syntax defined in [RFC8659], Section 4.2. To ensure forward compatibility, the server MUST ignore any parameter within the issue-value that has an unrecognized tag.¶

2. The issuer-domain-name portion of the issue-value MUST be one of the Issuer Domain Names provided by the CA in the issuerDomainNames array of the challenge object. If the issuer-domain-name does not match any of the provided values, the CA MUST reject the record.¶

3. The issue-value MUST contain an accounturi parameter whose value is a hashed URI identifying the ACME account requesting validation. A hashed URI cryptographically binds the account to the domain being validated without publishing the account URL in cleartext. It is formed by concatenating the CA's accountHashPrefix, a hash-algorithm identifier, a "/" separator, and a base64url hash value:¶

   <accountHashPrefix><hash-alg>/<base64url hash value>
   

   ¶

   A CA that advertises support for the dns-persist-01 challenge type MUST advertise an accountHashPrefix string in the meta object of its directory ([RFC8555], Section 7.1.1). This prefix places hashed account URIs under the CA's infrastructure and lets a client construct them from the directory without a per-provisioning request to the CA. The CA MUST choose a prefix such that appending the remaining components yields a valid URI (for example, https://ca.example/account-hash/).¶

   <hash-alg> MUST be the exact Hash Name String registered in the "Named Information Hash Algorithm Registry" defined by [RFC6920], Section 9.4. Both clients and CAs implementing dns-persist-01 MUST support the registered sha-256 Hash Name String, which identifies SHA-256 [FIPS180-4]: a client MUST be able to compute, and a CA MUST accept, a hashed URI that uses this token, so that every conforming implementation interoperates without prior negotiation. A CA MAY accept other registered algorithms and MUST document each additional algorithm it accepts. An additional algorithm MUST have a registered digest length of at least 256 bits and MUST remain collision resistant at the time of use. A client MAY use an optional algorithm only after establishing from the CA's documentation that the CA accepts it. This document defines no separate algorithm-negotiation mechanism.¶

   <base64url hash value> is the base64url encoding [RFC4648], with trailing padding (=) omitted, of the hash digest computed with the identified algorithm over the following octet string:¶

   H(length_of_domain || domain_name || key || account_URL)
   

   ¶

   where H is the identified hash algorithm and || denotes octet-string concatenation. The inputs are:¶

   1. length_of_domain is a single octet giving the length in octets of domain_name. A domain name is limited to 255 octets ([RFC1035], Section 2.3.4), so a single octet always suffices. This length prefix delimits domain_name from the fields that follow.¶

   2. domain_name is, by default, the FQDN being validated: the Validation Domain Name with its leading _validation-persist label removed and no trailing dot, in the normalized lowercase A-label form produced by Section 9.2. This form is US-ASCII. This is the FQDN at which the _validation-persist record is provisioned, not the FQDN of the certificate ultimately requested; binding the record to its own domain is what makes the hashed URI domain-specific (see Section 7.2.3).¶

      As an exception, a client MAY set domain_name to the single US-ASCII octet * (0x2a; length_of_domain is then 0x01) to opt out of the domain-correlation mitigation. The resulting hashed URI does not depend on the domain and MAY therefore be reused across domains. A CA MUST accept a hashed URI computed with domain_name set to *. The privacy trade-off of this opt-out is described in Section 7.2.3.¶

   3. key is the 43 ASCII octets of the unpadded base64url encoding [RFC4648] of the SHA-256 JWK Thumbprint [RFC7638] of a public key associated with the ACME account. This is the encoding used for the thumbprint component of an ACME key authorization ([RFC8555], Section 8.1), so a client can reuse that component without decoding it. When provisioning a _validation-persist record, the client MUST use the account's current key. A CA MUST accept a hashed URI generated with the current key associated with the account. Additionally, a CA MUST accept a hashed URI generated with a prior key previously associated with the account that is known to the CA per the key retention obligation in Section 4.2, subject to the deactivation and key-rotation limits stated there. This allows a record provisioned before a key rotation to continue to validate. The rationale for these requirements is given in Section 7.2.3.¶

   4. account_URL is the ACME account URL ([RFC8555], Section 7.3). A URI is US-ASCII per [RFC3986], so it is encoded as those US-ASCII octets.¶

   The CA MUST verify that the hashed URI in the DNS record authorizes the ACME account making the request, by recomputing it as described in Section 4.2; if no recomputation matches, the CA MUST reject the record.¶

4. The issue-value MAY contain a policy parameter. If present, this parameter modifies the validation scope. The policy parameter follows the 'tag=value' syntax from [RFC8659]. Comparison of the values defined for this parameter MUST be case-insensitive (e.g., "WILDCARD" and "wildcard" are equivalent).¶

   Note: The requirement to ignore unrecognized parameters (item 1) ensures forward compatibility, allowing future extensions without breaking existing implementations, consistent with ACME's extensibility model ([RFC8555]). The explicit case-insensitivity requirement is necessary to ensure consistent behavior across implementations; without it, some CAs might reject unknown parameter values, preventing protocol evolution.¶

   The following value for the policy parameter is defined with respect to subdomain and wildcard validation:¶

   • policy=wildcard: If this value is present, the CA MAY consider this validation sufficient for issuing certificates for the validated FQDN, for specific subdomains of the validated FQDN (as covered by wildcard scope or specific subdomain validation rules), and for wildcard certificates (e.g., *.example.com). See Section 5 and Section 6.¶

   If the policy parameter is absent, or if its value is anything other than wildcard, the CA MUST proceed as if the policy parameter were not present (i.e., the validation applies only to the specific FQDN).¶

5. The issue-value MAY contain a persistUntil parameter. If present, the value MUST be a base-10 encoded integer representing a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds). If the value is not a valid base-10 integer, the CA MUST treat the record as malformed and reject it. After the specified timestamp, a CA MUST NOT use the record for a new validation attempt or reuse validation data previously obtained from it.¶

This specification defines the following case-handling rules for parameter values in dns-persist-01 records:¶

• accounturi: The value is a hashed URI. CAs MUST compare accounturi values using Simple String Comparison per [RFC3986], Section 6.2.1, with no case-folding or other normalization.¶

• policy: Case-insensitive, as specified in item 4 above.¶

• persistUntil: The value is a base-10 integer. Case does not apply.¶

For example, for validation of the FQDN "example.com" with issuer domain name "authority.example", where the CA advertises an accountHashPrefix of "https://ca.example/account-hash/" and the account's hashed URI (see Section 10.2 for the full computation) is "https://ca.example/account-hash/sha-256/5SQm7n6tPh2-PlLbCKGnViTXX5z19SCN4cPGQHSk-kw", the DNS TXT record would contain:¶

_validation-persist.example.com. IN TXT ("authority.example;"
" accounturi=https://ca.example/account-hash/"
"sha-256/5SQm7n6tPh2-PlLbCKGnViTXX5z19SCN4cPGQHSk-kw")

4.2. Verification Procedure

The ACME server verifies the challenge by performing a DNS lookup for TXT records at the Validation Domain Name. It then iterates through the returned records to find one that conforms to the required structure. For a record to be considered valid, its issuer-domain-name value MUST match one of the values provided in the issuerDomainNames array from the challenge object, and its accounturi parameter MUST be a hashed URI that identifies the requesting account, as defined in Section 4.1. When comparing issuer domain names, the server MUST adhere to the normalization rules specified in Section 3.1. The server also interprets any policy parameter values according to this specification. If no record meeting all requirements is found, the server MUST treat the challenge as failed.¶

To verify a hashed-URI accounturi value, the CA already knows the requesting account's URL and the FQDN being validated. The CA computes the expected hashed URI as defined in Section 4.1 over each ACME public key it retains for that account (see below); for each such key it computes the value twice, once using the FQDN being validated as domain_name and once using the domain-omitted opt-out form (domain_name set to *). The CA treats the record as satisfying the requirement if its accounturi value equals any of these computed hashed URIs under Simple String Comparison ([RFC3986], Section 6.2.1). Retaining an account's prior key thumbprints allows records provisioned before a key rotation to continue validating.¶

To recompute these hashed URIs, a CA has a data-retention obligation: it MUST retain an association between each ACME account and the SHA-256 JWK Thumbprints of the public keys that account has used, and it MUST retain, for each currently valid certificate, the link from that certificate to the specific key that computed the hashed URI of the _validation-persist record that most recently validated a domain for it. The following rules govern this retained data and the acceptance of the keys behind it, listed in order of precedence with earlier rules overriding later ones:¶

1. Deactivation overrides retention. A CA MUST NOT accept a hashed URI computed from a key of a deactivated ACME account, regardless of any retention rule below and regardless of whether a currently valid certificate depends on that key. Deactivating an account ([RFC8555], Section 7.3.6) therefore stops all of that account's _validation-persist records from validating immediately, which is the intended behavior for a suspected key or account compromise.¶

2. Certificate-backed retention. A CA MUST retain the thumbprint of the key used to compute the hashed URI of any _validation-persist record that most recently validated a domain for a currently valid certificate, and MUST NOT prune it while that certificate remains valid, regardless of the key's age or any key-rotation bound. This ensures a record backing an in-use certificate does not cease to validate through routine key rotation.¶

3. General retention. Subject to the rules above, a CA SHOULD retain the thumbprint of every public key an account has used since the CA began accepting dns-persist-01 records, so that a record computed under any of those keys continues to validate. A CA MAY bound acceptance of a rotated-out key with a keyRotationPeriod (see Section 4.3); once no currently valid certificate depends on a given key's hashed URI, and any applicable keyRotationPeriod has elapsed, the CA MAY prune that key's thumbprint.¶

4.3. Account Key Rotation Period

A CA MAY advertise a keyRotationPeriod in the meta object of its directory ([RFC8555], Section 7.1.1). When present, its value MUST be a non-negative integer number of seconds. It bounds how long, after a public key ceases to be the current key of an ACME account (for example, because the account rotated to a new key per [RFC8555], Section 7.3.5), the CA continues to accept hashed URIs computed with that prior key.¶

After the period elapses, the CA MAY cease accepting the rotated-out key, subject to the precedence rules in Section 4.2: certificate-backed retention keeps a key acceptable while a currently valid certificate depends on it even after the period has elapsed, and account deactivation stops acceptance immediately even before the period elapses. A CA that does not advertise a keyRotationPeriod retains and accepts prior keys per the general retention guidance in Section 4.2.¶

The keyRotationPeriod gives domain owners an upper bound on how long a _validation-persist record computed with a since-rotated key remains usable, and gives CAs a defined point at which prior-key thumbprints may be pruned. Clients SHOULD republish _validation-persist records using the account's current key after a key rotation, and SHOULD do so before the CA's keyRotationPeriod elapses, so that validation does not lapse.¶

4.4. Multiple Issuer Support

A domain MAY authorize multiple Certificate Authorities (CAs) by provisioning a separate _validation-persist TXT record for each issuer. This allows domain owners to maintain relationships with multiple CAs simultaneously, enhancing flexibility and resilience.¶

_validation-persist.example.org. 3600 IN TXT ("ca1.example;"
" accounturi=https://ca1.example/account-hash/"
"sha-256/wjZNvLpIgf7zrr9KQo7zCLaG2Ea67KS4o4cAwSepsls;"
" policy=wildcard")
_validation-persist.example.org. 3600 IN TXT ("ca2.example;"
" accounturi=https://ca2.example/account-hash/"
"sha-256/Mpngr2LZCN9gPArggXqEu4pKtYZvLL5IxMStzyWrrXc;"
" persistUntil=1767225600")

4.5. Just-in-Time Validation

When processing a new authorization request, a CA MAY perform an immediate DNS lookup for _validation-persist TXT records at the Validation Domain Name corresponding to the requested domain identifier.¶

If one or more such records exist, the CA MUST evaluate them according to the requirements specified in Section 4.4. If at least one record meets all validation requirements, the CA MAY transition the authorization to the "valid" status without returning a "pending" challenge to the client. This mechanism is an optimization and does not alter the ACME state machine defined in [RFC8555]. The server internally transitions the authorization from "pending" through "processing" to "valid" instantaneously. From the client's perspective, it receives a "valid" authorization object directly in response to its creation request.¶

If no DNS TXT record meets the validation requirements, or if the records are absent, the CA MUST proceed with the standard authorization flow by returning a "pending" authorization with an associated dns-persist-01 challenge object.¶

CAs implementing Just-in-Time validation SHOULD rate-limit JIT DNS lookups per domain identifier, independent of the requesting account, to prevent amplification attacks where multiple accounts trigger excessive queries against a target domain. CAs SHOULD restrict JIT validation to accounts that have previously completed a successful dns-persist-01 validation. CAs implementing Just-in-Time validation SHOULD provide account activity notifications or logging, as this path eliminates the challenge-response interaction that might otherwise provide a detection window for account compromise.¶

This mechanism enables efficient reuse of persistent validation records while maintaining the security properties of the validation method.¶

4.6. Pre-Provisioning Records

Domain owners MAY provision _validation-persist TXT records before requesting any certificates, provided they can compute the accounturi value. When constructing records without a challenge object, the following values MUST be used:¶

• accounturi: The hashed URI, computed as specified in Section 4.1. A client knows its own ACME account URL (as returned in the Location header of the account creation response, [RFC8555], Section 7.3), the FQDN it is provisioning, and its current account key, so it can compute and publish the hashed URI itself from the CA's accountHashPrefix without a per-provisioning request to the CA. A client that wishes to reuse a single record across multiple domains MAY instead use the domain-omitted opt-out form (domain_name set to *, see Section 4.1).¶

• issuer-domain-name: A CA offering the dns-persist-01 challenge type advertises its Issuer Domain Names in the issuerDomainNames array of its directory meta object (see Section 3.2). Clients pre-provisioning records SHOULD use one of these values; a value obtained elsewhere is not guaranteed to appear in a later challenge and can leave the record unusable.¶

For a pre-provisioned record, the client computes the hashed accounturi itself, outside the ACME challenge-response flow, from its own ACME account URL, its current account key, and the CA's accountHashPrefix. The client obtains the accountHashPrefix from the CA's directory ([RFC8555], Section 7.1.1) and SHOULD retrieve the directory over an authenticated channel, so that the record is placed under the intended CA's infrastructure. Because the hashed URI cryptographically binds the account key (see Section 7.2.3), a record computed with the client's genuine account key cannot be made to validate for a different account; this key binding is what lets a domain owner safely pre-provision without the challenge-response exchange.¶

Organizations pre-provisioning records SHOULD maintain an inventory of _validation-persist records and the ACME accounts they reference. Records MAY include a persistUntil parameter to bound their effective lifetime (see Section 7.10). Domain owners SHOULD audit _validation-persist records after any DNS infrastructure security incident, as pre-provisioned records persist beyond the window of compromise.¶

CAs implementing dns-persist-01 SHOULD maintain a stable accountHashPrefix and stable account URLs for the lifetime of an account, and SHOULD document their stability guarantees, since the hashed URI is computed over the account URL and served under the prefix. If a CA must change its accountHashPrefix or account-URL structure, it SHOULD provide a transition period during which hashed URIs under both the old and new forms are accepted for validation.¶

5.1. Scope of policy=wildcard

When a DNS TXT record includes the policy=wildcard parameter value, it authorizes certificate issuance for:¶

1. The validated FQDN itself - The base domain for which the TXT record exists (e.g., example.com)¶

2. Wildcard certificates - Wildcard certificates for the validated FQDN or any of its subdomains (e.g., *.example.com, *.dept.example.com)¶

3. Specific subdomains - Any specific subdomain of the validated FQDN (e.g., www.example.com, app.example.com, server.dept.example.com)¶

For example, a TXT record at _validation-persist.example.com containing policy=wildcard can validate certificates for example.com, *.example.com, www.example.com, and any other subdomain of example.com.¶

If the policy parameter is absent, or if its value is anything other than wildcard, the validation applies only to the specific FQDN being validated. CAs MUST NOT consider such validation sufficient for wildcard certificates or subdomains.¶

6.1. Determining Permitted Subdomains

To determine which subdomains are permitted, the FQDN for which the persistent TXT record exists (referred to as the "validated FQDN") MUST be a proper suffix of the FQDN for which a certificate is requested (referred to as the "requested FQDN"). For wildcard certificate requests, the proper suffix check applies to the base domain name after removing the wildcard prefix (*.), consistent with [RFC8555], Section 7.1.3. The base-level wildcard (e.g., *.example.com where the validated FQDN is example.com) is authorized directly by Section 5 and is not subject to this proper suffix requirement.¶

For example, if dept.example.com is the validated FQDN, a certificate for server.dept.example.com is permitted because dept.example.com is its suffix. A certificate for *.server.dept.example.com is also permitted: after removing the wildcard prefix, server.dept.example.com has dept.example.com as a proper suffix.¶

6.2. Implementation Requirements

• The persistent DNS TXT record MUST include policy=wildcard for subdomain validation to be permitted.¶

• CAs MUST verify that the validated FQDN is a proper suffix of the requested FQDN. For wildcard requests, this check applies to the base domain after removing the *. prefix. The base-level wildcard is exempt per Section 5.¶

• If the policy parameter is absent or has any value other than wildcard, subdomain validation MUST NOT be permitted.¶

See Section 7.3 for important security implications of enabling subdomain validation.¶

6.3. Example: Subdomain Validation

For a persistent TXT record provisioned at _validation-persist.example.com with policy=wildcard:¶

• Permitted: example.com, www.example.com, app.example.com, server.dept.example.com, *.example.com, *.dept.example.com¶

• Not permitted without additional validation: otherexample.com, example.net¶

7.1. Persistent Record Risks

The persistence of validation records creates extended windows of vulnerability compared to traditional ACME challenge methods. If an attacker gains control of a DNS zone containing persistent validation records, they can potentially obtain certificates for the validated domains until the validation records are removed or modified.¶

Clients SHOULD protect validation records through appropriate DNS security measures, including:¶

• Using DNS providers with strong authentication and access controls¶

• Implementing DNS Security Extensions (DNSSEC) where possible¶

• Monitoring DNS zones for unauthorized changes¶

• Regularly reviewing and rotating validation records¶

7.2. Account Binding Security

The accounturi parameter provides strong binding between domain validation and the ACME account identified by the hashed URI. However, this binding depends on the security of the account itself.¶

The security of this method is fundamentally bound to the security of the ACME account's private key. Because the accounturi is a hashed URI computed in part over the account key (see Section 7.2.3), if this key is compromised, an attacker can immediately use any pre-existing dns-persist-01 authorizations associated with that account to issue certificates, without needing any further access to the domain's DNS infrastructure. This elevates the importance of secure key management for ACME clients far above that required for transient challenge methods, as the window of opportunity for an attacker is tied to the lifetime of the persistent authorization, not a momentary challenge.¶

CAs SHOULD implement robust account security measures, including:¶

• Strong authentication requirements for ACME accounts¶

• Account activity monitoring and anomaly detection¶

• Rapid account revocation capabilities¶

• Regular account security reviews¶

• Account key rotation policies and procedures¶

Clients SHOULD protect their ACME account keys with the same level of security as they would protect private keys for high-value certificates.¶

7.3. Subdomain Validation Risks

Enabling subdomain validation via policy=wildcard creates significant security implications. Organizations using this feature SHOULD carefully control subdomain delegation and monitor for unauthorized subdomains. This policy value serves as the explicit mechanism for domain owners to opt-in to broader validation scopes.¶

The ability to issue certificates for subdomains of validated FQDNs creates significant security risks, particularly in environments with subdomain delegation or where subdomains may be controlled by different entities.¶

Potential risks include:¶

• Subdomain takeover attacks where abandoned subdomains are claimed by attackers¶

• Unauthorized certificate issuance for subdomains controlled by different organizations¶

• Confusion about which entity has authority over specific subdomains¶

Organizations considering the use of subdomain validation SHOULD:¶

• Maintain strict control over subdomain delegation¶

• Implement monitoring for subdomain creation and changes¶

• Consider limiting subdomain validation to specific, controlled scenarios¶

• Provide clear governance policies for subdomain certificate authority¶

7.4. Cross-CA Validation Reuse

The persistent nature of validation records raises concerns about potential reuse across different Certificate Authorities. While the issuer-domain-name parameter is designed to prevent such reuse, implementations MUST validate that the issuer-domain-name in the DNS record matches the CA's disclosed Issuer Domain Name.¶

7.5. Record Tampering and Integrity

DNS records are generally not authenticated end-to-end, making them potentially vulnerable to tampering. CAs SHOULD implement additional integrity checks where possible and consider the overall security posture of the DNS infrastructure when relying on persistent validation records.¶

Additionally, CAs SHOULD protect their ACME directory URL with appropriate security measures. Using DNSSEC to protect the CA's ACME directory URL is RECOMMENDED. An attacker who compromises the DNS for a CA's ACME directory URL could disrupt validation or potentially impersonate the CA in certain scenarios. While this is a systemic DNS security risk that extends beyond this specification, it is amplified by any mechanism that relies on DNS for identity.¶

7.6. Issuer Domain Name Normalization and Limits

The issuerDomainNames field requires domain names to be provided in a normalized form (lowercase A-labels, no trailing dot) to prevent errors and security issues arising from case-sensitivity differences or Unicode homograph attacks. By requiring a canonical representation, servers and clients can perform simple byte-for-byte comparisons, ensuring interoperability and deterministic validation. The order of names in the array has no significance.¶

The server-side limit on the number of issuer domain names provided in a single challenge (e.g., 10) helps mitigate denial-of-service vectors where a client might be forced to perform an excessive number of DNS queries or a server might be burdened by validating against a large set of domains.¶

7.7. CAA Interaction

The dns-persist-01 validation method is a valid validationmethods parameter value for CAA records per [RFC8657]. Under [RFC8657], Section 3.1, a CAA accounturi for an ACME account is the URI of the ACME account object (the account URL); when the parameter is present, the CA matches that URI as part of CAA processing. The dns-persist-01 accounturi is instead the hashed URI defined in Section 4.1, which the CA matches by recomputing it while validating the _validation-persist record. These parameters occur in different DNS records and need not have the same value. They are independent reinforcing checks: both can restrict issuance, and the CA evaluates them separately.¶

7.8. DNS Security Measures

To enhance the security and integrity of the validation process, CAs and clients should consider implementing advanced DNS security measures.¶

7.9. Validation Data Reuse

This validation method is explicitly designed for persistence and reuse. The period for which a CA may rely on validation data is its Validation Data Reuse Period (as defined in Section 2), bounded by the CA's own policy, applicable root program requirements, and any persistUntil constraint on the record (Section 4.1). The DNS TTL of the _validation-persist record governs caching at the DNS layer only; it is not a validation data reuse limit, and a CA MUST NOT derive the effective validation data reuse period from the record's observed TTL.¶

CAs MAY reuse validation data obtained through this method for the duration of their Validation Data Reuse Period. CAs MUST also respect any persistUntil constraint as specified in Section 4.1. For a validation attempt that queries DNS, removing or changing the TXT record takes effect after resolver caches expire, as described in Section 7.11. Record removal does not invalidate previously obtained validation data before its allowed reuse period expires.¶

7.10. persistUntil Parameter Considerations

The persistUntil parameter provides domain owners with direct control over the validity period of their validation records. CAs and clients should be aware of the following considerations:¶

• Domain owners should set expiration dates for validation records that balance security and operational needs. To avoid unexpected validation failures during certificate renewal, domain owners are advised to:¶

  • Align persistUntil values with certificate lifetimes or planned maintenance intervals¶

  • Monitor or set reminders for persistUntil expirations¶

  • Document persistUntil practices in certificate management procedures¶

  • Automate updates to validation records with new persistUntil values during certificate renewal workflows¶

• CAs MUST parse and apply the persistUntil timestamp as specified in Section 4.1.¶

7.11. Revocation and Invalidation of Persistent Authorizations

The persistent nature of dns-persist-01 authorizations means that a valid DNS TXT record can grant control for an extended period, potentially even if the domain owner's intent changes or if the associated account key is compromised. Therefore, explicit mechanisms for revoking or invalidating these persistent authorizations are critical.¶

There are two primary revocation and invalidation actions:¶

1. Remove DNS record: Removing the corresponding DNS TXT record from the Validation Domain Name is the standard method for an Applicant to invalidate a dns-persist-01 authorization. After the record is removed and resolver caches have expired, new validation attempts for the domain will fail. This action is available to the domain owner and does not require CA involvement.¶

2. Deactivate ACME account: For situations requiring immediate revocation of issuance capability (e.g., suspected account key compromise), the account bound by the record can be deactivated as specified in [RFC8555], Section 7.3.6. Per the deactivation rule in Section 4.2, a CA MUST NOT accept a hashed URI computed from any key of a deactivated account; deactivation therefore takes effect immediately and overrides key retention, including the certificate-backed retention of a key that a currently valid certificate depends on. This makes account deactivation a full emergency measure that invalidates the record's utility without waiting for DNS caches to expire.¶

The following table summarizes the applicability and timing of these actions:¶

Independently of these actions, a CA MAY bound how long a record computed with a since-rotated key remains acceptable by advertising a keyRotationPeriod (see Section 4.3). This bounds acceptance over time but is a routine lifecycle limit, not an immediate revocation mechanism.¶

ACME Clients SHOULD provide clear mechanisms for users to:¶

• Remove the _validation-persist DNS TXT record.¶

• Monitor the presence and content of their _validation-persist records to ensure they accurately reflect desired authorization.¶

Certificate Authorities (CAs) implementing this method MUST:¶

• During a validation attempt, fail the validation if the corresponding DNS TXT record is no longer present or if its content does not meet the requirements of this specification (e.g., incorrect issuer-domain-name, missing accounturi, altered policy).¶

• Respect the persistUntil constraint as specified in Section 4.1, rejecting new validation attempts after the specified timestamp even if the record remains present.¶

• Ensure their internal systems are capable of efficiently handling the validation failure when DNS records are removed or become invalid.¶

While this method provides a persistent signal of control, the fundamental ACME authorization object (as defined in [RFC8555]) remains subject to its own lifecycle, including expiration. A persistent DNS record allows for repeated authorizations, but each authorization object issued by the CA will have a defined validity period, after which it expires unless renewed.¶

8.1. ACME Validation Methods Registry

IANA is requested to register the following entry in the "ACME Validation Methods" registry:¶

• Label: dns-persist-01¶

• Identifier Type: dns¶

• ACME: Y¶

• Reference: This document¶

8.2. Underscored and Globally Scoped DNS Node Names Registry

IANA is requested to register the following entry in the "Underscored and Globally Scoped DNS Node Names" registry defined in [RFC8552]:¶

• RR Type: TXT¶

• _NODE NAME: _validation-persist¶

• Reference: This document¶

8.3. ACME Directory Metadata Fields

IANA is requested to register the following entries in the "Fields in the 'meta' Object within a Directory Object" registry defined in [RFC8555], Section 9.7.6:¶

• Field Name: accountHashPrefix¶

• Field Type: string¶

• Reference: This document¶

• Field Name: keyRotationPeriod¶

• Field Type: integer¶

• Reference: This document¶

• Field Name: issuerDomainNames¶

• Field Type: array of string¶

• Reference: This document¶

9.1. DNS Record Size Considerations

The RDATA of the TXT record, which contains the issue-value, may become large, particularly if the accounturi is long. While the total size of a TXT record's RDATA can be up to 65,535 octets, it must be formatted as a sequence of one or more character-strings, where each string is limited to 255 octets in length.¶

CA Implementation Guidelines:¶

• CAs SHOULD endeavor to keep the accounturi values they generate reasonably concise to minimize the final record size.¶

Client Implementation Guidelines:¶

• Clients MUST properly handle the creation of TXT records where the RDATA exceeds 255 octets. As specified in [RFC1035], Section 3.3.14, clients MUST split the RDATA into multiple, concatenated, quote-enclosed strings, each no more than 255 octets. For example:¶

_validation-persist.example.com. IN TXT ("first-255-bytes..."
" ...remaining-bytes")

Failure to correctly format long RDATA values may result in validation failures.¶

9.2. Domain Name Normalization Algorithm

This section provides an algorithm for domain name normalization to promote interoperability. Both clients and servers SHOULD follow a consistent normalization process to ensure that domain names are handled uniformly.¶

The recommended normalization process consists of the following four steps, applied in order:¶

1. Case-folding: Apply Unicode-aware, locale-independent case-folding to the entire domain name string to convert it to lowercase.¶

2. Unicode Normalization: Normalize the string to Unicode Normalization Form C (NFC).¶

3. Punycode Conversion: Convert each label of the domain name to its A-label (Punycode) representation as specified in [RFC5890].¶

4. Trailing Dot Removal: Remove any trailing dot from the final string.¶

For example, a domain name like EXAMPLE.com. is normalized as follows:¶

1. After case-folding: example.com.¶

2. After NFC normalization: example.com.¶

3. After Punycode conversion: example.com.¶

4. After removing trailing dot: example.com¶

An internationalized domain name like üÑICODE-example.com. is normalized as follows:¶

1. After case-folding: ünicode-example.com.¶

2. After NFC normalization: ünicode-example.com.¶

3. After Punycode conversion: xn--nicode-example-9jb.com.¶

4. After removing trailing dot: xn--nicode-example-9jb.com¶

9.3. CA Implementation Guidelines

Certificate Authorities implementing this validation method should consider:¶

• Establishing clear policies for Issuer Domain Name disclosure in Certificate Policies and Certification Practice Statements¶

• Creating account security monitoring and incident response procedures¶

• Providing clear documentation for clients on proper record construction¶

9.4. Client Implementation Guidelines

ACME clients implementing this validation method should consider:¶

• Implementing secure DNS record management practices¶

• Providing clear user interfaces for managing persistent validation records¶

• Implementing validation record monitoring and alerting¶

• Designing appropriate error handling for validation failures¶

• Considering the security implications of persistent records in their threat models¶

Clients that manage or provision _validation-persist records SHOULD inspect their own local provisioning state (rather than relying on a DNS lookup) before initiating a new order, and SHOULD warn the operator if a record's persistUntil value has already expired or is likely to expire before validation completes. A client that skips this check risks initiating a validation attempt that the CA will reject with an unauthorized error (see Section 9.3) instead of reporting an actionable, locally diagnosed cause.¶

9.5. DNS Provider Considerations

DNS providers supporting this validation method should consider:¶

• Implementing appropriate access controls for validation record management¶

• Providing audit logging for validation record changes¶

• Considering dedicated interfaces or APIs for ACME validation record management¶

10.1. Basic Validation Example (FQDN Only)

For validation of "example.com" by a CA using "authority.example" as its Issuer Domain Name, where the validation should only apply to "example.com":¶

1. CA provides challenge object with a list of valid Issuer Domain Names:¶

   {
     "type": "dns-persist-01",
     "url": "https://ca.example/acme/authz/1234/0",
     "status": "pending",
     "issuerDomainNames": ["authority.example", "ca.example.net"]
   }
   

   ¶

2. Client chooses one of the provided Issuer Domain Names (e.g., "authority.example"), computes its hashed URI as shown in Section 10.2, and provisions a DNS TXT record (note the absence of a policy parameter for scope):¶

   _validation-persist.example.com. IN TXT ("authority.example;"
   " accounturi=https://ca.example/account-hash/"
   "sha-256/5SQm7n6tPh2-PlLbCKGnViTXX5z19SCN4cPGQHSk-kw")
   

   ¶

3. CA validates the record through DNS queries. This validation is sufficient only for "example.com".¶

10.2. Hashed-URI Example

This example validates "example.com" using a hashed URI (Section 4.1) and serves as a test vector. The hash inputs are:¶

• length_of_domain: 0x0b (the domain example.com is 11 octets)¶

• domain_name: example.com¶

• key: the 43 ASCII octets of NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs, the unpadded base64url encoding of the account's current SHA-256 JWK Thumbprint [RFC7638] (the example thumbprint from [RFC7638], Section 3.1)¶

• account_URL: https://ca.example/acct/123¶

Computing SHA-256(length_of_domain || domain_name || key || account_URL) and applying unpadded base64url encoding to the 32-octet digest yields:¶

5SQm7n6tPh2-PlLbCKGnViTXX5z19SCN4cPGQHSk-kw

With a CA accountHashPrefix of https://ca.example/account-hash/ and the sha-256 algorithm identifier, the hashed URI is https://ca.example/account-hash/sha-256/5SQm7n6tPh2-PlLbCKGnViTXX5z19SCN4cPGQHSk-kw. Using issuer domain name "authority.example", the client provisions:¶

_validation-persist.example.com. IN TXT ("authority.example;"
" accounturi=https://ca.example/account-hash/"
"sha-256/5SQm7n6tPh2-PlLbCKGnViTXX5z19SCN4cPGQHSk-kw")

To instead opt out of the domain-correlation mitigation (Section 4.1), the client sets domain_name to the single octet * (so length_of_domain is 0x01), keeping the same key and account_URL. Computing SHA-256(0x01 || "*" || key || account_URL) yields:¶

NpDnSwUthQK8zCgFdefYxAdAVPnygMLbs9US6oO-5ug

The resulting hashed URI, https://ca.example/account-hash/sha-256/NpDnSwUthQK8zCgFdefYxAdAVPnygMLbs9US6oO-5ug, does not depend on the domain and MAY be reused across domains.¶

10.3. Wildcard Validation Example

For validation of "*.example.com" (which also validates "example.com" and specific subdomains like "www.example.com") by a CA using "authority.example" as its Issuer Domain Name:¶

1. The CA provides a challenge object similar to the basic example, containing an issuerDomainNames array.¶

2. Client chooses one of the provided Issuer Domain Names (e.g., "authority.example") and provisions a DNS TXT record at the base domain's Validation Domain Name, including policy=wildcard:¶

   _validation-persist.example.com. IN TXT ("authority.example;"
   " accounturi=https://ca.example/account-hash/"
   "sha-256/5SQm7n6tPh2-PlLbCKGnViTXX5z19SCN4cPGQHSk-kw;"
   " policy=wildcard")
   

3. CA validates the record through DNS queries. This validation authorizes certificates for "example.com", "*.example.com", and specific subdomains like "www.example.com".¶

10.4. Validation Example with persistUntil

For validation of "example.com" with an explicit expiration date:¶

1. The CA provides a challenge object similar to the basic example, containing an issuerDomainNames array.¶

2. Client chooses one of the provided Issuer Domain Names (e.g., "authority.example") and provisions a DNS TXT record including persistUntil:¶

   _validation-persist.example.com. IN TXT ("authority.example;"
   " accounturi=https://ca.example/account-hash/"
   "sha-256/5SQm7n6tPh2-PlLbCKGnViTXX5z19SCN4cPGQHSk-kw;"
   " persistUntil=1721952000")
   

3. CA validates the record. This validation is sufficient only for "example.com" and will not be considered valid after the specified timestamp (2024-07-26T00:00:00Z).¶

10.5. Wildcard Validation Example with persistUntil

For validation of "*.example.com" with an explicit expiration date:¶

1. The CA provides a challenge object similar to the basic example, containing an issuerDomainNames array.¶

2. Client chooses one of the provided Issuer Domain Names (e.g., "authority.example") and provisions a DNS TXT record including policy=wildcard and persistUntil:¶

   _validation-persist.example.com. IN TXT ("authority.example;"
   " accounturi=https://ca.example/account-hash/"
   "sha-256/5SQm7n6tPh2-PlLbCKGnViTXX5z19SCN4cPGQHSk-kw;"
   " policy=wildcard;"
   " persistUntil=1721952000")
   

3. CA validates the record. This validation authorizes certificates for "example.com", "*.example.com", and specific subdomains, but will not be considered valid after the specified timestamp (2024-07-26T00:00:00Z).¶

11.1. Normative References

[FIPS180-4]

National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015, <https://doi.org/10.6028/NIST.FIPS.180-4>.

[RFC8555]

Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.

[RFC8659]

Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, <https://www.rfc-editor.org/info/rfc8659>.

[RFC8657]

Landau, H., "Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding", RFC 8657, DOI 10.17487/RFC8657, November 2019, <https://www.rfc-editor.org/info/rfc8657>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC5890]

Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.

[RFC6920]

Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[RFC1035]

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/info/rfc7638>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.

11.2. Informative References

[birgelee-sc082-security]

Birge-Lee, H., "Security of SC-082 Redux", 2025.

[cabf-br]

"Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates", 2025, <https://cabforum.org/baseline-requirements-documents/>.

[RFC4033]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.

Since draft-ietf-acme-dns-persist-01

• The accounturi is now a hashed URI that cryptographically binds the ACME account to the domain being validated. In -01 the accounturi was the ACME account URL, or another URI that uniquely and permanently identified a single account ([RFC8657], Section 5.4), with no cryptographic binding; that form is no longer accepted.¶

• Defined the hashed URI as <accountHashPrefix><hash-alg>/<base64url hash value>, advertised via the new accountHashPrefix directory metadata field and carrying an in-URI hash-algorithm identifier for algorithm agility (the registered sha-256 Hash Name String is mandatory).¶

• Specified the digest as H(length_of_domain || domain_name || key || account_URL), with a leading length octet delimiting the domain name.¶

• Added a mandatory domain-omitted opt-out (domain_name set to *) for correlation opt-out and cross-domain record reuse.¶

• Specified CA key retention as a data-retention obligation with ranked precedence (deactivation overrides certificate-backed retention overrides general retention); account deactivation is an immediate override.¶

• Added the keyRotationPeriod directory metadata field.¶

• Renamed the challenge object's plural field from issuer-domain-names to issuerDomainNames to align with ACME's camelCase convention ([RFC8555]); the singular DNS issuer-domain-name parameter and persistUntil are unchanged (#56).¶

• Clarified that key in the digest is the 43-octet unpadded base64url encoding of the SHA-256 JWK Thumbprint [RFC7638], not the 32 raw digest octets, matching the encoding already used in ACME key authorizations ([RFC8555], Section 8.1).¶

• Required sha-256 support in both clients and CAs for interoperability, moved <hash-alg> to the Hash Name String registry defined by [RFC6920], excluded truncated digests shorter than 256 bits, and removed the document-local slash-to-hyphen substitution rule.¶

• Clarified the relationship between the CAA accounturi and the dns-persist-01 accounturi in the Introduction and Section 7.7, citing [RFC8657], Section 3.1.¶

• Added a privacy caveat noting that a cleartext http-01 key authorization exposes the same account-key thumbprint used in the hashed URI, leaving account-URL entropy as the remaining protection.¶

• Added client-side guidance (Section 9.4) to check persistUntil against local provisioning state before initiating an order (#38).¶

• Removed DNS TTL as a validation data reuse limit; reuse remains subject to persistUntil and the CA's Validation Data Reuse Period. Renamed Section 7.9 accordingly and removed the related TTL-specific implementation guidance (#42).¶

• Corrected the stale Account Key Rotation text: the account URL is stable, but the hashed accounturi changes with the account key, and continued acceptance of a prior key is governed by Section 4.2.¶

• Added the required directory issuerDomainNames metadata field and the D ⊆ C consistency rule with the challenge object's issuerDomainNames; the C ⊆ I rule against caaIdentities applies when the CA advertises caaIdentities (#60).¶