Network Working Group S. Sahib Internet-Draft Brave Software Intended status: Informational S. Huque Expires: 7 January 2027 Salesforce E. Nygren Akamai Technologies T. Wicinski Cox Communications 6 July 2026 A Survey of Domain Control Validation Techniques using DNS draft-sahib-dnsop-survey-dcv-techniques-00 Abstract [I-D.draft-ietf-dnsop-domain-verification-techniques] 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 This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (dnsop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Source for this draft and an issue tracker can be found at https://github.com/ShivanKaul/draft-sahib-survey-dcv-techniques. 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." Sahib, et al. Expires 7 January 2027 [Page 1] Internet-Draft Survey of Domain Control Validation July 2026 This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 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 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. TXT based . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Let's Encrypt . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Google Workspace . . . . . . . . . . . . . . . . . . . . 4 3.3. The AT Protocol . . . . . . . . . . . . . . . . . . . . . 4 3.4. GitHub . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. Public Suffix List . . . . . . . . . . . . . . . . . . . 5 4. CNAME based . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. CNAME for Domain Control Validation . . . . . . . . . . . 5 4.1.1. DocuSign . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. Google Workspace CNAME . . . . . . . . . . . . . . . 5 4.2. Delegated Domain Control Validation . . . . . . . . . . . 5 4.2.1. Content Delivery Networks (CDNs) . . . . . . . . . . 5 4.2.2. AWS Certificate Manager (ACM) . . . . . . . . . . . . 6 4.2.3. Akamai . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.4. DigiCert . . . . . . . . . . . . . . . . . . . . . . 6 4.2.5. Fastly . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.6. Cloudflare . . . . . . . . . . . . . . . . . . . . . 7 4.2.7. F5 Distributed Cloud . . . . . . . . . . . . . . . . 7 4.2.8. Google Cloud Certificate Manager . . . . . . . . . . 7 4.2.9. Certify DNS . . . . . . . . . . . . . . . . . . . . . 7 4.2.10. acme-dns (open source) . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Sahib, et al. Expires 7 January 2027 [Page 2] Internet-Draft Survey of Domain Control Validation July 2026 1. 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 [I-D.draft-ietf-dnsop-domain-verification-techniques] for best practices. 2. Conventions and Definitions This document uses the terminology defined in the "Conventions and Definitions" section of [I-D.draft-ietf-dnsop-domain-verification-techniques], including "Application Service Provider", "DNS Administrator", "User", "Unique Token", and "Validation Record". 3. 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: example.com. IN TXT "237943648324687364" 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, [RFC1464] 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 Sahib, et al. Expires 7 January 2027 [Page 3] Internet-Draft Survey of Domain Control Validation July 2026 follow the key-value pair model. Even so, the RDATA [RFC1034] 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.. Such patterns are useful for doing targeted domain control validation. The ACME protocol ([RFC8555]) 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.: _acme-challenge.example.com. IN TXT "cE3A8qQpEzAIYq-T9DWNdLJ1_YRXamdxcjGTbzrOH5L" [RFC8555] (Section 8.4) places requirements on the Unique Token. 3.1. Let's Encrypt The ACME example is implemented by Let's Encrypt [LETSENCRYPT-DNS01]. 3.2. Google Workspace Google Workspace [GOOGLE-WORKSPACE-TXT] 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. 3.3. 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 [ATPROTO-HANDLE]. For example, this is how the handle bsky.app would be resolved: _atproto.bsky.app. IN TXT "did=did:plc:z72i7hdynmk6r22z27h6tvur" Sahib, et al. Expires 7 January 2027 [Page 4] Internet-Draft Survey of Domain Control Validation July 2026 3.4. GitHub To verify domains for organizations, GitHub asks the User to create a DNS TXT record under _github-challenge-ORGANIZATION., where ORGANIZATION stands for the GitHub organization name. The RDATA value for the provided TXT record is a string that expires in 7 days [GITHUB-ORG-VERIFY]. 3.5. Public Suffix List The Public Suffix List [PSL] 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: _psl.example.com. IN TXT "https://github.com/publicsuffix/list/pull/100" 4. CNAME based 4.1. CNAME for Domain Control Validation 4.1.1. DocuSign DocuSign [DOCUSIGN-CNAME] 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.. 4.1.2. Google Workspace CNAME Google Workspace [GOOGLE-WORKSPACE-CNAME] 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.". 4.2. Delegated Domain Control Validation 4.2.1. 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 [LETSENCRYPT-DNS01]. Let's Encrypt only issues certs with a 90 day validity period for security reasons [LETSENCRYPT-90DAYS]. 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. Sahib, et al. Expires 7 January 2027 [Page 5] Internet-Draft Survey of Domain Control Validation July 2026 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. 4.2.2. AWS Certificate Manager (ACM) AWS Certificate Manager [ACM-CNAME] 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: * : Unique sub-domain, so there are no clashes when looking up the Validation Record. * : Proves to ACM that the requester controls the DNS for the requested domain at the time the CNAME is created. * : The actual token being verified. Note that if there are more than 5 CNAMEs being chained, then this method does not work. 4.2.3. Akamai Akamai [AKAMAI-DCV] uses a CNAME record: _acme-challenge.domain.com. IN CNAME validation.validate-akdv.net. 4.2.4. DigiCert DigiCert is switching to use a static prefix _dnsauth CNAME record configuration [DIGICERT-DCV]: _dnsauth.example.com. IN CNAME [random_value].dcv.digicert.com. 4.2.5. Fastly Fastly [FASTLY-TLS] uses a CNAME record: _acme-challenge.domain.com. IN CNAME token.fastly-validations.com. Sahib, et al. Expires 7 January 2027 [Page 6] Internet-Draft Survey of Domain Control Validation July 2026 4.2.6. Cloudflare Cloudflare [CLOUDFLARE-DCV] uses a CNAME record at _acme- challenge.domain.com. pointing to a Cloudflare validation target, for partial DNS setups. 4.2.7. F5 Distributed Cloud Customers create a CNAME record for _acme-challenge.demo.f5lab.com. with the value provided by F5 Distributed Cloud [F5-ACME]. 4.2.8. Google Cloud Certificate Manager Google's Certificate Manager [GOOGLE-CERT-MANAGER] uses DNS authorization where customers add CNAME records like _acme-challenge.myorg.example.com. pointing to Google's validation domains for certificate provisioning. 4.2.9. Certify DNS 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. 4.2.10. acme-dns (open source) acme-dns [ACME-DNS] is an open source limited DNS server with a RESTful HTTP API where customers create CNAME records like _acme-challenge.domainiwantcertfor.tld. IN CNAME a097455b-52cc-4569-90c8-7a4b97c6eba8.auth.example.org. 5. 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 [I-D.draft-ietf-dnsop-domain-verification-techniques]. Sahib, et al. Expires 7 January 2027 [Page 7] Internet-Draft Survey of Domain Control Validation July 2026 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, DOI 10.17487/RFC1464, May 1993, . 7.2. Informative References [ACM-CNAME] Amazon Web Services, "AWS Certificate Manager DNS validation", n.d., . [ACME-DNS] Hoikkala, J., "acme-dns", n.d., . [AKAMAI-DCV] Akamai Technologies, "Add a hostname with a default certificate", n.d., . [ATPROTO-HANDLE] Bluesky, "Handle", n.d., . [CERTIFY-DNS] Certify The Web, "Certify DNS", n.d., . [CLOUDFLARE-DCV] Cloudflare, "Delegated DCV", n.d., . Sahib, et al. Expires 7 January 2027 [Page 8] Internet-Draft Survey of Domain Control Validation July 2026 [DIGICERT-DCV] DigiCert, "CertCentral change log", 2025, . [DOCUSIGN-CNAME] DocuSign, "Verify a domain with a CNAME record", n.d., . [F5-ACME] F5, Inc, "What is an ACME challenge and how should I enter these records in my DNS zone?", n.d., . [FASTLY-TLS] Fastly, "Setting up TLS with certificates Fastly manages", n.d., . [GITHUB-ORG-VERIFY] GitHub, "Verifying your organization's domain", n.d., . [GOOGLE-CERT-MANAGER] Google, "Deploy a global Google-managed certificate with DNS authorization", n.d., . [GOOGLE-WORKSPACE-CNAME] Google, "CNAME record values", n.d., . [GOOGLE-WORKSPACE-TXT] Google, "TXT record values", n.d., . [I-D.draft-ietf-dnsop-domain-verification-techniques] Sahib, S. K., Huque, S., Wouters, P., Nygren, E., and T. Wicinski, "Domain Control Validation using DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-domain- verification-techniques-13, 21 June 2026, . Sahib, et al. Expires 7 January 2027 [Page 9] Internet-Draft Survey of Domain Control Validation July 2026 [LETSENCRYPT-90DAYS] Aas, J., "Why ninety-day lifetimes for certificates?", 2015, . [LETSENCRYPT-DNS01] Internet Security Research Group (ISRG), "Challenge Types", n.d., . [PSL] Mozilla Foundation, "Public Suffix List", n.d., . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . 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. Authors' Addresses Shivan Sahib Brave Software Email: shivankaulsahib@gmail.com Shumon Huque Salesforce Email: shuque@gmail.com Erik Nygren Akamai Technologies Email: erik+ietf@nygren.org Tim Wicinski Cox Communications Email: tjw.ietf@gmail.com Sahib, et al. Expires 7 January 2027 [Page 10]