draft-ietf-add-ddr-06.txt		draft-ietf-add-ddr-07.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: 6 October 2022 C. A. Wood		Expires: 26 December 2022 C. A. Wood
	Cloudflare		Cloudflare
	P. McManus		P. McManus
	Fastly		Fastly
	T. Jensen		T. Jensen
	Microsoft		Microsoft
	4 April 2022		24 June 2022
	Discovery of Designated Resolvers		Discovery of Designated Resolvers
	draft-ietf-add-ddr-06		draft-ietf-add-ddr-07
	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 6 October 2022.		This Internet-Draft will expire on 26 December 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 Revised BSD License.		provided without warranty as described in the Revised 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.1.1. Use of Designated Resolvers across network changes . 7
	4.2. Verified Discovery . . . . . . . . . . . . . . . . . . . 7		4.2. Verified Discovery . . . . . . . . . . . . . . . . . . . 7
	4.3. Opportunistic Discovery . . . . . . . . . . . . . . . . . 8		4.3. Opportunistic Discovery . . . . . . . . . . . . . . . . . 8
	5. Discovery Using Resolver Names . . . . . . . . . . . . . . . 8		5. Discovery Using Resolver Names . . . . . . . . . . . . . . . 9
	6. Deployment Considerations . . . . . . . . . . . . . . . . . . 9		6. Deployment Considerations . . . . . . . . . . . . . . . . . . 10
	6.1. Caching Forwarders . . . . . . . . . . . . . . . . . . . 9		6.1. Caching Forwarders . . . . . . . . . . . . . . . . . . . 10
	6.2. Certificate Management . . . . . . . . . . . . . . . . . 10		6.2. Certificate Management . . . . . . . . . . . . . . . . . 10
	6.3. Server Name Handling . . . . . . . . . . . . . . . . . . 10		6.3. Server Name Handling . . . . . . . . . . . . . . . . . . 10
	6.4. Handling non-DDR queries for resolver.arpa . . . . . . . 10		6.4. Handling non-DDR queries for resolver.arpa . . . . . . . 11
	6.5. Interaction with Network-Designated Resolvers . . . . . . 10		6.5. Interaction with Network-Designated Resolvers . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Special Use Domain Name "resolver.arpa" . . . . . . . . . 12		8.1. Special Use Domain Name "resolver.arpa" . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. Rationale for using SVCB records . . . . . . . . . . 15		Appendix A. Rationale for using SVCB records . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	When DNS clients wish to use encrypted DNS protocols such as DNS-		When DNS clients wish to use encrypted DNS protocols such as DNS-
	over-TLS (DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484], they		over-TLS (DoT) [RFC7858], DNS-over-QUIC (DoQ) [RFC9250], or DNS-over-
	require additional information beyond the IP address of the DNS		HTTPS (DoH) [RFC8484], they require additional information beyond the
	server, such as the resolver's hostname, non-standard ports, or URL		IP address of the DNS server, such as the resolver's hostname, non-
	paths. However, common configuration mechanisms only provide the		standard ports, or URI templates. However, common configuration
	resolver's IP address during configuration. Such mechanisms include		mechanisms only provide the resolver's IP address during
	network provisioning protocols like DHCP [RFC2132] and IPv6 Router		configuration. Such mechanisms include network provisioning
	Advertisement (RA) options [RFC8106], as well as manual		protocols like DHCP [RFC2132] [RFC8415] and IPv6 Router Advertisement
	configuration.		(RA) options [RFC8106], as well as manual 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 (SUDN) [RFC6761] to		client queries a special use domain name (SUDN) [RFC6761] to
	discover DNS SVCB records associated with one or more Encrypted		discover DNS SVCB records associated with one or more Encrypted
	Resolvers the Unencrypted Resolver has designated for use when		Resolvers the Unencrypted Resolver has designated for use when
	support for DNS encryption is requested (Section 4).		support for DNS encryption is requested (Section 4).
	skipping to change at page 4, line 13 ¶		skipping to change at page 4, line 13 ¶
	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 verified 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, DoT, and
	as well as future mechanisms.		DoQ, 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
			without encryption.
	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 and ports. This information is		such as the supported protocols and ports. This information is
	provided in ServiceMode Service Binding (SVCB) records for DNS		provided in ServiceMode Service Binding (SVCB) records for DNS
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 43 ¶
	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 example.net. (		_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 )
			The following is an example of an SVCB record describing a DoQ server
			discovered by querying for _dns.example.net:
			_dns.example.net. 7200 IN SVCB 1 doq.example.net (
			alpn=doq 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
	preference using the priority fields in each SVCB record		preference using the priority fields in each SVCB record
	[I-D.ietf-dnsop-svcb-https].		[I-D.ietf-dnsop-svcb-https].
	If the client encounters a mandatory parameter in an SVCB record it		If the client encounters a mandatory parameter in an SVCB record it
	does not understand, it MUST NOT use that record to discover a		does not understand, it MUST NOT use that record to discover a
	Designated Resolver. The client can still use others records in the		Designated Resolver. The client can still use others records in the
	same response if the client can understand all of their mandatory		same response if the client can understand all of their mandatory
	parameters. This allows future encrypted deployments to		parameters. This allows future encrypted deployments to
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 26 ¶
	of all those protocols. For example, if the Unencrypted Resolver		of all those protocols. For example, if the Unencrypted Resolver
	returns three SVCB records, one for DoH, one for DoT, and one for a		returns three SVCB records, one for DoH, one for DoT, and one for a
	yet-to-exist protocol, a client which only supports DoH and DoT		yet-to-exist protocol, a client which only supports DoH and DoT
	should be able to use those records while safely ignoring the third		should be able to use those records while safely ignoring the third
	record.		record.
	To avoid name lookup deadlock, Designated Resolvers SHOULD follow the		To avoid name lookup deadlock, Designated Resolvers SHOULD follow the
	guidance in Section 10 of [RFC8484] regarding the avoidance of DNS-		guidance in Section 10 of [RFC8484] regarding the avoidance of DNS-
	based references that block the completion of the TLS handshake.		based references that block the completion of the TLS handshake.
	This document focuses on discovering DoH and DoT Designated		This document focuses on discovering DoH, DoT, and DoQ Designated
	Resolvers. Other protocols can also use the format defined by		Resolvers. Other protocols can also use the format defined by
	[I-D.ietf-add-svcb-dns]. However, if any protocol does not involve		[I-D.ietf-add-svcb-dns]. However, if any protocol does not involve
	some form of certificate validation, new validation mechanisms will		some form of certificate validation, new validation mechanisms will
	need to be defined to support validating designation as defined in		need to be defined to support validating designation as defined in
	Section 4.2.		Section 4.2.
	4. Discovery Using Resolver IP Addresses		4. Discovery Using Resolver IP Addresses
	When a DNS client is configured with an Unencrypted Resolver IP		When a DNS client is configured with an Unencrypted Resolver IP
	address, it SHOULD query the resolver for SVCB records for		address, it SHOULD query the resolver for SVCB records for
	"dns://resolver.arpa" before making other queries. Specifically, the		"dns://resolver.arpa" before making other queries. Specifically, the
	client issues a query for _dns.resolver.arpa with the SVCB resource		client issues a query for _dns.resolver.arpa with the SVCB resource
	record type (64) [I-D.ietf-dnsop-svcb-https].		record type (64) [I-D.ietf-dnsop-svcb-https].
	Because this query is for an SUDN, which no entity can claim		Because this query is for an SUDN, which no entity can claim
	ownership over, the ServiceMode SVCB response MUST NOT use the "."		ownership over, the ServiceMode SVCB response MUST NOT use the "."
	value for the TargetName. Instead, the domain name used for DoT or		value for the TargetName. Instead, the domain name used for DoT/DoQ
	used to construct the DoH template MUST be provided.		or used to construct the DoH template MUST be provided.
	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.resolver.arpa:		discovered by querying for _dns.resolver.arpa:
	_dns.resolver.arpa 7200 IN SVCB 1 doh.example.net (		_dns.resolver.arpa. 7200 IN SVCB 1 doh.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.resolver.arpa:		discovered by querying for _dns.resolver.arpa:
	_dns.resolver.arpa 7200 IN SVCB 1 dot.example.net (		_dns.resolver.arpa. 7200 IN SVCB 1 dot.example.net (
	alpn=dot port=8530 )		alpn=dot port=8530 )
			The following is an example of an SVCB record describing a DoQ server
			discovered by querying for _dns.resolver.arpa:
			_dns.resolver.arpa. 7200 IN SVCB 1 doq.example.net (
			alpn=doq port=8530 )
	If the recursive resolver that receives this query has one or more		If the recursive resolver that receives this query has one or more
	Designated Resolvers, it will return the corresponding SVCB records.		Designated Resolvers, it will return the corresponding SVCB records.
	When responding to these special queries for "dns://resolver.arpa",		When responding to these special queries for "dns://resolver.arpa",
	the recursive resolver SHOULD include the A and AAAA records for the		the recursive resolver SHOULD include the A and AAAA records for the
	name of the Designated Resolver in the Additional Answers section.		name of the Designated Resolver in the Additional Answers section.
	This will allow the DNS client to make queries over an encrypted		This will allow the DNS client to make queries over an encrypted
	connection without waiting to resolve the Encrypted Resolver name per		connection without waiting to resolve the Encrypted Resolver name per
	[I-D.ietf-dnsop-svcb-https]. If no A/AAAA records or SVCB IP address		[I-D.ietf-dnsop-svcb-https]. If no A/AAAA records or SVCB IP address
	hints are included, clients will be forced to delay use of the		hints are included, clients will be forced to delay use of the
	Encrypted Resolver until an additional DNS lookup for the A and AAAA		Encrypted Resolver until an additional DNS lookup for the A and AAAA
	records can be made to the Unencrypted Resolver (or some other		records can be made to the Unencrypted Resolver (or some other
	resolver the DNS client has been configured to use).		resolver the DNS client has been configured to use).
			Designated Resolvers SHOULD be accessible using the IP address
			families that are supported by their associated Unencrypted
			Resolvers. If an Unencrypted Resolver is accessible using an IPv4
			address, it ought to provide an A record for an IPv4 address of the
			Designated Resolver; similarly, if it is accessible using an IPv6
			address, it ought to provide a AAAA record an IPv6 address of the
			Designated Resolver. The Designated Resolver can supported more
			address families than the Unencrypted Resolver, but it ought not to
			support fewer. If this is not done, clients that only have
			connectivity over one address family might not be able to access the
			Designated Resolver.
	If the recursive resolver that receives this query has no Designated		If the recursive resolver that receives this query has no Designated
	Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"		Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"
	SUDN.		SUDN.
	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:
	* Verified Discovery Section 4.2, for when a TLS certificate can be		* Verified Discovery Section 4.2, for when a TLS certificate 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's IP
	accessed using a non-public IP address.		address is a private or local 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.
	A client MUST NOT use a Designated Resolver designated by one		A client MUST NOT use a Designated Resolver designated by one
	Unencrypted Resolver in place of another Unencrypted Resolver. As		Unencrypted Resolver in place of another Unencrypted Resolver. As
	these are known only by IP address, this means each unique IP address		these are known only by IP address, this means each unique IP address
	used for unencrypted DNS requires its own designation discovery.		used for unencrypted DNS requires its own designation discovery.
	This ensures queries are being sent to a party designated by the		This ensures queries are being sent to a party designated by the
	resolver originally being used.		resolver originally being used.
			4.1.1. Use of Designated Resolvers across network changes
	Generally, clients also SHOULD NOT reuse the Designated Resolver		Generally, clients also SHOULD NOT reuse the Designated Resolver
	discovered from an Unencrypted Resolver over one network connection		discovered from an Unencrypted Resolver over one network connection
	in place of the same Unencrypted Resolver on another network		in place of the same Unencrypted Resolver on another network
	connection. Instead, clients SHOULD repeat the discovery process on		connection. Instead, clients SHOULD repeat the discovery process on
	the other network connection.		the other network connection.
	However, if a given Unencrypted Resolver designates a Designated		However, if a given Unencrypted Resolver designates a Designated
	Resolver that uses a public IP address and can be verified using the		Resolver that does not use a private or local IP address and can be
	mechanism described in Section 4.2, it MAY be used on different		verified using the mechanism described in Section 4.2, it MAY be used
	network connections so long as the subsequent connections over other		on different network connections so long as the subsequent
	networks can also be successfully verified using the mechanism		connections over other networks can also be successfully verified
	described in Section 4.2. This is a tradeoff between performance (by		using the mechanism described in Section 4.2. This is a tradeoff
	having no delay in establishing an encrypted DNS connection on the		between performance (by having no delay in establishing an encrypted
	new network) and functionality (if the Unencrypted Resolver intends		DNS connection on the new network) and functionality (if the
	to designate different Designated Resolvers based on the network from		Unencrypted Resolver intends to designate different Designated
	which clients connect).		Resolvers based on the network from which clients connect).
	4.2. Verified Discovery		4.2. Verified Discovery
	Verified 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 a verified Designated Resolver, the TLS		In order to be considered a verified Designated Resolver, the TLS
	certificate presented by the Designated Resolver MUST contain the IP		certificate presented by the Designated Resolver MUST contain the IP
	address of the designating Unencrypted Resolver in a subjectAltName		address of the designating Unencrypted Resolver in a subjectAltName
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 34 ¶
	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 Verified 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 private IP addresses [RFC1918], Unique Local
	defined in [RFC1918] whose identity cannot be confirmed using TLS		Addresses (ULAs) [RFC4193], and Link Local Addresses [RFC3927]
	certificates.		[RFC4291], whose identity cannot be confirmed using TLS 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. Opportunistic Privacy similarly
	SVCB record for "dns://resolver.arpa" with this "opportunistic"		applies to DoQ [RFC9250]. A client MAY use information from the SVCB
	approach (not validating the names presented in the		record for "dns://resolver.arpa" with this "opportunistic" approach
	SubjectAlternativeName field of the certificate) as long as the IP		(not validating the names presented in the SubjectAlternativeName
	address of the Encrypted Resolver does not differ from the IP address		field of the certificate) as long as the IP address of the Encrypted
	of the Unencrypted Resolver. Clients SHOULD use this mode only for		Resolver does not differ from the IP address of the Unencrypted
	resolvers using non-public IP addresses. This approach can be used		Resolver. Clients SHOULD use this mode only for resolvers using
	for any encrypted DNS protocol that uses TLS.		private or local 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, such as
			by using Discovery of Network Resolvers (DNR) [I-D.ietf-add-dnr].
	For these cases, the client simply sends a DNS SVCB query using the		For these cases, the client simply sends a DNS SVCB query using the
	known name of the resolver. This query can be issued to the named		known name of the resolver. This query can be issued to the named
	Encrypted Resolver itself or to any other resolver. Unlike the case		Encrypted Resolver itself or to any other resolver. Unlike the case
	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
	skipping to change at page 9, line 41 ¶		skipping to change at page 10, line 27 ¶
	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
	will fail to authenticate because the forwarder's IP address is not		will fail to authenticate because the forwarder's IP address is not
	in the upstream resolver's Designated Resolver's TLS certificate SAN		in the upstream resolver's Designated Resolver's TLS certificate SAN
	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		that the upstream resolver does have the forwarder's IP address in
	certificate's SAN field or that the operator expects clients of the		its TLS certificate's SAN field or that the operator expects clients
	unencrypted resolver to use the SVCB information opportunistically.		of the 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 verified.		the SVCB record when it cannot be verified.
	6.2. Certificate Management		6.2. Certificate Management
	Resolver owners that support Verified Discovery will need to list		Resolver owners that support Verified Discovery will need to list
	valid referring IP addresses in their TLS certificates. This may		valid referring IP addresses in their TLS certificates. This 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		6.3. Server Name Handling
	Clients MUST NOT use "resolver.arpa" as the server name either in the		Clients MUST NOT use "resolver.arpa" as the server name either in the
	TLS Server Name Indication (SNI) ([RFC8446]) for DoT or DoH		TLS Server Name Indication (SNI) ([RFC8446]) for DoT, DoQ, or DoH
	connections, or in the URI host for DoH requests.		connections, or in the URI host for DoH requests.
	When performing discovery using resolver IP addresses, clients MUST		When performing discovery using resolver IP addresses, clients MUST
	use the IP address as the URI host for DoH requests.		use the IP address as the URI host for DoH requests.
	Note that since IP addresses are not supported by default in the TLS		Note that since IP addresses are not supported by default in the TLS
	SNI, resolvers that support discovery using IP addresses will need to		SNI, resolvers that support discovery using IP addresses will need to
	be configured to present the appropriate TLS certificate when no SNI		be configured to present the appropriate TLS certificate when no SNI
	is present for both DoT and DoH.		is present for DoT, DoQ, and DoH.
	6.4. Handling non-DDR queries for resolver.arpa		6.4. Handling non-DDR queries for resolver.arpa
	DNS resolvers that support DDR by responding to queries for		DNS resolvers that support DDR by responding to queries for
	_dns.resolver.arpa SHOULD treat resolver.arpa as a locally served		_dns.resolver.arpa SHOULD treat resolver.arpa as a locally served
	zone per [RFC6303]. In practice, this means that resolvers SHOULD		zone per [RFC6303]. In practice, this means that resolvers SHOULD
	respond to queries of any type other than SVCB for _dns.resolver.arpa		respond to queries of any type other than SVCB for _dns.resolver.arpa
	with NODATA and queries of any type for any domain name under		with NODATA and queries of any type for any domain name under
	resolver.arpa with NODATA.		resolver.arpa with NODATA.
	skipping to change at page 12, line 34 ¶		skipping to change at page 13, line 17 ¶
	"DNS Resolver Special-Use Domain", listing this document as the		"DNS Resolver Special-Use Domain", listing this document as the
	reference.		reference.
	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-
	02, 1 February 2022,		03, 22 April 2022, <https://datatracker.ietf.org/doc/html/
	<https://datatracker.ietf.org/doc/html/draft-ietf-add-		draft-ietf-add-svcb-dns-03>.
	svcb-dns-02>.
	[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-08, 12 October 2021,		dnsop-svcb-https-10, 24 May 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-		<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
	svcb-https-08>.		svcb-https-10>.
	[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>.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/rfc/rfc2119>.
			[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
			Configuration of IPv4 Link-Local Addresses", RFC 3927,
			DOI 10.17487/RFC3927, May 2005,
			<https://www.rfc-editor.org/rfc/rfc3927>.
			[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
			Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
			<https://www.rfc-editor.org/rfc/rfc4193>.
			[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
			Architecture", RFC 4291, DOI 10.17487/RFC4291, February
			2006, <https://www.rfc-editor.org/rfc/rfc4291>.
	[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,		[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
	RFC 6303, DOI 10.17487/RFC6303, July 2011,		RFC 6303, DOI 10.17487/RFC6303, July 2011,
	<https://www.rfc-editor.org/rfc/rfc6303>.		<https://www.rfc-editor.org/rfc/rfc6303>.
	[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",		[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
	RFC 6761, DOI 10.17487/RFC6761, February 2013,		RFC 6761, DOI 10.17487/RFC6761, February 2013,
	<https://www.rfc-editor.org/rfc/rfc6761>.		<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>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
	[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>.
			[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
			Dedicated QUIC Connections", RFC 9250,
			DOI 10.17487/RFC9250, May 2022,
			<https://www.rfc-editor.org/rfc/rfc9250>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-add-dnr]		[I-D.ietf-add-dnr]
	Boucadair, M., Reddy, T., Wing, D., Cook, N., and T.		Boucadair, M., Reddy, T., Wing, D., Cook, N., and T.
	Jensen, "DHCP and Router Advertisement Options for the		Jensen, "DHCP and Router Advertisement Options for the
	Discovery of Network-designated Resolvers (DNR)", Work in		Discovery of Network-designated Resolvers (DNR)", Work in
	Progress, Internet-Draft, draft-ietf-add-dnr-06, 22 March		Progress, Internet-Draft, draft-ietf-add-dnr-08, 12 June
	2022, <https://datatracker.ietf.org/doc/html/draft-ietf-		2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
	add-dnr-06>.		add-dnr-08>.
	[I-D.ietf-tls-esni]		[I-D.ietf-tls-esni]
	Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS		Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
	Encrypted Client Hello", Work in Progress, Internet-Draft,		Encrypted Client Hello", Work in Progress, Internet-Draft,
	draft-ietf-tls-esni-14, 13 February 2022,		draft-ietf-tls-esni-14, 13 February 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-tls-		<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
	esni-14>.		esni-14>.
	[I-D.schinazi-httpbis-doh-preference-hints]		[I-D.schinazi-httpbis-doh-preference-hints]
	Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference		Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference
	Hints for HTTP", Work in Progress, Internet-Draft, draft-		Hints for HTTP", Work in Progress, Internet-Draft, draft-
	schinazi-httpbis-doh-preference-hints-02, 13 July 2020,		schinazi-httpbis-doh-preference-hints-02, 13 July 2020,
	<https://datatracker.ietf.org/doc/html/draft-schinazi-		<https://datatracker.ietf.org/doc/html/draft-schinazi-
	httpbis-doh-preference-hints-02>.		httpbis-doh-preference-hints-02>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.
	[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor		[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
	Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,		Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2132>.		<https://www.rfc-editor.org/rfc/rfc2132>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<https://www.rfc-editor.org/rfc/rfc4861>.		<https://www.rfc-editor.org/rfc/rfc4861>.
	[RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch,		[RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch,
	skipping to change at page 14, line 29 ¶		skipping to change at page 15, line 36 ¶
	[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.		[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
	Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,		Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
	DOI 10.17487/RFC6105, February 2011,		DOI 10.17487/RFC6105, February 2011,
	<https://www.rfc-editor.org/rfc/rfc6105>.		<https://www.rfc-editor.org/rfc/rfc6105>.
	[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
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
	[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,		[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
	Richardson, M., Jiang, S., Lemon, T., and T. Winters,		Richardson, M., Jiang, S., Lemon, T., and T. Winters,
	"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",		"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
	RFC 8415, DOI 10.17487/RFC8415, November 2018,		RFC 8415, DOI 10.17487/RFC8415, November 2018,
	<https://www.rfc-editor.org/rfc/rfc8415>.		<https://www.rfc-editor.org/rfc/rfc8415>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/rfc/rfc8446>.		<https://www.rfc-editor.org/rfc/rfc8446>.
End of changes. 39 change blocks.
	76 lines changed or deleted		124 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/