< draft-ietf-add-ddr-00.txt		draft-ietf-add-ddr-01.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: 14 August 2021 C.A. Wood		Expires: 16 December 2021 C.A. Wood
	Cloudflare		Cloudflare
	P. McManus		P. McManus
	Fastly		Fastly
	T. Jensen		T. Jensen
	Microsoft		Microsoft
	10 February 2021		14 June 2021
	Discovery of Designated Resolvers		Discovery of Designated Resolvers
	draft-ietf-add-ddr-00		draft-ietf-add-ddr-01
	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 an		unencrypted DNS to encrypted DNS when only the IP address of an
	encrypted resolver is known. It can also be used to discover support		encrypted resolver is known. It can also be used to discover support
	for encrypted DNS protocols when the name of an encrypted resolver is		for encrypted DNS protocols when the name of an encrypted resolver is
	known. This mechanism is designed to be limited to cases where		known. This mechanism is designed to be limited to cases where
	unencrypted resolvers and their designated resolvers are operated by		unencrypted resolvers and their designated resolvers are operated by
	the same entity.		the same entity or cooperating entities.
			Discussion Venues
			This note is to be removed before publishing as an RFC.
			Discussion of this document takes place on the Adaptive DNS Discovery
			Working Group mailing list (add@ietf.org), which is archived at
			https://mailarchive.ietf.org/arch/browse/add/.
			Source for this draft and an issue tracker can be found at
			https://github.com/ietf-wg-add/draft-ietf-add-ddr.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 14 August 2021.		This Internet-Draft will expire on 16 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		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 . . . . . . . . . . . . . . . . . 3		3. DNS Service Binding Records . . . . . . . . . . . . . . . . . 4
	4. Discovery Using Resolver IP Addresses . . . . . . . . . . . . 4		4. Discovery Using Resolver IP Addresses . . . . . . . . . . . . 5
	4.1. Authenticated Discovery . . . . . . . . . . . . . . . . . 5		4.1. Authenticated Discovery . . . . . . . . . . . . . . . . . 5
	4.2. Opportunistic Discovery . . . . . . . . . . . . . . . . . 5		4.2. Opportunistic Discovery . . . . . . . . . . . . . . . . . 6
	5. Discovery Using Resolver Names . . . . . . . . . . . . . . . 6		5. Discovery Using Resolver Names . . . . . . . . . . . . . . . 6
	6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6		6. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
	6.1. Caching Forwarders . . . . . . . . . . . . . . . . . . . 7		6.1. Caching Forwarders . . . . . . . . . . . . . . . . . . . 7
	6.2. Certificate Management . . . . . . . . . . . . . . . . . 7		6.2. Certificate Management . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Special Use Domain Name "resolver.arpa" . . . . . . . . . 8		8.1. Special Use Domain Name "resolver.arpa" . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix A. Rationale for using SVCB records . . . . . . . . . . 10		Appendix A. Rationale for using SVCB records . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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] or DNS-over-HTTPS (DoH) [RFC8484], they
	require additional information beyond the IP address of the DNS		require additional information beyond the IP address of the DNS
	server, such as the resolver's hostname, non-standard ports, or URL		server, such as the resolver's hostname, non-standard ports, or URL
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 33 ¶
	records associated with the Unencrypted Resolver (Section 4).		records associated with the Unencrypted Resolver (Section 4).
	2. When the hostname of an encrypted DNS server is known, the client		2. When the hostname of an encrypted DNS server 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. "Equivalence" in this context means that the resolvers are		resolver. "Designated" in this context means that the resolvers are
	operated by the same entity; for example, the resolvers are		operated by the same entity or cooperating entities; for example, the
	accessible on the same IP address, or there is a certificate that		resolvers are accessible on the same IP address, or there is a
	claims ownership over both resolvers.		certificate that claims ownership over both resolvers.
	1.1. Specification of Requirements		1.1. Specification of Requirements
	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.
	2. Terminology		2. Terminology
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 31 ¶
	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, ports, and server name to use in
	certificate validation. This information is provided in Service		certificate validation. This information is provided in Service
	Binding (SVCB) records for DNS Servers, defined by		Binding (SVCB) records for DNS Servers, defined by
	[I-D.schwartz-svcb-dns].		[I-D.schwartz-svcb-dns].
	The following is an example of an SVCB record describing a DoH		The following is an example of an SVCB record describing a DoH
	server:		server:
	_dns.example.net 7200 IN SVCB 1 . (		_dns.example.net 7200 IN SVCB 1 . (
	alpn=h2 dohpath=/dns-query{?dns} ipv4hint=x.y.z.w )		alpn=h2 dohpath=/dns-query{?dns} )
	The following is an example of an SVCB record describing a DoT		The following is an example of an SVCB record describing a DoT
	server:		server:
	_dns.example.net 7200 IN SVCB 1 dot.example.net (		_dns.example.net 7200 IN SVCB 1 dot.example.net (
	alpn=dot port=8530 ipv4hint=x.y.z.w )		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
	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].
	This document focuses on discovering DoH and DoT Designated		This document focuses on discovering DoH and DoT Designated
	Resolvers. Other protocols can also use the format defined by		Resolvers. Other protocols can also use the format defined by
	[I-D.schwartz-svcb-dns]. However, if any protocol does not involve		[I-D.schwartz-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 equivalence as defined in		need to be defined to support validating designation as defined in
	Section 4.1.		Section 4.1.
	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].
	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 SVCB records SHOULD contain at least one "ipv4hint" and/or		the recursive resolver SHOULD include the A and AAAA records for the
	"ipv6hint" keys. These address hints indicate the address on which		name of the Designated Resolver in the Additional Answers section.
	the corresponding Encrypted Resolver can be reached and avoid		This will allow the DNS client to make queries over an encrypted
	additional DNS lookup for the A and AAAA records of the Encrypted		connection without waiting to resolve the Encrypted Resolver name per
	Resolver name.		[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
			Encrypted Resolver until an additional DNS lookup for the A and AAAA
			records can be made to the Unencrypted Resolver (or some other
			resolver the DNS client has been configured to use).
			If the recursive resolver that receives this query has no Designated
			Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"
			SUDN.
	4.1. Authenticated Discovery		4.1. Authenticated Discovery
	In order to be considered an authenticated Designated Resolver, the		In order to be considered an authenticated Designated Resolver, the
	TLS certificate presented by the Encrypted Resolver MUST contain both		TLS certificate presented by the Encrypted Resolver MUST contain both
	the domain name (from the SVCB answer) and the IP address of the		the domain name (from the SVCB answer) and the IP address of the
	designating Unencrypted Resolver within the SubjectAlternativeName		designating Unencrypted Resolver within the SubjectAlternativeName
	certificate field. The client MUST check the SubjectAlternativeName		certificate field. The client MUST check the SubjectAlternativeName
	field for both the Unencrypted Resolver's IP address and the		field for both the Unencrypted Resolver's IP address and the
	advertised name of the Designated Resolver. If the certificate can		advertised name of the Designated Resolver. If the certificate can
	skipping to change at page 5, line 28 ¶		skipping to change at page 6, line 5 ¶
	not cover the Unencrypted Resolver address, the client MUST NOT use		not cover the Unencrypted Resolver address, the client MUST NOT use
	the discovered Encrypted Resolver. Additionally, the client SHOULD		the discovered Encrypted Resolver. Additionally, the client SHOULD
	suppress any further queries for Designated Resolvers using this		suppress any further queries for Designated Resolvers using this
	Unencrypted Resolver for the length of time indicated by the SVCB		Unencrypted Resolver for the length of time indicated by the SVCB
	record's Time to Live (TTL).		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 Encrypted		address, clients MAY choose to opportunistically use the Encrypted
	Resolver even without this certificate check (Section 4.2).		Resolver even without this certificate check (Section 4.2).
			If resolving the name of an Encrypted Resolver from an SVCB record
			yields an IP address that was not presented in the Additional Answers
			section or ipv4hint or ipv6hint fields of the original SVCB query,
			the connection made to that IP address MUST pass the same TLS
			certificate checks before being allowed to replace a previously known
			and validated IP address for the same Encrypted Resolver name.
	4.2. Opportunistic Discovery		4.2. Opportunistic Discovery
	There are situations where authenticated discovery of encrypted DNS		There are situations where authenticated 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 whose identity		Unencrypted Resolvers on non-public IP addresses such as those
	cannot be confirmed using TLS certificates.		defined in [RFC1918] 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. 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, and that IP address is a private address		of the Unencrypted Resolver. This approach can be used for any
	(such as those defined in [RFC1918]). This approach can be used for		encrypted DNS protocol that uses TLS.
	DoT or DoH.
	If the IP addresses of the Encrypted and Unencrypted Resolvers are
	not the same, or the shared IP address is not a private IP address,
	the client MUST NOT use the Encrypted Resolver opportunistically.
	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 DEER 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.
	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.
	skipping to change at page 6, line 35 ¶		skipping to change at page 7, line 13 ¶
	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 . (
	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 2 . (
	alpn=dot )		alpn=dot )
	Often, the various supported encrypted DNS protocols will be		Often, the various supported encrypted DNS protocols will be
	accessible using the same hostname. In the example above, both DoH		accessible using the same hostname. In the example above, both DoH
	and DoT use the name "resolver.example.com" for their TLS		and DoT use the name "resolver.example.com" for their TLS
	certficates. If a deployment uses a different hostname for one		certificates. If a deployment uses a different hostname for one
	protocol, but still wants clients to treat both DNS servers as		protocol, but still wants clients to treat both DNS servers as
	designated, the TLS certificates MUST include both names in the		designated, the TLS certificates MUST include both names in the
	SubjectAlternativeName fields. Note that this name verification is		SubjectAlternativeName fields. Note that this name verification is
	not related to the DNS resolver that provided the SVCB answer.		not related to the DNS resolver that provided the SVCB answer.
	For example, being able to discover a Designated Resolver for a known		For example, being able to discover a Designated Resolver for a known
	Encrypted Resolver is useful when a client has a DoT configuration		Encrypted Resolver is useful when a client has a DoT configuration
	for "foo.resolver.example.com" but is on a network that blocks DoT		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		traffic. The client can still send a query to any other accessible
	resolver (either the local network resolver or an accessible DoH		resolver (either the local network resolver or an accessible DoH
	server) to discover if there is a designated DoH server for		server) to discover if there is a designated DoH server for
	"foo.resolver.example.com".		"foo.resolver.example.com".
	6. Deployment Considerations		6. Deployment Considerations
	Resolver deployments that support DEER 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
	If a caching forwarder consults multiple resolvers, it may be		A DNS forwarder SHOULD NOT forward queries for "resolver.arpa"
	possible for it to cache records for the "resolver.arpa" Special Use		upstream. This prevents a client from receiving an SVCB record that
	Domain Name (SUDN) for multiple resolvers. This may result in		will fail to authenticate because the forwarder's IP address is not
	clients sending queries intended to discover Designated Resolvers for		in the upstream resolver's Designated Resolver's TLS certificate SAN
	resolver "foo" and receiving answers for resolvers "foo" and "bar".		field. A DNS forwarder which already acts as a completely blind
			forwarder MAY choose to forward these queries when the operator
	A client will successfully reject unintended connections because the		expects that this does not apply, either because the operator knows
	authenticated discovery will fail or the resolver addresses do not		the upstream resolver does have the forwarder's IP address in its TLS
	match. Clients that attempt unauthenticated connections to resolvers		certificate's SAN field or that the operator expects clients of the
	discovered through SVCB queries run the risk of connecting to the		unencrypted resolver to use the SVCB information opportunistically.
	wrong server in this scenario.
	To prevent unnecessary traffic from clients to incorrect resolvers,		Operators who choose to forward queries for "resolver.arpa" upstream
	DNS caching resolvers SHOULD NOT cache results for the		should note that client behavior is never guaranteed and use of DDR
	"resolver.arpa" SUDN other than for Designated Resolvers under their		by a resolver does not communicate a requirement for clients to use
	control.		the SVCB record when it cannot be authenticated.
	6.2. Certificate Management		6.2. Certificate Management
	Resolver owners that support authenticated discovery will need to		Resolver owners that support authenticated discovery will need to
	list valid referring IP addresses in their TLS certificates. This		list valid referring IP addresses in their TLS certificates. This
	may pose challenges for resolvers with a large number of referring IP		may pose challenges for resolvers with a large number of referring IP
	addresses.		addresses.
	7. Security Considerations		7. Security Considerations
	skipping to change at page 8, line 26 ¶		skipping to change at page 9, line 5 ¶
	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 creation of the "resolver.arpa" SUDN.
	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
			querying client is not interested in an answer from the authoritative
			"arpa" name servers. The intent of the SUDN is to allow clients to
			communicate with the Unencrypted Resolver much like "ipv4only.arpa"
			allows for client-to-middlebox communication. For more context, see
			the rationale behind "ipv4only.arpa" in [RFC8880].
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[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-02, 2 November 2020,		dnsop-svcb-https-05, 21 April 2021,
	<http://www.ietf.org/internet-drafts/draft-ietf-dnsop-		<https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-
	svcb-https-02.txt>.		https-05.txt>.
	[I-D.ietf-tls-esni]		[I-D.ietf-tls-esni]
	Rescorla, E., Oku, K., Sullivan, N., and C. 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-09, 16 December 2020,		draft-ietf-tls-esni-10, 8 March 2021,
	<http://www.ietf.org/internet-drafts/draft-ietf-tls-esni-		<https://www.ietf.org/archive/id/draft-ietf-tls-esni-
	09.txt>.		10.txt>.
	[I-D.schwartz-svcb-dns]		[I-D.schwartz-svcb-dns]
	Schwartz, B., "Service Binding Mapping for DNS Servers",		Schwartz, B., "Service Binding Mapping for DNS Servers",
	Work in Progress, Internet-Draft, draft-schwartz-svcb-dns-		Work in Progress, Internet-Draft, draft-schwartz-svcb-dns-
	01, 10 August 2020, <http://www.ietf.org/internet-drafts/		03, 19 April 2021, <https://www.ietf.org/archive/id/draft-
	draft-schwartz-svcb-dns-01.txt>.		schwartz-svcb-dns-03.txt>.
	[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/info/rfc1918>.		February 1996, <https://www.rfc-editor.org/info/rfc1918>.
	[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/info/rfc7858>.		2016, <https://www.rfc-editor.org/info/rfc7858>.
	skipping to change at page 9, line 25 ¶		skipping to change at page 10, line 9 ¶
	[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/info/rfc8484>.		<https://www.rfc-editor.org/info/rfc8484>.
	9.2. Informative References		9.2. Informative References
	[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,
	<http://www.ietf.org/internet-drafts/draft-schinazi-		<https://www.ietf.org/archive/id/draft-schinazi-httpbis-
	httpbis-doh-preference-hints-02.txt>.		doh-preference-hints-02.txt>.
	[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/info/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/info/rfc2132>.		<https://www.rfc-editor.org/info/rfc2132>.
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 40 ¶
	[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/info/rfc8106>.		<https://www.rfc-editor.org/info/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/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8880] Cheshire, S. and D. Schinazi, "Special Use Domain Name
			'ipv4only.arpa'", RFC 8880, DOI 10.17487/RFC8880, August
			2020, <https://www.rfc-editor.org/info/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
	Resolver (using its domain name).		Resolver (using its domain name).
	There are various other proposals for how to provide similar		There are various other proposals for how to provide similar
	functionality. There are several reasons that this mechanism has		functionality. There are several reasons that this mechanism has
End of changes. 31 change blocks.
	64 lines changed or deleted		96 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/