]> Brave Software

shivankaulsahib@gmail.com

Salesforce

shuque@gmail.com

Aiven

paul.wouters@aiven.io

Internet-Draft 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 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 requester's domain. There is wide variation in the details of these methods today. This document proposes some best practices to avoid known problems. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction Many providers of internet services need domain owners to prove that they control a particular DNS domain before the provider can operate services for or grant some privilege to that domain. For instance, certificate authorities (CAs) ask requesters of TLS certificates to prove that they operate the domain they are requesting the certificate for. Providers generally allow for several different ways of proving control of a domain. In practice, DNS-based methods take the form of the provider generating a random token and asking the requester to create a DNS record containing this random token and placing it at a location within the domain that the provider can query for. Generally only one temporary DNS record is sufficient for proving domain ownership, although sometimes the DNS record must be kept in the zone to prove continued ownership of the domain. This document describes pitfalls associated with some common practices using DNS-based techniques deployed today, and recommends using TXT based domain control validation which is time-bound and targeted to the service. The includes a more detailed survey of different methods used by a set of application service providers. Other techniques such as email or HTTP(S) based validation are out-of-scope.

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 when, and only when, they appear in all capitals, as shown here.

• Validation record: the DNS record that is used to prove ownership of a domain. It typically contains an unguessable value generated by the provider which serves as a challenge. The provider looks for the validation record in the zone of the domain being verified and checks if it contains the unguessable value.
• Provider: an internet-based provider of a service, for e.g., a Certificate Authority or a service that allows for user-controlled websites. These services often require a user to verify that they control a domain.
• Random Token: a random value that uniquely identifies the DNS domain control validation challenge, defined in .

Common Pitfalls A very common but unfortunate technique in use today is to employ a DNS TXT record and placing it at the exact domain name whose control is being validated. This has a number of known operational issues. If the domain owner uses multiple application services using this technique, it will end up deploying a DNS TXT record "set" at the domain name, containing one TXT record for each of the services. Since DNS resource record sets are treated atomically, a query for the validation record will return all TXT records in the response. There is no way for the verifier to surgically query only the TXT record that is pertinent to their application service. The verifier must obtain the aggregate response and search through it to find the specific record it is interested in. Additionally, placing many such TXT records at the same name increases the size of the DNS response. If the size of the response is large enough that it does not fit into a single DNS UDP packet (UDP being the most common DNS transport today), this may result in fragmentation, which often does not work reliably on the Internet today due to firewalls and middleboxes, and also is vulnerable to various attacks (). Depending on message size limits being negotiated, it may alternatively cause the DNS server to "truncate" the UDP response and force the DNS client to re-try the query over TCP in order to get the full response. Not all networks properly transport DNS over TCP and some DNS software mistakenly believe TCP support is optional (). Other possible issues may occur. If a TXT record (or any other record type) is designed to be place at the same domain name that is being validated, it may not be possible to do so if that name already has a CNAME record. This is because CNAME records cannot co-exist with other records at the same name. This situation cannot occur at the apex of a DNS zone, but can at a name deeper within the zone.

Scope of Validation For security reasons, it is crucial to understand the scope of the domain name being validated. Both application service providers and the domain owner need to clearly specify and understand whether the validation request is for a single hostname or for the entire domain rooted at that name. This is particularly important in large multi-tenant enterprises, where an individual deployer of a service may not necessarily have operational authority of an entire domain. In the case of X.509 certificate issuance, the request is clear about whether it is for a single host or a wildcard domain. Unfortunately, the ACME protocol's DNS challenge mechanism () does not appear to differentiate these cases in the DNS validation record. In the absence of this distinction, the DNS administrator tasked with deploying the validation record may need to explicitly confirm the details of the certificate issuance request to make sure the certificate is not given broader authority than the domain owner intended. In the more general case of an Internet application service granting authority to a domain owner, again no existing DNS challenge scheme makes this distinction today. These services should very clearly indicate the scope of the validation in their public documentation so that the domain administrator can use this information to assess whether the validation record is granting the appropriately scoped authority.

