< draft-ietf-dprive-dnsoquic-07.txt		draft-ietf-dprive-dnsoquic-08.txt >
	Network Working Group C. Huitema		Network Working Group C. Huitema
	Internet-Draft Private Octopus Inc.		Internet-Draft Private Octopus Inc.
	Intended status: Standards Track S. Dickinson		Intended status: Standards Track S. Dickinson
	Expires: 4 June 2022 Sinodun IT		Expires: 14 July 2022 Sinodun IT
	A. Mankin		A. Mankin
	Salesforce		Salesforce
	1 December 2021		10 January 2022
	DNS over Dedicated QUIC Connections		DNS over Dedicated QUIC Connections
	draft-ietf-dprive-dnsoquic-07		draft-ietf-dprive-dnsoquic-08
	Abstract		Abstract
	This document describes the use of QUIC to provide transport privacy		This document describes the use of QUIC to provide transport privacy
	for DNS. The encryption provided by QUIC has similar properties to		for DNS. The encryption provided by QUIC has similar properties to
	that provided by TLS, while QUIC transport eliminates the head-of-		that provided by TLS, while QUIC transport eliminates the head-of-
	line blocking issues inherent with TCP and provides more efficient		line blocking issues inherent with TCP and provides more efficient
	packet loss recovery than UDP. DNS over QUIC (DoQ) has privacy		packet loss recovery than UDP. DNS over QUIC (DoQ) has privacy
	properties similar to DNS over TLS (DoT) specified in RFC7858, and		properties similar to DNS over TLS (DoT) specified in RFC7858, and
	latency characteristics similar to classic DNS over UDP.		latency characteristics similar to classic DNS over UDP. This
			specification describes the use of DNS over QUIC as a general-purpose
			transport for DNS and includes the use of DNS over QUIC for stub to
			recursive, recursive to authoritative, and zone transfer scenarios.
	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 4 June 2022.		This Internet-Draft will expire on 14 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	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
	2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Document work via GitHub . . . . . . . . . . . . . . . . . . 5		3. Document work via GitHub . . . . . . . . . . . . . . . . . . 5
	4. Design Considerations . . . . . . . . . . . . . . . . . . . . 5		4. Design Considerations . . . . . . . . . . . . . . . . . . . . 5
	4.1. Provide DNS Privacy . . . . . . . . . . . . . . . . . . . 5		4.1. Provide DNS Privacy . . . . . . . . . . . . . . . . . . . 5
	4.2. Design for Minimum Latency . . . . . . . . . . . . . . . 5		4.2. Design for Minimum Latency . . . . . . . . . . . . . . . 5
	4.3. Middlebox Considerations . . . . . . . . . . . . . . . . 6		4.3. Middlebox Considerations . . . . . . . . . . . . . . . . 6
	4.4. No Server Initiated Transactions . . . . . . . . . . . . 6		4.4. No Server-Initiated Transactions . . . . . . . . . . . . 6
	5. Specifications . . . . . . . . . . . . . . . . . . . . . . . 6		5. Specifications . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Connection Establishment . . . . . . . . . . . . . . . . 6		5.1. Connection Establishment . . . . . . . . . . . . . . . . 7
	5.1.1. Draft Version Identification . . . . . . . . . . . . 7		5.1.1. Draft Version Identification . . . . . . . . . . . . 7
	5.1.2. Port Selection . . . . . . . . . . . . . . . . . . . 7		5.1.2. Port Selection . . . . . . . . . . . . . . . . . . . 7
	5.2. Stream Mapping and Usage . . . . . . . . . . . . . . . . 7		5.2. Stream Mapping and Usage . . . . . . . . . . . . . . . . 7
	5.2.1. DNS Message IDs . . . . . . . . . . . . . . . . . . . 8		5.2.1. DNS Message IDs . . . . . . . . . . . . . . . . . . . 8
	5.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 9		5.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 9
	5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 9		5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 9
	5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 10		5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 10
	5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 10		5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 10
	5.3.4. Alternative error codes . . . . . . . . . . . . . . . 11		5.3.4. Alternative error codes . . . . . . . . . . . . . . . 11
	5.4. Connection Management . . . . . . . . . . . . . . . . . . 11		5.4. Connection Management . . . . . . . . . . . . . . . . . . 11
	5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 12		5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 12
	5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 13		5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 13
	6. Implementation Requirements . . . . . . . . . . . . . . . . . 13		6. Implementation Requirements . . . . . . . . . . . . . . . . . 13
	6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 13		6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 13
	6.2. Fallback to Other Protocols on Connection Failure . . . . 14		6.2. Fallback to Other Protocols on Connection Failure . . . . 14
	6.3. Address Validation . . . . . . . . . . . . . . . . . . . 14		6.3. Address Validation . . . . . . . . . . . . . . . . . . . 14
	6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14		6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 15		6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 15
	6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 15		6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 15
	6.5.2. Resource Management . . . . . . . . . . . . . . . . . 15		6.5.2. Resource Management . . . . . . . . . . . . . . . . . 16
	6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 16		6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 16
	6.5.4. Controlling Connection Migration For Privacy . . . . 17		6.5.4. Controlling Connection Migration For Privacy . . . . 17
	6.6. Processing Queries in Parallel . . . . . . . . . . . . . 17		6.6. Processing Queries in Parallel . . . . . . . . . . . . . 17
	6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 17		6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 17
	6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 18		6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 18
	7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18		7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
	7.1. Performance Measurements . . . . . . . . . . . . . . . . 19		7.1. Performance Measurements . . . . . . . . . . . . . . . . 19
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 20		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20		9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
	9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 20		9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 20
	9.2. Privacy Issues With Session Resumption . . . . . . . . . 21		9.2. Privacy Issues With Session Resumption . . . . . . . . . 21
	9.3. Privacy Issues With Address Validation Tokens . . . . . . 22		9.3. Privacy Issues With Address Validation Tokens . . . . . . 22
	9.4. Privacy Issues With Long Duration Sessions . . . . . . . 22		9.4. Privacy Issues With Long Duration Sessions . . . . . . . 22
	9.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23		9.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	10.1. Registration of DoQ Identification String . . . . . . . 23		10.1. Registration of DoQ Identification String . . . . . . . 23
	10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 23		10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 23
	10.2.1. Port number 784 for experimentations . . . . . . . . 24		10.2.1. Port number 784 for experimentations . . . . . . . . 24
	10.3. Reservation of Extended DNS Error Code Too Early . . . . 24		10.3. Reservation of Extended DNS Error Code Too Early . . . . 24
	10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 24		10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 25
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	12.1. Normative References . . . . . . . . . . . . . . . . . . 26		12.1. Normative References . . . . . . . . . . . . . . . . . . 27
	12.2. Informative References . . . . . . . . . . . . . . . . . 29		12.2. Informative References . . . . . . . . . . . . . . . . . 29
	Appendix A. The NOTIFY Service . . . . . . . . . . . . . . . . . 30		Appendix A. The NOTIFY Service . . . . . . . . . . . . . . . . . 30
	Appendix B. Notable Changes From Previous Versions . . . . . . . 30		Appendix B. Notable Changes From Previous Versions . . . . . . . 31
	B.1. Stream Mapping Incompatibility With Draft-02 . . . . . . 31		B.1. Stream Mapping Incompatibility With Draft-02 . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	Domain Name System (DNS) concepts are specified in "Domain names -		Domain Name System (DNS) concepts are specified in "Domain names -
	concepts and facilities" [RFC1034]. The transmission of DNS queries		concepts and facilities" [RFC1034]. The transmission of DNS queries
	and responses over UDP and TCP is specified in "Domain names -		and responses over UDP and TCP is specified in "Domain names -
	implementation and specification" [RFC1035].		implementation and specification" [RFC1035].
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 9 ¶
	2. Provide an improved level of source address validation for DNS		2. Provide an improved level of source address validation for DNS
	servers compared to classic DNS over UDP.		servers compared to classic DNS over UDP.
	3. Provide a transport that is not constrained by path MTU		3. Provide a transport that is not constrained by path MTU
	limitations on the size of DNS responses it can send.		limitations on the size of DNS responses it can send.
	In order to achieve these goals, and to support ongoing work on		In order to achieve these goals, and to support ongoing work on
	encryption of DNS, the scope of this document includes		encryption of DNS, the scope of this document includes
	* the "stub to recursive resolver" scenario		* the "stub to recursive resolver" scenario
	* the "recursive resolver to authoritative nameserver" scenario and		* the "recursive resolver to authoritative nameserver" scenario and
	* the "nameserver to nameserver" scenario (mainly used for zone		* the "nameserver to nameserver" scenario (mainly used for zone
	transfers (XFR) [RFC1995], [RFC5936]).		transfers (XFR) [RFC1995], [RFC5936]).
	In other words, this document is intended to specify QUIC as a		In other words, this document specifies QUIC as a general-purpose
	general purpose transport for DNS.		transport for DNS.
	The specific non-goals of this document are:		The specific non-goals of this document are:
	1. No attempt is made to evade potential blocking of DNS over QUIC		1. No attempt is made to evade potential blocking of DNS over QUIC
	traffic by middleboxes.		traffic by middleboxes.
	2. No attempt to support server initiated transactions, which are		2. No attempt to support server-initiated transactions, which are
	used only in DNS Stateful Operations (DSO) [RFC8490].		used only in DNS Stateful Operations (DSO) [RFC8490].
	Specifying the transmission of an application over QUIC requires		Specifying the transmission of an application over QUIC requires
	specifying how the application's messages are mapped to QUIC streams,		specifying how the application's messages are mapped to QUIC streams,
	and generally how the application will use QUIC. This is done for		and generally how the application will use QUIC. This is done for
	HTTP in "Hypertext Transfer Protocol Version 3		HTTP in "Hypertext Transfer Protocol Version 3
	(HTTP/3)"[I-D.ietf-quic-http]. The purpose of this document is to		(HTTP/3)"[I-D.ietf-quic-http]. The purpose of this document is to
	define the way DNS messages can be transmitted over QUIC.		define the way DNS messages can be transmitted over QUIC.
	DNS over HTTP [RFC8484] can be used with HTTP/3 to get some of the		DNS over HTTP [RFC8484] can be used with HTTP/3 to get some of the
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 49 ¶
	behavior.		behavior.
	In this document, Section 4 presents the reasoning that guided the		In this document, Section 4 presents the reasoning that guided the
	proposed design. Section 5 specifies the actual mapping of DoQ.		proposed design. Section 5 specifies the actual mapping of DoQ.
	Section 6 presents guidelines on the implementation, usage and		Section 6 presents guidelines on the implementation, usage and
	deployment of DoQ.		deployment of DoQ.
	2. Key Words		2. Key Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in BCP 14 [RFC8174].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. Document work via GitHub		3. Document work via GitHub
	(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)The		(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)The
	Github repository for this document is at https://github.com/huitema/		Github repository for this document is at https://github.com/huitema/
	dnsoquic. Proposed text and editorial changes are very much welcomed		dnsoquic. Proposed text and editorial changes are very much welcomed
	there, but any functional changes should always first be discussed on		there, but any functional changes should always first be discussed on
	the IETF DPRIVE WG (dns-privacy) mailing list.		the IETF DPRIVE WG (dns-privacy) mailing list.
	4. Design Considerations		4. Design Considerations
	This section and its subsections present the design guidelines that		This section and its subsections present the design guidelines that
	were used for DoQ. This section is informative in nature.		were used for DoQ. Whilst all other sections in this document are
			normative, this section is informative in nature.
	4.1. Provide DNS Privacy		4.1. Provide DNS Privacy
	DoT [RFC7858] defines how to mitigate some of the issues described in		DoT [RFC7858] defines how to mitigate some of the issues described in
	"DNS Privacy Considerations" [RFC9076] by specifying how to transmit		"DNS Privacy Considerations" [RFC9076] by specifying how to transmit
	DNS messages over TLS. The "Usage Profiles for DNS over TLS and DNS		DNS messages over TLS. The "Usage Profiles for DNS over TLS and DNS
	over DTLS" [RFC8310] specify Strict and Opportunistic Usage Profiles		over DTLS" [RFC8310] specify Strict and Opportunistic Usage Profiles
	for DoT including how stub resolvers can authenticate recursive		for DoT including how stub resolvers can authenticate recursive
	resolvers.		resolvers.
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 36 ¶
	devices on the network path using encryption and traffic analysis		devices on the network path using encryption and traffic analysis
	resistance techniques like padding. This specification does not		resistance techniques like padding. This specification does not
	include any measures that are designed to avoid such classification.		include any measures that are designed to avoid such classification.
	Consequently, firewalls and other middleboxes might be able to		Consequently, firewalls and other middleboxes might be able to
	distinguish DoQ from other protocols that use QUIC, like HTTP, and		distinguish DoQ from other protocols that use QUIC, like HTTP, and
	apply different treatment.		apply different treatment.
	The lack of measures in this specification to avoid protocol		The lack of measures in this specification to avoid protocol
	classification is not an endorsement of such practices.		classification is not an endorsement of such practices.
	4.4. No Server Initiated Transactions		4.4. No Server-Initiated Transactions
	As stated in Section 1, this document does not specify support for		As stated in Section 1, this document does not specify support for
	server initiated transactions within established DoQ connections.		server-initiated transactions within established DoQ connections.
	That is, only the initiator of the DoQ connection may send queries		That is, only the initiator of the DoQ connection may send queries
	over the connection.		over the connection.
	DSO does support server-initiated transactions within existing		DSO does support server-initiated transactions within existing
	connections. However DoQ as defined here does not meet the criteria		connections. However, DoQ as defined here does not meet the criteria
	for an applicable transport for DSO because it does not guarantee in-		for an applicable transport for DSO because it does not guarantee in-
	order delivery of messages, see Section 4.2 of [RFC8490].		order delivery of messages, see Section 4.2 of [RFC8490].
	5. Specifications		5. Specifications
	5.1. Connection Establishment		5.1. Connection Establishment
	DoQ connections are established as described in the QUIC transport		DoQ connections are established as described in the QUIC transport
	specification [RFC9000]. During connection establishment, DoQ		specification [RFC9000]. During connection establishment, DoQ
	support is indicated by selecting the ALPN token "doq" in the crypto		support is indicated by selecting the ALPN token "doq" in the crypto
	handshake.		handshake.
	5.1.1. Draft Version Identification		5.1.1. Draft Version Identification
	(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) Only		(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) Only
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 34 ¶
	By default, a DNS server that supports DoQ MUST listen for and accept		By default, a DNS server that supports DoQ MUST listen for and accept
	QUIC connections on the dedicated UDP port TBD (number to be defined		QUIC connections on the dedicated UDP port TBD (number to be defined
	in Section 10), unless there is a mutual agreement to use another		in Section 10), unless there is a mutual agreement to use another
	port.		port.
	By default, a DNS client desiring to use DoQ with a particular server		By default, a DNS client desiring to use DoQ with a particular server
	MUST establish a QUIC connection to UDP port TBD on the server,		MUST establish a QUIC connection to UDP port TBD on the server,
	unless there is a mutual agreement to use another port.		unless there is a mutual agreement to use another port.
	In order to use a port other than TBD, both clients and servers would
	need a configuration option in their software.
	DoQ connections MUST NOT use UDP port 53. This recommendation		DoQ connections MUST NOT use UDP port 53. This recommendation
	against use of port 53 for DoQ is to avoid confusion between DoQ and		against use of port 53 for DoQ is to avoid confusion between DoQ and
	the use of DNS over UDP [RFC1035].		the use of DNS over UDP [RFC1035].
	In the stub to recursive scenario, the use of port 443 as a mutually		In the stub to recursive scenario, the use of port 443 as a mutually
	agreed alternative port can be operationally beneficial, since port		agreed alternative port can be operationally beneficial, since port
	443 is less likely to be blocked than other ports. Several		443 is less likely to be blocked than other ports. Several
	mechanisms for stubs to discover recursives offering encrypted		mechanisms for stubs to discover recursives offering encrypted
	transports, including the use of custom ports, are the subject of		transports, including the use of custom ports, are the subject of
	ongoing work.		ongoing work.
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 34 ¶
	in conformance with the QUIC transport specification [RFC9000].		in conformance with the QUIC transport specification [RFC9000].
	The client MUST send the DNS query over the selected stream, and MUST		The client MUST send the DNS query over the selected stream, and MUST
	indicate through the STREAM FIN mechanism that no further data will		indicate through the STREAM FIN mechanism that no further data will
	be sent on that stream.		be sent on that stream.
	The server MUST send the response(s) on the same stream and MUST		The server MUST send the response(s) on the same stream and MUST
	indicate, after the last response, through the STREAM FIN mechanism		indicate, after the last response, through the STREAM FIN mechanism
	that no further data will be sent on that stream.		that no further data will be sent on that stream.
	Therefore, a single client initiated DNS transaction consumes a		Therefore, a single client-initiated DNS transaction consumes a
	single stream. This means that the client's first query occurs on		single stream. This means that the client's first query occurs on
	QUIC stream 0, the second on 4, and so on.		QUIC stream 0, the second on 4, and so on.
	Servers MAY defer processing of a query until the STREAM FIN has been		Servers MAY defer processing of a query until the STREAM FIN has been
	indicated on the stream selected by the client. Servers and clients		indicated on the stream selected by the client. Servers and clients
	MAY monitor the number of "dangling" streams for which the expected		MAY monitor the number of "dangling" streams for which the expected
	queries or responses have been received but not the STREAM FIN.		queries or responses have been received but not the STREAM FIN.
	Implementations MAY impose a limit on the number of such dangling		Implementations MAY impose a limit on the number of such dangling
	streams. If limits are encountered, implementations MAY close the		streams. If limits are encountered, implementations MAY close the
	connection.		connection.
	skipping to change at page 9, line 50 ¶		skipping to change at page 9, line 50 ¶
	tests.		tests.
	See Section 10.4 for details on registering new error codes.		See Section 10.4 for details on registering new error codes.
	5.3.1. Transaction Cancellation		5.3.1. Transaction Cancellation
	In QUIC, sending STOP_SENDING requests that a peer cease transmission		In QUIC, sending STOP_SENDING requests that a peer cease transmission
	on a stream. If a DoQ client wishes to cancel an outstanding		on a stream. If a DoQ client wishes to cancel an outstanding
	request, it MUST issue a QUIC Stop Sending with error code		request, it MUST issue a QUIC Stop Sending with error code
	DOQ_REQUEST_CANCELLED. This may be sent at any time but will be		DOQ_REQUEST_CANCELLED. This may be sent at any time but will be
	ignored if the server has already sent the response. The		ignored if the server response has already been acknowledged. The
	corresponding DNS transaction MUST be abandoned.		corresponding DNS transaction MUST be abandoned.
	Servers that receive STOP_SENDING act in accordance with Section 3.5		Servers that receive STOP_SENDING act in accordance with Section 3.5
	of [RFC9000]. Servers MAY impose implementation limits on the total		of [RFC9000]. Servers MAY impose implementation limits on the total
	number or rate of request cancellations. If limits are encountered,		number or rate of request cancellations. If limits are encountered,
	servers MAY close the connection. In this case, servers wanting to		servers MAY close the connection. In this case, servers wanting to
	help client debugging MAY use the error code DOQ_EXCESSIVE_LOAD.		help client debugging MAY use the error code DOQ_EXCESSIVE_LOAD.
	There is always a trade-off between helping good faith clients debug		There is always a trade-off between helping good faith clients debug
	issues and allowing denial-of-service attackers to test server		issues and allowing denial-of-service attackers to test server
	defenses, so depending on circumstances servers might very well chose		defenses, so depending on circumstances servers might very well chose
	skipping to change at page 11, line 15 ¶		skipping to change at page 11, line 15 ¶
	expected (e.g. multiple responses to a query for an A record)		expected (e.g. multiple responses to a query for an A record)
	* a client receives a STOP_SENDING request		* a client receives a STOP_SENDING request
	* the client or server does not indicate the expected STREAM FIN		* the client or server does not indicate the expected STREAM FIN
	after sending requests or responses (see Section 5.2).		after sending requests or responses (see Section 5.2).
	* an implementation receives a message containing the edns-tcp-		* an implementation receives a message containing the edns-tcp-
	keepalive EDNS(0) Option [RFC7828] (see Section 6.5.2)		keepalive EDNS(0) Option [RFC7828] (see Section 6.5.2)
	* a client or a server attempts to open an unidirectional QUIC		* a client or a server attempts to open a unidirectional QUIC stream
	stream
	* a server attempts to open a server-initiated bidirectional QUIC		* a server attempts to open a server-initiated bidirectional QUIC
	stream		stream
	If a peer encounters such an error condition it is considered a fatal		If a peer encounters such an error condition it is considered a fatal
	error. It SHOULD forcibly abort the connection using QUIC's		error. It SHOULD forcibly abort the connection using QUIC's
	CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code		CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code
	DOQ_PROTOCOL_ERROR.		DOQ_PROTOCOL_ERROR.
	It is noted that the restrictions on use of the above EDNS(0) options		It is noted that the restrictions on use of the above EDNS(0) options
	skipping to change at page 12, line 4 ¶		skipping to change at page 11, line 50 ¶
	Implementations MAY wish to test the support for the error code		Implementations MAY wish to test the support for the error code
	extension mechanism by using error codes not listed in this document,		extension mechanism by using error codes not listed in this document,
	or they MAY use DOQ_ERROR_RESERVED.		or they MAY use DOQ_ERROR_RESERVED.
	5.4. Connection Management		5.4. Connection Management
	Section 10 of [RFC9000], the QUIC transport specification, specifies		Section 10 of [RFC9000], the QUIC transport specification, specifies
	that connections can be closed in three ways:		that connections can be closed in three ways:
	* idle timeout		* idle timeout
	* immediate close
			* immediate close
	* stateless reset		* stateless reset
	Clients and servers implementing DoQ SHOULD negotiate use of the idle		Clients and servers implementing DoQ SHOULD negotiate use of the idle
	timeout. Closing on idle timeout is done without any packet		timeout. Closing on idle timeout is done without any packet
	exchange, which minimizes protocol overhead. Per Section 10.1 of		exchange, which minimizes protocol overhead. Per Section 10.1 of
	[RFC9000], the QUIC transport specification, the effective value of		[RFC9000], the QUIC transport specification, the effective value of
	the idle timeout is computed as the minimum of the values advertised		the idle timeout is computed as the minimum of the values advertised
	by the two endpoints. Practical considerations on setting the idle		by the two endpoints. Practical considerations on setting the idle
	timeout are discussed in Section 6.5.2.		timeout are discussed in Section 6.5.2.
	skipping to change at page 14, line 45 ¶		skipping to change at page 14, line 45 ¶
	DoQ implementations that configure Address Validation using Retry		DoQ implementations that configure Address Validation using Retry
	Packets SHOULD implement the Address Validation for Future		Packets SHOULD implement the Address Validation for Future
	Connections procedure defined in Section 8.1.3 of [RFC9000], the QUIC		Connections procedure defined in Section 8.1.3 of [RFC9000], the QUIC
	transport specification. This defines how servers can send NEW_TOKEN		transport specification. This defines how servers can send NEW_TOKEN
	frames to clients after the client address is validated, in order to		frames to clients after the client address is validated, in order to
	avoid the 1-RTT penalty during subsequent connections by the client		avoid the 1-RTT penalty during subsequent connections by the client
	from the same address.		from the same address.
	6.4. Padding		6.4. Padding
	Implementations SHOULD protect against the traffic analysis attacks		Implementations MUST protect against the traffic analysis attacks
	described in Section 9.5 by the judicious injection of padding. This		described in Section 9.5 by the judicious injection of padding. This
	could be done either by padding individual DNS messages using the		could be done either by padding individual DNS messages using the
	EDNS(0) Padding Option [RFC7830] and by padding QUIC packets (see		EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see
	Section 8.6 of [RFC9000], the QUIC transport specification.		Section 8.6 of [RFC9000], the QUIC transport specification.
	In theory, padding at the QUIC level could result in better		In theory, padding at the QUIC level could result in better
	performance for the equivalent protection, because the amount of		performance for the equivalent protection, because the amount of
	padding can take into account non-DNS frames such as acknowledgeemnts		padding can take into account non-DNS frames such as acknowledgements
	or flow control updates, and also because QUIC packets can carry		or flow control updates, and also because QUIC packets can carry
	multiple DNS messages. However, applications can only control the		multiple DNS messages. However, applications can only control the
	amount of padding in QUIC packets if the implementation of QUIC		amount of padding in QUIC packets if the implementation of QUIC
	exposes adequate APIs. This leads to the following recommendation:		exposes adequate APIs. This leads to the following recommendation:
	* if the implementation of QUIC exposes APIs to set a padding		* if the implementation of QUIC exposes APIs to set a padding
	policy, DNS over QUIC SHOULD use that API to align the packet		policy, DNS over QUIC SHOULD use that API to align the packet
	length to a small set of fixed sizes, aligned with the		length to a small set of fixed sizes.
	recommendations of the "Padding Policies for Extension Mechanisms
	for DNS (EDNS(0))" [RFC8467].
	* if padding at the QUIC level is not available or not used, DNS		* if padding at the QUIC level is not available or not used, DNS
	over QUIC MUST ensure that all DNS queries and responses are		over QUIC MUST ensure that all DNS queries and responses are
	padded to a small set of fixed sizes, using the EDNS padding		padded to a small set of fixed sizes, using the EDNS(0) padding
	extension as specified in "Padding Policies for Extension		extension as specified in [RFC7830].
	Mechanisms for DNS (EDNS(0))" [RFC8467].
			Implementation might choose not to use a QUIC API for padding if it
			is significantly simpler to re-use existing DNS message padding logic
			which is applied to other encrypted transports.
			In the absence of a standard policy for padding sizes,
			implementations should consider following the recommendations of the
			Experimental status "Padding Policies for Extension Mechanisms for
			DNS (EDNS(0))" [RFC8467].
	6.5. Connection Handling		6.5. Connection Handling
	"DNS Transport over TCP - Implementation Requirements" [RFC7766]		"DNS Transport over TCP - Implementation Requirements" [RFC7766]
	provides updated guidance on DNS over TCP, some of which is		provides updated guidance on DNS over TCP, some of which is
	applicable to DoQ. This section provides similar advice on		applicable to DoQ. This section provides similar advice on
	connection handling for DoQ.		connection handling for DoQ.
	6.5.1. Connection Reuse		6.5.1. Connection Reuse
	Historic implementations of DNS clients are known to open and close		Historic implementations of DNS clients are known to open and close
	TCP connections for each DNS query. To amortise connection setup		TCP connections for each DNS query. To amortize connection setup
	costs, both clients and servers SHOULD support connection reuse by		costs, both clients and servers SHOULD support connection reuse by
	sending multiple queries and responses over a single persistent QUIC		sending multiple queries and responses over a single persistent QUIC
	connection.		connection.
	In order to achieve performance on par with UDP, DNS clients SHOULD		In order to achieve performance on par with UDP, DNS clients SHOULD
	send their queries concurrently over the QUIC streams on a QUIC		send their queries concurrently over the QUIC streams on a QUIC
	connection. That is, when a DNS client sends multiple queries to a		connection. That is, when a DNS client sends multiple queries to a
	server over a QUIC connection, it SHOULD NOT wait for an outstanding		server over a QUIC connection, it SHOULD NOT wait for an outstanding
	reply before sending the next query.		reply before sending the next query.
	skipping to change at page 17, line 24 ¶		skipping to change at page 17, line 28 ¶
	session resumption tickets. Servers SHOULD implement the anti-replay		session resumption tickets. Servers SHOULD implement the anti-replay
	mechanisms specified in Section 8 of [RFC8446].		mechanisms specified in Section 8 of [RFC8446].
	6.5.4. Controlling Connection Migration For Privacy		6.5.4. Controlling Connection Migration For Privacy
	DoQ implementation might consider using the connection migration		DoQ implementation might consider using the connection migration
	features defined in Section 9 of [RFC9000]. These features enable		features defined in Section 9 of [RFC9000]. These features enable
	connections to continue operating as the client's connectivity		connections to continue operating as the client's connectivity
	changes. As detailed in Section 9.4, these features trade off		changes. As detailed in Section 9.4, these features trade off
	privacy for latency. By default, clients SHOULD be configured to		privacy for latency. By default, clients SHOULD be configured to
	prioritise privacy and start new sessions if their connectivity		prioritize privacy and start new sessions if their connectivity
	changes.		changes.
	6.6. Processing Queries in Parallel		6.6. Processing Queries in Parallel
	As specified in Section 7 of [RFC7766] "DNS Transport over TCP -		As specified in Section 7 of [RFC7766] "DNS Transport over TCP -
	Implementation Requirements", resolvers are RECOMMENDED to support		Implementation Requirements", resolvers are RECOMMENDED to support
	the preparing of responses in parallel and sending them out of order.		the preparing of responses in parallel and sending them out of order.
	In DoQ, they do that by sending responses on their specific stream as		In DoQ, they do that by sending responses on their specific stream as
	soon as possible, without waiting for availability of responses for		soon as possible, without waiting for availability of responses for
	previously opened streams.		previously opened streams.
	skipping to change at page 19, line 42 ¶		skipping to change at page 19, line 42 ¶
	over-quic) is an open source DNS performance and functional		over-quic) is an open source DNS performance and functional
	testing utility written in C++ that has an experimental		testing utility written in C++ that has an experimental
	implementation of DoQ.		implementation of DoQ.
	4. aioquic (https://github.com/aiortc/aioquic) is an implementation		4. aioquic (https://github.com/aiortc/aioquic) is an implementation
	of QUIC in Python. It includes example client and server for		of QUIC in Python. It includes example client and server for
	DoQ.		DoQ.
	7.1. Performance Measurements		7.1. Performance Measurements
	To our knowledge, no benchmarking studies comparing DoT, DoH and DoQ		To the authors' knowledge, no benchmarking studies comparing DoT, DoH
	are published yet. However anecdotal evidence from the AdGuard DoQ		and DoQ are published yet. However, anecdotal evidence from the
	recursive resolver deployment (https://adguard.com/en/blog/dns-over-		AdGuard DoQ recursive resolver deployment
	quic.html) indicates that it performs well compared to the other		(https://adguard.com/en/blog/dns-over-quic.html) indicates that it
			performs similarly (and possibly better) compared to the other
	encrypted protocols, particularly in mobile environments. Reasons		encrypted protocols, particularly in mobile environments. Reasons
	given for this include that DoQ		given for this include that DoQ
	* Uses less bandwidth due to a more efficient handshake (and due to		* Uses less bandwidth due to a more efficient handshake (and due to
	less per message overhead when compared to DoH).		less per message overhead when compared to DoH).
	* Performs better in mobile environments due to the increased		* Performs better in mobile environments due to the increased
	resilience to packet loss		resilience to packet loss
	* Can maintain connections as users move between mobile networks via		* Can maintain connections as users move between mobile networks via
	skipping to change at page 21, line 16 ¶		skipping to change at page 21, line 16 ¶
	behavior of the recursive resolver discussed in "DNS Privacy		behavior of the recursive resolver discussed in "DNS Privacy
	Considerations" [RFC9076]. The attack is partially mitigated by		Considerations" [RFC9076]. The attack is partially mitigated by
	reducing the observability of this traffic. The mandatory replay		reducing the observability of this traffic. The mandatory replay
	protection mechanisms in TLS 1.3 [RFC8446] limit but do not eliminate		protection mechanisms in TLS 1.3 [RFC8446] limit but do not eliminate
	the risk of replay. 0-RTT packets can only be replayed within a		the risk of replay. 0-RTT packets can only be replayed within a
	narrow window, which is only wide enough to account for variations in		narrow window, which is only wide enough to account for variations in
	clock skew and network transmission.		clock skew and network transmission.
	The recommendation for TLS 1.3 [RFC8446] is that the capability to		The recommendation for TLS 1.3 [RFC8446] is that the capability to
	use 0-RTT data should be turned off by default, and only enabled if		use 0-RTT data should be turned off by default, and only enabled if
	the user clearly understands the associated risks. In our case,		the user clearly understands the associated risks. In the case of
	allowing 0-RTT data provides significant performance gains, and we		DoQ, allowing 0-RTT data provides significant performance gains, and
	are concerned that a recommendation to not use it would simply be		there is a concern that a recommendation to not use it would simply
	ignored. Instead, we provide a set of practical recommendations in		be ignored. Instead, a set of practical recommendations is provided
	Section 5.5 and Section 6.5.3.		in Section 5.5 and Section 6.5.3.
	The prevention on allowing replayable transactions in 0-RTT data		The prevention on allowing replayable transactions in 0-RTT data
	expressed in Section 5.5 blocks the most obvious risks of replay		expressed in Section 5.5 blocks the most obvious risks of replay
	attacks, as it only allows for transactions that will not change the		attacks, as it only allows for transactions that will not change the
	long term state of the server.		long-term state of the server.
	The attacks described above apply to the stub resolver to recursive		The attacks described above apply to the stub resolver to recursive
	resolver scenario, but similar attacks might be envisaged in the		resolver scenario, but similar attacks might be envisaged in the
	recursive resolver to authoritative resolver scenario, and the same		recursive resolver to authoritative resolver scenario, and the same
	mitigations apply.		mitigations apply.
	9.2. Privacy Issues With Session Resumption		9.2. Privacy Issues With Session Resumption
	The QUIC session resumption mechanism reduces the cost of re-		The QUIC session resumption mechanism reduces the cost of re-
	establishing sessions and enables 0-RTT data. There is a linkability		establishing sessions and enables 0-RTT data. There is a linkability
	skipping to change at page 22, line 25 ¶		skipping to change at page 22, line 25 ¶
	time such transfers are not particularly latency sensitive. This		time such transfers are not particularly latency sensitive. This
	means that applications supporting zone transfers may decide to apply		means that applications supporting zone transfers may decide to apply
	the same protections as stub to recursive applications.		the same protections as stub to recursive applications.
	9.3. Privacy Issues With Address Validation Tokens		9.3. Privacy Issues With Address Validation Tokens
	QUIC specifies address validation mechanisms in Section 8 of		QUIC specifies address validation mechanisms in Section 8 of
	[RFC9000]. Use of an address validation token allows QUIC servers to		[RFC9000]. Use of an address validation token allows QUIC servers to
	avoid an extra RTT for new connections. Address validation tokens		avoid an extra RTT for new connections. Address validation tokens
	are typically tied to an IP address. QUIC clients normally only use		are typically tied to an IP address. QUIC clients normally only use
	these tokens when setting a new connection from a previously used		these tokens when setting up a new connection from a previously used
	address. However, due to the prevalence of NAT, clients are not		address. However, clients are not always aware that they are using a
	always aware that they are using a new address. There is a		new address. This could be due to NAT, or because the client does
	linkability risk if clients mistakenly use address validation tokens		not have an API available to check if the IP address has changed
	after unknowingly moving to a new location.		(which can be quite often for IPv6). There is a linkability risk if
			clients mistakenly use address validation tokens after unknowingly
			moving to a new location.
	The recommendations in Section 6.5.3 mitigates this risk by tying the		The recommendations in Section 6.5.3 mitigates this risk by tying the
	usage of the NEW_TOKEN to that of session resumption.		usage of the NEW_TOKEN to that of session resumption.
	9.4. Privacy Issues With Long Duration Sessions		9.4. Privacy Issues With Long Duration Sessions
	A potential alternative to session resumption is the use of long		A potential alternative to session resumption is the use of long
	duration sessions: if a session remains open for a long time, new		duration sessions: if a session remains open for a long time, new
	queries can be sent without incurring connection establishment		queries can be sent without incurring connection establishment
	delays. It is worth pointing out that the two solutions have similar		delays. It is worth pointing out that the two solutions have similar
	skipping to change at page 23, line 40 ¶		skipping to change at page 23, line 40 ¶
	The "doq" string identifies DoQ:		The "doq" string identifies DoQ:
	Protocol: DoQ		Protocol: DoQ
	Identification Sequence: 0x64 0x6F 0x71 ("doq")		Identification Sequence: 0x64 0x6F 0x71 ("doq")
	Specification: This document		Specification: This document
	10.2. Reservation of Dedicated Port		10.2. Reservation of Dedicated Port
	Port 853 is currently reserved for 'DNS query-response protocol run		For both TCP and UDP port 853 is currently reserved for 'DNS query-
	over TLS/DTLS' [RFC7858]. However, the specification for DNS over		response protocol run over TLS/DTLS' [RFC7858].
	DTLS (DoD) [RFC8094] is experimental, limited to stub to resolver,
	and no implementations or deployments currently exist to our
	knowledge (even though several years have passed since the
	specification was published).
	This specification proposes to additionally reserve the use of port		However, the specification for DNS over DTLS (DoD) [RFC8094] is
	853 for DoQ. QUIC was designed to be able to co-exist with other		experimental, limited to stub to resolver, and no implementations or
	protocols on the same port, including DTLS , see Section 17.2 of		deployments currently exist to the authors' knowledge (even though
	[RFC9000].		several years have passed since the specification was published).
	IANA is requested to add the following value to the "Service Name and		This specification proposes to additionally reserve the use of UDP
	Transport Protocol Port Number Registry" in the System Range. The		port 853 for DoQ. QUIC version 1 was designed to be able to co-exist
	registry for that range requires IETF Review or IESG Approval		with other protocols on the same port, including DTLS , see
			Section 17.2 of [RFC9000]. This means that deployments that serve
			DNS over DTLS and DNS over QUIC (QUIC version 1) on the same port
			will be able to demultiplex the two due to the second most
			significant bit in each UDP payload. Such deployments ought to check
			the signatures of future versions or extensions (e.g.
			[I-D.ietf-quic-bit-grease]) of QUIC and DTLS before deploying them to
			serve DNS on the same port.
			IANA is requested to update the following value in the "Service Name
			and Transport Protocol Port Number Registry" in the System Range.
			The registry for that range requires IETF Review or IESG Approval
	[RFC6335].		[RFC6335].
	Service Name: dns-over-quic		IANA responded to the early allocation request with the following
			TEMPORARY assignment:
			Service Name: domain-s
	Port Number: 853		Port Number: 853
	Transport Protocol(s): UDP		Transport Protocol(s): UDP
	Assignee: IESG		Assignee: IETF DPRIVE Chairs
	Contact: IETF Chair		Contact: Brian Haberman
	Description: DNS query-response protocol run over QUIC		Description: DNS query-response protocol run over DTLS or QUIC
	Reference: This document		Reference: [RFC7858][RFC8094] This document
			The TEMPORARY assignment expires 13th December 2022.
			Additionally, IANA is requested to update the Description field for
			the corresponding TCP port 853 allocation to be 'DNS query-response
			protocol run over TLS' for consistency and clarity.
	10.2.1. Port number 784 for experimentations		10.2.1. Port number 784 for experimentations
	(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)		(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)
	Early experiments MAY use port 784. This port is marked in the IANA		Early experiments MAY use port 784. This port is marked in the IANA
	registry as unassigned.		registry as unassigned.
	(Note that version in -02 of this draft experiments were directed to		(Note that version in -02 of this draft experiments were directed to
	use port 8853.)		use port 8853.)
	skipping to change at page 25, line 13 ¶		skipping to change at page 25, line 28 ¶
	policies:		policies:
	* Permanent registrations for values between 0x00 and 0x3f (in		* Permanent registrations for values between 0x00 and 0x3f (in
	hexadecimal; inclusive), which are assigned using Standards Action		hexadecimal; inclusive), which are assigned using Standards Action
	or IESG Approval as defined in Section 4.9 and Section 4.10 of		or IESG Approval as defined in Section 4.9 and Section 4.10 of
	[RFC8126]		[RFC8126]
	* Permanent registrations for values larger than 0x3f, which are		* Permanent registrations for values larger than 0x3f, which are
	assigned using the Specification Required policy ([RFC8126])		assigned using the Specification Required policy ([RFC8126])
	* Provisonal registrations for values larger than 0x3f, which		* Provisional registrations for values larger than 0x3f, which
	require Expert Review, as defined in Section 4.5 of [RFC8126].		require Expert Review, as defined in Section 4.5 of [RFC8126].
	Provisional reservations share the range of values larger than 0x3f		Provisional reservations share the range of values larger than 0x3f
	with some permanent registrations. This is by design, to enable		with some permanent registrations. This is by design, to enable
	conversion of provisional registrations into permanent registrations		conversion of provisional registrations into permanent registrations
	without requiring changes in deployed systems. (This design is		without requiring changes in deployed systems. (This design is
	aligned with the principles set in Section 22 of [RFC9000].)		aligned with the principles set in Section 22 of [RFC9000].)
	Registrations in this registry MUST include the following fields:		Registrations in this registry MUST include the following fields:
	skipping to change at page 27, line 23 ¶		skipping to change at page 27, line 37 ¶
	<https://www.rfc-editor.org/info/rfc1034>.		<https://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.		November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,		[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
	DOI 10.17487/RFC1995, August 1996,		DOI 10.17487/RFC1995, August 1996,
	<https://www.rfc-editor.org/info/rfc1995>.		<https://www.rfc-editor.org/info/rfc1995>.
			[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/info/rfc2119>.
	[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol		[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
	(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,		(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
	<https://www.rfc-editor.org/info/rfc5936>.		<https://www.rfc-editor.org/info/rfc5936>.
	[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms		[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
	for DNS (EDNS(0))", STD 75, RFC 6891,		for DNS (EDNS(0))", STD 75, RFC 6891,
	DOI 10.17487/RFC6891, April 2013,		DOI 10.17487/RFC6891, April 2013,
	<https://www.rfc-editor.org/info/rfc6891>.		<https://www.rfc-editor.org/info/rfc6891>.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	skipping to change at page 28, line 14 ¶		skipping to change at page 28, line 33 ¶
	[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>.
	[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)		[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
	Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,		Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
	<https://www.rfc-editor.org/info/rfc7873>.		<https://www.rfc-editor.org/info/rfc7873>.
	[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
	Transport Layer Security (DTLS)", RFC 8094,
	DOI 10.17487/RFC8094, February 2017,
	<https://www.rfc-editor.org/info/rfc8094>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[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>.
	[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles		[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
	for DNS over TLS and DNS over DTLS", RFC 8310,		for DNS over TLS and DNS over DTLS", RFC 8310,
	DOI 10.17487/RFC8310, March 2018,		DOI 10.17487/RFC8310, March 2018,
	<https://www.rfc-editor.org/info/rfc8310>.		<https://www.rfc-editor.org/info/rfc8310>.
	[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
	for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
	October 2018, <https://www.rfc-editor.org/info/rfc8467>.
	[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.		[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
	Lawrence, "Extended DNS Errors", RFC 8914,		Lawrence, "Extended DNS Errors", RFC 8914,
	DOI 10.17487/RFC8914, October 2020,		DOI 10.17487/RFC8914, October 2020,
	<https://www.rfc-editor.org/info/rfc8914>.		<https://www.rfc-editor.org/info/rfc8914>.
	[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,		DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/info/rfc9000>.		<https://www.rfc-editor.org/info/rfc9000>.
	skipping to change at page 29, line 16 ¶		skipping to change at page 29, line 25 ¶
	Mankin, "DNS Zone Transfer over TLS", RFC 9103,		Mankin, "DNS Zone Transfer over TLS", RFC 9103,
	DOI 10.17487/RFC9103, August 2021,		DOI 10.17487/RFC9103, August 2021,
	<https://www.rfc-editor.org/info/rfc9103>.		<https://www.rfc-editor.org/info/rfc9103>.
	12.2. Informative References		12.2. Informative References
	[DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG		[DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG
	mailing list, 6 April 2016, <https://www.ietf.org/mail-		mailing list, 6 April 2016, <https://www.ietf.org/mail-
	archive/web/dns-privacy/current/msg01276.html>.		archive/web/dns-privacy/current/msg01276.html>.
			[I-D.ietf-quic-bit-grease]
			Thomson, M., "Greasing the QUIC Bit", Work in Progress,
			Internet-Draft, draft-ietf-quic-bit-grease-02, 10 November
			2021, <https://www.ietf.org/archive/id/draft-ietf-quic-
			bit-grease-02.txt>.
	[I-D.ietf-quic-http]		[I-D.ietf-quic-http]
	Bishop, M., "Hypertext Transfer Protocol Version 3		Bishop, M., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-		(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
	quic-http-34, 2 February 2021,		quic-http-34, 2 February 2021,
	<https://www.ietf.org/archive/id/draft-ietf-quic-http-		<https://www.ietf.org/archive/id/draft-ietf-quic-http-
	34.txt>.		34.txt>.
	[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone		[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
	Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,		Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
	August 1996, <https://www.rfc-editor.org/info/rfc1996>.		August 1996, <https://www.rfc-editor.org/info/rfc1996>.
	skipping to change at page 29, line 39 ¶		skipping to change at page 30, line 5 ¶
	Procedures for the Management of the Service Name and		Procedures for the Management of the Service Name and
	Transport Protocol Port Number Registry", BCP 165,		Transport Protocol Port Number Registry", BCP 165,
	RFC 6335, DOI 10.17487/RFC6335, August 2011,		RFC 6335, DOI 10.17487/RFC6335, August 2011,
	<https://www.rfc-editor.org/info/rfc6335>.		<https://www.rfc-editor.org/info/rfc6335>.
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		RFC 7942, DOI 10.17487/RFC7942, July 2016,
	<https://www.rfc-editor.org/info/rfc7942>.		<https://www.rfc-editor.org/info/rfc7942>.
			[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
			Transport Layer Security (DTLS)", RFC 8094,
			DOI 10.17487/RFC8094, February 2017,
			<https://www.rfc-editor.org/info/rfc8094>.
	[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/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
			[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
			for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
			October 2018, <https://www.rfc-editor.org/info/rfc8467>.
	[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>.
	[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,		[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
	Lemon, T., and T. Pusateri, "DNS Stateful Operations",		Lemon, T., and T. Pusateri, "DNS Stateful Operations",
	RFC 8490, DOI 10.17487/RFC8490, March 2019,		RFC 8490, DOI 10.17487/RFC8490, March 2019,
	<https://www.rfc-editor.org/info/rfc8490>.		<https://www.rfc-editor.org/info/rfc8490>.
	[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and		[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
	skipping to change at page 31, line 11 ¶		skipping to change at page 31, line 30 ¶
	Appendix B. Notable Changes From Previous Versions		Appendix B. Notable Changes From Previous Versions
	(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)		(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)
	B.1. Stream Mapping Incompatibility With Draft-02		B.1. Stream Mapping Incompatibility With Draft-02
	Versions prior to -02 of this specification proposed a simpler		Versions prior to -02 of this specification proposed a simpler
	mapping scheme of queries and responses to QUIc stream, which omitted		mapping scheme of queries and responses to QUIc stream, which omitted
	the 2 byte length field and supported only a single response on a		the 2 byte length field and supported only a single response on a
	given stream. The more complex mapping in Section 5.2 was adopted to		given stream. The more complex mapping in Section 5.2 was adopted to
	specifically cater for XFR support, however it breaks compatibility		specifically cater for XFR support, however, it breaks compatibility
	with earlier versions.		with earlier versions.
	Authors' Addresses		Authors' Addresses
	Christian Huitema		Christian Huitema
	Private Octopus Inc.		Private Octopus Inc.
	427 Golfcourse Rd		427 Golfcourse Rd
	Friday Harbor, WA 98250		Friday Harbor, WA 98250
	United States of America		United States of America
End of changes. 55 change blocks.
	86 lines changed or deleted		125 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/