draft-ietf-dprive-unauth-to-authoritative-00.txt		draft-ietf-dprive-unauth-to-authoritative-01.txt
	Network Working Group P. Hoffman		Network Working Group P. Hoffman
	Internet-Draft ICANN		Internet-Draft ICANN
	Intended status: Experimental P. van Dijk		Intended status: Experimental P. van Dijk
	Expires: 14 October 2021 PowerDNS		Expires: 20 November 2021 PowerDNS
	12 April 2021		19 May 2021
	Recursive to Authoritative DNS with Unauthenticated Encryption		Recursive to Authoritative DNS with Unauthenticated Encryption
	draft-ietf-dprive-unauth-to-authoritative-00		draft-ietf-dprive-unauth-to-authoritative-01
	Abstract		Abstract
	This document describes a use case and a method for a DNS recursive		This document describes a use case and a method for a DNS recursive
	resolver to use unauthenticated encryption when communicating with		resolver to use unauthenticated encryption when communicating with
	authoritative servers. The motivating use case for this method is		authoritative servers. The motivating use case for this method is
	that more encryption on the Internet is better, and some resolver		that more encryption on the Internet is better, and some resolver
	operators believe that unauthenticated encryption is better than no		operators believe that unauthenticated encryption is better than no
	encryption at all. The method described here is optional for both		encryption at all. The method described here is optional for both
	the recursive resolver and the authoritative server. This method		the recursive resolver and the authoritative server. This method
	supports unauthenticated encryption using the same mechanism for		supports unauthenticated encryption using the same mechanism for
	discovery of encryption support for the server as		discovery of encryption support for the server as [FULL-AUTH].
	[I-D.rescorla-dprive-adox-latest].
	NOTE: The file name for this draft, draft-ietf-dprive-opportunistic-
	adotq, is now incorrect. This draft only covers unauthenticated
	encryption, not opportunistic encryption.
	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 October 2021.		This Internet-Draft will expire on 20 November 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 18 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Use Case for Unauthenticated Encryption . . . . . . . . . 3		1.1. Use Case for Unauthenticated Encryption . . . . . . . . . 3
	1.2. Summary of Protocol . . . . . . . . . . . . . . . . . . . 3		1.2. Summary of Protocol . . . . . . . . . . . . . . . . . . . 3
	1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Discovering Whether an Authoritative Server Uses		2. Discovering Whether an Authoritative Server Uses
	Encryption . . . . . . . . . . . . . . . . . . . . . . . 4		Encryption . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Resolving with Encryption . . . . . . . . . . . . . . . . . . 5		3. Resolving with Encryption . . . . . . . . . . . . . . . . . . 5
	3.1. Resolver Session Failures . . . . . . . . . . . . . . . . 6		3.1. Resolver Session Failures . . . . . . . . . . . . . . . . 5
	3.2. Resolver Process as Pseudocode . . . . . . . . . . . . . 7		4. Serving with Encryption . . . . . . . . . . . . . . . . . . . 5
	4. Serving with Encryption . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	5. Resolvers Reporting Errors to Authoritative Servers . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 6
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	A recursive resolver using traditional DNS over port 53 may wish		A recursive resolver using traditional DNS over port 53 may wish
	instead to use encrypted communication with authoritative servers in		instead to use encrypted communication with authoritative servers in
	order to limit snooping of its DNS traffic by passive or on-path		order to limit snooping of its DNS traffic by passive or on-path
	attackers. The recursive resolver can use unauthenticated encryption		attackers. The recursive resolver can use unauthenticated encryption
	(defined in [RFC7435]) to achieve this goal.		(defined in [OPPORTUN]) to achieve this goal.
	This document describes the use case for unauthenticated encryption		This document describes the use case for unauthenticated encryption
	in recursive resolvers in Section 1.1. The encryption method with		in recursive resolvers in Section 1.1. The encryption method with
	authoritative servers can be DNS-over-TLS [RFC7858] (DoT), DNS-over-		authoritative servers can be DNS-over-TLS [DNSOTLS] (DoT), DNS-over-
	HTTPS [RFC8484] (DoH), and/or DNS-over-QUIC		HTTPS [DNSOHTTPS] (DoH), and/or DNS-over-QUIC [DNSOQUIC] (DoQ), as
	[I-D.ietf-dprive-dnsoquic] (DoQ), as described in Section 3.		described in Section 3.
	The document also describes a discovery method that shows if an		The document also describes a discovery method that shows if an
	authoritative server supports encryption in Section 2.		authoritative server supports encryption in Section 2.
	See [I-D.rescorla-dprive-adox-latest] for a description of the use		See [FULL-AUTH] for a description of the use case and a proposed
	case and a proposed mechanism for fully-authenticated encryption.		mechanism for fully-authenticated encryption. See [COMMON] for a
			definition of the features that are in common between this document
			and [FULL-AUTH].
	NOTE: The draft uses the SVCB record as a discovery mechanism for		NOTE: The draft uses the SVCB record as a discovery mechanism for
	encryption by a particular authoritative server. Any record type		encryption by a particular authoritative server. Any record type
	that can show multiple types of encryption (currently DoT, DoH, and		that can show multiple types of encryption (currently DoT, DoH, and
	DoQ) can be used for discovery. Thus, this record type might change		DoQ) can be used for discovery. Thus, this record type might change
	in the future, depending on the discussion in the DPRIVE WG.		in the future, depending on the discussion in the DPRIVE WG.
	1.1. Use Case for Unauthenticated Encryption		1.1. Use Case for Unauthenticated Encryption
	The use case in this document for unauthenticated encryption is		The use case in this document for unauthenticated encryption is
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	authoritative servers to signal when they are ready to begin offering		authoritative servers to signal when they are ready to begin offering
	DNS with encryption.		DNS with encryption.
	1.2. Summary of Protocol		1.2. Summary of Protocol
	This summary gives an overview of how the parts of the protocol work		This summary gives an overview of how the parts of the protocol work
	together.		together.
	* The resolver discovers whether any authoritative server of		* The resolver discovers whether any authoritative server of
	interest supports DNS with encryption by querying for the SVCB		interest supports DNS with encryption by querying for the SVCB
	records [I-D.ietf-dnsop-svcb-https]. As described in		records [SVCB]. As described in [DNS-SVCB], SVCB records can
	[I-D.schwartz-svcb-dns], SVCB records can indicate that a server		indicate that a server supports encrypted transport of DNS
	supports encrypted transport of DNS queries.		queries.
	NOTE: In this document, the term "SVCB record" is used _only_ for		NOTE: In this document, the term "SVCB record" is used _only_ for
	SVCB records that indicate encryption as described in		SVCB records that indicate encryption as described in [DNS-SVCB].
	[I-D.schwartz-svcb-dns]. SVCB records that do not have these		SVCB records that do not have these indicators in the RDATA are
	indicators in the RDATA are not included in the term "SVCB record"		not included in the term "SVCB record" in this document.
	in this document.
	* The resolver uses any authoritative server with a SVCB record that		* The resolver uses any authoritative server with a SVCB record that
	indicates encryption to perform unauthenticated encryption.		indicates encryption to perform unauthenticated encryption.
	* The resolver does not fail to set up encryption if the		* The resolver does not fail to set up encryption if the
	authentication in the TLS session fails.		authentication in the TLS session fails.
	1.3. Definitions		1.3. Definitions
	The terms "recursive resolver", "authoritative server", and "classic		The terms "recursive resolver", "authoritative server", and "classic
	DNS" are defined in [I-D.ietf-dnsop-rfc8499bis].		DNS" are defined in [DNS-TERM].
	"DNS with encryption" means transport of DNS over any of DoT, DoH, or		"DNS with encryption" means transport of DNS over any of DoT, DoH, or
	DoQ. A server that supports DNS with encryption supports transport		DoQ. A server that supports DNS with encryption supports transport
	over one or more of DoT, DoH, or DoQ.		over one or more of DoT, DoH, or DoQ.
	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 [MUSTSHOULD1] [MUSTSHOULD2] when, and only when, they appear in
	capitals, as shown here.		all capitals, as shown here.
	2. Discovering Whether an Authoritative Server Uses Encryption		2. Discovering Whether an Authoritative Server Uses Encryption
	A recursive resolver discovers whether an authoritative server		A recursive resolver discovers whether an authoritative server
	supports DNS with encryption by looking for a cached SVCB record for		supports DNS with encryption by using the discovery mechanism
	the name of the authoritative server (with "_dns" prefix) with a		described in [COMMON]. A resolver MAY also use port probing,
	positive answer. A cached SVCB record with a negative answer		although the mechanism for that is not described here.
	indicates that the authoritative server does not support any
	encrypted transport. Positive and negative responses for SVCB
	queries are cached the same way as for all other DNS resource
	records.
	See [I-D.rescorla-dprive-adox-latest] for examples of querying for NS
	records and for SVCB records, and the interpretation of positive
	answers.
	If the cache has no positive or negative answers for any SVCB record		If the cache has no positive or negative answers for any SVCB record
	for any of a zone's authoritative servers, the resolver MAY send		for any of a zone's authoritative servers, the resolver MAY send
	queries for the SVCB records for some or all of the zone's		queries for the SVCB records for some or all of the zone's
	authoritative servers and wait for a positive response so that the		authoritative servers and wait for a positive response so that the
	resolver can use DNS with encryption for the original query. In this		resolver can use DNS with encryption for the original query. In this
	situation, the resolver MAY instead just use classic DNS for the		situation, the resolver MAY instead just use classic DNS for the
	original query but simultaneously queue queries for the SVCB records		original query but simultaneously queue queries for the SVCB records
	for some or all of the zone's authoritative servers so that future		for some or all of the zone's authoritative servers so that future
	queries might be able to use DNS with encryption.		queries might be able to use DNS with encryption.
	Discovery using SVCB records differs between resolvers using
	unauthenticated encryption and those using fully-authenticated
	encryption (described in [I-D.rescorla-dprive-adox-latest]). If the
	resolver is using unauthenticated encryption, the SVCB records do not
	need to be DNSSEC-signed.
	DNSSEC validation of SVCB RRsets used strictly for this discovery		DNSSEC validation of SVCB RRsets used strictly for this discovery
	mechanism is not mandated.		mechanism is not mandated.
	As described in [I-D.rescorla-dprive-adox-latest], these records may
	be in the resolver's cache because they came in the Additional
	section of a query for the NS records of a zone. This document does
	not rely on that feature being standardized or operationally present
	to work.
	Because some authoritative servers or middleboxes are misconfigured,
	requests for unknown RRtypes might be ignored by them. Resolvers
	should be ready to deal with timeouts or other bad responses to their
	SVCB queries.
	3. Resolving with Encryption		3. Resolving with Encryption
	A resolver following this protocol MUST use SVCB records in its cache		A resolver following this protocol processes the discovery response
	to decide whether to use classic DNS or encryption to contact		using the processing mechanism described in [COMMON].
	authoritative servers for a zone. If any of the SVCB records in the
	cache for the authoritative servers for a zone are positive
	responses, the resolver uses any of those servers for encryption. A
	resolver MUST NOT attempt encryption for a server that has a negative
	response in its cache for the associated SVCB record.
	If all of the SVCB records for the authoritative servers in the cache
	for a zone are negative responses, the resolver MUST use classic
	(unencrypted) DNS instead of encryption. Similarly, if none of the
	SVCB records for the authoritative servers in the cache have
	information about encrypted services as described in
	[I-D.schwartz-svcb-dns], the resolver MUST use classic (unencrypted)
	DNS instead of encryption.
	If there are any SVCB records in the cache for the authoritative
	servers for a zone with a positive response, the resolver MUST try
	each indicated authoritative server using DNS with encryption until
	it successfully sets up a connection. The resolver only attempts to
	use the encrypted transports that are in the associated SVCB record
	for the authoritative server. Reasons for TLS failures are listed in
	Section 3.1.
	After a DNS with encryption session is set up, the resolver uses that
	authoritative server for whatever query about the zone it was going
	to send. If a resolver cannot set up a DNS with encryption session
	with any of the authoritative servers, it MUST attempt to perform the
	resolution over classic (unencrypted) DNS as it would have without
	encryption.
	A resolver SHOULD keep a DNS with encryption session to a particular
	server open if it expects to send additional queries to that server
	in a short period of time. If the server closes the DNS with
	encryption session, the resolver can possibly re-establish a DNS with
	encryption session using encrypted session resumption. [RFC7766]
	says "both clients and servers SHOULD support connection reuse" for
	TCP connections, and that advice could apply as well for DNS with
	encryption even though DNS with encryption has greater overhead for
	saving state.
	Privacy-oriented resolvers (defined in [RFC8932]) following this		A resolver following this protocol does not need to authenticate TLS
	protocol MUST NOT indicate that they are using encryption because		servers. Thus, when setting up a TLS connection, if the server's
	this protocol is susceptible to on-path attacks.		authentication credentials do not match those expected by the
			resolver, the resolver continues with the TLS connection. Privacy-
			oriented resolvers (defined in [PRIVACY-REC]) following this protocol
			MUST NOT indicate that they are using encryption because this
			protocol is susceptible to on-path attacks.
	3.1. Resolver Session Failures		3.1. Resolver Session Failures
	The following are the reasons that a DNS with encryption session		The following are some of the reasons that a DNS with encryption
	might fail to be set up:		session might fail to be set up:
	* The resolver receives a TCP RST response		* The resolver receives a TCP RST response
	* The resolver does not receive replies to TCP or TLS setup (such as		* The resolver does not receive replies to TCP or TLS setup (such as
	getting the TCP SYN message, the first TLS message, or completing		getting the TCP SYN message, the first TLS message, or completing
	TLS handshakes)		TLS handshakes)
	* The TLS handshake gets a definitive failure		* The TLS handshake gets a definitive failure
	* The encrypted session fails for reasons other than for		* The encrypted session fails for reasons other than for
	authentication, such as incorrect algorithm choices or TLS record		authentication, such as incorrect algorithm choices or TLS record
	failures		failures
	3.2. Resolver Process as Pseudocode
	This section is meant as an informal clarification of the protocol,
	and is not normative. The pseudocode here is designed to show the
	intent of the protocol, so it is not optimized for things like
	intersection of sets and other shortcuts.
	# Inputs
	ns_names = List of NS Rdatas from the NS RRset for the queried name
	can_do_secure = List of secure transports supported by resolver
	secure_names_and_transports = Empty list, filled in below
	# Does this resolver support any secure transports?
	if length of can_do_secure is 0:
	query using classic DNS on any/all ns_names; finished
	# Fill secure_names_and_transports with (name, transport) tuples
	for this_name in ns_names:
	if signal_rrset(this_name) is in the resolver cache:
	if signal_rrset(this_name) is NXDOMAIN:
	continue
	for this_transport in signal_rrset(this_name):
	if this_transport in can_do_secure:
	add (this_name, this_transport) to secure_names_and_transports
	else: # if signal_rrset(this_name) is not in the resolver cache
	queue a query for signal_rrset(this_name) for later caching
	# Query over secure transport until successful
	for (this_name, this_transport) tuple in secure_names_and_transports:
	query using this_transport on this_name
	if successful:
	finished
	# Got here if no this_name/this_transport query was successful
	# or if secure_names_and_transports was empty
	query using classic DNS on any/all ns_names; finished
	4. Serving with Encryption		4. Serving with Encryption
	An operator of an authoritative server following this protocol SHOULD		An authoritative server following this protocol publishes the
	publish SVCB records as described in Section 2. If they cannot		discovery records using the serving mechanism described in [COMMON].
	publish such records, the security properties of their authoritative
	servers will not be found. If an operator wants to test serving
	using encryption, they can publish SVCB records with short TTLs and
	then stop serving with encryption after removing the SVCB records and
	waiting for the TTLs to expire.
	An operator of authoritative servers for a zone that is following
	this protocol MAY support encryption towards any IP address on which
	it offers service for classic DNS on port 53. It is acceptable for
	such an operator to only offer encryption on some of the named
	authoritative servers, such as when the operator is determining how
	far to roll out encrypted service.
	A server MAY close an encrypted connection at any time. For example,
	it can close the session if it has not received a DNS query in a
	defined length of time. The server MAY close an encrypted session
	after it sends a DNS response; however, it might also want to keep
	the session open waiting for another DNS query from the resolver.
	[RFC7766] says "both clients and servers SHOULD support connection
	reuse" for TCP connections, and that advice could apply as well for
	DNS with encryption even though DNS with encryption has greater
	overhead for saving state.
	5. Resolvers Reporting Errors to Authoritative Servers
	Resolvers should have a method of telling authoritative servers that
	there are problems with the encrypted service they are offering.
	There is a proposal that the DNSOP Working Group might adopt
	[I-D.arends-dns-error-reporting], which would enable such reporting.
	(( Clearly, more will need to go here. ))
	6. IANA Considerations
	(( Update registration for TCP/853 to also include ADoT ))		5. IANA Considerations
	(( Maybe other updates for DoH and DoQ ))		Relevant IANA considerations are covered in [COMMON].
	7. Security Considerations		6. Security Considerations
	The method described in this document explicitly allows a resolver to		The method described in this document explicitly allows a resolver to
	perform DNS communications over traditional unencrypted,		perform DNS communications over traditional unencrypted,
	unauthenticated DNS on port 53, if it cannot find an authoritative		unauthenticated DNS on port 53, if it cannot find an authoritative
	server that advertises that it supports encryption. The method		server that advertises that it supports encryption. The method
	described in this document explicitly allows a resolver using		described in this document explicitly allows a resolver using
	encryption to choose to allow unauthenticated encryption. In either		encryption to choose to allow unauthenticated encryption. In either
	of these cases, the resulting communication will be susceptible to		of these cases, the resulting communication will be susceptible to
	obvious and well-understood attacks from an attacker in the path of		obvious and well-understood attacks from an attacker in the path of
	the communications.		the communications.
	An authoritative server that wants to only serve data to resolvers		7. Acknowledgements
	that using fully-authenticated encryption as described in
	[I-D.rescorla-dprive-adox-latest] cannot differentiate between those
	resolvers and resolvers using the mechanisms described in this
	document.
	8. Acknowledgements
	Puneet Sood contributed many ideas to early drafts of this document.		Puneet Sood contributed many ideas to early drafts of this document.
	The DPRIVE Working Group has contributed many ideas that keep		The DPRIVE Working Group has contributed many ideas that keep
	shifting the focus and content of this document.		shifting the focus and content of this document.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[I-D.ietf-dnsop-rfc8499bis]		[COMMON] Dijk, P. V. and P. Hoffman, "Common Features for Encrypted
	Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in		Recursive to Authoritative DNS", Work in Progress,
			Internet-Draft, draft-pp-dprive-common-features-00, 2 May
			2021, <https://www.ietf.org/archive/id/draft-pp-dprive-
			common-features-00.txt>.
			[DNS-SVCB] Schwartz, B., "Service Binding Mapping for DNS Servers",
			Work in Progress, Internet-Draft, draft-schwartz-svcb-dns-
			03, 19 April 2021, <https://www.ietf.org/archive/id/draft-
			schwartz-svcb-dns-03.txt>.
			[DNS-TERM] Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in
	Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-01,		Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-01,
	20 November 2020, <https://www.ietf.org/archive/id/draft-		20 November 2020, <https://www.ietf.org/archive/id/draft-
	ietf-dnsop-rfc8499bis-01.txt>.		ietf-dnsop-rfc8499bis-01.txt>.
	[I-D.ietf-dnsop-svcb-https]		[FULL-AUTH]
	Schwartz, B., Bishop, M., and E. Nygren, "Service binding
	and parameter specification via the DNS (DNS SVCB and
	HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-
	dnsop-svcb-https-04, 17 March 2021,
	<https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-
	https-04.txt>.
	[I-D.rescorla-dprive-adox-latest]
	Pauly, T., Rescorla, E., Schinazi, D., and C. A. Wood,		Pauly, T., Rescorla, E., Schinazi, D., and C. A. Wood,
	"Signaling Authoritative DNS Encryption", Work in		"Signaling Authoritative DNS Encryption", Work in
	Progress, Internet-Draft, draft-rescorla-dprive-adox-		Progress, Internet-Draft, draft-rescorla-dprive-adox-
	latest-00, 26 February 2021,		latest-00, 26 February 2021,
	<https://www.ietf.org/archive/id/draft-rescorla-dprive-		<https://www.ietf.org/archive/id/draft-rescorla-dprive-
	adox-latest-00.txt>.		adox-latest-00.txt>.
	[I-D.schwartz-svcb-dns]		[MUSTSHOULD1]
	Schwartz, B., "Service Binding Mapping for DNS Servers",		Bradner, S., "Key words for use in RFCs to Indicate
	Work in Progress, Internet-Draft, draft-schwartz-svcb-dns-
	02, 17 February 2021, <https://www.ietf.org/archive/id/
	draft-schwartz-svcb-dns-02.txt>.
	[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>.
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection		[MUSTSHOULD2]
			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/info/rfc8174>.
			[OPPORTUN] Dukhovni, V., "Opportunistic Security: Some Protection
	Most of the Time", RFC 7435, DOI 10.17487/RFC7435,		Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
	December 2014, <https://www.rfc-editor.org/info/rfc7435>.		December 2014, <https://www.rfc-editor.org/info/rfc7435>.
	[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and		[SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding
	D. Wessels, "DNS Transport over TCP - Implementation		and parameter specification via the DNS (DNS SVCB and
	Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,		HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-
	<https://www.rfc-editor.org/info/rfc7766>.		dnsop-svcb-https-05, 21 April 2021,
			<https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-
	[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		https-05.txt>.
	and P. Hoffman, "Specification for DNS over Transport
	Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
	2016, <https://www.rfc-editor.org/info/rfc7858>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		8.2. Informative References
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS		[DNSOHTTPS]
			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		[DNSOQUIC] Huitema, C., Mankin, A., and S. Dickinson, "Specification
	[I-D.arends-dns-error-reporting]
	Arends, R. and M. Larson, "DNS Error Reporting", Work in
	Progress, Internet-Draft, draft-arends-dns-error-
	reporting-00, 30 October 2020,
	<https://www.ietf.org/archive/id/draft-arends-dns-error-
	reporting-00.txt>.
	[I-D.ietf-dprive-dnsoquic]
	Huitema, C., Mankin, A., and S. Dickinson, "Specification
	of DNS over Dedicated QUIC Connections", Work in Progress,		of DNS over Dedicated QUIC Connections", Work in Progress,
	Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February		Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February
	2021, <https://www.ietf.org/archive/id/draft-ietf-dprive-		2021, <https://www.ietf.org/archive/id/draft-ietf-dprive-
	dnsoquic-02.txt>.		dnsoquic-02.txt>.
	[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and		[DNSOTLS] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
			and P. Hoffman, "Specification for DNS over Transport
			Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
			2016, <https://www.rfc-editor.org/info/rfc7858>.
			[PRIVACY-REC]
			Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
	A. Mankin, "Recommendations for DNS Privacy Service		A. Mankin, "Recommendations for DNS Privacy Service
	Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,		Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
	October 2020, <https://www.rfc-editor.org/info/rfc8932>.		October 2020, <https://www.rfc-editor.org/info/rfc8932>.
	[RSO_STATEMENT]		[RSO_STATEMENT]
	"Statement on DNS Encryption", 2021, <https://root-		"Statement on DNS Encryption", 2021, <https://root-
	servers.org/media/news/Statement_on_DNS_Encryption.pdf>.		servers.org/media/news/Statement_on_DNS_Encryption.pdf>.
	Authors' Addresses		Authors' Addresses
End of changes. 35 change blocks.
	238 lines changed or deleted		91 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/