]> Fastly

sheurich@fastly.com

Princeton University

birgelee@princeton.edu

Amazon Trust Services

slghtr@amazon.com

Security Automated Certificate Management Environment acme dns validation persistent This document specifies "dns-persist-01", a new validation method for the Automated Certificate Management Environment (ACME) protocol. This method allows a Certification Authority (CA) to verify control over a domain by confirming the presence of a persistent DNS TXT record containing CA and account identification information. This method is particularly suited for environments where traditional challenge methods are impractical, such as IoT deployments, multi-tenant platforms, and scenarios requiring batch certificate operations. The validation method is designed with a strong focus on security and robustness, incorporating widely adopted industry best practices for persistent domain control validation. This design aims to make it suitable for Certification Authorities operating under various policy environments, including those that align with the CA/Browser Forum Baseline Requirements. About This Document Status information for this document may be found at . Discussion of this document takes place on the Automated Certificate Management Environment Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Automated Certificate Management Environment (ACME) protocol defines mechanisms for automating certificate issuance and domain validation. The existing challenge methods, "http-01" and "dns-01", require real-time interaction between the ACME client and the domain's infrastructure during the validation process. While effective for many use cases, these methods present challenges in certain deployment scenarios. Examples include:

• Internet of Things (IoT) deployments where devices may not be able to host an HTTP service or coordinate DNS updates in real-time.
• Edge compute and multi-tenant hosting platforms where the entity managing the DNS zone is distinct from the tenant subscribing to the certificate.
• Organizations that wish to pre-validate domains and batch issuance operations offline or at a later time.
• Scenarios requiring wildcard certificates where domain control is proven once and reused over an extended period.
• Environments with strict change management processes where DNS modifications require approval workflows.

This document defines a new ACME challenge type, "dns-persist-01". This method proves control over a Fully Qualified Domain Name (FQDN) by confirming the presence of a persistent DNS TXT record containing CA and account identification information. The record format is based on the "issue-value" syntax from , incorporating an issuer-domain-name and a mandatory accounturi parameter that uniquely identifies the applicant's account. This design provides strong binding between the domain, the CA, and the specific account requesting validation.

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

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

DNS TXT Record Persistent DCV Domain Label

The label "_validation-persist" as specified in this document. This label is consistent with industry practices for persistent domain validation.

Authorization Domain Name

The domain name at which the validation TXT record is provisioned. It is formed by prepending the DNS TXT Record Persistent DCV Domain Label to the FQDN being validated.

Issuer Domain Name

A domain name disclosed by the CA in Section 4.2 of the CA's Certificate Policy and/or Certification Practices Statement to identify the CA for the purposes of this validation method. Note: The issuer-domain-names provided in the challenge object SHOULD be drawn from the machine-readable caaIdentities array in the ACME server's directory object, as specified in , Section 9.7.6. This creates a clearer programmatic link between the server's advertised identities and the challenge object.

Validation Data Reuse Period

The period during which a CA may rely on validation data, as defined by the CA's practices and applicable requirements.

persistUntil

An optional parameter in the validation record that specifies the timestamp after which the validation record should no longer be considered valid by CAs. The value MUST be a base-10 encoded integer representing a UNIX timestamp in UTC (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds).

The "dns-persist-01" Challenge The "dns-persist-01" challenge allows an ACME client to demonstrate control over an FQDN by proving it can provision a DNS TXT record containing specific, persistent validation information. The validation information links the FQDN to both the Certificate Authority performing the validation and the specific ACME account requesting the validation. When an ACME client accepts a "dns-persist-01" challenge, it proves control by provisioning a DNS TXT record at the Authorization Domain Name. Unlike the existing "dns-01" challenge, this record is designed to persist and may be reused for multiple certificate issuances over an extended period.

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, ).
  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:

Example dns-persist-01 Challenge Object

Challenge Response and Verification To respond to the challenge, the ACME client provisions a DNS TXT record for the Authorization Domain Name being validated. The Authorization Domain Name is formed by prepending the label "_validation-persist" to the domain name being validated. For example, if the domain being validated is "example.com", the Authorization Domain Name would be "_validation-persist.example.com". The RDATA of this TXT record MUST fulfill the following requirements:

