idnits 2.17.1 draft-sahib-domain-verification-techniques-01.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 (15 April 2021) is 1101 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 S. Huque 4 Intended status: Informational Salesforce 5 Expires: 17 October 2021 15 April 2021 7 Survey of Domain Verification Techniques using DNS 8 draft-sahib-domain-verification-techniques-01 10 Abstract 12 Verification of ownership of domains in the Domain Name System (DNS) 13 [RFC1034] [RFC1035] often relies on adding or editing DNS records 14 within the domain. This document surveys various techniques in wide 15 use today, the pros and cons of each, and possible improvements. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Source for this draft and an issue tracker can be found at 22 https://github.com/ShivanKaul/draft-sahib-domain-verification- 23 techniques. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 17 October 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 60 3. Verification Techniques . . . . . . . . . . . . . . . . . . . 3 61 3.1. TXT based . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. CNAME based . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. Common Patterns . . . . . . . . . . . . . . . . . . . . . 5 66 3.3.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3.2. RDATA . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Targeted Domain Verification . . . . . . . . . . . . . . 6 70 4.2. TXT vs CNAME . . . . . . . . . . . . . . . . . . . . . . 6 71 4.3. Continuous checking . . . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 7.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 Many providers on the internet need users to prove that they control 83 a particular domain before granting them some sort of privilege 84 associated with that domain. For instance, certificate authorities 85 like Let's Encrypt [LETSENCRYPT] ask requesters of TLS certificates 86 to prove that they operate the domain they're requesting the 87 certificate for. Providers generally allow for several different 88 ways of proving domain control, some of which include manipulating 89 DNS records. This document focuses on DNS techniques for domain 90 verification; other techniques (such as email or HTML verification) 91 are out-of-scope. 93 In practice, DNS-based verification often looks like the provider 94 generating a random value and asking the requester to create a DNS 95 record containing this random value and placing it at a location that 96 the provider can query for. Generally only one temporary DNS record 97 is sufficient for proving domain ownership. 99 2. Conventions and Definitions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 Provider: an internet-based provider of a service, for e.g., Let's 108 Encrypt provides a certificate authority service or GitHub provides 109 code-hosting services. These services often require a user to verify 110 that they control a domain. 112 3. Verification Techniques 114 3.1. TXT based 116 TXT record-based DNS domain verification is usually the default 117 option for DNS verification. The service provider asks the user to 118 add a DNS TXT record (perhaps through their domain host or DNS 119 provider) at the domain with a certain value. Then, the service 120 provider does a DNS TXT query for the domain being verified and 121 checks that the value exists. For example, this is what a DNS TXT 122 verification record could look like: 124 example.com. IN TXT "foo-verification=bar" 126 Here, the value "bar" for the attribute "foo-verification" serves as 127 the randomly-generated TXT value being added to prove ownership of 128 the domain to Foo provider. Although the original DNS protocol 129 specifications did not associate any semantics with the DNS TXT 130 record, [RFC1464] describes how to use them to store attributes in 131 the form of ASCII text key-value pairs for a particular domain. In 132 practice, there is wide variation in the content of DNS TXT records 133 used for domain verification, and they often do not follow the key- 134 value pair model. Even so, the rdata portion of the DNS TXT record 135 has to contain the value being used to verify the domain. The value 136 is usually a randomly-generated token in order to guarantee that the 137 entity who requested that the domain be verified (i.e. the person 138 managing the account at Foo provider) is the one who has (direct or 139 delegated) access to DNS records for the domain. The generated token 140 typically expires in a few days. The TXT record is usually placed at 141 the domain being verified ("example.com" in the example above). 142 After a TXT record has been added, the service provider will usually 143 take some time to verify that the DNS TXT record with the expected 144 token exists for the domain. 146 The same domain name can have multiple distinct TXT records (a TXT 147 Record Set). 149 3.1.1. Examples 151 3.1.1.1. Let's Encrypt 153 Let's Encrypt [LETSENCRYPT] has a challenge type "DNS-01" that lets a 154 user prove domain ownership in accordance with the ACME protocol 155 [RFC8555]. In this challenge, Let's Encrypt asks you to create a TXT 156 record with a randomly-generated token at "_acme- 157 challenge.". For example, if you wanted to prove domain 158 ownership of "example.com", Let's Encrypt could ask you to create the 159 DNS record: 161 _acme-challenge.example.com. IN TXT "cE3A8qQpEzAIYq-T9DWNdLJ1_YRXamdxcjGTbzrOH5L" 163 [RFC8555] (section 8.4) places requirements on the random value. 165 3.1.1.2. Google Workspace 167 [GOOGLE-WORKSPACE-TXT] asks the user to sign in with their 168 administrative account and obtain their verification token as part of 169 the setup process for Google Workspace. The verification token is a 170 68-character string that begins with "google-site-verification=", 171 followed by 43 characters. Google recommends a TTL of 3600 seconds. 172 The owner name of the TXT record is the domain or subdomain neme 173 being verified. 175 3.1.1.3. GitHub 177 GitHub asks you to create a DNS TXT record under "_github-challenge- 178 ORGANIZATION-", where ORGANIZATION stands for the GitHub 179 organization name [GITHUB-TXT]. The code is a numeric code that 180 expires in 7 days. 182 3.2. CNAME based 184 Less commonly than TXT record verification, service providers also 185 provide the ability to verify domain ownership via CNAME records. 186 This is used in case the user cannot create TXT records. One common 187 reason is that the domain name may already have CNAME record that 188 aliases it to a 3rd-party target domain. CNAMEs have a technical 189 restriction that no other record types can be placed along side them 190 at the same domain name ([RFC1034], Section 3.6.2).. The CNAME based 191 domain verification method typically uses a randomized label 192 prepended to the domain name being verified. 194 3.2.1. Examples 196 3.2.1.1. Google 198 [GOOGLE-WORKSPACE-CNAME] lets you specify a CNAME record for 199 verifying domain ownership. The user gets a unique 12-character 200 string that is added as "Host", with TTL 3600 (or default) and 201 Destination an 86-character string beginning with "gv-" and ending 202 with ".domainverify.googlehosted.com.". 204 To verify a subdomain, the unique 12-character string is appended 205 with the subdomain name for "Host" field for e.g. 206 JLKDER712AFP.subdomain where subdomain is the subdomain being 207 verified. 209 3.2.1.2. AWS Certificate Manager (ACM) 211 To get issued a certificate by AWS Certificate Manager (ACM), you can 212 create a CNAME record to verify domain ownership [ACM-CNAME]. The 213 record name for the CNAME looks like "_.example.com", 214 which would point to "_..acm- 215 validations.aws." 217 Note that if there are more than 5 CNAMEs being chained, then this 218 method does not work. 220 3.3. Common Patterns 222 3.3.1. Name 224 ACME and GitHub have a suffix of "_PROVIDER_NAME-challenge" in the 225 Name field of the TXT record challenge. For ACME, the full Host is 226 "_acme-challenge.", while for GitHub it is "_github- 227 challenge-ORGANIZATION-". Both these patterns are 228 useful for doing targeted domain verification, as discussed in 229 section (#targeted-domain-verification) because if the provider knows 230 what it is looking for (domain in the case of ACME, organization name 231 + domain in case of GitHub) it can specifically do a DNS query for 232 that TXT record, as opposed to having to do a TXT query for the apex. 234 ACME does the same name construction for CNAME records. 236 3.3.2. RDATA 238 One pattern that quite a few providers follow (Dropbox, Atlassian) is 239 constructing the rdata of the TXT DNS record in the form of 240 "PROVIDER-SERVICE-domain-verification=" followed by the random value 241 being checked for. This is in accordance with [RFC1464] which 242 mandates that attributes must be stored as key-value pairs. 244 4. Recommendations 246 4.1. Targeted Domain Verification 248 The TXT record being used for domain verification is most commonly 249 placed at the domain name being verified. For example, if 250 "example.com" is being verified, then the DNS TXT record will have 251 "example.com" in the Name section. 253 If many services are attempting to verify the domain name, many 254 distinct TXT records end up being placed at that name. There is no 255 way to surgically query only the TXT record for a specific service, 256 resulting in extra work for a verifying service to sift through the 257 records for its own domain verification record. In addition, since 258 DNS Resource Record sets are treated atomically, all TXT records must 259 be returned to the querier, which leads to a bloating of DNS 260 responses. This could cause truncation and expensive retrying over 261 TCP. 263 A better method is to place the TXT record at a subdomain of the 264 domain being verified that is specially reserved for use by the 265 application service in question. 267 4.2. TXT vs CNAME 269 TODO 271 4.3. Continuous checking 273 After domain verification is done, there is no need for the TXT or 274 CNAME record to continue to exist as the existence of the domain 275 verifying DNS record for a service only implies that a user with 276 access to the service also has DNS control of the domain at the time 277 the code was generated. It should be safe to remove the verifying 278 DNS record once the verification is done. However, despite this, 279 some services ask the record to exist in perpetuity 280 [ATLASSIAN-VERIFY]. 282 5. Security Considerations 284 DNSSEC [RFC4033] should be employed by the domain owner to protect 285 against domain name spoofing. 287 6. IANA Considerations 289 This document has no IANA actions. 291 7. References 293 7.1. Normative References 295 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 296 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 297 . 299 [RFC1035] Mockapetris, P., "Domain names - implementation and 300 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 301 November 1987, . 303 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 304 Arbitrary String Attributes", RFC 1464, 305 DOI 10.17487/RFC1464, May 1993, 306 . 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, 310 DOI 10.17487/RFC2119, March 1997, 311 . 313 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 314 Rose, "DNS Security Introduction and Requirements", 315 RFC 4033, DOI 10.17487/RFC4033, March 2005, 316 . 318 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 319 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 320 May 2017, . 322 7.2. Informative References 324 [ACM-CNAME] 325 AWS, ., "Option 1: DNS Validation", n.d., 326 . 329 [ATLASSIAN-VERIFY] 330 Atlassian, ., "Verify over DNS", n.d., 331 . 335 [GITHUB-TXT] 336 GitHub, ., "Verifying your organization's domain", n.d., 337 . 341 [GOOGLE-WORKSPACE-CNAME] 342 Google, ., "CNAME record values", n.d., 343 . 345 [GOOGLE-WORKSPACE-TXT] 346 Google, ., "TXT record values", n.d., 347 . 349 [LETSENCRYPT] 350 Let's Encrypt, ., "Challenge Types: DNS-01 challenge", 351 2020, . 354 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 355 Kasten, "Automatic Certificate Management Environment 356 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 357 . 359 Acknowledgments 361 TODO 363 Authors' Addresses 364 Shivan Sahib 365 Salesforce 367 Email: shivankaulsahib@gmail.com 369 Shumon Huque 370 Salesforce 372 Email: shuque@gmail.com