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. Mandatory multi-perspective validation by the Certificate Authority, enhancing resilience against localized DNS attacks and ensuring global visibility of the record (see Section 4.1).¶

3. Consideration of DNS TTL values when determining the effective validity period of an authorization, balancing persistence with responsiveness to DNS changes (see Section 4.2).¶

4. 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 (see Section 4.1).¶

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-name (required, string): The Issuer Domain Name that the client MUST include in the DNS TXT record¶

Example challenge object:¶

{
  "type": "dns-persist-01",
  "url": "https://ca.example/acme/authz/1234/0",
  "status": "pending",
  "issuer-domain-name": "authority.example"
}

4.1. Multi-Perspective Validation

CAs performing validations using the "dns-persist-01" method MUST implement Multi-Perspective Issuance Corroboration. To count as corroborating, a Network Perspective MUST observe the same challenge information as the Primary Network Perspective.¶

4.2. 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 adjust the effective validation data reuse period for that specific validation. In such cases, the effective validation data reuse period SHALL be the greater of: (a) the DNS TXT record's TTL, or (b) 8 hours.¶

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

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=specific-subdomains-only or policy=wildcard-allowed creates significant security implications. Organizations using this feature MUST carefully control subdomain delegation and monitor for unauthorized subdomains. These policy values serve 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 (such as DNSSEC). 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. 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. Once the record is removed, the CA, upon subsequent validation attempts or periodic re-checks, will no longer find the required information, and the authorization will cease to be valid after the expiration of its effective Validation Data Reuse Period.¶

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

• Periodically re-check active dns-persist-01 authorizations to confirm the continued presence and validity of the DNS TXT record. The frequency of these re-checks SHOULD be at least as often as the effective Validation Data Reuse Period for that specific validation (as determined per Section 4.2), and MUST occur no less frequently than every 8 hours to promptly detect and act upon record removal or modification.¶

• Invalidate an authorization 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).¶

• Ensure their internal systems are capable of efficiently handling the invalidation of authorizations 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. 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¶

• Implementing robust multi-perspective validation infrastructure¶

• 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.2. 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.3. 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:¶

{
  "type": "dns-persist-01",
  "url": "https://ca.example/acme/authz/1234/0",
  "status": "pending",
  "issuer-domain-name": "authority.example"
}

1. Client provisions 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"

1. CA validates the record through multi-perspective DNS queries. This validation is sufficient only for "example.com".¶

10.2. Specific Subdomain Validation Example

For validation of "example.com" and its specific subdomains (e.g., "www.example.com", "api.example.com"), but NOT for "*.example.com", by a CA using "authority.example":¶

1. Same challenge object format as above.¶

2. Client provisions DNS TXT record including policy=specific-subdomains-only:¶

_validation-persist.example.com. IN TXT "authority.example; accounturi=https://ca.example/acct/123; policy=specific-subdomains-only"

1. CA validates the record. This validation authorizes certificates for "example.com" and specific subdomains like "www.example.com", but not for "*.example.com".¶

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. Same challenge object format as above.¶

2. Client provisions DNS TXT record at the base domain's Authorization Domain Name, including policy=wildcard-allowed:¶

_validation-persist.example.com. IN TXT "authority.example; accounturi=https://ca.example/acct/123; policy=wildcard-allowed"

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

11.1. Normative References

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

[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

[CABF-BR]

CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates", 2024, <https://cabforum.org/baseline-requirements-documents/>.