1. The RDATA value MUST conform to the issue-value syntax as defined in , Section 4.
2. The issuer-domain-name portion of the issue-value MUST be one of the Issuer Domain Names provided by the CA in the issuer-domain-names array of the challenge object.
3. The issue-value MUST contain an accounturi parameter. The value of this parameter MUST be a unique URI identifying the account of the applicant which requested the validation, constructed according to , Section 3.
4. The issue-value MAY contain a policy parameter. If present, this parameter modifies the validation scope. The policy parameter follows the key=value syntax. The policy parameter key and its defined values MUST be treated as case-insensitive. CAs MUST ignore any unknown parameter keys. 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 and .
   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). CAs MUST NOT consider this validation record valid for new validation attempts after the specified timestamp. However, this does not affect the reuse of already-validated data.

For example, if the ACME client is requesting validation for the FQDN "example.com" from a CA that uses "authority.example" as its Issuer Domain Name, and the client's account URI is "https://ca.example/acct/123", it might provision: The ACME server verifies the challenge by performing a DNS lookup for TXT records at the Authorization 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 issuer-domain-names array from the challenge object, and it must contain a valid accounturi for the requesting account. When comparing issuer domain names, the server MUST adhere to the normalization rules specified in . The server also interprets any policy parameter values according to this specification.

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.

Coexistence of Records When multiple TXT records are present at the same DNS label (e.g., _validation-persist.example.com), each record functions as an independent authorization for the specified issuer. This follows a similar pattern to CAA records , where multiple records at the same label are permissible.

CA Verification Process When a CA performs validation for a domain with multiple _validation-persist TXT records, it MUST follow these steps:

1. Query DNS: Retrieve all TXT records from the Authorization Domain Name.
2. Filter Records: Iterate through the returned records to find one where the issuer-domain-name value matches one of the Issuer Domain Names the CA is configured to use for this validation. The CA MUST ignore all other records.
3. Validate Record: If a matching record is found, the CA proceeds to validate it according to the requirements in this specification, including verifying the accounturi and persistUntil parameters.
4. Handle No Match: If no record with a matching issuer-domain-name is found, the validation attempt MUST fail.

Security and Management Considerations When authorizing multiple issuers, domain owners MUST consider the following:

Auditing

Regularly audit DNS records to ensure that only intended CAs remain authorized. Remove records for CAs that are no longer in use.

Independent Security

Each authorized CA operates independently. The compromise of one CA's systems does not directly affect the security of other authorized CAs.

Weakest Link

The domain's overall security posture is influenced by the security practices of all authorized CAs. Domain owners should consider the practices of each CA they authorize.

Authorization Removal

To de-authorize a CA, the corresponding TXT record MUST be deleted from the DNS zone.

Example: Authorizing Two CAs This example demonstrates how a domain owner can authorize two different CAs, "ca1.example" and "ca2.example", to issue certificates for example.org. DNS Configuration: Verification Flow for CA1:

1. CA1 queries for TXT records at _validation-persist.example.org.
2. It receives both records.
3. It filters for the record where issuer-domain-name is "ca1.example".
4. It validates the request using this record, noting the policy=wildcard authorization.
5. The second record for "ca2.example" is ignored.

Verification Flow for CA2:

1. CA2 queries for TXT records at _validation-persist.example.org.
2. It receives both records.
3. It filters for the record where issuer-domain-name is "ca2.example".
4. It validates the request using this record, noting the persistUntil constraint.
5. The first record for "ca1.example" is ignored.

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

Wildcard and Subdomain Certificate Validation This validation method supports validation for wildcard certificates (e.g., *.example.com) and specific subdomains through the use of the policy=wildcard parameter.

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.

Subdomain Certificate Validation When the policy=wildcard parameter is present (as described in ), CAs MAY issue certificates for subdomains of the validated FQDN. This section describes the implementation details for subdomain validation.

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.

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 for important security implications of enabling subdomain validation.

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

Security Considerations

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

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.

Account Key Rotation The accounturi parameter is a stable identifier for the ACME account that persists across key rotations. When a client rotates their account key following the procedures defined in , Section 7.3.5, the accounturi remains unchanged. Therefore, existing DNS TXT records containing the accounturi parameter do not require modification when performing account key rotations.

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

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.

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.

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.

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

