]> Brave Software

shivankaulsahib@gmail.com

Salesforce

shuque@gmail.com

Akamai Technologies

erik+ietf@nygren.org

Cox Communications

tjw.ietf@gmail.com

Internet-Draft describes best practices for using the DNS to verify ownership or control of a domain, a process generally referred to as "Domain Control Validation". This document is a companion survey that catalogs the DNS-based Domain Control Validation techniques in use today across a range of Application Service Providers and protocols. Discussion Venues Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (dnsop@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Application Service Providers often need domain owners to prove control of a DNS domain before providing a service, such as a Certification Authority (CA) issuing a TLS certificate. DNS-based methods typically ask the requester to publish one or more DNS records, with content and placement specified by the Application Service Provider, that the provider can then query for. This document surveys such DNS-based Domain Control Validation techniques in use today, cataloging the record types (primarily TXT and CNAME), naming conventions, and token placement drawn from the publicly documented behavior of a range of Application Service Providers and protocols. It makes no recommendations; see for best practices.

Conventions and Definitions This document uses the terminology defined in the "Conventions and Definitions" section of , including "Application Service Provider", "DNS Administrator", "User", "Unique Token", and "Validation Record".

TXT based A TXT record is usually the default option for domain control validation. The Application Service Provider asks the User to add a DNS TXT record (perhaps through their domain host or DNS provider) at the domain with a certain value. Then the Application Service Provider does a DNS TXT query for the domain being verified and checks that the correct value is present. For example, this is what a DNS TXT record could look like for an Application Service Provider Service: Here, the value "237943648324687364" serves as the randomly-generated TXT value being added to prove ownership of the domain to Service Application Service Provider. Note that in this construction Application Service Provider Service would have to query for all TXT records at "example.com" to get the Validation Record. Although the original DNS protocol specifications did not associate any semantics with the DNS TXT record, describes how to use them to store attributes in the form of ASCII text key-value pairs for a particular domain. In practice, there is wide variation in the content of DNS TXT records used for domain control validation, and they often do not follow the key-value pair model. Even so, the RDATA portion of the DNS TXT record has to contain the value being used to verify the domain. The value is usually a Unique Token in order to guarantee that the entity who requested that the domain be verified (i.e., the person managing the account at Application Service Provider Service) is the one who has (direct or delegated) access to DNS records for the domain. After a TXT record has been added, the Application Service Provider will usually take some time to verify that the DNS TXT record with the expected token exists for the domain. The generated token typically expires in a few days. Some Application Service Providers use a prefix of _PROVIDER_NAME-challenge in the Name field of the TXT record challenge. For ACME, the full Host is _acme-challenge.<YOUR_DOMAIN>. Such patterns are useful for doing targeted domain control validation. The ACME protocol () has a challenge type DNS-01 that lets a User prove domain ownership. In this challenge, an implementing CA asks you to create a TXT record with a randomly-generated token at _acme-challenge.<YOUR_DOMAIN>: (Section 8.4) places requirements on the Unique Token.

Let's Encrypt The ACME example is implemented by Let's Encrypt .

Google Workspace Google Workspace asks the User to sign in with their administrative account and obtain their token as part of the setup process for Google Workspace. The verification token is a 68-character string that begins with "google-site-verification=", followed by 43 characters. Google recommends a TTL of 3600 seconds. The owner name of the TXT record is the domain or subdomain name being verified.

The AT Protocol The Authenticated Transfer (AT) Protocol supports DNS TXT records for resolving social media "handles" (human-readable identifiers) to the User's persistent account identifier . For example, this is how the handle bsky.app would be resolved:

GitHub To verify domains for organizations, GitHub asks the User to create a DNS TXT record under _github-challenge-ORGANIZATION.<YOUR_DOMAIN>, where ORGANIZATION stands for the GitHub organization name. The RDATA value for the provided TXT record is a string that expires in 7 days .

Public Suffix List The Public Suffix List asks owners of private domains to authenticate by creating a TXT record containing the pull request URL for adding the domain to the Public Suffix List. For example, to authenticate "example.com" submitted under pull request 100, a requestor would add:

CNAME based

CNAME for Domain Control Validation

DocuSign DocuSign asks the User to add a CNAME record with the "Host Name" set to be a 32-digit random value pointing to verifydomain.docusign.net..

Google Workspace CNAME Google Workspace lets you specify a CNAME record for verifying domain ownership. The User gets a unique 12-character string that is added as "Host", with TTL 3600 (or default) and Destination an 86-character string beginning with "gv-" and ending with ".domainverify.googlehosted.com.".

Delegated Domain Control Validation

Content Delivery Networks (CDNs) In order to be issued a TLS cert from a Certification Authority like Let's Encrypt, the requester needs to prove that they control the domain. Often this is done via the DNS-01 challenge . Let's Encrypt only issues certs with a 90 day validity period for security reasons . This means that after 90 days, the DNS-01 challenge has to be re-done and the Unique Token has to be replaced with a new one. Doing this manually is error-prone. Content Delivery Networks offer to automate this process using a CNAME record in the User's DNS that points to the Validation Record in the CDN's zone.

AWS Certificate Manager (ACM) AWS Certificate Manager allows delegated domain control validation. The record name for the CNAME looks like: .example.com. IN CNAME _.acm-validations.aws. ]]> The CNAME points to: .acm-validations.aws. IN TXT "" ]]> Here, the random tokens are used for the following:

• <random-token1>: Unique sub-domain, so there are no clashes when looking up the Validation Record.
• <random-token2>: Proves to ACM that the requester controls the DNS for the requested domain at the time the CNAME is created.
• <random-token3>: The actual token being verified.

Note that if there are more than 5 CNAMEs being chained, then this method does not work.

Akamai Akamai uses a CNAME record:

DigiCert DigiCert is switching to use a static prefix _dnsauth CNAME record configuration :

Fastly Fastly uses a CNAME record:

Cloudflare Cloudflare uses a CNAME record at _acme-challenge.domain.com. pointing to a Cloudflare validation target, for partial DNS setups.

F5 Distributed Cloud Customers create a CNAME record for with the value provided by F5 Distributed Cloud .

Google Cloud Certificate Manager Google's Certificate Manager uses DNS authorization where customers add CNAME records like pointing to Google's validation domains for certificate provisioning.

Certify DNS Certify DNS is a cloud hosted version of the acme-dns protocol that uses CNAME delegation of ACME challenge TXT records to a dedicated challenge response service.

acme-dns (open source) acme-dns is an open source limited DNS server with a RESTful HTTP API where customers create CNAME records like

Security Considerations This document is a survey of existing Domain Control Validation techniques and does not itself define a new protocol. The techniques surveyed here have varying security properties; some of the operational and security considerations that apply to them, including the construction of tokens and the placement of Validation Records, are discussed in .

IANA Considerations This document has no IANA actions.

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. This memo defines an Experimental Protocol for the Internet community. Informative 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. Brave Software Salesforce Aiven Akamai Technologies Cox Communications Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and it can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d.

Acknowledgments This survey is derived from material originally developed as part of the Domain Control Validation using DNS work in the DNS Operations Working Group. Thanks to the contributors and reviewers of that document.