Recommendations

Validation Record Format

Name The RECOMMENDED format is application-specific underscore prefix labels. Domain Control Validation records are constructed by the provider by prepending the label "_<PROVIDER_RELEVANT_NAME>-challenge" to the domain name being validated (e.g. "_foo-challenge.example.com"). The prefixed "_" is used to avoid collisions with existing hostnames.

Random Token A unique token used in the challenge. It should be a random value with the following properties:

1. MUST have at least 128 bits of entropy.
2. base64url () encoded.

See for additional information on randomness requirements. This random token is placed in the RDATA as described in the rest of this section.

TXT Record The RECOMMENDED method of doing DNS-based domain control validation is to use DNS TXT records. The name is constructed as described in , and RDATA MUST contain at least a Random Token (constructed as in ). If metadata (see ) is not used, then the unique token generated as-above can be placed as the only contents of the RDATA. For example: If a provider has an application-specific need to have multiple validations for the same label, multiple prefixes can be used: This again allows the provider to query only for application-specific records it needs, while giving flexibility to the user adding the DNS record (i.e. they can be given permission to only add records under a specific prefix by the DNS administrator). Whether or not multiple validation records can exist for the same domain is up to the implementation. Consumers of the provider services need to relay information from a provider's website to their local DNS administrators. The exact DNS record type, content and location is often not clear when the DNS administrator receives the information, especially to consumers who are not DNS experts. Providers SHOULD offer detailed help pages, that are accessible without needing a login on the provider website, as the DNS administrator often has no login account on the provider service website. Similarly, for clarity, the exact and full DNS record (including a Fully Qualified Domain Name) to be added SHOULD be provided along with help instructions.

Metadata For Expiry Providers MUST provide clear instructions on when a validation record can be removed. These instructions SHOULD be encoded in the RDATA via comma-separated ASCII key-value pairs , using the key "expiry" to hold a time after which it is safe to remove the validation record. If this key-value format is used, the verification token should use the key "token". For example: Alternatively, if the record should never expire (for instance, if it may be checked periodically by the provider) and should not be removed, the key "expiry" can be set to have value "never". The "expiry" key MAY be omitted in cases where the provider has clarified the record expiry policy out-of-band (). Note that this is semantically the same as: The user SHOULD de-provision the resource record provisioned for DNS-based domain control validation once it is no longer required.

CNAME Record CNAME records MAY be used instead of TXT records, but they should not be placed at the same domain name that is being validated. This is for the same reason already cited in . CNAME records cannot co-exist with other data, and there may already be other record types that exist at the domain name. Instead, as with the TXT record recommendation, an application specific label should be added as a subdomain of the domain to be verified. This ensures that the CNAME does not collide with other record types. In practice, many application services that employ CNAMEs today use a random subdomain label, which also works to avoid collisions. But adding an application specific component makes it easier for the domain owner to keep track of why and for what service a validation record has been deployed. Note that some DNS implementations permit the deployment of CNAME records co-existing with other record types. These implementations are in violation of the DNS protocol. Furthermore, they can cause resolution failures in unpredictable ways depending on the behavior of DNS resolvers, the order in which query types for the name are processed etc. In short, they cannot work reliably and these implementations should be fixed.

Delegated Domain Control Validation CNAME records enable delegated domain control validation, which lets the user delegate the domain control validation process for their domain to an intermediary without having to hand over full DNS access. The intermediary provides the user with a CNAME record to add for the domain and provider being validated that points to the intermediary's DNS, where the actual validation TXT record is placed. The record name and random tokens are generated as in . For example: .intermediarydns.com" ]]> The intermediary then adds the actual validation record: .intermediarydns.com. TXT "" ]]> Such a setup is especially useful when the provider wants to periodically re-issue the challenge. CNAMEs allow automating the renewal process by letting the intermediary place the random token in their DNS instead of needing continuous write access to the user's DNS. Importantly, the CNAME record also contains a random token which proves to the intermediary that example.com is controlled by the user. See for examples.

