idnits 2.17.1 draft-sahib-domain-verification-techniques-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 322 lines 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 March 2021) is 1137 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 4 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: 11 September 2021 10 March 2021 7 Survey of Domain Verification Techniques using DNS 8 draft-sahib-domain-verification-techniques-00 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 lays out the various techniques and 15 the pros and cons of each. 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 11 September 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 59 2. Conventions and Definitions 60 3. Verification Techniques 61 3.1. TXT based 62 3.1.1. Examples 63 3.2. CNAME based 64 3.2.1. Examples 65 4. Recommendations 66 4.1. TXT vs CNAME 67 4.2. TXT recommendations 68 4.3. CNAME recommendations 69 5. Security Considerations 70 6. IANA Considerations 71 7. References 72 7.1. Normative References 73 7.2. Informative References 74 Acknowledgments 75 Authors' Addresses 77 1. Introduction 79 Many providers on the internet need users to prove that they control 80 a particular domain before granting them some sort of privilege 81 associated with that domain. For instance, certificate authorities 82 like Let's Encrypt [LETSENCRYPT] ask requesters of TLS certificates 83 to prove that they operate the domain they're requesting the 84 certificate for. Providers generally allow for several different 85 ways of proving domain control, some of which include manipulating 86 DNS records. This document focuses on DNS techniques for domain 87 verification; other techniques (such as email or HTML verification) 88 are out-of-scope. 90 In practice, DNS-based verification often looks like the provider 91 generating a random value and asking the requester to create a DNS 92 record containing this random value and placing it at a location that 93 the provider can query for. Generally only one temporary DNS record 94 is sufficient for proving domain ownership. 96 2. Conventions and Definitions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 3. Verification Techniques 106 3.1. TXT based 108 Although the original DNS protocol specifications did not associate 109 any semantics with the DNS TXT record, [RFC1464] describes how to use 110 them to store attributes in the form of ASCII text key-value pairs 111 for a particular domain. 113 host.widgets.com IN TXT "printer=lpr5" 115 In practice, there is wide variation in the content of DNS TXT 116 records used for domain verification, and they often do not follow 117 the key-value pair model. 119 The same domain name can have multiple distinct TXT records (a TXT 120 Record Set). 122 TXT record-based DNS domain verification is usually the default 123 option for DNS verification. The service provider asks the user to 124 add a DNS TXT record (perhaps through their domain host or DNS 125 provider) at the domain with a certain value. Then, the service 126 provider does a DNS TXT query for the domain being verified and 127 checks that the value exists. For example, this is what a DNS TXT 128 verification record could look like: 130 example.com. IN TXT "foo-verification=bar" 132 Here, the value "bar" for the attribute "foo-verification" serves as 133 the randomly-generated TXT value being added to prove ownership of 134 the domain to Foo provider. The value is usually a randomly- 135 generated token in order to guarantee that the entity who requested 136 that the domain be verified (i.e. the person managing the account at 137 Foo provider) is the one who has (direct or delegated) access to DNS 138 records for the domain. The generated token typically expires in a 139 few days. The TXT record is usually placed at the domain being 140 verified ("example.com" in the example above). After a TXT record 141 has been added, the service provider will usually take some time to 142 verify that the DNS TXT record with the expected token exists for the 143 domain. 145 One drawback of this method is that the TXT record is typically 146 placed at the domain name being verified. If many services are 147 attempting to verify the domain name, many distinct TXT records end 148 up being placed at that name. Since DNS Resource Record sets are 149 treated atomically, all TXT records must be returned to the querier, 150 increasing the size of the response. There is no way to surgically 151 query only the TXT record for a specific 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 teypically 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 4. Recommendations 226 4.1. TXT vs CNAME 228 4.2. TXT recommendations 230 4.3. CNAME recommendations 232 5. Security Considerations 234 DNSSEC [RFC4033] should be employed by the domain owner to protect 235 against domain name spoofing. 237 6. IANA Considerations 239 This document has no IANA actions. 241 7. References 243 7.1. Normative References 245 [RFC1034] Mockapetris, P.V., "Domain names - concepts and 246 facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, 247 November 1987, . 249 [RFC1035] Mockapetris, P.V., "Domain names - implementation and 250 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 251 November 1987, . 253 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 254 Arbitrary String Attributes", RFC 1464, 255 DOI 10.17487/RFC1464, May 1993, 256 . 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 264 Rose, "DNS Security Introduction and Requirements", 265 RFC 4033, DOI 10.17487/RFC4033, March 2005, 266 . 268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 270 May 2017, . 272 7.2. Informative References 274 [ACM-CNAME] 275 AWS, ., "Option 1: DNS Validation", n.d., 276 . 279 [GITHUB-TXT] 280 GitHub, ., "Verifying your organization's domain", n.d., 281 . 285 [GOOGLE-WORKSPACE-CNAME] 286 Google, ., "CNAME record values", n.d., 287 . 289 [GOOGLE-WORKSPACE-TXT] 290 Google, ., "TXT record values", n.d., 291 . 293 [LETSENCRYPT] 294 Let's Encrypt, ., "Challenge Types: DNS-01 challenge", 295 2020, . 298 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 299 Kasten, "Automatic Certificate Management Environment 300 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 301 . 303 Acknowledgments 305 TODO 307 Authors' Addresses 309 Shivan Sahib 310 Salesforce 312 Email: shivankaulsahib@gmail.com 314 Shumon Huque 315 Salesforce 317 Email: shuque@gmail.com