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. Consideration of DNS TTL values when determining the effective validity period of an authorization, balancing persistence with responsiveness to DNS changes (see Section 7.8).¶

3. Explicit binding of the domain validation to a specific 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¶

• issuer-domain-names (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 issuer-domain-names 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",
  "issuer-domain-names": ["authority.example", "ca.example.net"]
}

4.1. 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/acme/acct/12345;"
" policy=wildcard")
_validation-persist.example.org. 3600 IN TXT ("ca2.example;"
" accounturi=https://ca2.example/acme/acct/67890;"
" persistUntil=1767225600")

4.2. 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 Authorization 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.1. 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.¶

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

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 - Certificates covering immediate subdomains (e.g., *.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 and MUST NOT be considered 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 appear as the exact suffix of the FQDN for which a certificate is requested (referred to as the "requested FQDN").¶

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.¶

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.¶

• 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 - 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 specific ACME accounts. However, this binding depends on the security of the ACME account itself.¶

The security of this method is fundamentally bound to the security of the ACME account's private key. 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 MUST 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 MUST:¶

• 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 carefully 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 MUST protect their issuer-domain-name with robust security measures. Using DNSSEC is a recommended mechanism for this purpose. An attacker who compromises the DNS for a CA's issuer-domain-name 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 issuer-domain-names 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. DNS Security Measures

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

7.8. Validation Data Reuse and TTL Handling

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). However, if the DNS TXT record's Time-to-Live (TTL) is shorter than this period, the CA MUST treat the record's TTL as the effective validation data reuse period for that specific validation.¶

CAs MAY reuse validation data obtained through this method for the duration of their validation data reuse period, subject to the TTL constraints described in this section. The persistUntil parameter indicates when the DNS validation record should no longer be considered valid for new validation attempts. If a persistUntil parameter is present in the DNS TXT record, the CA MUST NOT successfully complete a validation attempt after the date and time specified in that parameter. This restriction does not preclude reuse of data that has already been validated.¶

7.9. 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 properly parse and interpret the integer timestamp value as a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds) and apply the expiration correctly.¶

• CAs MUST reject or consider expired any validation record where the current time exceeds the persistUntil timestamp.¶

7.10. 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 ACME account key is compromised. Therefore, explicit mechanisms for revoking or invalidating these persistent authorizations are critical.¶

The primary method for an Applicant to invalidate a dns-persist-01 authorization for a domain is to remove the corresponding DNS TXT record from the Authorization Domain Name. After the record is removed, new validation attempts for the domain will fail. This behavior represents a deliberate design trade-off: any existing authorization obtained via this method will remain valid until it expires as per the CA's Validation Data Reuse Period. This persistence underscores the importance of protecting the ACME account key.¶

For situations requiring immediate revocation of issuance capability, such as a suspected account key compromise, the primary and most effective mechanism is to deactivate the ACME account as specified in [RFC8555], Section 7.5.2. Deactivating the account immediately and irrevocably prevents it from being used for any further certificate issuance.¶

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).¶

• Reject new validation attempts when the current time exceeds the timestamp specified in a persistUntil parameter, even if the DNS TXT record remains present and would otherwise satisfy all other validation requirements.¶

• 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¶

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, clients MUST split the RDATA into multiple, concatenated, quote-enclosed strings, each no more than 255 octets. For example:¶

~~~ dns _validation-persist.example.com. IN TXT ("first-part-of-long-string..." " ...second-part-of-long-string") ~~~¶

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

9.2. 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¶

• Developing procedures for handling validation record TTL variations¶

• Creating account security monitoring and incident response procedures¶

• Providing clear documentation for clients on proper record construction¶

9.3. 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¶

9.4. 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¶

• Supporting reasonable TTL values for validation records¶

• 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",
     "issuer-domain-names": ["authority.example", "ca.example.net"]
   }
   

   ¶

2. Client chooses one of the provided Issuer Domain Names (e.g., "authority.example") 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/acct/123")
   

   ¶

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

10.2. 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 issuer-domain-names 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 Authorization Domain Name, including policy=wildcard:¶

   _validation-persist.example.com. IN TXT ("authority.example;"
   " accounturi=https://ca.example/acct/123;"
   " 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.3. 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 issuer-domain-names 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/acct/123;"
   " 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.4. 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 issuer-domain-names 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/acct/123;"
   " 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

[RFC1035]

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

[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/rfc/rfc2119>.

[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/rfc/rfc5890>.

[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/rfc/rfc8174>.

[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/rfc/rfc8555>.

[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/rfc/rfc8657>.

[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/rfc/rfc8659>.

11.2. Informative References

[birgelee-sc082-security]

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

[draft-sheth-identifiers-dns]

Sheth, S. and A. Kaizer, "Best Practices for Persistent References in DNS", 22 April 2025, <https://datatracker.ietf.org/doc/draft-sheth-identifiers-dns/>.