A Survey of Domain Control Validation Techniques using DNS
draft-sahib-dnsop-survey-dcv-techniques-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Shivan Kaul Sahib , Shumon Huque , Erik Nygren , Tim Wicinski | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sahib-dnsop-survey-dcv-techniques-00
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.<YOUR_DOMAIN>. 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.<YOUR_DOMAIN>:
_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.<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 [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:
_<random-token1>.example.com. IN CNAME _<random-token2>.acm-validations.aws.
The CNAME points to:
_<random-token2>.acm-validations.aws. IN TXT "<random-token3>"
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.
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,
<https://www.rfc-editor.org/rfc/rfc1034>.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464,
DOI 10.17487/RFC1464, May 1993,
<https://www.rfc-editor.org/rfc/rfc1464>.
7.2. Informative References
[ACM-CNAME]
Amazon Web Services, "AWS Certificate Manager DNS
validation", n.d.,
<https://docs.aws.amazon.com/acm/latest/userguide/dns-
validation.html>.
[ACME-DNS] Hoikkala, J., "acme-dns", n.d.,
<https://github.com/acme-dns/acme-dns>.
[AKAMAI-DCV]
Akamai Technologies, "Add a hostname with a default
certificate", n.d., <https://techdocs.akamai.com/property-
mgr/docs/add-hn-with-default-cert-la>.
[ATPROTO-HANDLE]
Bluesky, "Handle", n.d.,
<https://atproto.com/specs/handle#dns-txt-method>.
[CERTIFY-DNS]
Certify The Web, "Certify DNS", n.d.,
<https://docs.certifytheweb.com/docs/dns/providers/
certifydns/>.
[CLOUDFLARE-DCV]
Cloudflare, "Delegated DCV", n.d.,
<https://developers.cloudflare.com/ssl/edge-certificates/
changing-dcv-method/methods/delegated-dcv/>.
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,
<https://docs.digicert.com/en/whats-new/change-log/
certcentral-change-log.html>.
[DOCUSIGN-CNAME]
DocuSign, "Verify a domain with a CNAME record", n.d.,
<https://support.docusign.com/s/document-
item?bundleId=rrf1583359212854&topicId=gso1583359141256_1.html>.
[F5-ACME] F5, Inc, "What is an ACME challenge and how should I enter
these records in my DNS zone?", n.d.,
<https://f5cloud.zendesk.com/hc/en-us/
articles/24624288087959-What-is-an-ACME-challenge-and-how-
should-I-enter-these-records-in-my-DNS-zone>.
[FASTLY-TLS]
Fastly, "Setting up TLS with certificates Fastly manages",
n.d., <https://docs.fastly.com/en/guides/setting-up-tls-
with-certificates-fastly-manages>.
[GITHUB-ORG-VERIFY]
GitHub, "Verifying your organization's domain", n.d.,
<https://docs.github.com/en/github/setting-up-and-
managing-organizations-and-teams/verifying-your-
organizations-domain>.
[GOOGLE-CERT-MANAGER]
Google, "Deploy a global Google-managed certificate with
DNS authorization", n.d., <https://cloud.google.com/
certificate-manager/docs/deploy-google-managed-dns-auth>.
[GOOGLE-WORKSPACE-CNAME]
Google, "CNAME record values", n.d.,
<https://support.google.com/a/answer/112038>.
[GOOGLE-WORKSPACE-TXT]
Google, "TXT record values", n.d.,
<https://support.google.com/a/answer/2716802>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
domain-verification-techniques-13>.
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,
<https://letsencrypt.org/2015/11/09/why-90-days.html>.
[LETSENCRYPT-DNS01]
Internet Security Research Group (ISRG), "Challenge
Types", n.d., <https://letsencrypt.org/docs/challenge-
types/#dns-01-challenge>.
[PSL] Mozilla Foundation, "Public Suffix List", n.d.,
<https://publicsuffix.org/>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
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]