< draft-sahib-domain-verification-techniques-00.txt		draft-sahib-domain-verification-techniques-01.txt >
	Network Working Group S. Sahib		Network Working Group S. Sahib
	Internet-Draft S. Huque		Internet-Draft S. Huque
	Intended status: Informational Salesforce		Intended status: Informational Salesforce
	Expires: 11 September 2021 10 March 2021		Expires: 17 October 2021 15 April 2021
	Survey of Domain Verification Techniques using DNS		Survey of Domain Verification Techniques using DNS
	draft-sahib-domain-verification-techniques-00		draft-sahib-domain-verification-techniques-01
	Abstract		Abstract
	Verification of ownership of domains in the Domain Name System (DNS)		Verification of ownership of domains in the Domain Name System (DNS)
	[RFC1034] [RFC1035] often relies on adding or editing DNS records		[RFC1034] [RFC1035] often relies on adding or editing DNS records
	within the domain. This document lays out the various techniques and		within the domain. This document surveys various techniques in wide
	the pros and cons of each.		use today, the pros and cons of each, and possible improvements.
	Discussion Venues		Discussion Venues
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Source for this draft and an issue tracker can be found at		Source for this draft and an issue tracker can be found at
	https://github.com/ShivanKaul/draft-sahib-domain-verification-		https://github.com/ShivanKaul/draft-sahib-domain-verification-
	techniques.		techniques.
	Status of This Memo		Status of This Memo
	skipping to change at line 40 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 11 September 2021.		This Internet-Draft will expire on 17 October 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions and Definitions		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	3. Verification Techniques		3. Verification Techniques . . . . . . . . . . . . . . . . . . . 3
	3.1. TXT based		3.1. TXT based . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1.1. Examples		3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. CNAME based		3.2. CNAME based . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2.1. Examples		3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 5
	4. Recommendations		3.3. Common Patterns . . . . . . . . . . . . . . . . . . . . . 5
	4.1. TXT vs CNAME		3.3.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. TXT recommendations		3.3.2. RDATA . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. CNAME recommendations		4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations		4.1. Targeted Domain Verification . . . . . . . . . . . . . . 6
	6. IANA Considerations		4.2. TXT vs CNAME . . . . . . . . . . . . . . . . . . . . . . 6
	7. References		4.3. Continuous checking . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	Acknowledgments		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses		7.1. Normative References . . . . . . . . . . . . . . . . . . 7
			7.2. Informative References . . . . . . . . . . . . . . . . . 8
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	Many providers on the internet need users to prove that they control		Many providers on the internet need users to prove that they control
	a particular domain before granting them some sort of privilege		a particular domain before granting them some sort of privilege
	associated with that domain. For instance, certificate authorities		associated with that domain. For instance, certificate authorities
	like Let's Encrypt [LETSENCRYPT] ask requesters of TLS certificates		like Let's Encrypt [LETSENCRYPT] ask requesters of TLS certificates
	to prove that they operate the domain they're requesting the		to prove that they operate the domain they're requesting the
	certificate for. Providers generally allow for several different		certificate for. Providers generally allow for several different
	ways of proving domain control, some of which include manipulating		ways of proving domain control, some of which include manipulating
	skipping to change at line 104 ¶		skipping to change at page 3, line 19 ¶
	is sufficient for proving domain ownership.		is sufficient for proving domain ownership.
	2. Conventions and Definitions		2. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
			Provider: an internet-based provider of a service, for e.g., Let's
			Encrypt provides a certificate authority service or GitHub provides
			code-hosting services. These services often require a user to verify
			that they control a domain.
	3. Verification Techniques		3. Verification Techniques
	3.1. TXT based		3.1. TXT based
	Although the original DNS protocol specifications did not associate
	any semantics with the DNS TXT record, [RFC1464] describes how to use
	them to store attributes in the form of ASCII text key-value pairs
	for a particular domain.
	host.widgets.com IN TXT "printer=lpr5"
	In practice, there is wide variation in the content of DNS TXT
	records used for domain verification, and they often do not follow
	the key-value pair model.
	The same domain name can have multiple distinct TXT records (a TXT
	Record Set).
	TXT record-based DNS domain verification is usually the default		TXT record-based DNS domain verification is usually the default
	option for DNS verification. The service provider asks the user to		option for DNS verification. The service provider asks the user to
	add a DNS TXT record (perhaps through their domain host or DNS		add a DNS TXT record (perhaps through their domain host or DNS
	provider) at the domain with a certain value. Then, the service		provider) at the domain with a certain value. Then, the service
	provider does a DNS TXT query for the domain being verified and		provider does a DNS TXT query for the domain being verified and
	checks that the value exists. For example, this is what a DNS TXT		checks that the value exists. For example, this is what a DNS TXT
	verification record could look like:		verification record could look like:
	example.com. IN TXT "foo-verification=bar"		example.com. IN TXT "foo-verification=bar"
	Here, the value "bar" for the attribute "foo-verification" serves as		Here, the value "bar" for the attribute "foo-verification" serves as
	the randomly-generated TXT value being added to prove ownership of		the randomly-generated TXT value being added to prove ownership of
	the domain to Foo provider. The value is usually a randomly-		the domain to Foo provider. Although the original DNS protocol
	generated token in order to guarantee that the entity who requested		specifications did not associate any semantics with the DNS TXT
	that the domain be verified (i.e. the person managing the account at		record, [RFC1464] describes how to use them to store attributes in
	Foo provider) is the one who has (direct or delegated) access to DNS		the form of ASCII text key-value pairs for a particular domain. In
	records for the domain. The generated token typically expires in a		practice, there is wide variation in the content of DNS TXT records
	few days. The TXT record is usually placed at the domain being		used for domain verification, and they often do not follow the key-
	verified ("example.com" in the example above). After a TXT record		value pair model. Even so, the rdata portion of the DNS TXT record
	has been added, the service provider will usually take some time to		has to contain the value being used to verify the domain. The value
	verify that the DNS TXT record with the expected token exists for the		is usually a randomly-generated token in order to guarantee that the
	domain.		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. The generated token
			typically expires in a few days. The TXT record is usually placed at
			the domain being verified ("example.com" in the example above).
			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.
	One drawback of this method is that the TXT record is typically		The same domain name can have multiple distinct TXT records (a TXT
	placed at the domain name being verified. If many services are		Record Set).
	attempting to verify the domain name, many distinct TXT records end
	up being placed at that name. Since DNS Resource Record sets are
	treated atomically, all TXT records must be returned to the querier,
	increasing the size of the response. There is no way to surgically
	query only the TXT record for a specific service.
	3.1.1. Examples		3.1.1. Examples
	3.1.1.1. Let's Encrypt		3.1.1.1. Let's Encrypt
	Let's Encrypt [LETSENCRYPT] has a challenge type "DNS-01" that lets a		Let's Encrypt [LETSENCRYPT] has a challenge type "DNS-01" that lets a
	user prove domain ownership in accordance with the ACME protocol		user prove domain ownership in accordance with the ACME protocol
	[RFC8555]. In this challenge, Let's Encrypt asks you to create a TXT		[RFC8555]. In this challenge, Let's Encrypt asks you to create a TXT
	record with a randomly-generated token at "_acme-		record with a randomly-generated token at "_acme-
	challenge.<YOUR_DOMAIN>". For example, if you wanted to prove domain		challenge.<YOUR_DOMAIN>". For example, if you wanted to prove domain
	skipping to change at line 182 ¶		skipping to change at page 4, line 41 ¶
	administrative account and obtain their verification token as part of		administrative account and obtain their verification token as part of
	the setup process for Google Workspace. The verification token is a		the setup process for Google Workspace. The verification token is a
	68-character string that begins with "google-site-verification=",		68-character string that begins with "google-site-verification=",
	followed by 43 characters. Google recommends a TTL of 3600 seconds.		followed by 43 characters. Google recommends a TTL of 3600 seconds.
	The owner name of the TXT record is the domain or subdomain neme		The owner name of the TXT record is the domain or subdomain neme
	being verified.		being verified.
	3.1.1.3. GitHub		3.1.1.3. GitHub
	GitHub asks you to create a DNS TXT record under "_github-challenge-		GitHub asks you to create a DNS TXT record under "_github-challenge-
	ORGANIZATION-<your-domain>", where ORGANIZATION stands for the GitHub		ORGANIZATION-<YOUR_DOMAIN>", where ORGANIZATION stands for the GitHub
	organization name [GITHUB-TXT]. The code is a numeric code that		organization name [GITHUB-TXT]. The code is a numeric code that
	expires in 7 days.		expires in 7 days.
	3.2. CNAME based		3.2. CNAME based
	Less commonly than TXT record verification, service providers also		Less commonly than TXT record verification, service providers also
	provide the ability to verify domain ownership via CNAME records.		provide the ability to verify domain ownership via CNAME records.
	This is used in case the user cannot create TXT records. One common		This is used in case the user cannot create TXT records. One common
	reason is that the domain name may already have CNAME record that		reason is that the domain name may already have CNAME record that
	aliases it to a 3rd-party target domain. CNAMEs have a technical		aliases it to a 3rd-party target domain. CNAMEs have a technical
	restriction that no other record types can be placed along side them		restriction that no other record types can be placed along side them
	at the same domain name ([RFC1034], Section 3.6.2).. The CNAME based		at the same domain name ([RFC1034], Section 3.6.2).. The CNAME based
	domain verification method teypically uses a randomized label		domain verification method typically uses a randomized label
	prepended to the domain name being verified.		prepended to the domain name being verified.
	3.2.1. Examples		3.2.1. Examples
	3.2.1.1. Google		3.2.1.1. Google
	[GOOGLE-WORKSPACE-CNAME] lets you specify a CNAME record for		[GOOGLE-WORKSPACE-CNAME] lets you specify a CNAME record for
	verifying domain ownership. The user gets a unique 12-character		verifying domain ownership. The user gets a unique 12-character
	string that is added as "Host", with TTL 3600 (or default) and		string that is added as "Host", with TTL 3600 (or default) and
	Destination an 86-character string beginning with "gv-" and ending		Destination an 86-character string beginning with "gv-" and ending
	skipping to change at line 224 ¶		skipping to change at page 5, line 43 ¶
	To get issued a certificate by AWS Certificate Manager (ACM), you can		To get issued a certificate by AWS Certificate Manager (ACM), you can
	create a CNAME record to verify domain ownership [ACM-CNAME]. The		create a CNAME record to verify domain ownership [ACM-CNAME]. The
	record name for the CNAME looks like "_<random-token1>.example.com",		record name for the CNAME looks like "_<random-token1>.example.com",
	which would point to "_<random-token2>.<random-token3>.acm-		which would point to "_<random-token2>.<random-token3>.acm-
	validations.aws."		validations.aws."
	Note that if there are more than 5 CNAMEs being chained, then this		Note that if there are more than 5 CNAMEs being chained, then this
	method does not work.		method does not work.
			3.3. Common Patterns
			3.3.1. Name
			ACME and GitHub have a suffix of "_PROVIDER_NAME-challenge" in the
			Name field of the TXT record challenge. For ACME, the full Host is
			"_acme-challenge.<YOUR_DOMAIN>", while for GitHub it is "_github-
			challenge-ORGANIZATION-<YOUR_DOMAIN>". Both these patterns are
			useful for doing targeted domain verification, as discussed in
			section (#targeted-domain-verification) because if the provider knows
			what it is looking for (domain in the case of ACME, organization name
			+ domain in case of GitHub) it can specifically do a DNS query for
			that TXT record, as opposed to having to do a TXT query for the apex.
			ACME does the same name construction for CNAME records.
			3.3.2. RDATA
			One pattern that quite a few providers follow (Dropbox, Atlassian) is
			constructing the rdata of the TXT DNS record in the form of
			"PROVIDER-SERVICE-domain-verification=" followed by the random value
			being checked for. This is in accordance with [RFC1464] which
			mandates that attributes must be stored as key-value pairs.
	4. Recommendations		4. Recommendations
	4.1. TXT vs CNAME		4.1. Targeted Domain Verification
	4.2. TXT recommendations		The TXT record being used for domain verification is most commonly
			placed at the domain name being verified. For example, if
			"example.com" is being verified, then the DNS TXT record will have
			"example.com" in the Name section.
	4.3. CNAME recommendations		If many services are attempting to verify the domain name, many
			distinct TXT records end up being placed at that name. There is no
			way to surgically query only the TXT record for a specific service,
			resulting in extra work for a verifying service to sift through the
			records for its own domain verification record. In addition, since
			DNS Resource Record sets are treated atomically, all TXT records must
			be returned to the querier, which leads to a bloating of DNS
			responses. This could cause truncation and expensive retrying over
			TCP.
			A better method is to place the TXT record at a subdomain of the
			domain being verified that is specially reserved for use by the
			application service in question.
			4.2. TXT vs CNAME
			TODO
			4.3. Continuous checking
			After domain verification is done, there is no need for the TXT or
			CNAME record to continue to exist as the existence of the domain
			verifying 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 verifying
			DNS record once the verification is done. However, despite this,
			some services ask the record to exist in perpetuity
			[ATLASSIAN-VERIFY].
	5. Security Considerations		5. Security Considerations
	DNSSEC [RFC4033] should be employed by the domain owner to protect		DNSSEC [RFC4033] should be employed by the domain owner to protect
	against domain name spoofing.		against domain name spoofing.
	6. IANA Considerations		6. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC1034] Mockapetris, P.V., "Domain names - concepts and		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	November 1987, <https://doi.org/10.17487/RFC1034>.		<https://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P.V., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://doi.org/10.17487/RFC1035>.		November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store		[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
	Arbitrary String Attributes", RFC 1464,		Arbitrary String Attributes", RFC 1464,
	DOI 10.17487/RFC1464, May 1993,		DOI 10.17487/RFC1464, May 1993,
	<https://doi.org/10.17487/RFC1464>.		<https://www.rfc-editor.org/info/rfc1464>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://doi.org/10.17487/RFC2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	RFC 4033, DOI 10.17487/RFC4033, March 2005,		RFC 4033, DOI 10.17487/RFC4033, March 2005,
	<https://doi.org/10.17487/RFC4033>.		<https://www.rfc-editor.org/info/rfc4033>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://doi.org/10.17487/RFC8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References		7.2. Informative References
	[ACM-CNAME]		[ACM-CNAME]
	AWS, ., "Option 1: DNS Validation", n.d.,		AWS, ., "Option 1: DNS Validation", n.d.,
	<https://docs.aws.amazon.com/acm/latest/userguide/dns-		<https://docs.aws.amazon.com/acm/latest/userguide/dns-
	validation.html>.		validation.html>.
			[ATLASSIAN-VERIFY]
			Atlassian, ., "Verify over DNS", n.d.,
			<https://support.atlassian.com/user-management/docs/
			verify-a-domain-to-manage-
			accounts/#Verifyadomainforyourorganization-VerifyoverDNS>.
	[GITHUB-TXT]		[GITHUB-TXT]
	GitHub, ., "Verifying your organization's domain", n.d.,		GitHub, ., "Verifying your organization's domain", n.d.,
	<https://docs.github.com/en/github/setting-up-and-		<https://docs.github.com/en/github/setting-up-and-
	managing-organizations-and-teams/verifying-your-		managing-organizations-and-teams/verifying-your-
	organizations-domain>.		organizations-domain>.
	[GOOGLE-WORKSPACE-CNAME]		[GOOGLE-WORKSPACE-CNAME]
	Google, ., "CNAME record values", n.d.,		Google, ., "CNAME record values", n.d.,
	<https://support.google.com/a/answer/112038>.		<https://support.google.com/a/answer/112038>.
	skipping to change at line 301 ¶		skipping to change at page 8, line 44 ¶
	<https://support.google.com/a/answer/2716802>.		<https://support.google.com/a/answer/2716802>.
	[LETSENCRYPT]		[LETSENCRYPT]
	Let's Encrypt, ., "Challenge Types: DNS-01 challenge",		Let's Encrypt, ., "Challenge Types: DNS-01 challenge",
	2020, <https://letsencrypt.org/docs/challenge-types/#dns-		2020, <https://letsencrypt.org/docs/challenge-types/#dns-
	01-challenge>.		01-challenge>.
	[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.		[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
	Kasten, "Automatic Certificate Management Environment		Kasten, "Automatic Certificate Management Environment
	(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,		(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
	<https://doi.org/10.17487/RFC8555>.		<https://www.rfc-editor.org/info/rfc8555>.
	Acknowledgments		Acknowledgments
	TODO		TODO
	Authors' Addresses		Authors' Addresses
	Shivan Sahib		Shivan Sahib
	Salesforce		Salesforce
	Email: shivankaulsahib@gmail.com		Email: shivankaulsahib@gmail.com
	Shumon Huque		Shumon Huque
	Salesforce		Salesforce
	Email: shuque@gmail.com		Email: shuque@gmail.com
End of changes. 25 change blocks.
	70 lines changed or deleted		125 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/