idnits 2.17.1 draft-sahib-domain-verification-techniques-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([RFC1034], [RFC1035]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (10 June 2021) is 1048 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sahib 3 Internet-Draft Brave Software 4 Intended status: Informational S. Huque 5 Expires: 12 December 2021 Salesforce 6 10 June 2021 8 Survey of Domain Verification Techniques using DNS 9 draft-sahib-domain-verification-techniques-02 11 Abstract 13 Many services on the Internet need to verify ownership or control of 14 domains in the Domain Name System (DNS) [RFC1034] [RFC1035]. This 15 verification often relies on adding or editing DNS records within the 16 domain. This document surveys various techniques in wide use today, 17 the pros and cons of each, and possible improvements. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Source for this draft and an issue tracker can be found at 24 https://github.com/ShivanKaul/draft-sahib-domain-verification- 25 techniques. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 12 December 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 62 3. Verification Techniques . . . . . . . . . . . . . . . . . . . 3 63 3.1. TXT based . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. CNAME based . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Common Patterns . . . . . . . . . . . . . . . . . . . . . 5 68 3.3.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.3.2. RDATA . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Targeted Domain Verification . . . . . . . . . . . . . . 6 72 4.2. TXT vs CNAME . . . . . . . . . . . . . . . . . . . . . . 6 73 4.3. Time-bound checking . . . . . . . . . . . . . . . . . . . 7 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 7.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 Many providers on the internet need users to prove that they control 85 a particular domain before granting them some sort of privilege 86 associated with that domain. For instance, certificate authorities 87 like Let's Encrypt [LETSENCRYPT] ask requesters of TLS certificates 88 to prove that they operate the domain they're requesting the 89 certificate for. Providers generally allow for several different 90 ways of proving domain control, some of which include manipulating 91 DNS records. This document focuses on DNS techniques for domain 92 verification; other techniques (such as email or HTML verification) 93 are out-of-scope. 95 In practice, DNS-based verification often takes the form of the 96 provider generating a random value visible only to the requester, and 97 then asking the requester to create a DNS record containing this 98 random value and placing it at a location that the provider can query 99 for. Generally only one temporary DNS record is sufficient for 100 proving domain ownership. 102 2. Conventions and Definitions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 Provider: an internet-based provider of a service, for e.g., Let's 111 Encrypt provides a certificate authority service or GitHub provides 112 code-hosting services. These services often require a user to verify 113 that they control a domain. 115 3. Verification Techniques 117 3.1. TXT based 119 TXT record-based DNS domain verification is usually the default 120 option for DNS verification. The service provider asks the user to 121 add a DNS TXT record (perhaps through their domain host or DNS 122 provider) at the domain with a certain value. Then, the service 123 provider does a DNS TXT query for the domain being verified and 124 checks that the value exists. For example, this is what a DNS TXT 125 verification record could look like: 127 example.com. IN TXT "foo-verification=bar-237943648324687364" 129 Here, the value "bar-bar-237943648324687364" for the attribute "foo- 130 verification" serves as the randomly-generated TXT value being added 131 to prove ownership of the domain to Foo provider. Although the 132 original DNS protocol specifications did not associate any semantics 133 with the DNS TXT record, [RFC1464] describes how to use them to store 134 attributes in the form of ASCII text key-value pairs for a particular 135 domain. In practice, there is wide variation in the content of DNS 136 TXT records used for domain verification, and they often do not 137 follow the key-value pair model. Even so, the rdata portion of the 138 DNS TXT record has to contain the value being used to verify the 139 domain. The value is usually a randomly-generated token in order to 140 guarantee that the entity who requested that the domain be verified 141 (i.e. the person managing the account at Foo provider) is the one who 142 has (direct or delegated) access to DNS records for the domain. The 143 generated token typically expires in a few days. The TXT record is 144 usually placed at the domain being verified ("example.com" in the 145 example above). After a TXT record has been added, the service 146 provider will usually take some time to verify that the DNS TXT 147 record with the expected token exists for the domain. 149 The same domain name can have multiple distinct TXT records (a TXT 150 Record Set), where each TXT record may be associated with a distinct 151 service. 153 3.1.1. Examples 155 3.1.1.1. Let's Encrypt 157 Let's Encrypt [LETSENCRYPT] has a challenge type "DNS-01" that lets a 158 user prove domain ownership in accordance with the ACME protocol 159 [RFC8555]. In this challenge, Let's Encrypt asks you to create a TXT 160 record with a randomly-generated token at "_acme- 161 challenge.". For example, if you wanted to prove domain 162 ownership of "example.com", Let's Encrypt could ask you to create the 163 DNS record: 165 _acme-challenge.example.com. IN TXT "cE3A8qQpEzAIYq-T9DWNdLJ1_YRXamdxcjGTbzrOH5L" 167 [RFC8555] (section 8.4) places requirements on the random value. 169 3.1.1.2. Google Workspace 171 [GOOGLE-WORKSPACE-TXT] asks the user to sign in with their 172 administrative account and obtain their verification token as part of 173 the setup process for Google Workspace. The verification token is a 174 68-character string that begins with "google-site-verification=", 175 followed by 43 characters. Google recommends a TTL of 3600 seconds. 176 The owner name of the TXT record is the domain or subdomain neme 177 being verified. 179 3.1.1.3. GitHub 181 GitHub asks you to create a DNS TXT record under "_github-challenge- 182 ORGANIZATION-", where ORGANIZATION stands for the GitHub 183 organization name [GITHUB-TXT]. The code is a numeric code that 184 expires in 7 days. 186 3.2. CNAME based 188 Less commonly than TXT record verification, service providers also 189 provide the ability to verify domain ownership via CNAME records. 190 This is used in case the user cannot create TXT records. One common 191 reason is that the domain name may already have CNAME record that 192 aliases it to a 3rd-party target domain. CNAMEs have a technical 193 restriction that no other record types can be placed along side them 194 at the same domain name ([RFC1034], Section 3.6.2).. The CNAME based 195 domain verification method typically uses a randomized label 196 prepended to the domain name being verified. 198 3.2.1. Examples 200 3.2.1.1. Google 202 [GOOGLE-WORKSPACE-CNAME] lets you specify a CNAME record for 203 verifying domain ownership. The user gets a unique 12-character 204 string that is added as "Host", with TTL 3600 (or default) and 205 Destination an 86-character string beginning with "gv-" and ending 206 with ".domainverify.googlehosted.com.". 208 To verify a subdomain, the unique 12-character string is appended 209 with the subdomain name for "Host" field for e.g. 210 JLKDER712AFP.subdomain where subdomain is the subdomain being 211 verified. 213 3.2.1.2. AWS Certificate Manager (ACM) 215 To get issued a certificate by AWS Certificate Manager (ACM), you can 216 create a CNAME record to verify domain ownership [ACM-CNAME]. The 217 record name for the CNAME looks like "_.example.com", 218 which would point to "_..acm- 219 validations.aws." 221 Note that if there are more than 5 CNAMEs being chained, then this 222 method does not work. 224 3.3. Common Patterns 226 3.3.1. Name 228 ACME and GitHub have a suffix of "_PROVIDER_NAME-challenge" in the 229 Name field of the TXT record challenge. For ACME, the full Host is 230 "_acme-challenge.", while for GitHub it is "_github- 231 challenge-ORGANIZATION-". Both these patterns are 232 useful for doing targeted domain verification, as discussed in 233 section (#targeted-domain-verification) because if the provider knows 234 what it is looking for (domain in the case of ACME, organization name 235 + domain in case of GitHub) it can specifically do a DNS query for 236 that TXT record, as opposed to having to do a TXT query for the apex. 238 ACME does the same name construction for CNAME records. 240 3.3.2. RDATA 242 One pattern that quite a few providers follow (Dropbox, Atlassian) is 243 constructing the rdata of the TXT DNS record in the form of 244 "PROVIDER-SERVICE-domain-verification=" followed by the random value 245 being checked for. This is in accordance with [RFC1464] which 246 mandates that attributes must be stored as key-value pairs. 248 4. Recommendations 250 4.1. Targeted Domain Verification 252 The TXT record being used for domain verification is most commonly 253 placed at the domain name being verified. For example, if 254 "example.com" is being verified, then the DNS TXT record will have 255 "example.com" in the Name section. 257 If many services are attempting to verify the domain name, many 258 distinct TXT records end up being placed at that name. There is no 259 way to surgically query only the TXT record for a specific service, 260 resulting in extra work for a verifying service to sift through the 261 records for its own domain verification record. In addition, since 262 DNS Resource Record sets are treated atomically, all TXT records must 263 be returned to the querier, which leads to a bloating of DNS 264 responses. This could cause truncation and retrying DNS queries over 265 TCP, which is more resource intensive. 267 A better method is to place the TXT record at a subdomain of the 268 domain being verified that is specially reserved for use by the 269 application service in question. The LetsEncrypt ACME challenge 270 mentioned earlier uses this method. 272 4.2. TXT vs CNAME 274 TODO 276 4.3. Time-bound checking 278 After domain verification is done, there is no need for the TXT or 279 CNAME record to continue to exist as the presence of the domain- 280 verifying DNS record for a service only implies that a user with 281 access to the service also has DNS control of the domain at the time 282 the code was generated. It should be safe to remove the verifying 283 DNS record once the verification is done and the service provider 284 doing the verification should specify how long the verification will 285 take (i.e. after how much time can the verifying DNS record be 286 deleted). However, despite this, some services ask the record to 287 exist in perpetuity [ATLASSIAN-VERIFY]. 289 5. Security Considerations 291 DNSSEC [RFC4033] should be employed by the domain owner to protect 292 against domain name spoofing. 294 6. IANA Considerations 296 This document has no IANA actions. 298 7. References 300 7.1. Normative References 302 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 303 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 304 . 306 [RFC1035] Mockapetris, P., "Domain names - implementation and 307 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 308 November 1987, . 310 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 311 Arbitrary String Attributes", RFC 1464, 312 DOI 10.17487/RFC1464, May 1993, 313 . 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 321 Rose, "DNS Security Introduction and Requirements", 322 RFC 4033, DOI 10.17487/RFC4033, March 2005, 323 . 325 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 326 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 327 May 2017, . 329 7.2. Informative References 331 [ACM-CNAME] 332 AWS, ., "Option 1: DNS Validation", n.d., 333 . 336 [ATLASSIAN-VERIFY] 337 Atlassian, ., "Verify over DNS", n.d., 338 . 342 [GITHUB-TXT] 343 GitHub, ., "Verifying your organization's domain", n.d., 344 . 348 [GOOGLE-WORKSPACE-CNAME] 349 Google, ., "CNAME record values", n.d., 350 . 352 [GOOGLE-WORKSPACE-TXT] 353 Google, ., "TXT record values", n.d., 354 . 356 [LETSENCRYPT] 357 Let's Encrypt, ., "Challenge Types: DNS-01 challenge", 358 2020, . 361 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 362 Kasten, "Automatic Certificate Management Environment 363 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 364 . 366 Acknowledgments 368 TODO 370 Authors' Addresses 371 Shivan Sahib 372 Brave Software 374 Email: shivankaulsahib@gmail.com 376 Shumon Huque 377 Salesforce 379 Email: shuque@gmail.com