< draft-sahib-domain-verification-techniques-01.txt		draft-sahib-domain-verification-techniques-02.txt >
	Network Working Group S. Sahib		Network Working Group S. Sahib
	Internet-Draft S. Huque		Internet-Draft Brave Software
	Intended status: Informational Salesforce		Intended status: Informational S. Huque
	Expires: 17 October 2021 15 April 2021		Expires: 12 December 2021 Salesforce
			10 June 2021
	Survey of Domain Verification Techniques using DNS		Survey of Domain Verification Techniques using DNS
	draft-sahib-domain-verification-techniques-01		draft-sahib-domain-verification-techniques-02
	Abstract		Abstract
	Verification of ownership of domains in the Domain Name System (DNS)		Many services on the Internet need to verify ownership or control of
	[RFC1034] [RFC1035] often relies on adding or editing DNS records		domains in the Domain Name System (DNS) [RFC1034] [RFC1035]. This
	within the domain. This document surveys various techniques in wide		verification often relies on adding or editing DNS records within the
	use today, the pros and cons of each, and possible improvements.		domain. This document surveys various techniques in wide 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 page 1, line 41 ¶		skipping to change at page 1, line 43 ¶
	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 17 October 2021.		This Internet-Draft will expire on 12 December 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
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	3.1. TXT based . . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. TXT based . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 4		3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. CNAME based . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. CNAME based . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 5		3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Common Patterns . . . . . . . . . . . . . . . . . . . . . 5		3.3. Common Patterns . . . . . . . . . . . . . . . . . . . . . 5
	3.3.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 5		3.3.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3.2. RDATA . . . . . . . . . . . . . . . . . . . . . . . . 6		3.3.2. RDATA . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6		4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Targeted Domain Verification . . . . . . . . . . . . . . 6		4.1. Targeted Domain Verification . . . . . . . . . . . . . . 6
	4.2. TXT vs CNAME . . . . . . . . . . . . . . . . . . . . . . 6		4.2. TXT vs CNAME . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Continuous checking . . . . . . . . . . . . . . . . . . . 7		4.3. Time-bound checking . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . 7		7.1. Normative References . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . 8
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	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
	DNS records. This document focuses on DNS techniques for domain		DNS records. This document focuses on DNS techniques for domain
	verification; other techniques (such as email or HTML verification)		verification; other techniques (such as email or HTML verification)
	are out-of-scope.		are out-of-scope.
	In practice, DNS-based verification often looks like the provider		In practice, DNS-based verification often takes the form of the
	generating a random value and asking the requester to create a DNS		provider generating a random value visible only to the requester, and
	record containing this random value and placing it at a location that		then asking the requester to create a DNS record containing this
	the provider can query for. Generally only one temporary DNS record		random value and placing it at a location that the provider can query
	is sufficient for proving domain ownership.		for. Generally only one temporary DNS record 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		Provider: an internet-based provider of a service, for e.g., Let's
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 37 ¶
	3.1. TXT based		3.1. TXT based
	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-237943648324687364"
	Here, the value "bar" for the attribute "foo-verification" serves as		Here, the value "bar-bar-237943648324687364" for the attribute "foo-
	the randomly-generated TXT value being added to prove ownership of		verification" serves as the randomly-generated TXT value being added
	the domain to Foo provider. Although the original DNS protocol		to prove ownership of the domain to Foo provider. Although the
	specifications did not associate any semantics with the DNS TXT		original DNS protocol specifications did not associate any semantics
	record, [RFC1464] describes how to use them to store attributes in		with the DNS TXT record, [RFC1464] describes how to use them to store
	the form of ASCII text key-value pairs for a particular domain. In		attributes in the form of ASCII text key-value pairs for a particular
	practice, there is wide variation in the content of DNS TXT records		domain. In practice, there is wide variation in the content of DNS
	used for domain verification, and they often do not follow the key-		TXT records used for domain verification, and they often do not
	value pair model. Even so, the rdata portion of the DNS TXT record		follow the key-value pair model. Even so, the rdata portion of the
	has to contain the value being used to verify the domain. The value		DNS TXT record has to contain the value being used to verify the
	is usually a randomly-generated token in order to guarantee that the		domain. The value is usually a randomly-generated token in order to
	entity who requested that the domain be verified (i.e. the person		guarantee that the entity who requested that the domain be verified
	managing the account at Foo provider) is the one who has (direct or		(i.e. the person managing the account at Foo provider) is the one who
	delegated) access to DNS records for the domain. The generated token		has (direct or delegated) access to DNS records for the domain. The
	typically expires in a few days. The TXT record is usually placed at		generated token typically expires in a few days. The TXT record is
	the domain being verified ("example.com" in the example above).		usually placed at the domain being verified ("example.com" in the
	After a TXT record has been added, the service provider will usually		example above). After a TXT record has been added, the service
	take some time to verify that the DNS TXT record with the expected		provider will usually take some time to verify that the DNS TXT
	token exists for the domain.		record with the expected token exists for the domain.
	The same domain name can have multiple distinct TXT records (a TXT		The same domain name can have multiple distinct TXT records (a TXT
	Record Set).		Record Set), where each TXT record may be associated with a distinct
			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 page 6, line 34 ¶		skipping to change at page 6, line 34 ¶
	"example.com" is being verified, then the DNS TXT record will have		"example.com" is being verified, then the DNS TXT record will have
	"example.com" in the Name section.		"example.com" in the Name section.
	If many services are attempting to verify the domain name, many		If many services are attempting to verify the domain name, many
	distinct TXT records end up being placed at that name. There is no		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,		way to surgically query only the TXT record for a specific service,
	resulting in extra work for a verifying service to sift through the		resulting in extra work for a verifying service to sift through the
	records for its own domain verification record. In addition, since		records for its own domain verification record. In addition, since
	DNS Resource Record sets are treated atomically, all TXT records must		DNS Resource Record sets are treated atomically, all TXT records must
	be returned to the querier, which leads to a bloating of DNS		be returned to the querier, which leads to a bloating of DNS
	responses. This could cause truncation and expensive retrying over		responses. This could cause truncation and retrying DNS queries over
	TCP.		TCP, which is more resource intensive.
	A better method is to place the TXT record at a subdomain of the		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		domain being verified that is specially reserved for use by the
	application service in question.		application service in question. The LetsEncrypt ACME challenge
			mentioned earlier uses this method.
	4.2. TXT vs CNAME		4.2. TXT vs CNAME
	TODO		TODO
	4.3. Continuous checking		4.3. Time-bound checking
	After domain verification is done, there is no need for the TXT or		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		CNAME record to continue to exist as the presence of the domain-
	verifying DNS record for a service only implies that a user with		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		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		the code was generated. It should be safe to remove the verifying
	DNS record once the verification is done. However, despite this,		DNS record once the verification is done and the service provider
	some services ask the record to exist in perpetuity		doing the verification should specify how long the verification will
	[ATLASSIAN-VERIFY].		take (i.e. after how much time can the verifying DNS record be
			deleted). 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., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<https://www.rfc-editor.org/info/rfc1034>.		<https://www.rfc-editor.org/rfc/rfc1034>.
	[RFC1035] Mockapetris, P., "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://www.rfc-editor.org/info/rfc1035>.		November 1987, <https://www.rfc-editor.org/rfc/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://www.rfc-editor.org/info/rfc1464>.		<https://www.rfc-editor.org/rfc/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://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/rfc/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://www.rfc-editor.org/info/rfc4033>.		<https://www.rfc-editor.org/rfc/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://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/rfc/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]
	Atlassian, ., "Verify over DNS", n.d.,		Atlassian, ., "Verify over DNS", n.d.,
	skipping to change at page 8, line 44 ¶		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://www.rfc-editor.org/info/rfc8555>.		<https://www.rfc-editor.org/rfc/rfc8555>.
	Acknowledgments		Acknowledgments
	TODO		TODO
	Authors' Addresses		Authors' Addresses
	Shivan Sahib		Shivan Sahib
	Salesforce		Brave Software
	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. 22 change blocks.
	52 lines changed or deleted		59 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/