DNSSEC DNS Security Extensions (DNSSEC) provide cryptographic authentication of DNS data. This is a critical security measure that ensures the validation records retrieved by a CA are authentic and have not been tampered with. For CAs operating within the public WebPKI, the use of DNSSEC is a vital best practice for ensuring the integrity of domain validation. For private or closed PKI environments, DNSSEC is strongly recommended but may not be required, depending on the trust model and risk profile of the specific deployment.

Multi-Perspective Validation Multi-Perspective Issuance Corroboration (MPIC) is a technique to validate domain control from multiple network vantage points. This is a critical defense against localized network attacks, such as BGP hijacking and DNS spoofing, which could otherwise lead to certificate mis-issuance. For CAs subject to requirements like the CA/Browser Forum Baseline Requirements, MPIC is essential for robust domain validation. However, for private PKI systems where the network topology is well-known and such localized attacks are not part of the threat model, MPIC may be considered optional.

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

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.

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

IANA Considerations

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

Implementation Considerations

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

Domain Name Normalization Algorithm This section provides a non-normative 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 .
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

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

Error Handling When implementing the "dns-persist-01" validation method, Certificate Authorities SHOULD return appropriate ACME error codes to provide clear feedback on validation failures. Specifically:

• CAs SHOULD return a malformed error (as defined in ) when the TXT record has invalid syntax, such as duplicate parameters, invalid timestamp format in the persistUntil parameter, missing mandatory accounturi parameter, or other syntactic violations of the record format specified in this document.
• CAs SHOULD return an unauthorized error (as defined in ) when validation fails due to authorization issues, including:
  • The accounturi parameter in the DNS TXT record does not match the URI of the ACME account making the request
  • The persistUntil timestamp has expired, indicating that the validation record is no longer considered valid for new validation attempts
  • The issuer-domain-name in the DNS TXT record does not match any of the values provided in the issuer-domain-names array of the challenge object

Note that these error codes apply to validation attempts on specific challenges. In the case of Just-in-Time Validation (see ), when a CA finds a pre-existing DNS TXT record that does not meet validation requirements, the CA proceeds with the standard authorization flow by issuing a new pending challenge rather than returning an error. These error codes help ACME clients distinguish between different types of validation failures and take appropriate corrective actions.

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

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

Examples

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:
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):
3. CA validates the record through DNS queries. This validation is sufficient only for "example.com".

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:
3. CA validates the record through DNS queries. This validation authorizes certificates for "example.com", "*.example.com", and specific subdomains like "www.example.com".

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

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

References Normative References Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs. This document obsoletes RFC 6844. The Certification Authority Authorization (CAA) DNS record allows a domain to communicate an issuance policy to Certification Authorities (CAs) but only allows a domain to define a policy with CA-level granularity. However, the CAA specification (RFC 8659) also provides facilities for an extension to admit a more granular, CA-specific policy. This specification defines two such parameters: one allowing specific accounts of a CA to be identified by URIs and one allowing specific methods of domain control validation as defined by the Automatic Certificate Management Environment (ACME) protocol to be required. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. Informative References Verisign Labs Verisign Labs Princeton University

Acknowledgments The authors acknowledge prior community work that directly informed this specification:

• The CA/Browser Forum ballot proposals to enable persistent / static DNS Domain Control Validation signals in the Baseline Requirements, in particular Ballot SC-082 ("Clarify CA Assisted DNS Validation under 3.2.2.4.7", authored by Michael Slaughter) and the active proposal SC-088 ("DNS TXT Record with Persistent Value DCV Method", GitHub PR #608, also authored by Michael Slaughter). These efforts provided the policy framing and initial industry discussion motivating standardization of a reusable ACME DNS validation record.
• The formal and empirical security analysis of static / persistent DCV methods performed by Henry Birge-Lee ("Proof of static DCV security" presentation, the "Security of SC-082 Redux" paper , and related research), which helped clarify the threat model and informed the security considerations in this document.
• The Delegated DNS Domain Validation (DDDV) Threat Modeling Tiger Team discussions and document ("Validation SC - Delegated DNS Domain Validation (DDDV) Threat Model"), whose participants contributed to broad threat enumeration; notable contributors include Michael Slaughter (Amazon Trust Services), Corey Bonnell (DigiCert), Clint Wilson (Apple), and Martijn Katerbarg (Sectigo).

The authors also thank members of the ACME Working Group and CA/Browser Forum who provided early review, critique, and operational perspectives on persistent validation records. Any errors or omissions are the responsibility of the authors.