< draft-ietf-dprive-dnsoquic-04.txt		draft-ietf-dprive-dnsoquic-05.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: 6 March 2022 Sinodun IT		Expires: 14 April 2022 Sinodun IT
	A. Mankin		A. Mankin
	Salesforce		Salesforce
	2 September 2021		11 October 2021
	Specification of DNS over Dedicated QUIC Connections		DNS over Dedicated QUIC Connections
	draft-ietf-dprive-dnsoquic-04		draft-ietf-dprive-dnsoquic-05
	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
	error corrections than UDP. DNS over QUIC (DoQ) has privacy		error corrections 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.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 6 March 2022.		This Internet-Draft will expire on 14 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	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 . . . . . . . . . . . . . . . . 6
	5.1.1. Draft Version Identification . . . . . . . . . . . . 6		5.1.1. Draft Version Identification . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . . . . 8		5.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 8
	5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 9		5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 9
	5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 9		5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 9
	5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 9		5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 10
	5.4. Connection Management . . . . . . . . . . . . . . . . . . 10		5.4. Connection Management . . . . . . . . . . . . . . . . . . 10
	5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 11		5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 11
	5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 12		5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 12
	6. Implementation Requirements . . . . . . . . . . . . . . . . . 12		6. Implementation Requirements . . . . . . . . . . . . . . . . . 12
	6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 12		6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 12
	6.2. Fall Back to Other Protocols on Connection Failure . . . 12		6.2. Fall Back to Other Protocols on Connection Failure . . . 13
	6.3. Address Validation . . . . . . . . . . . . . . . . . . . 13		6.3. Address Validation . . . . . . . . . . . . . . . . . . . 13
	6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 13		6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 14		6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 14
	6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 14		6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 14
	6.5.2. Resource Management and Idle Timeout Values . . . . . 14		6.5.2. Resource Management and Idle Timeout Values . . . . . 14
	6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 15		6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 15
	6.6. Processing Queries in Parallel . . . . . . . . . . . . . 15		6.6. Processing Queries in Parallel . . . . . . . . . . . . . 16
	6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 16		6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 16
	6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 16		6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 16
	7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17		7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
	7.1. Performance Measurements . . . . . . . . . . . . . . . . 18		7.1. Performance Measurements . . . . . . . . . . . . . . . . 18
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18		9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
	9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 19		9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 19
	9.2. Privacy Issues With Session Resumption . . . . . . . . . 20		9.2. Privacy Issues With Session Resumption . . . . . . . . . 20
	9.3. Privacy Issues With New Tokens . . . . . . . . . . . . . 20		9.3. Privacy Issues With New Tokens . . . . . . . . . . . . . 20
	9.4. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 21		9.4. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 21
	skipping to change at page 3, line 15 ¶		skipping to change at page 3, line 15 ¶
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	10.1. Registration of DoQ Identification String . . . . . . . 21		10.1. Registration of DoQ Identification String . . . . . . . 21
	10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 21		10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 21
	10.2.1. Port number 784 for experimentations . . . . . . . . 22		10.2.1. Port number 784 for experimentations . . . . . . . . 22
	10.3. Reservation of Extended DNS Error Code Too Early . . . . 22		10.3. Reservation of Extended DNS Error Code Too Early . . . . 22
	10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 22		10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 22
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	12.1. Normative References . . . . . . . . . . . . . . . . . . 24		12.1. Normative References . . . . . . . . . . . . . . . . . . 24
	12.2. Informative References . . . . . . . . . . . . . . . . . 26		12.2. Informative References . . . . . . . . . . . . . . . . . 26
	Appendix A. The NOTIFY service . . . . . . . . . . . . . . . . . 27		Appendix A. The NOTIFY service . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	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]. This document presents		implementation and specification" [RFC1035]. This document presents
	a mapping of the DNS protocol over the QUIC transport [RFC9000]		a mapping of the DNS protocol over the QUIC transport [RFC9000]
	[RFC9001]. DNS over QUIC is referred here as DoQ, in line with "DNS		[RFC9001]. DNS over QUIC is referred here as DoQ, in line with "DNS
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	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. 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" [RFC7626] 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.
	QUIC connection setup includes the negotiation of security parameters		QUIC connection setup includes the negotiation of security parameters
	using TLS, as specified in "Using TLS to Secure QUIC" [RFC9001],		using TLS, as specified in "Using TLS to Secure QUIC" [RFC9001],
	enabling encryption of the QUIC transport. Transmitting DNS messages		enabling encryption of the QUIC transport. Transmitting DNS messages
	over QUIC will provide essentially the same privacy protections as		over QUIC will provide essentially the same privacy protections as
	DoT [RFC7858] including Strict and Opportunistic Usage Profiles		DoT [RFC7858] including Strict and Opportunistic Usage Profiles
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 26 ¶
	TBD, both clients and servers would need a configuration option in		TBD, both clients and servers would need a configuration option in
	their software.		their software.
	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 it has mutual agreement with its server to use a port other		unless it has mutual agreement with its server to use a port other
	than port TBD for DoQ. Such another port MUST NOT be port 53. This		than port TBD for DoQ. Such another port MUST NOT be port 53. This
	recommendation against use of port 53 for DoQ is to avoid confusion		recommendation against use of port 53 for DoQ is to avoid confusion
	between DoQ and the use of DNS over UDP [RFC1035].		between DoQ and the use of DNS over UDP [RFC1035].
			In the stub to recursive scenario, the use of port 443 as a mutually
			agreed alternative port can be operationally beneficial, since port
			443 is less likely to be blocked than other ports. Several
			mechanisms for stubs to discover recursives offering encrypted
			transports, including the use of custom ports, are the subject of
			work in the ADD working group.
	5.2. Stream Mapping and Usage		5.2. Stream Mapping and Usage
	The mapping of DNS traffic over QUIC streams takes advantage of the		The mapping of DNS traffic over QUIC streams takes advantage of the
	QUIC stream features detailed in Section 2 of the QUIC transport		QUIC stream features detailed in Section 2 of the QUIC transport
	specification [RFC9000].		specification [RFC9000].
	DNS traffic follows a simple pattern in which the client sends a		DNS traffic follows a simple pattern in which the client sends a
	query, and the server provides one or more responses (multiple can		query, and the server provides one or more responses (multiple can
	responses occur in zone transfers).		responses occur in zone transfers).
	skipping to change at page 12, line 33 ¶		skipping to change at page 12, line 43 ¶
	specify the UDP message size. This parameter is ignored by DoQ. DoQ		specify the UDP message size. This parameter is ignored by DoQ. DoQ
	implementations always assume that the maximum message size is 65535		implementations always assume that the maximum message size is 65535
	bytes.		bytes.
	6. Implementation Requirements		6. Implementation Requirements
	6.1. Authentication		6.1. Authentication
	For the stub to recursive resolver scenario, the authentication		For the stub to recursive resolver scenario, the authentication
	requirements are the same as described in DoT [RFC7858] and "Usage		requirements are the same as described in DoT [RFC7858] and "Usage
	Profiles for DNS over TLS and DNS over DTLS" [RFC8310]. There is no		Profiles for DNS over TLS and DNS over DTLS" [RFC8310]. [RFC8932]
	need to authenticate the client's identity in either scenario.		states that DNS privacy services SHOULD provide credentials that
			clients can use to authenticate the server. Given this, and to align
			with the authentication model for DoH, DoQ stubs SHOULD use a Strict
			authentication profile. Client authentication for the encrypted stub
			to recursive scenario is not described in any DNS RFC.
	For zone transfer, the requirements are the same as described in		For zone transfer, the requirements are the same as described in
	[RFC9103].		[RFC9103].
	For the recursive resolver to authoritative nameserver scenario,		For the recursive resolver to authoritative nameserver scenario,
	authentication requirements are unspecified at the time of writing		authentication requirements are unspecified at the time of writing
	and are the subject on ongoing work in the DPRIVE WG.		and are the subject on ongoing work in the DPRIVE WG.
	6.2. Fall Back to Other Protocols on Connection Failure		6.2. Fall Back to Other Protocols on Connection Failure
	skipping to change at page 18, line 35 ¶		skipping to change at page 18, line 40 ¶
	its connection management		its connection management
	8. Security Considerations		8. Security Considerations
	The security considerations of DoQ should be comparable to those of		The security considerations of DoQ should be comparable to those of
	DoT [RFC7858].		DoT [RFC7858].
	9. Privacy Considerations		9. Privacy Considerations
	The general considerations of encrypted transports provided in "DNS		The general considerations of encrypted transports provided in "DNS
	Privacy Considerations" [I-D.ietf-dprive-rfc7626-bis] apply to DoQ.		Privacy Considerations" [RFC9076] apply to DoQ. The specific
	The specific considerations provided there do not differ between DoT		considerations provided there do not differ between DoT and DoQ, and
	and DoQ, and are not discussed further here.		are not discussed further here. Similarly, "Recommendations for DNS
			Privacy Service Operators" [RFC8932] (which covers operational,
			policy, and security considerations for DNS privacy services) is also
			applicable to DoQ services.
	QUIC incorporates the mechanisms of TLS 1.3 [RFC8446] and this		QUIC incorporates the mechanisms of TLS 1.3 [RFC8446] and this
	enables QUIC transmission of "0-RTT" data. This can provide		enables QUIC transmission of "0-RTT" data. This can provide
	interesting latency gains, but it raises two concerns:		interesting latency gains, but it raises two concerns:
	1. Adversaries could replay the 0-RTT data and infer its content		1. Adversaries could replay the 0-RTT data and infer its content
	from the behavior of the receiving server.		from the behavior of the receiving server.
	2. The 0-RTT mechanism relies on TLS session resumption, which can		2. The 0-RTT mechanism relies on TLS session resumption, which can
	provide linkability between successive client sessions.		provide linkability between successive client sessions.
	skipping to change at page 19, line 15 ¶		skipping to change at page 19, line 20 ¶
	9.1. Privacy Issues With 0-RTT data		9.1. Privacy Issues With 0-RTT data
	The 0-RTT data can be replayed by adversaries. That data may trigger		The 0-RTT data can be replayed by adversaries. That data may trigger
	queries by a recursive resolver to authoritative resolvers.		queries by a recursive resolver to authoritative resolvers.
	Adversaries may be able to pick a time at which the recursive		Adversaries may be able to pick a time at which the recursive
	resolver outgoing traffic is observable, and thus find out what name		resolver outgoing traffic is observable, and thus find out what name
	was queried for in the 0-RTT data.		was queried for in the 0-RTT data.
	This risk is in fact a subset of the general problem of observing the		This risk is in fact a subset of the general problem of observing the
	behavior of the recursive resolver discussed in "DNS Privacy		behavior of the recursive resolver discussed in "DNS Privacy
	Considerations" [RFC7626]. The attack is partially mitigated by		Considerations" [RFC9076]. The attack is partially mitigated by
	reducing the observability of this traffic. However, the risk is		reducing the observability of this traffic. However, the risk is
	amplified for 0-RTT data, because the attacker might replay it at		amplified for 0-RTT data, because the attacker might replay it at
	chosen times, several times.		chosen times, several times.
	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 our case,
	allowing 0-RTT data provides significant performance gains, and we		allowing 0-RTT data provides significant performance gains, and we
	are concerned that a recommendation to not use it would simply be		are concerned that a recommendation to not use it would simply be
	ignored. Instead, we provide a set of practical recommendations in		ignored. Instead, we provide a set of practical recommendations in
	skipping to change at page 19, line 38 ¶		skipping to change at page 19, line 43 ¶
	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.
	Attacks trying to assess the state of the cache are more powerful if		Attacks trying to assess the state of the cache are more powerful if
	the attacker can choose the time at which the 0-RTT data will be		the attacker can choose the time at which the 0-RTT data will be
	replayed. Such attacks are blocked if the server enforces single-use		replayed. Such attacks are blocked if the server enforces single-use
	tickets, or if the server implements a combination of Client Hello		tickets, or if the server implements a combination of Client Hello
	recording and freshness checks, as specified in section 8 of		recording and freshness checks, as specified in section 8 of
	[RFC8446]. These blocking mechanisms rely on shared state between		[RFC8446].
	all server instances in a server system. In the case of DNS over
	QUIC, the protection against replay attacks on the DNS cache is
	achieved if this state is shared between all servers that share the
	same DNS cache.
	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 24, line 46 ¶		skipping to change at page 24, line 46 ¶
	privacy issues. Reviews by Paul Hoffman and Martin Thomson and		privacy issues. Reviews by Paul Hoffman and Martin Thomson and
	interoperability tests conducted by Stephane Bortzmeyer helped		interoperability tests conducted by Stephane Bortzmeyer helped
	improve the definition of the protocol.		improve the definition of the protocol.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-dnsop-rfc8499bis]		[I-D.ietf-dnsop-rfc8499bis]
	Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in		Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in
	Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-02,		Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03,
	24 June 2021, <https://www.ietf.org/archive/id/draft-ietf-		28 September 2021, <https://www.ietf.org/archive/id/draft-
	dnsop-rfc8499bis-02.txt>.		ietf-dnsop-rfc8499bis-03.txt>.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<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,
	skipping to change at page 25, line 37 ¶		skipping to change at page 25, line 37 ¶
	[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and		[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
	D. Wessels, "DNS Transport over TCP - Implementation		D. Wessels, "DNS Transport over TCP - Implementation
	Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,		Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
	<https://www.rfc-editor.org/info/rfc7766>.		<https://www.rfc-editor.org/info/rfc7766>.
	[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The		[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
	edns-tcp-keepalive EDNS0 Option", RFC 7828,		edns-tcp-keepalive EDNS0 Option", RFC 7828,
	DOI 10.17487/RFC7828, April 2016,		DOI 10.17487/RFC7828, April 2016,
	<https://www.rfc-editor.org/info/rfc7828>.		<https://www.rfc-editor.org/info/rfc7828>.
			[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
			DOI 10.17487/RFC7830, May 2016,
			<https://www.rfc-editor.org/info/rfc7830>.
	[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		[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
	skipping to change at page 26, line 19 ¶		skipping to change at page 26, line 24 ¶
	[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>.
	[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>.
	[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
	skipping to change at page 26, line 48 ¶		skipping to change at page 27, line 9 ¶
	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-dprive-rfc7626-bis]
	Wicinski, T., "DNS Privacy Considerations", Work in
	Progress, Internet-Draft, draft-ietf-dprive-rfc7626-bis-
	09, 9 March 2021, <https://www.ietf.org/archive/id/draft-
	ietf-dprive-rfc7626-bis-09.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>.
	[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.		[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
	Cheshire, "Internet Assigned Numbers Authority (IANA)		Cheshire, "Internet Assigned Numbers Authority (IANA)
	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>.
	[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
	DOI 10.17487/RFC7626, August 2015,
	<https://www.rfc-editor.org/info/rfc7626>.
	[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
	DOI 10.17487/RFC7830, May 2016,
	<https://www.rfc-editor.org/info/rfc7830>.
	[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>.
	[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>.
	[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
			A. Mankin, "Recommendations for DNS Privacy Service
			Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
			October 2020, <https://www.rfc-editor.org/info/rfc8932>.
	[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection		[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
	and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,		and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
	May 2021, <https://www.rfc-editor.org/info/rfc9002>.		May 2021, <https://www.rfc-editor.org/info/rfc9002>.
			[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
			DOI 10.17487/RFC9076, July 2021,
			<https://www.rfc-editor.org/info/rfc9076>.
	Appendix A. The NOTIFY service		Appendix A. The NOTIFY service
	This appendix discusses the issue of allowing NOTIFY to be sent in		This appendix discusses the issue of allowing NOTIFY to be sent in
	0-RTT data.		0-RTT data.
	Section Section 5.5 says "The 0-RTT mechanism SHOULD NOT be used to		Section Section 5.5 says "The 0-RTT mechanism SHOULD NOT be used to
	send DNS requests that are not "replayable" transactions", and		send DNS requests that are not "replayable" transactions", and
	suggests this is limited to OPCODE QUERY. It might also be viable to		suggests this is limited to OPCODE QUERY. It might also be viable to
	propose that NOTIFY should be permitted in 0-RTT data because		propose that NOTIFY should be permitted in 0-RTT data because
	although it technically changes the state of the receiving server,		although it technically changes the state of the receiving server,
	skipping to change at page 28, line 32 ¶		skipping to change at page 28, line 37 ¶
	scope of encrypting zone transfers. Given this, the privacy benefit		scope of encrypting zone transfers. Given this, the privacy benefit
	of using DoQ for NOTIFY is not clear - but for the same reason,		of using DoQ for NOTIFY is not clear - but for the same reason,
	sending NOTIFY as 0-RTT data has no privacy risk above that of		sending NOTIFY as 0-RTT data has no privacy risk above that of
	sending it using cleartext DNS.		sending it using cleartext DNS.
	Authors' Addresses		Authors' Addresses
	Christian Huitema		Christian Huitema
	Private Octopus Inc.		Private Octopus Inc.
	427 Golfcourse Rd		427 Golfcourse Rd
	Friday Harbor		Friday Harbor, WA 98250
			United States of America
	Email: huitema@huitema.net		Email: huitema@huitema.net
	Sara Dickinson		Sara Dickinson
	Sinodun IT		Sinodun IT
	Oxford Science Park		Oxford Science Park
	Oxford		Oxford
			OX4 4GA
			United Kingdom
	Email: sara@sinodun.com		Email: sara@sinodun.com
	Allison Mankin		Allison Mankin
	Salesforce		Salesforce
	Email: allison.mankin@gmail.com		Email: allison.mankin@gmail.com
End of changes. 25 change blocks.
	44 lines changed or deleted		55 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/