Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation
draft-ietf-acme-dns-persist-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Shiloh Heurich , Henry Birge-Lee , Michael Slaughter | ||
| Last updated | 2025-12-02 (Latest revision 2025-11-03) | ||
| Replaces | draft-sheurich-acme-dns-persist | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-acme-dns-persist-00
Automated Certificate Management Environment S. Heurich
Internet-Draft Fastly
Intended status: Standards Track H. Birge-Lee
Expires: 7 May 2026 Crosslayer Labs, Inc.
M. Slaughter
Amazon Trust Services
3 November 2025
Automated Certificate Management Environment (ACME) Challenge for
Persistent DNS TXT Record Validation
draft-ietf-acme-dns-persist-00
Abstract
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
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist/.
Discussion of this document takes place on the Automated Certificate
Management Environment Working Group mailing list
(mailto:acme@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/acme/. Subscribe at
https://www.ietf.org/mailman/listinfo/acme/.
Source for this draft and an issue tracker can be found at
https://github.com/sheurich/draft-sheurich-acme-dns-persist.
Heurich, et al. Expires 7 May 2026 [Page 1]
Internet-Draft ACME Persistent DNS Challenge November 2025
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 May 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Robustness and Alignment with Industry Best Practices . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. The "dns-persist-01" Challenge . . . . . . . . . . . . . . . 6
3.1. Challenge Object . . . . . . . . . . . . . . . . . . . . 6
4. Challenge Response and Verification . . . . . . . . . . . . . 7
4.1. Multiple Issuer Support . . . . . . . . . . . . . . . . . 9
4.1.1. Coexistence of Records . . . . . . . . . . . . . . . 9
4.1.2. CA Verification Process . . . . . . . . . . . . . . . 9
4.1.3. Security and Management Considerations . . . . . . . 10
4.1.4. Example: Authorizing Two CAs . . . . . . . . . . . . 10
4.2. Just-in-Time Validation . . . . . . . . . . . . . . . . . 11
5. Wildcard and Subdomain Certificate Validation . . . . . . . . 12
5.1. Scope of policy=wildcard . . . . . . . . . . . . . . . . 12
6. Subdomain Certificate Validation . . . . . . . . . . . . . . 12
Heurich, et al. Expires 7 May 2026 [Page 2]
Internet-Draft ACME Persistent DNS Challenge November 2025
6.1. Determining Permitted Subdomains . . . . . . . . . . . . 12
6.2. Implementation Requirements . . . . . . . . . . . . . . . 13
6.3. Example: Subdomain Validation . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Persistent Record Risks . . . . . . . . . . . . . . . . . 13
7.2. Account Binding Security . . . . . . . . . . . . . . . . 14
7.2.1. Account Key Rotation . . . . . . . . . . . . . . . . 14
7.3. Subdomain Validation Risks . . . . . . . . . . . . . . . 15
7.4. Cross-CA Validation Reuse . . . . . . . . . . . . . . . . 15
7.5. Record Tampering and Integrity . . . . . . . . . . . . . 16
7.6. Issuer Domain Name Normalization and Limits . . . . . . . 16
7.7. DNS Security Measures . . . . . . . . . . . . . . . . . . 16
7.7.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 16
7.7.2. Multi-Perspective Validation . . . . . . . . . . . . 17
7.8. Validation Data Reuse and TTL Handling . . . . . . . . . 17
7.9. persistUntil Parameter Considerations . . . . . . . . . . 17
7.10. Revocation and Invalidation of Persistent
Authorizations . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. ACME Validation Methods Registry . . . . . . . . . . . . 19
9. Implementation Considerations . . . . . . . . . . . . . . . . 19
9.1. DNS Record Size Considerations . . . . . . . . . . . . . 20
9.1.1. Domain Name Normalization Algorithm . . . . . . . . . 20
9.2. CA Implementation Guidelines . . . . . . . . . . . . . . 21
9.2.1. Error Handling . . . . . . . . . . . . . . . . . . . 21
9.3. Client Implementation Guidelines . . . . . . . . . . . . 22
9.4. DNS Provider Considerations . . . . . . . . . . . . . . . 22
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Basic Validation Example (FQDN Only) . . . . . . . . . . 23
10.2. Wildcard Validation Example . . . . . . . . . . . . . . 23
10.3. Validation Example with persistUntil . . . . . . . . . . 24
10.4. Wildcard Validation Example with persistUntil . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
The Automated Certificate Management Environment (ACME) protocol
[RFC8555] 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.
Heurich, et al. Expires 7 May 2026 [Page 3]
Internet-Draft ACME Persistent DNS Challenge November 2025
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
[RFC8659], incorporating an issuer-domain-name and a mandatory
accounturi parameter [RFC8657] that uniquely identifies the
applicant's account. This design provides strong binding between the
domain, the CA, and the specific account requesting 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).
Heurich, et al. Expires 7 May 2026 [Page 4]
Internet-Draft ACME Persistent DNS Challenge November 2025
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.
2. 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 [RFC2119] [RFC8174] 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 MAY
be drawn from the machine-readable caaIdentities array in the ACME
server's directory object, as specified in [RFC8555],
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).
Heurich, et al. Expires 7 May 2026 [Page 5]
Internet-Draft ACME Persistent DNS Challenge November 2025
3. 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.
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.
Heurich, et al. Expires 7 May 2026 [Page 6]
Internet-Draft ACME Persistent DNS Challenge November 2025
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"]
}
Figure 1: Example dns-persist-01 Challenge Object
4. 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 defined in
[RFC8659], Section 4. 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 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 [RFC8657], Section 3.
Heurich, et al. Expires 7 May 2026 [Page 7]
Internet-Draft ACME Persistent DNS Challenge November 2025
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]. The parameter's
'tag' and its defined values MUST be treated as case-insensitive.
Note: This requirement ensures forward compatibility, allowing
future extensions without breaking existing implementations,
consistent with ACME's extensibility model (RFC 8555,
Section 7.3). The explicit requirement is necessary to ensure
consistent behavior across implementations; without it, some CAs
might reject unknown parameters, 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). 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:
_validation-persist.example.com. IN TXT ("authority.example;"
" accounturi=https://ca.example/acct/123")
Figure 2: Basic Validation TXT Record
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
Heurich, et al. Expires 7 May 2026 [Page 8]
Internet-Draft ACME Persistent DNS Challenge November 2025
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 Section 3.1. The server also
interprets any policy parameter values according to this
specification.
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.
4.1.1. 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 [RFC8659], where multiple records at
the same label are permissible.
4.1.2. 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.
Heurich, et al. Expires 7 May 2026 [Page 9]
Internet-Draft ACME Persistent DNS Challenge November 2025
4.1.3. 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.
4.1.4. 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:*
_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")
Figure 3: Multiple CA Authorization Records
*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.
Heurich, et al. Expires 7 May 2026 [Page 10]
Internet-Draft ACME Persistent DNS Challenge November 2025
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.
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.
Heurich, et al. Expires 7 May 2026 [Page 11]
Internet-Draft ACME Persistent DNS Challenge November 2025
5. 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.
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. Subdomain Certificate Validation
When the policy=wildcard parameter is present (as described in
Section 5), CAs MAY issue certificates for subdomains of the
validated FQDN. This section describes the implementation details
for subdomain validation.
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").
Heurich, et al. Expires 7 May 2026 [Page 12]
Internet-Draft ACME Persistent DNS Challenge November 2025
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. Security Considerations
The requirement for CAs to ignore unknown parameter tags means that
future extensions must be carefully designed to ensure that being
ignored does not create security vulnerabilities. Extensions that
require strict enforcement should use alternative mechanisms, such as
separate record types or explicit version negotiation.
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
Heurich, et al. Expires 7 May 2026 [Page 13]
Internet-Draft ACME Persistent DNS Challenge November 2025
* 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.2.1. 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 [RFC8555],
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.
Heurich, et al. Expires 7 May 2026 [Page 14]
Internet-Draft ACME Persistent DNS Challenge November 2025
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.
Heurich, et al. Expires 7 May 2026 [Page 15]
Internet-Draft ACME Persistent DNS Challenge November 2025
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 to protect the CA's issuer-domain-
name 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.7.1. DNSSEC
DNS Security Extensions (DNSSEC) provide cryptographic authentication
of DNS data, ensuring that the validation records retrieved by a CA
are authentic and have not been tampered with. To ensure the
integrity of the validation process, DNSSEC signatures SHOULD be
validated on dns-persist-01 TXT records.
Heurich, et al. Expires 7 May 2026 [Page 16]
Internet-Draft ACME Persistent DNS Challenge November 2025
7.7.2. 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.
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
Heurich, et al. Expires 7 May 2026 [Page 17]
Internet-Draft ACME Persistent DNS Challenge November 2025
- 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:
Heurich, et al. Expires 7 May 2026 [Page 18]
Internet-Draft ACME Persistent DNS Challenge November 2025
* 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. IANA Considerations
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. Implementation Considerations
When designing future extensions to this specification, new
parameters SHOULD be designed to degrade gracefully when ignored by
CAs that do not recognize them. Parameters that fundamentally change
the security properties of the validation SHOULD NOT be introduced
without a version negotiation mechanism.
Heurich, et al. Expires 7 May 2026 [Page 19]
Internet-Draft ACME Persistent DNS Challenge November 2025
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")
~~~
{: #ex-long-txt-record title="Multi-String TXT Record Format"}
Failure to correctly format long RDATA values may result in
validation failures.
9.1.1. 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 [RFC5890].
Heurich, et al. Expires 7 May 2026 [Page 20]
Internet-Draft ACME Persistent DNS Challenge November 2025
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.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.2.1. 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 [RFC8555]) 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 [RFC8555])
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
Heurich, et al. Expires 7 May 2026 [Page 21]
Internet-Draft ACME Persistent DNS Challenge November 2025
- 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
Section 4.2), 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.
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
Heurich, et al. Expires 7 May 2026 [Page 22]
Internet-Draft ACME Persistent DNS Challenge November 2025
10. Examples
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")
Figure 4: Wildcard Policy Validation Record
Heurich, et al. Expires 7 May 2026 [Page 23]
Internet-Draft ACME Persistent DNS Challenge November 2025
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")
Figure 5: Validation Record with Expiration Time
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")
Figure 6: Wildcard Validation Record with Expiration Time
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).
Heurich, et al. Expires 7 May 2026 [Page 24]
Internet-Draft ACME Persistent DNS Challenge November 2025
11. References
11.1. Normative References
[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>.
[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>.
11.2. Informative References
[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/>.
[birgelee-sc082-security]
Birge-Lee, H., "Security of SC-082 Redux", 2025.
Heurich, et al. Expires 7 May 2026 [Page 25]
Internet-Draft ACME Persistent DNS Challenge November 2025
[cabf-br] "Baseline Requirements for the Issuance and Management of
Publicly-Trusted TLS Server Certificates", 2025,
<https://cabforum.org/baseline-requirements-documents/>.
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 [cabf-br], 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", 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
[birgelee-sc082-security], 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.
Authors' Addresses
Shiloh Heurich
Fastly
Email: sheurich@fastly.com
Henry Birge-Lee
Crosslayer Labs, Inc.
Heurich, et al. Expires 7 May 2026 [Page 26]
Internet-Draft ACME Persistent DNS Challenge November 2025
Email: henry@crosslayerlabs.com
Michael Slaughter
Amazon Trust Services
Email: slghtr@amazon.com
Heurich, et al. Expires 7 May 2026 [Page 27]