Time-bound checking After domain control validation is completed, there is typically no need for the TXT or CNAME record to continue to exist as the presence of the domain validation DNS record for a service only implies that a user with access to the service also has DNS control of the domain at the time the code was generated. It should be safe to remove the validation DNS record once the validation is done and the service provider doing the validation should specify how long the validation will take (i.e. after how much time can the validation DNS record be deleted). One exception is if the record is being used as part of a delegated domain control validation setup (); in that case, the CNAME record that points to the actual validation TXT record cannot be removed.

DNAME Domain control validation in the presence of a DNAME is theoretically possible. Since a DNAME record redirects the entire subtree of names underneath the owner of the DNAME, it is not possible to place a validation record under the DNAME owner itself. It would have to be placed under the DNAME target name, since any lookups for a name under the DNAME owner will be redirected to the corresponding name under the DNAME target.

Security Considerations A malicious service that promises to deliver something after domain control validation could surreptitiously ask another service provider to start processing or sending mail for the target domain and then present the victim domain administrator with this DNS TXT record pretending to be for their service. Once the administrator has added the DNS TXT record, instead of getting their service, their domain is now certifying another service of which they are not aware they are now a consumer. If services use a clear description and name attribution in the required DNS TXT record, this can be avoided. For example, by requiring a DNS TXT record at _vendorname.example.com instead of at example.com, a malicious service could no longer replay this without the DNS administrator noticing this. Both the provider and the service being authenticated and authorized should be unambiguous from the TXT record owner name and RDATA content to prevent malicious services from misleading the domain owner into certifying a different provider or service. A domain owner SHOULD sign their DNS zone using DNSSEC to protect validation records against DNS spoofing attacks. DNSSEC validation SHOULD be performed by service providers that verify validation records they have requested to be deployed. If no DNSSEC support is detected for the domain owner zone, or if DNSSEC validation cannot be performed, service providers SHOULD attempt to query and confirm the validation record by matching responses from multiple DNS resolvers on unpredictable geographically diverse IP addresses to reduce an attacker's ability to complete a challenge by spoofing DNS. Alternatively, service providers MAY perform multiple queries spread out over a longer time period to reduce the chance of receiving spoofed DNS answers.

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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Informative References Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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. This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld. The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK] n.d. n.d. n.d. n.d. n.d. n.d.

Appendix A survey of several different methods deployed today for DNS based domain control validation follows.

Survey of Techniques

TXT based TXT records is usually the default option for domain control validation. The 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 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 a provider Foo: Here, the value "237943648324687364" serves as the randomly-generated TXT value being added to prove ownership of the domain to Foo provider. Note that in this construction provider Foo would have to query for all TXT records at "example.com" to get the validating 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 Random Token in order to guarantee that the entity who requested that the domain be verified (i.e. the person managing the account at Foo provider) is the one who has (direct or delegated) access to DNS records for the domain. After a TXT record has been added, the 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 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 Random Token.

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

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.

GitHub GitHub asks you to create a DNS TXT record under _github-challenge-ORGANIZATION.<YOUR_DOMAIN>, where ORGANIZATION stands for the GitHub organization name . The code is a numeric code that expires in 7 days.

CNAME based

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

Cloudflare In order to be issued a TLS cert from a Certificate Authority like Let’s Encrypt, the requester needs to prove that they control the domain. Typically, this is done via the 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 random token has to be replaced with a new one. Doing this manually is error-prone. Content Delivery Networks like Cloudflare offer to automate this process using a CNAME record in the user's DNS that points to the validation record in Cloudflare'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's no clashes when looking up the validation record.
• <random-token2>: Proves to ACM that the requester controls the DNS for the requested domain.
• <random-token3>: The actual token being verified.

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

Atlassian Some services ask the DNS record to exist in perpetuity . If the record is removed, the user gets a limited amount of time to re-add it before they lose domain validation status.