idnits 2.17.1 draft-sahib-domain-verification-techniques-03.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 are 3 instances 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 date (7 March 2022) is 774 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: 8 September 2022 Salesforce 6 P. Wouters 7 Aiven 8 7 March 2022 10 Survey of Domain Verification Techniques using DNS 11 draft-sahib-domain-verification-techniques-03 13 Abstract 15 Many services on the Internet need to verify ownership or control of 16 a domain in the Domain Name System (DNS) [RFC1034] [RFC1035]. This 17 verification is often done by requesting a specific DNS record to be 18 visible in the domain. This document surveys various techniques in 19 wide use today, the pros and cons of each, and proposes some 20 practises to avoid known problems. 22 Discussion Venues 24 This note is to be removed before publishing as an RFC. 26 Source for this draft and an issue tracker can be found at 27 https://github.com/ShivanKaul/draft-sahib-domain-verification- 28 techniques. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 8 September 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 65 3. Verification Techniques . . . . . . . . . . . . . . . . . . . 3 66 3.1. TXT based . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. CNAME based . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 5 70 3.3. Common Patterns . . . . . . . . . . . . . . . . . . . . . 6 71 3.3.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.3.2. RDATA . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. Targeted Domain Verification . . . . . . . . . . . . . . 6 75 4.2. Targeted Service Verification . . . . . . . . . . . . . . 7 76 4.3. TXT vs CNAME . . . . . . . . . . . . . . . . . . . . . . 7 77 4.4. Time-bound checking . . . . . . . . . . . . . . . . . . . 8 78 5. Email sending authorization . . . . . . . . . . . . . . . . . 9 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 7. Operational Considerations . . . . . . . . . . . . . . . . . 9 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 9.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 Many providers of internet services need domain owners to prove that 91 they control a particular domain before they can operate a services 92 or grant some privilege to the associated domain. For instance, 93 certificate authorities like Let's Encrypt [LETSENCRYPT] ask 94 requesters of TLS certificates to prove that they operate the domain 95 they are requesting the certificate for. Providers generally allow 96 for several different ways of proving domain control. This document 97 describes and recommends common practises with using DNS based 98 techniques for domain verification. Other techniques such as email 99 or HTTP(S) based verification are out-of-scope. 101 In practice, DNS-based verification takes the form of the provider 102 generating a random value visible only to the requester, and then 103 asking the requester to create a DNS record containing this random 104 value and placing it at a location within the domain that the 105 provider can query for. Generally only one temporary DNS record is 106 sufficient for proving domain ownership, although sometimes the DNS 107 record must be kept in the zone to prove continued ownership of the 108 domain. 110 2. Conventions and Definitions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 Provider: an internet-based provider of a service, for e.g., Let's 119 Encrypt provides a certificate authority service or GitHub provides 120 code-hosting services. These services often require a user to verify 121 that they control a domain. 123 3. Verification Techniques 125 3.1. TXT based 127 TXT record-based DNS domain verification is usually the default 128 option for DNS verification. The service provider asks the user to 129 add a DNS TXT record (perhaps through their domain host or DNS 130 provider) at the domain with a certain value. Then, the service 131 provider does a DNS TXT query for the domain being verified and 132 checks that the value exists. For example, this is what a DNS TXT 133 verification record could look like: 135 example.com. IN TXT "foo-verification=bar-237943648324687364" 137 Here, the value "bar-237943648324687364" for the attribute "foo- 138 verification" serves as the randomly-generated TXT value being added 139 to prove ownership of the domain to Foo provider. Although the 140 original DNS protocol specifications did not associate any semantics 141 with the DNS TXT record, [RFC1464] describes how to use them to store 142 attributes in the form of ASCII text key-value pairs for a particular 143 domain. In practice, there is wide variation in the content of DNS 144 TXT records used for domain verification, and they often do not 145 follow the key-value pair model. Even so, the rdata portion of the 146 DNS TXT record has to contain the value being used to verify the 147 domain. The value is usually a randomly-generated token in order to 148 guarantee that the entity who requested that the domain be verified 149 (i.e. the person managing the account at Foo provider) is the one who 150 has (direct or delegated) access to DNS records for the domain. The 151 generated token typically expires in a few days. The TXT record is 152 placed at the domain being verified ("example.com" in the example 153 above). After a TXT record has been added, the service provider will 154 usually take some time to verify that the DNS TXT record with the 155 expected token exists for the domain. 157 The same domain name can have multiple distinct TXT records (a TXT 158 Record Set), where each TXT record may be associated with a distinct 159 service. Having many of these may cause operational issues, and it 160 is RECOMMENDED that providers use a prefix (eg "_foo.example.com") 161 instead of using the top of the domain ("APEX") directly, such as: 163 _foo.example.com. IN TXT "bar-237943648324687364" 165 3.1.1. Examples 167 3.1.1.1. Let's Encrypt 169 Let's Encrypt [LETSENCRYPT] has a challenge type DNS-01 that lets a 170 user prove domain ownership in accordance with the ACME protocol 171 [RFC8555]. In this challenge, Let's Encrypt asks you to create a TXT 172 record with a randomly-generated token at _acme- 173 challenge.. For example, if you wanted to prove domain 174 ownership of example.com, Let's Encrypt could ask you to create the 175 DNS record: 177 _acme-challenge.example.com. IN TXT "cE3A8qQpEzAIYq-T9DWNdLJ1_YRXamdxcjGTbzrOH5L" 179 [RFC8555] (section 8.4) places requirements on the random value. 181 3.1.1.2. Google Workspace 183 [GOOGLE-WORKSPACE-TXT] asks the user to sign in with their 184 administrative account and obtain their verification token as part of 185 the setup process for Google Workspace. The verification token is a 186 68-character string that begins with "google-site-verification=", 187 followed by 43 characters. Google recommends a TTL of 3600 seconds. 188 The owner name of the TXT record is the domain or subdomain neme 189 being verified. 191 3.1.1.3. GitHub 193 GitHub asks you to create a DNS TXT record under _github-challenge- 194 ORGANIZATION-, where ORGANIZATION stands for the GitHub 195 organization name [GITHUB-TXT]. The code is a numeric code that 196 expires in 7 days. 198 3.2. CNAME based 200 Less commonly than TXT record verification, service providers also 201 provide the ability to verify domain ownership via CNAME records. 202 One reason for using CNAME is for the case where the user cannot 203 create TXT records. One common reason is that the domain name may 204 already have CNAME record that aliases it to a 3rd-party target 205 domain. CNAMEs have a technical restriction that no other record 206 types can be placed along side them at the same domain name 207 ([RFC1034], Section 3.6.2).. The CNAME based domain verification 208 method typically uses a randomized label prepended to the domain name 209 being verified. 211 3.2.1. Examples 213 3.2.1.1. Google 215 [GOOGLE-WORKSPACE-CNAME] lets you specify a CNAME record for 216 verifying domain ownership. The user gets a unique 12-character 217 string that is added as "Host", with TTL 3600 (or default) and 218 Destination an 86-character string beginning with "gv-" and ending 219 with ".domainverify.googlehosted.com.". 221 To verify a subdomain, the unique 12-character string is appended 222 with the subdomain name for "Host" field for e.g. 223 JLKDER712AFP.subdomain where subdomain is the subdomain being 224 verified. 226 3.2.1.2. AWS Certificate Manager (ACM) 228 To get issued a certificate by AWS Certificate Manager (ACM), you can 229 create a CNAME record to verify domain ownership [ACM-CNAME]. The 230 record name for the CNAME looks like: 232 `\_.example.com. IN CNAME \_RANDOM-TOKEN.acm-validations.aws.` 234 Note that if there are more than 5 CNAMEs being chained, then this 235 method does not work. 237 3.3. Common Patterns 239 3.3.1. Name 241 ACME and GitHub have a suffix of _PROVIDER_NAME-challenge in the Name 242 field of the TXT record challenge. For ACME, the full Host is _acme- 243 challenge., while for GitHub it is _github-challenge- 244 ORGANIZATION-. Both these patterns are useful for doing 245 targeted domain verification, as discussed in section (#targeted- 246 domain-verification) because if the provider knows what it is looking 247 for (domain in the case of ACME, organization name + domain in case 248 of GitHub) it can specifically do a DNS query for that TXT record, as 249 opposed to having to do a TXT query for the apex. 251 ACME does the same name construction for CNAME records. 253 3.3.2. RDATA 255 One pattern that quite a few providers follow (Dropbox, Atlassian) is 256 constructing the rdata of the TXT DNS record in the form of PROVIDER- 257 SERVICE-domain-verification= followed by the random value being 258 checked for. This is in accordance with [RFC1464] which mandates 259 that attributes must be stored as key-value pairs. 261 4. Recommendations 263 4.1. Targeted Domain Verification 265 The TXT record being used for domain verification is most commonly 266 placed at the domain name being verified. For example, if 267 example.com is being verified, then the DNS TXT record will have 268 example.com in the Name section. Unfortunately, this practise does 269 not scale very well. 271 Many services are now attempting to verify domain names, causing many 272 of these TXT records to be placed at that same location at the top of 273 the domain (the APEX). 275 When a DNS administrator sees 15 DNS TXT records for their domain 276 based on only random letters, they can no longer determine for which 277 service or vendor the DNS TXT records were added. This causes 278 administrators to leave all DNS TXT records in there, as they want to 279 avoid breaking a service. Over time, the domain ends up with a lot 280 of no longer needed, unknown and untracable DNS TXT records. 282 An operational issue arises from the DNS protocol only being able to 283 query for "all TXT records" at a single location. If multiple 284 services all require TXT records, this can cause the DNS answer for 285 TXT records to become very large. It has been observed that some 286 well known domains had so many services deployed that their DNS TXT 287 answer did not fit in a single UDP DNS packet. This results in 288 fragmentation which is known to be vulnerable to various attacks 289 draft-ietf-dnsop-avoid-fragmentation-06. It can also lead to UDP 290 packet truncation, causing a retry over TCP. Not all networks 291 properly transport DNS over TCP and some DNS software mistakenly 292 believe TCP support is optional draft-ietf-dnsop-dns-tcp- 293 requirements-15. 295 4.2. Targeted Service Verification 297 One malicious service that promises to deliver something after domain 298 verification could surreptitiously ask another service provider to 299 start processing or sending mail for the target domain and then 300 present the victim domain administrator with this DNS TXT record 301 pretending to be for their service. Once the administrator has added 302 the DNS TXT record, instead of getting their service, their domain is 303 now certifying another service of which they are not aware they are 304 now a consumer. 306 If services use a clear description and name attribution in the 307 required DNS TXT record, this can be avoided. For example by 308 requiring a DNS TXT record at _vendorname.example.com instead of at 309 example.com, a malicious service could no longer replay this without 310 the DNS administrator noticing this. The LetsEncrypt ACME challenge 311 uses this method. 313 4.3. TXT vs CNAME 315 The inherent problem of a CNAME is that it cannot co-exist with any 316 other data. What happens when both a CNAME and other data such as a 317 TXT record or NS record exist depends on the DNS implementation. But 318 most likely, either the CNAME or the other records will be silently 319 ignored. The user interface for adding a record might not check for 320 this. It might also break in unexpected ways. If a CNAME is added 321 for continuous authorization, and for another service a TXT record is 322 added, the TXT record might work but the CNAME record might break. 324 Operational experience has also shown a vendor that provides two 325 difference services, one requiring a CNAME and one requiring a TXT 326 record for authorization that needed to be deployed at the same 327 location. If both services would have used a TXT record, this would 328 not have caused any problems. 330 Another issues with CNAME records is that they MUST NOT point to 331 another CNAME. But where this might be true in an initial 332 deployment, if the target that the CNAME points to is changed from a 333 non-CNAME record to a CNAME record, some DNS software might no longer 334 resolve this as expected. 336 Early web based DNS administration tools did not always have the TXT 337 record available in a pulldown menu for DNS record types, while CNAME 338 would be available. However as many anti-spam meassures now require 339 TXT records, this support is now generally available. It is 340 recommended that the CNAME method is only used for delegating 341 authorization to an actual subdomain, for example: 343 recruitement.example.com. IN CNAME example.recruitement-vendor.com. 345 4.4. Time-bound checking 347 After domain verification is done, there is no need for the TXT or 348 CNAME record to continue to exist as the presence of the domain- 349 verifying DNS record for a service only implies that a user with 350 access to the service also has DNS control of the domain at the time 351 the code was generated. It should be safe to remove the verifying 352 DNS record once the verification is done and the service provider 353 doing the verification should specify how long the verification will 354 take (i.e. after how much time can the verifying DNS record be 355 deleted). However, despite this, some services ask the record to 356 exist in perpetuity [ATLASSIAN-VERIFY]. 358 If a provider will use the DNS TXT record only for a one-time 359 verification, it is RECOMMENDED that they clearly indicate this in 360 the RDATA of the TXT record, so a DNS administrator at the target 361 domain can easilly spot an obsolete record in the future. For 362 example: 364 _provider-token.example.com. IN TXT "type=activation_only 365 expiry=2023-10-12 token=TOKENDATA" 367 If a provider requires the continued precense of the TXT record as 368 proof that the domain owner is still authorizing the service, this 369 should also be clear from the TXT record RDATA. For example: 371 _provider-service.example.com. IN TXT "type=continued_service 372 expiry=never token=TOKENDATA" 374 5. Email sending authorization 376 Some vendors use a hosted service that wants to generate emails that 377 appear to be from the customer. When a customer has deployed anti- 378 spam meassures such as DKIM [RFC6376], DMARC [RFC7489] or SPF 379 [RFC7208], the vendor's mail service needs to be added to the list of 380 allowed mail servers. However, some customers might not want to give 381 permission for a vendor to send emails from their entire domain. It 382 is recommended that a vendor uses a subdomain. If the vendor's 383 domain is example-vendor.com, and the customer domain is example- 384 customer.com, the vendor could use the subdomain example- 385 customer.example-vendor.com to send emails. Alternatively, the 386 customer could delegate a subdomain example-vendor.example- 387 customer.com to the vendoer for email sending, as those email 388 addresses would have a stronger origin appearance of being emails 389 send by the customer to their clients. 391 Besides requiring proof of ownership of the domain, the customer 392 needs to authorize the hosted service to send email on their behalf. 394 6. Security Considerations 396 Both the provider and the service being authenticated and authorized 397 should be obvious from the TXT content to prevent malicious services 398 from misleading the domain owner into certifying a different provider 399 or service. 401 It is RECOMMENDED that DNSSEC [RFC4033] is employed by the domain 402 owner. A service provider MUST enable DNSSEC validation when 403 verifying doman name challanges to protect against domain name 404 spoofing. 406 7. Operational Considerations 408 It is often consumers of the provider services that are not DNS 409 experts that need to relay information from a provider's website to 410 their local DNS administrators. The exact DNS record type, content 411 and location is often not clear when the DNS administrator receives 412 the information. It is RECOMMENDED that providers offer extremely 413 detailed help pages, that are accessible without needing a login on 414 the provider website, as the DNS adminstrator often has no login 415 account on the provider service website. It is recommended that any 416 instructions given by the provider contains the entire DNS record 417 using a Fully Qualified Domain Name (FQDN). 419 8. IANA Considerations 421 This document has no IANA actions. 423 9. References 425 9.1. Normative References 427 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 428 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 429 . 431 [RFC1035] Mockapetris, P., "Domain names - implementation and 432 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 433 November 1987, . 435 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 436 Arbitrary String Attributes", RFC 1464, 437 DOI 10.17487/RFC1464, May 1993, 438 . 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, 442 DOI 10.17487/RFC2119, March 1997, 443 . 445 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 446 Rose, "DNS Security Introduction and Requirements", 447 RFC 4033, DOI 10.17487/RFC4033, March 2005, 448 . 450 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 451 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 452 May 2017, . 454 9.2. Informative References 456 [ACM-CNAME] 457 AWS, "Option 1: DNS Validation", n.d., 458 . 461 [ATLASSIAN-VERIFY] 462 Atlassian, "Verify over DNS", n.d., 463 . 467 [GITHUB-TXT] 468 GitHub, "Verifying your organization's domain", n.d., 469 . 473 [GOOGLE-WORKSPACE-CNAME] 474 Google, "CNAME record values", n.d., 475 . 477 [GOOGLE-WORKSPACE-TXT] 478 Google, "TXT record values", n.d., 479 . 481 [LETSENCRYPT] 482 Let's Encrypt, "Challenge Types: DNS-01 challenge", 2020, 483 . 486 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 487 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 488 RFC 6376, DOI 10.17487/RFC6376, September 2011, 489 . 491 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 492 Authorizing Use of Domains in Email, Version 1", RFC 7208, 493 DOI 10.17487/RFC7208, April 2014, 494 . 496 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 497 Message Authentication, Reporting, and Conformance 498 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 499 . 501 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 502 Kasten, "Automatic Certificate Management Environment 503 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 504 . 506 Acknowledgments 508 TODO 510 Authors' Addresses 512 Shivan Sahib 513 Brave Software 514 Email: shivankaulsahib@gmail.com 515 Shumon Huque 516 Salesforce 517 Email: shuque@gmail.com 519 Paul Wouters 520 Aiven 521 Email: paul.wouters@aiven.io