rfc9103v3.txt		rfc9103.txt
	skipping to change at line 73 ¶		skipping to change at line 73 ¶
	4. Design Considerations for XoT		4. Design Considerations for XoT
	5. Connection and Data Flows in Existing XFR Mechanisms		5. Connection and Data Flows in Existing XFR Mechanisms
	5.1. AXFR Mechanism		5.1. AXFR Mechanism
	5.2. IXFR Mechanism		5.2. IXFR Mechanism
	5.3. Data Leakage of NOTIFY and SOA Message Exchanges		5.3. Data Leakage of NOTIFY and SOA Message Exchanges
	5.3.1. NOTIFY		5.3.1. NOTIFY
	5.3.2. SOA		5.3.2. SOA
	6. Updates to Existing Specifications		6. Updates to Existing Specifications
	6.1. Update to RFC 1995 for IXFR over TCP		6.1. Update to RFC 1995 for IXFR over TCP
	6.2. Update to RFC 5936 for AXFR over TCP		6.2. Update to RFC 5936 for AXFR over TCP
	6.3. Updates to RFC 1995 and RFC 5936 for XFR over TCP		6.3. Updates to RFCs 1995 and 5936 for XFR over TCP
	6.3.1. Connection Reuse		6.3.1. Connection Reuse
	6.3.2. AXFRs and IXFRs on the Same Connection		6.3.2. AXFRs and IXFRs on the Same Connection
	6.3.3. XFR Limits		6.3.3. XFR Limits
	6.3.4. The edns-tcp-keepalive EDNS(0) Option		6.3.4. The edns-tcp-keepalive EDNS(0) Option
	6.3.5. Backwards Compatibility		6.3.5. Backwards Compatibility
	6.4. Update to RFC 7766		6.4. Update to RFC 7766
	7. XoT Specification		7. XoT Specification
	7.1. Connection Establishment		7.1. Connection Establishment
	7.2. TLS Versions		7.2. TLS Versions
	7.3. Port Selection		7.3. Port Selection
	skipping to change at line 595 ¶		skipping to change at line 595 ¶
	6.2. Update to RFC 5936 for AXFR over TCP		6.2. Update to RFC 5936 for AXFR over TCP
	For clarity, an AXFR-over-TCP server compliant with this		For clarity, an AXFR-over-TCP server compliant with this
	specification MUST be able to handle multiple concurrent AXoT		specification MUST be able to handle multiple concurrent AXoT
	sessions on a single TCP connection (for the same and different		sessions on a single TCP connection (for the same and different
	zones). The response streams for concurrent AXFRs MAY be		zones). The response streams for concurrent AXFRs MAY be
	intermingled, and AXFR-over-TCP clients compliant with this		intermingled, and AXFR-over-TCP clients compliant with this
	specification, which pipeline AXFR requests, MUST be able to handle		specification, which pipeline AXFR requests, MUST be able to handle
	this.		this.
	6.3. Updates to RFC 1995 and RFC 5936 for XFR over TCP		6.3. Updates to RFCs 1995 and 5936 for XFR over TCP
	6.3.1. Connection Reuse		6.3.1. Connection Reuse
	As specified, XFR-over-TCP clients SHOULD reuse any existing open TCP		As specified, XFR-over-TCP clients SHOULD reuse any existing open TCP
	connection when starting any new XFR request to the same primary, and		connection when starting any new XFR request to the same primary, and
	for issuing SOA queries, instead of opening a new connection. The		for issuing SOA queries, instead of opening a new connection. The
	number of TCP connections between a secondary and primary SHOULD be		number of TCP connections between a secondary and primary SHOULD be
	minimized (also see Section 6.4).		minimized (also see Section 6.4).
	Valid reasons for not reusing existing connections might include:		Valid reasons for not reusing existing connections might include:
	skipping to change at line 902 ¶		skipping to change at line 902 ¶
	opportunistic encryption has also been raised as a possibility;		opportunistic encryption has also been raised as a possibility;
	therefore, it is highly likely that use of encryption by		therefore, it is highly likely that use of encryption by
	authoritative servers will evolve in the coming years.		authoritative servers will evolve in the coming years.
	This raises questions in the short term with regard to TLS connection		This raises questions in the short term with regard to TLS connection
	and message handling for authoritative servers. In particular, there		and message handling for authoritative servers. In particular, there
	is likely to be a class of authoritative servers that wish to use XoT		is likely to be a class of authoritative servers that wish to use XoT
	in the near future with a small number of configured secondaries but		in the near future with a small number of configured secondaries but
	that do not wish to support DoT for regular queries from recursives		that do not wish to support DoT for regular queries from recursives
	in that same time frame. These servers have to potentially cope with		in that same time frame. These servers have to potentially cope with
	probing and direct queries from recursives and test servers and also		probing and direct queries from recursives and from test servers and
	potential attacks that might wish to make use of TLS to overload the		also potential attacks that might wish to make use of TLS to overload
	server.		the server.
	[RFC5936] clearly states that non-AXFR session traffic can use an		[RFC5936] clearly states that non-AXFR session traffic can use an
	open connection; however, this requirement needs to be reevaluated		open connection; however, this requirement needs to be reevaluated
	when considering the application of the same model to XoT. Proposing		when considering the application of the same model to XoT. Proposing
	that a server should also start responding to all queries received		that a server should also start responding to all queries received
	over TLS just because it has enabled XoT would be equivalent to		over TLS just because it has enabled XoT would be equivalent to
	defining a form of authoritative DoT. This specification does not		defining a form of authoritative DoT. This specification does not
	propose that, but it also does not prohibit servers from answering		propose that, but it also does not prohibit servers from answering
	queries unrelated to XFR exchanges over TLS. Rather, this		queries unrelated to XFR exchanges over TLS. Rather, this
	specification simply outlines in later sections:		specification simply outlines in later sections:
	skipping to change at line 1107 ¶		skipping to change at line 1107 ¶
	provides a brief summary of some of the existing authentication and		provides a brief summary of some of the existing authentication and
	validation mechanisms (both transport independent and TLS specific)		validation mechanisms (both transport independent and TLS specific)
	that are available when performing zone transfers. Section 10 then		that are available when performing zone transfers. Section 10 then
	discusses in more detail specifically how a combination of TLS		discusses in more detail specifically how a combination of TLS
	authentication, TSIG, and IP-based ACLs interact for XoT.		authentication, TSIG, and IP-based ACLs interact for XoT.
	In this document, the mechanisms are classified based on the		In this document, the mechanisms are classified based on the
	following properties:		following properties:
	Data Origin Authentication (DO):		Data Origin Authentication (DO):
	Authentication that the DNS message originated from the party with		Authentication 1) of the fact that the DNS message originated from
	whom credentials were shared and of the data integrity of the		the party with whom credentials were shared and 2) of the data
	message contents (the originating party may or may not be the		integrity of the message contents (the originating party may or
	party operating the far end of a TCP/TLS connection in a 'proxy'		may not be the party operating the far end of a TCP/TLS connection
	scenario).		in a 'proxy' scenario).
	Channel Confidentiality (CC):		Channel Confidentiality (CC):
	Confidentiality of the communication channel between the client		Confidentiality of the communication channel between the client
	and server (i.e., the two endpoints of a TCP/TLS connection) from		and server (i.e., the two endpoints of a TCP/TLS connection) from
	passive surveillance.		passive surveillance.
	Channel Authentication (CA):		Channel Authentication (CA):
	Authentication of the identity of the party to whom a TCP/TLS		Authentication of the identity of the party to whom a TCP/TLS
	connection is made (this might not be a direct connection between		connection is made (this might not be a direct connection between
	the primary and secondary in a proxy scenario).		the primary and secondary in a proxy scenario).
	skipping to change at line 1511 ¶		skipping to change at line 1511 ¶
	Hardaker, "Message Digest for DNS Zones", RFC 8976,		Hardaker, "Message Digest for DNS Zones", RFC 8976,
	DOI 10.17487/RFC8976, February 2021,		DOI 10.17487/RFC8976, February 2021,
	<https://www.rfc-editor.org/info/rfc8976>.		<https://www.rfc-editor.org/info/rfc8976>.
	[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,		[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
	DOI 10.17487/RFC9076, July 2021,		DOI 10.17487/RFC9076, July 2021,
	<https://www.rfc-editor.org/info/rfc9076>.		<https://www.rfc-editor.org/info/rfc9076>.
	[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS		[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
	Encrypted Client Hello", Work in Progress, Internet-Draft,		Encrypted Client Hello", Work in Progress, Internet-Draft,
	draft-ietf-tls-esni-12, 7 July 2021,		draft-ietf-tls-esni-13, 12 August 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-tls-		<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
	esni-12>.		esni-13>.
	Appendix A. XoT Server Connection Handling		Appendix A. XoT Server Connection Handling
	This appendix provides a non-normative outline of the pros and cons		This appendix provides a non-normative outline of the pros and cons
	of XoT server connection-handling options.		of XoT server connection-handling options.
	For completeness, it is noted that an earlier draft version of this		For completeness, it is noted that an earlier draft version of this
	document suggested using a XoT-specific ALPN to negotiate TLS		document suggested using a XoT-specific ALPN to negotiate TLS
	connections that supported only a limited set of queries (SOA, XFRs);		connections that supported only a limited set of queries (SOA, XFRs);
	however, this did not gain support. Reasons given included		however, this did not gain support. Reasons given included
End of changes. 6 change blocks.
	12 lines changed or deleted		12 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/