< draft-ietf-add-ddr-03.txt		draft-ietf-add-ddr-04.txt >
	ADD T. Pauly		ADD T. Pauly
	Internet-Draft E. Kinnear		Internet-Draft E. Kinnear
	Intended status: Standards Track Apple Inc.		Intended status: Standards Track Apple Inc.
	Expires: 4 April 2022 C.A. Wood		Expires: 19 May 2022 C.A. Wood
	Cloudflare		Cloudflare
	P. McManus		P. McManus
	Fastly		Fastly
	T. Jensen		T. Jensen
	Microsoft		Microsoft
	1 October 2021		15 November 2021
	Discovery of Designated Resolvers		Discovery of Designated Resolvers
	draft-ietf-add-ddr-03		draft-ietf-add-ddr-04
	Abstract		Abstract
	This document defines Discovery of Designated Resolvers (DDR), a		This document defines Discovery of Designated Resolvers (DDR), a
	mechanism for DNS clients to use DNS records to discover a resolver's		mechanism for DNS clients to use DNS records to discover a resolver's
	encrypted DNS configuration. This mechanism can be used to move from		encrypted DNS configuration. This mechanism can be used to move from
	unencrypted DNS to encrypted DNS when only the IP address of a		unencrypted DNS to encrypted DNS when only the IP address of a
	resolver is known. This mechanism is designed to be limited to cases		resolver is known. This mechanism is designed to be limited to cases
	where unencrypted resolvers and their designated resolvers are		where unencrypted resolvers and their designated resolvers are
	operated by the same entity or cooperating entities. It can also be		operated by the same entity or cooperating entities. It can also be
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 4 April 2022.		This Internet-Draft will expire on 19 May 2022.
	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 34 ¶		skipping to change at page 2, line 34 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Specification of Requirements . . . . . . . . . . . . . . 3		1.1. Specification of Requirements . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. DNS Service Binding Records . . . . . . . . . . . . . . . . . 4		3. DNS Service Binding Records . . . . . . . . . . . . . . . . . 4
	4. Discovery Using Resolver IP Addresses . . . . . . . . . . . . 5		4. Discovery Using Resolver IP Addresses . . . . . . . . . . . . 5
	4.1. Use of Designated Resolvers . . . . . . . . . . . . . . . 6		4.1. Use of Designated Resolvers . . . . . . . . . . . . . . . 6
	4.2. Authenticated Discovery . . . . . . . . . . . . . . . . . 6		4.2. Verified Discovery . . . . . . . . . . . . . . . . . . . 6
	4.3. Opportunistic Discovery . . . . . . . . . . . . . . . . . 7		4.3. Opportunistic Discovery . . . . . . . . . . . . . . . . . 7
	5. Discovery Using Resolver Names . . . . . . . . . . . . . . . 7		5. Discovery Using Resolver Names . . . . . . . . . . . . . . . 7
	6. Deployment Considerations . . . . . . . . . . . . . . . . . . 8		6. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
	6.1. Caching Forwarders . . . . . . . . . . . . . . . . . . . 8		6.1. Caching Forwarders . . . . . . . . . . . . . . . . . . . 8
	6.2. Certificate Management . . . . . . . . . . . . . . . . . 9		6.2. Certificate Management . . . . . . . . . . . . . . . . . 9
			6.3. Server Name Handling . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Special Use Domain Name "resolver.arpa" . . . . . . . . . 10		8.1. Special Use Domain Name "resolver.arpa" . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Rationale for using SVCB records . . . . . . . . . . 12		Appendix A. Rationale for using SVCB records . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	resolver's IP address during configuration. Such mechanisms include		resolver's IP address during configuration. Such mechanisms include
	network provisioning protocols like DHCP [RFC2132] and IPv6 Router		network provisioning protocols like DHCP [RFC2132] and IPv6 Router
	Advertisement (RA) options [RFC8106], as well as manual		Advertisement (RA) options [RFC8106], as well as manual
	configuration.		configuration.
	This document defines two mechanisms for clients to discover		This document defines two mechanisms for clients to discover
	designated resolvers using DNS server Service Binding (SVCB,		designated resolvers using DNS server Service Binding (SVCB,
	[I-D.ietf-dnsop-svcb-https]) records:		[I-D.ietf-dnsop-svcb-https]) records:
	1. When only an IP address of an Unencrypted Resolver is known, the		1. When only an IP address of an Unencrypted Resolver is known, the
	client queries a special use domain name to discover DNS SVCB		client queries a special use domain name (SUDN) [RFC6761] to
	records associated with one or more Encrypted Resolvers the		discover DNS SVCB records associated with one or more Encrypted
	Unencrypted Resolver has designated for use when support for DNS		Resolvers the Unencrypted Resolver has designated for use when
	encryption is requested (Section 4).		support for DNS encryption is requested (Section 4).
	2. When the hostname of an Encrypted Resolver is known, the client		2. When the hostname of an Encrypted Resolver is known, the client
	requests details by sending a query for a DNS SVCB record. This		requests details by sending a query for a DNS SVCB record. This
	can be used to discover alternate encrypted DNS protocols		can be used to discover alternate encrypted DNS protocols
	supported by a known server, or to provide details if a resolver		supported by a known server, or to provide details if a resolver
	name is provisioned by a network (Section 5).		name is provisioned by a network (Section 5).
	Both of these approaches allow clients to confirm that a discovered		Both of these approaches allow clients to confirm that a discovered
	Encrypted Resolver is designated by the originally provisioned		Encrypted Resolver is designated by the originally provisioned
	resolver. "Designated" in this context means that the resolvers are		resolver. "Designated" in this context means that the resolvers are
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	2. Terminology		2. Terminology
	This document defines the following terms:		This document defines the following terms:
	DDR: Discovery of Designated Resolvers. Refers to the mechanisms		DDR: Discovery of Designated Resolvers. Refers to the mechanisms
	defined in this document.		defined in this document.
	Designated Resolver: A resolver, presumably an Encrypted Resolver,		Designated Resolver: A resolver, presumably an Encrypted Resolver,
	designated by another resolver for use in its own place. This		designated by another resolver for use in its own place. This
	designation can be authenticated with TLS certificates.		designation can be verified with TLS certificates.
	Encrypted Resolver: A DNS resolver using any encrypted DNS		Encrypted Resolver: A DNS resolver using any encrypted DNS
	transport. This includes current mechanisms such as DoH and DoT		transport. This includes current mechanisms such as DoH and DoT
	as well as future mechanisms.		as well as future mechanisms.
	Unencrypted Resolver: A DNS resolver using TCP or UDP port 53.		Unencrypted Resolver: A DNS resolver using TCP or UDP port 53.
	3. DNS Service Binding Records		3. DNS Service Binding Records
	DNS resolvers can advertise one or more Designated Resolvers that may		DNS resolvers can advertise one or more Designated Resolvers that may
	offer support over encrypted channels and are controlled by the same		offer support over encrypted channels and are controlled by the same
	entity.		entity.
	When a client discovers Designated Resolvers, it learns information		When a client discovers Designated Resolvers, it learns information
	such as the supported protocols, ports, and server name to use in		such as the supported protocols and ports. This information is
	certificate validation. This information is provided in Service		provided in Service Binding (SVCB) records for DNS Servers. The
	Binding (SVCB) records for DNS Servers. The formatting of these		formatting of these records, including the DNS-unique parameters such
	records, including the DNS-unique parameters such as "dohpath", are		as "dohpath", are defined by [I-D.ietf-add-svcb-dns].
	defined by [I-D.ietf-add-svcb-dns].
	The following is an example of an SVCB record describing a DoH server		The following is an example of an SVCB record describing a DoH server
	discovered by querying for _dns.example.net:		discovered by querying for _dns.example.net:
	_dns.example.net 7200 IN SVCB 1 . (		_dns.example.net. 7200 IN SVCB 1 example.net. (
	alpn=h2 dohpath=/dns-query{?dns} )		alpn=h2 dohpath=/dns-query{?dns} )
	The following is an example of an SVCB record describing a DoT server		The following is an example of an SVCB record describing a DoT server
	discovered by querying for _dns.example.net:		discovered by querying for _dns.example.net:
	_dns.example.net 7200 IN SVCB 1 dot.example.net (		_dns.example.net 7200 IN SVCB 1 dot.example.net (
	alpn=dot port=8530 )		alpn=dot port=8530 )
	If multiple Designated Resolvers are available, using one or more		If multiple Designated Resolvers are available, using one or more
	encrypted DNS protocols, the resolver deployment can indicate a		encrypted DNS protocols, the resolver deployment can indicate a
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 15 ¶
	4.1. Use of Designated Resolvers		4.1. Use of Designated Resolvers
	When a client discovers Designated Resolvers from an Unencrypted		When a client discovers Designated Resolvers from an Unencrypted
	Resolver IP address, it can choose to use these Designated Resolvers		Resolver IP address, it can choose to use these Designated Resolvers
	either automatically, or based on some other policy, heuristic, or		either automatically, or based on some other policy, heuristic, or
	user choice.		user choice.
	This document defines two preferred methods to automatically use		This document defines two preferred methods to automatically use
	Designated Resolvers:		Designated Resolvers:
	* Authenticated Discovery Section 4.2, for when a TLS certificate		* Verified Discovery Section 4.2, for when a TLS certificate can be
	can be used to validate the resolver's identity.		used to validate the resolver's identity.
	* Opportunistic Discovery Section 4.3, for when a resolver is		* Opportunistic Discovery Section 4.3, for when a resolver is
	accessed using a non-public IP address.		accessed using a non-public IP address.
	A client MAY additionally use a discovered Designated Resolver		A client MAY additionally use a discovered Designated Resolver
	without either of these methods, based on implementation-specific		without either of these methods, based on implementation-specific
	policy or user input. Details of such policy are out of scope of		policy or user input. Details of such policy are out of scope of
	this document. Clients SHOULD NOT automatically use a Designated		this document. Clients SHOULD NOT automatically use a Designated
	Resolver without some sort of validation, such as the two methods		Resolver without some sort of validation, such as the two methods
	defined in this document or a future mechanism.		defined in this document or a future mechanism.
	4.2. Authenticated Discovery		4.2. Verified Discovery
	Authenticated Discovery is a mechanism that allows automatic use of a		Verified Discovery is a mechanism that allows automatic use of a
	Designated Resolver that supports DNS encryption that performs a TLS		Designated Resolver that supports DNS encryption that performs a TLS
	handshake.		handshake.
	In order to be considered an authenticated Designated Resolver, the		In order to be considered a verified Designated Resolver, the TLS
	TLS certificate presented by the Designated Resolver MUST contain		certificate presented by the Designated Resolver MUST contain the IP
	both the domain name (from the SVCB answer) and the IP address of the		address of the designating Unencrypted Resolver in a subjectAltName
	designating Unencrypted Resolver within the SubjectAlternativeName		extension. If the certificate can be validated, the client SHOULD
	certificate field. The client MUST check the SubjectAlternativeName		use the discovered Designated Resolver for any cases in which it
	field for both the Unencrypted Resolver's IP address and the		would have otherwise used the Unencrypted Resolver. If the
	advertised name of the Designated Resolver. If the certificate can		Designated Resolver has a different IP address than the Unencrypted
	be validated, the client SHOULD use the discovered Designated		Resolver and the TLS certificate does not cover the Unencrypted
	Resolver for any cases in which it would have otherwise used the		Resolver address, the client MUST NOT automatically use the
	Unencrypted Resolver. If the Designated Resolver has a different IP		discovered Designated Resolver. Additionally, the client SHOULD
	address than the Unencrypted Resolver and the TLS certificate does		suppress any further queries for Designated Resolvers using this
	not cover the Unencrypted Resolver address, the client MUST NOT		Unencrypted Resolver for the length of time indicated by the SVCB
	automatically use the discovered Designated Resolver. Additionally,		record's Time to Live (TTL).
	the client SHOULD suppress any further queries for Designated
	Resolvers using this Unencrypted Resolver for the length of time
	indicated by the SVCB record's Time to Live (TTL).
	If the Designated Resolver and the Unencrypted Resolver share an IP		If the Designated Resolver and the Unencrypted Resolver share an IP
	address, clients MAY choose to opportunistically use the Designated		address, clients MAY choose to opportunistically use the Designated
	Resolver even without this certificate check (Section 4.3).		Resolver even without this certificate check (Section 4.3).
	If resolving the name of a Designated Resolver from an SVCB record		If resolving the name of a Designated Resolver from an SVCB record
	yields an IP address that was not presented in the Additional Answers		yields an IP address that was not presented in the Additional Answers
	section or ipv4hint or ipv6hint fields of the original SVCB query,		section or ipv4hint or ipv6hint fields of the original SVCB query,
	the connection made to that IP address MUST pass the same TLS		the connection made to that IP address MUST pass the same TLS
	certificate checks before being allowed to replace a previously known		certificate checks before being allowed to replace a previously known
	and validated IP address for the same Designated Resolver name.		and validated IP address for the same Designated Resolver name.
	4.3. Opportunistic Discovery		4.3. Opportunistic Discovery
	There are situations where authenticated discovery of encrypted DNS		There are situations where Verified Discovery of encrypted DNS
	configuration over unencrypted DNS is not possible. This includes		configuration over unencrypted DNS is not possible. This includes
	Unencrypted Resolvers on non-public IP addresses such as those		Unencrypted Resolvers on non-public IP addresses such as those
	defined in [RFC1918] whose identity cannot be confirmed using TLS		defined in [RFC1918] whose identity cannot be confirmed using TLS
	certificates.		certificates.
	Opportunistic Privacy is defined for DoT in Section 4.1 of [RFC7858]		Opportunistic Privacy is defined for DoT in Section 4.1 of [RFC7858]
	as a mode in which clients do not validate the name of the resolver		as a mode in which clients do not validate the name of the resolver
	presented in the certificate. A client MAY use information from the		presented in the certificate. A client MAY use information from the
	SVCB record for "dns://resolver.arpa" with this "opportunistic"		SVCB record for "dns://resolver.arpa" with this "opportunistic"
	approach (not validating the names presented in the		approach (not validating the names presented in the
	SubjectAlternativeName field of the certificate) as long as the IP		SubjectAlternativeName field of the certificate) as long as the IP
	address of the Encrypted Resolver does not differ from the IP address		address of the Encrypted Resolver does not differ from the IP address
	of the Unencrypted Resolver. This approach can be used for any		of the Unencrypted Resolver. Clients SHOULD use this mode only for
	encrypted DNS protocol that uses TLS.		resolvers using non-public IP addresses. This approach can be used
			for any encrypted DNS protocol that uses TLS.
	5. Discovery Using Resolver Names		5. Discovery Using Resolver Names
	A DNS client that already knows the name of an Encrypted Resolver can		A DNS client that already knows the name of an Encrypted Resolver can
	use DDR to discover details about all supported encrypted DNS		use DDR to discover details about all supported encrypted DNS
	protocols. This situation can arise if a client has been configured		protocols. This situation can arise if a client has been configured
	to use a given Encrypted Resolver, or if a network provisioning		to use a given Encrypted Resolver, or if a network provisioning
	protocol (such as DHCP or IPv6 Router Advertisements) provides a name		protocol (such as DHCP or IPv6 Router Advertisements) provides a name
	for an Encrypted Resolver alongside the resolver IP address.		for an Encrypted Resolver alongside the resolver IP address.
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 5 ¶
	of bootstrapping from an Unencrypted Resolver (Section 4), these		of bootstrapping from an Unencrypted Resolver (Section 4), these
	records SHOULD be available in the public DNS.		records SHOULD be available in the public DNS.
	For example, if the client already knows about a DoT server		For example, if the client already knows about a DoT server
	resolver.example.com, it can issue an SVCB query for		resolver.example.com, it can issue an SVCB query for
	_dns.resolver.example.com to discover if there are other encrypted		_dns.resolver.example.com to discover if there are other encrypted
	DNS protocols available. In the following example, the SVCB answers		DNS protocols available. In the following example, the SVCB answers
	indicate that resolver.example.com supports both DoH and DoT, and		indicate that resolver.example.com supports both DoH and DoT, and
	that the DoH server indicates a higher priority than the DoT server.		that the DoH server indicates a higher priority than the DoT server.
	_dns.resolver.example.com 7200 IN SVCB 1 . (		_dns.resolver.example.com. 7200 IN SVCB 1 resolver.example.com. (
	alpn=h2 dohpath=/dns-query{?dns} )		alpn=h2 dohpath=/dns-query{?dns} )
	_dns.resolver.example.com 7200 IN SVCB 2 . (		_dns.resolver.example.com. 7200 IN SVCB 1 resolver.example.com. (
	alpn=dot )		alpn=dot )
	Often, the various supported encrypted DNS protocols will be		Clients MUST validate that for any Encrypted Resolver discovered
	accessible using the same hostname. In the example above, both DoH		using a known resolver name, the TLS certificate of the resolver
	and DoT use the name resolver.example.com for their TLS certificates.		contains the known name in a subjectAltName extension. In the
	If a deployment uses a different hostname for one protocol, but still		example above, this means that both servers need to have certificates
	wants clients to treat both DNS servers as designated, the TLS		that cover the name resolver.example.com. Often, the various
	certificates MUST include both names in the SubjectAlternativeName		supported encrypted DNS protocols will be specified such that the
	fields. Note that this name verification is not related to the DNS		SVCB TargetName matches the known name, as is true in the example
	resolver that provided the SVCB answer.		above. However, even when the TargetName is different (for example,
			if the DoH server had a TargetName of doh.example.com), the clients
			still check for the original known resolver name in the certificate.
	For example, being able to discover a Designated Resolver for a known		Note that this resolver validation is not related to the DNS resolver
	Encrypted Resolver is useful when a client has a DoT configuration		that provided the SVCB answer.
	for foo.resolver.example.com but is on a network that blocks DoT
	traffic. The client can still send a query to any other accessible		As another example, being able to discover a Designated Resolver for
	resolver (either the local network resolver or an accessible DoH		a known Encrypted Resolver is useful when a client has a DoT
	server) to discover if there is a designated DoH server for		configuration for foo.resolver.example.com but is on a network that
	foo.resolver.example.com.		blocks DoT traffic. The client can still send a query to any other
			accessible resolver (either the local network resolver or an
			accessible DoH server) to discover if there is a designated DoH
			server for foo.resolver.example.com.
	6. Deployment Considerations		6. Deployment Considerations
	Resolver deployments that support DDR are advised to consider the		Resolver deployments that support DDR are advised to consider the
	following points.		following points.
	6.1. Caching Forwarders		6.1. Caching Forwarders
	A DNS forwarder SHOULD NOT forward queries for "resolver.arpa"		A DNS forwarder SHOULD NOT forward queries for "resolver.arpa"
	upstream. This prevents a client from receiving an SVCB record that		upstream. This prevents a client from receiving an SVCB record that
	skipping to change at page 9, line 8 ¶		skipping to change at page 9, line 8 ¶
	field. A DNS forwarder which already acts as a completely blind		field. A DNS forwarder which already acts as a completely blind
	forwarder MAY choose to forward these queries when the operator		forwarder MAY choose to forward these queries when the operator
	expects that this does not apply, either because the operator knows		expects that this does not apply, either because the operator knows
	the upstream resolver does have the forwarder's IP address in its TLS		the upstream resolver does have the forwarder's IP address in its TLS
	certificate's SAN field or that the operator expects clients of the		certificate's SAN field or that the operator expects clients of the
	unencrypted resolver to use the SVCB information opportunistically.		unencrypted resolver to use the SVCB information opportunistically.
	Operators who choose to forward queries for "resolver.arpa" upstream		Operators who choose to forward queries for "resolver.arpa" upstream
	should note that client behavior is never guaranteed and use of DDR		should note that client behavior is never guaranteed and use of DDR
	by a resolver does not communicate a requirement for clients to use		by a resolver does not communicate a requirement for clients to use
	the SVCB record when it cannot be authenticated.		the SVCB record when it cannot be verified.
	6.2. Certificate Management		6.2. Certificate Management
	Resolver owners that support authenticated discovery will need to		Resolver owners that support Verified Discovery will need to list
	list valid referring IP addresses in their TLS certificates. This		valid referring IP addresses in their TLS certificates. This may
	may pose challenges for resolvers with a large number of referring IP		pose challenges for resolvers with a large number of referring IP
	addresses.		addresses.
			6.3. Server Name Handling
			Clients MUST NOT use "resolver.arpa" as the server name either in the
			TLS Server Name Indication (SNI) ([RFC8446]) for DoT or DoH
			connections, or in the URI host for DoH requests.
			When performing discovery using resolver IP addresses, clients MUST
			use the IP address as the URI host for DoH requests.
			Note that since IP addresses are not supported by default in the TLS
			SNI, resolvers that support discovery using IP addresses will need to
			be configured to present the appropriate TLS certificate when no SNI
			is present for both DoT and DoH.
	7. Security Considerations		7. Security Considerations
	Since clients can receive DNS SVCB answers over unencrypted DNS, on-		Since clients can receive DNS SVCB answers over unencrypted DNS, on-
	path attackers can prevent successful discovery by dropping SVCB		path attackers can prevent successful discovery by dropping SVCB
	packets. Clients should be aware that it might not be possible to		packets. Clients should be aware that it might not be possible to
	distinguish between resolvers that do not have any Designated		distinguish between resolvers that do not have any Designated
	Resolver and such an active attack. To limit the impact of discovery		Resolver and such an active attack. To limit the impact of discovery
	queries being dropped either maliciously or unintentionally, clients		queries being dropped either maliciously or unintentionally, clients
	can re-send their SVCB queries periodically.		can re-send their SVCB queries periodically.
			DoH resolvers that allow discovery using DNS SVCB answers over
			unencrypted DNS MUST NOT provide differentiated behavior based on the
			HTTP path alone, since an attacker could modify the "dohpath"
			parameter.
	While the IP address of the Unencrypted Resolver is often provisioned		While the IP address of the Unencrypted Resolver is often provisioned
	over insecure mechanisms, it can also be provisioned securely, such		over insecure mechanisms, it can also be provisioned securely, such
	as via manual configuration, a VPN, or on a network with protections		as via manual configuration, a VPN, or on a network with protections
	like RA guard [RFC6105]. An attacker might try to direct Encrypted		like RA guard [RFC6105]. An attacker might try to direct Encrypted
	DNS traffic to itself by causing the client to think that a		DNS traffic to itself by causing the client to think that a
	discovered Designated Resolver uses a different IP address from the		discovered Designated Resolver uses a different IP address from the
	Unencrypted Resolver. Such a Designated Resolver might have a valid		Unencrypted Resolver. Such a Designated Resolver might have a valid
	certificate, but be operated by an attacker that is trying to observe		certificate, but be operated by an attacker that is trying to observe
	or modify user queries without the knowledge of the client or		or modify user queries without the knowledge of the client or
	network.		network.
	If the IP address of a Designated Resolver differs from that of an		If the IP address of a Designated Resolver differs from that of an
	Unencrypted Resolver, clients applying Authenicated Discovery		Unencrypted Resolver, clients applying Verified Discovery
	(Section 4.2) MUST validate that the IP address of the Unencrypted		(Section 4.2) MUST validate that the IP address of the Unencrypted
	Resolver is covered by the SubjectAlternativeName of the Designated		Resolver is covered by the SubjectAlternativeName of the Designated
	Resolver's TLS certificate.		Resolver's TLS certificate.
	Clients using Opportunistic Discovery (Section 4.3) MUST be limited		Clients using Opportunistic Discovery (Section 4.3) MUST be limited
	to cases where the Unencrypted Resolver and Designated Resolver have		to cases where the Unencrypted Resolver and Designated Resolver have
	the same IP address.		the same IP address.
	The constraints on validation of Designated Resolvers specified here		The constraints on the use of Designated Resolvers specified here
	apply specifically to the automatic discovery mechanisms defined in		apply specifically to the automatic discovery mechanisms defined in
	this document, which are referred to as Authenticated Discovery and		this document, which are referred to as Verified Discovery and
	Opportunistic Discovery. Clients MAY use some other mechanism to		Opportunistic Discovery. Clients MAY use some other mechanism to
	validate and use Designated Resolvers discovered using the DNS SVCB		verify and use Designated Resolvers discovered using the DNS SVCB
	record. However, use of such an alternate mechanism needs to take		record. However, use of such an alternate mechanism needs to take
	into account the attack scenarios detailed here.		into account the attack scenarios detailed here.
	8. IANA Considerations		8. IANA Considerations
	8.1. Special Use Domain Name "resolver.arpa"		8.1. Special Use Domain Name "resolver.arpa"
	This document calls for the creation of the "resolver.arpa" SUDN.		This document calls for the addition of "resolver.arpa" to the
			Special-Use Domain Names (SUDN) registry established by [RFC6761].
	This will allow resolvers to respond to queries directed at		This will allow resolvers to respond to queries directed at
	themselves rather than a specific domain name. While this document		themselves rather than a specific domain name. While this document
	uses "resolver.arpa" to return SVCB records indicating designated		uses "resolver.arpa" to return SVCB records indicating designated
	encrypted capability, the name is generic enough to allow future		encrypted capability, the name is generic enough to allow future
	reuse for other purposes where the resolver wishes to provide		reuse for other purposes where the resolver wishes to provide
	information about itself to the client.		information about itself to the client.
	The "resolver.arpa" SUDN is similar to "ipv4only.arpa" in that the		The "resolver.arpa" SUDN is similar to "ipv4only.arpa" in that the
	querying client is not interested in an answer from the authoritative		querying client is not interested in an answer from the authoritative
	"arpa" name servers. The intent of the SUDN is to allow clients to		"arpa" name servers. The intent of the SUDN is to allow clients to
	skipping to change at page 10, line 39 ¶		skipping to change at page 11, line 8 ¶
	allows for client-to-middlebox communication. For more context, see		allows for client-to-middlebox communication. For more context, see
	the rationale behind "ipv4only.arpa" in [RFC8880].		the rationale behind "ipv4only.arpa" in [RFC8880].
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-add-svcb-dns]		[I-D.ietf-add-svcb-dns]
	Schwartz, B., "Service Binding Mapping for DNS Servers",		Schwartz, B., "Service Binding Mapping for DNS Servers",
	Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns-		Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns-
	00, 1 October 2021,		01, 21 October 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-add-		<https://datatracker.ietf.org/doc/html/draft-ietf-add-
	svcb-dns-00>.		svcb-dns-01>.
	[I-D.ietf-dnsop-svcb-https]		[I-D.ietf-dnsop-svcb-https]
	Schwartz, B., Bishop, M., and E. Nygren, "Service binding		Schwartz, B., Bishop, M., and E. Nygren, "Service binding
	and parameter specification via the DNS (DNS SVCB and		and parameter specification via the DNS (DNS SVCB and
	HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-		HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-
	dnsop-svcb-https-07, 5 August 2021,		dnsop-svcb-https-08, 12 October 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-		<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
	svcb-https-07>.		svcb-https-08>.
	[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
	J., and E. Lear, "Address Allocation for Private		J., and E. Lear, "Address Allocation for Private
	Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,		Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
	February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.		February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.
			[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
			RFC 6761, DOI 10.17487/RFC6761, February 2013,
			<https://www.rfc-editor.org/rfc/rfc6761>.
	[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
	and P. Hoffman, "Specification for DNS over Transport		and P. Hoffman, "Specification for DNS over Transport
	Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May		Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
	2016, <https://www.rfc-editor.org/rfc/rfc7858>.		2016, <https://www.rfc-editor.org/rfc/rfc7858>.
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS		[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
	(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,		(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
	<https://www.rfc-editor.org/rfc/rfc8484>.		<https://www.rfc-editor.org/rfc/rfc8484>.
	9.2. Informative References		9.2. Informative References
	skipping to change at page 12, line 14 ¶		skipping to change at page 12, line 33 ¶
	[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,		[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
	"IPv6 Router Advertisement Options for DNS Configuration",		"IPv6 Router Advertisement Options for DNS Configuration",
	RFC 8106, DOI 10.17487/RFC8106, March 2017,		RFC 8106, DOI 10.17487/RFC8106, March 2017,
	<https://www.rfc-editor.org/rfc/rfc8106>.		<https://www.rfc-editor.org/rfc/rfc8106>.
	[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/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/rfc/rfc8446>.
	[RFC8880] Cheshire, S. and D. Schinazi, "Special Use Domain Name		[RFC8880] Cheshire, S. and D. Schinazi, "Special Use Domain Name
	'ipv4only.arpa'", RFC 8880, DOI 10.17487/RFC8880, August		'ipv4only.arpa'", RFC 8880, DOI 10.17487/RFC8880, August
	2020, <https://www.rfc-editor.org/rfc/rfc8880>.		2020, <https://www.rfc-editor.org/rfc/rfc8880>.
	Appendix A. Rationale for using SVCB records		Appendix A. Rationale for using SVCB records
	This mechanism uses SVCB/HTTPS resource records		This mechanism uses SVCB/HTTPS resource records
	[I-D.ietf-dnsop-svcb-https] to communicate that a given domain		[I-D.ietf-dnsop-svcb-https] to communicate that a given domain
	designates a particular Designated Resolver for clients to use in		designates a particular Designated Resolver for clients to use in
	place of an Unencrypted Resolver (using a SUDN) or another Encrypted		place of an Unencrypted Resolver (using a SUDN) or another Encrypted
End of changes. 35 change blocks.
	69 lines changed or deleted		100 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/