A Survey of Domain Control Validation Techniques using DNS

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

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

_atproto.bsky.app.  IN  TXT "did=did:plc:z72i7hdynmk6r22z27h6tvur"

_psl.example.com.  IN TXT "https://github.com/publicsuffix/list/pull/100"

4. CNAME based

_<random-token1>.example.com.  IN   CNAME _<random-token2>.acm-validations.aws.

_<random-token2>.acm-validations.aws.  IN   TXT "<random-token3>"

_acme-challenge.domain.com. IN CNAME validation.validate-akdv.net.

_dnsauth.example.com. IN CNAME [random_value].dcv.digicert.com.

_acme-challenge.domain.com. IN CNAME token.fastly-validations.com.

_acme-challenge.demo.f5lab.com.

_acme-challenge.myorg.example.com.

_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].¶

6. IANA Considerations

This document has no IANA actions.¶

7. References

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