draft-ietf-dprive-xfr-over-tls-00.txt		draft-ietf-dprive-xfr-over-tls-01.txt
	dprive H. Zhang		dprive H. Zhang
	Internet-Draft P. Aras		Internet-Draft P. Aras
	Updates: 1995 (if approved) Salesforce		Updates: 1995 (if approved) Salesforce
	Intended status: Standards Track W. Toorop		Intended status: Standards Track W. Toorop
	Expires: May 21, 2020 NLnet Labs		Expires: November 21, 2020 NLnet Labs
	S. Dickinson		S. Dickinson
	Sinodun IT		Sinodun IT
	A. Mankin		A. Mankin
	Salesforce		Salesforce
	November 18, 2019		May 20, 2020
	DNS Zone Transfer-over-TLS		DNS Zone Transfer-over-TLS
	draft-ietf-dprive-xfr-over-tls-00		draft-ietf-dprive-xfr-over-tls-01
	Abstract		Abstract
	DNS zone transfers are transmitted in clear text, which gives		DNS zone transfers are transmitted in clear text, which gives
	attackers the opportunity to collect the content of a zone by		attackers the opportunity to collect the content of a zone by
	eavesdropping on network connections. The DNS Transaction Signature		eavesdropping on network connections. The DNS Transaction Signature
	(TSIG) mechanism is specified to restrict direct zone transfer to		(TSIG) mechanism is specified to restrict direct zone transfer to
	authorized clients only, but it does not add confidentiality. This		authorized clients only, but it does not add confidentiality. This
	document specifies use of DNS-over-TLS to prevent zone contents		document specifies use of DNS-over-TLS to prevent zone contents
	collection via passive monitoring of zone transfers.		collection via passive monitoring of zone transfers.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 May 21, 2020.		This Internet-Draft will expire on November 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 4		3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 4
	4. Connection and Data Flows in Existing XFR Mechanisms . . . . 5		4. Connection and Data Flows in Existing XFR Mechanisms . . . . 5
	4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 5		4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 5
	4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 6		4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 7		4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 7
	4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 7		4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Connection and Data Flows in XoT . . . . . . . . . . . . . . 8		5. Connection and Data Flows in XoT . . . . . . . . . . . . . . 8
	5.1. Performance Considerations . . . . . . . . . . . . . . . 8		5.1. Performance Considerations . . . . . . . . . . . . . . . 8
	5.2. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 8		5.2. TLS versions . . . . . . . . . . . . . . . . . . . . . . 8
	5.3. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 9		5.3. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 8
	5.3.1. Fallback to AXFR . . . . . . . . . . . . . . . . . . 10		5.4. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 9
			5.4.1. Fallback to AXFR . . . . . . . . . . . . . . . . . . 10
	6. Zone Transfer with DoT - Authentication . . . . . . . . . . . 10		6. Zone Transfer with DoT - Authentication . . . . . . . . . . . 10
	6.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 10		6.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 11
	6.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 10		6.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 11
	6.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 10		6.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 11
	6.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 11		6.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 11
	6.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 11		6.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.6. Comparison of Authentication Methods . . . . . . . . . . 11		6.6. Comparison of Authentication Methods . . . . . . . . . . 12
	7. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 12		7. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 13
	8. Multi-primary Configurations . . . . . . . . . . . . . . . . 13		8. Multi-primary Configurations . . . . . . . . . . . . . . . . 14
	9. Implementation Considerations . . . . . . . . . . . . . . . . 14		9. Implementation Considerations . . . . . . . . . . . . . . . . 14
	10. Implementation Status . . . . . . . . . . . . . . . . . . . . 14		10. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 14		12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
	14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15		14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	15.1. Normative References . . . . . . . . . . . . . . . . . . 15		15.1. Normative References . . . . . . . . . . . . . . . . . . 16
	15.2. Informative References . . . . . . . . . . . . . . . . . 17		15.2. Informative References . . . . . . . . . . . . . . . . . 17
	15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17		15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	DNS has a number of privacy vulnerabilities, as discussed in detail		DNS has a number of privacy vulnerabilities, as discussed in detail
	in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver		in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver
	query privacy has received the most attention to date. There are now		query privacy has received the most attention to date. There are now
	standards track documents for three encryption capabilities for stub		standards track documents for three encryption capabilities for stub
	to recursive queries and more work going on to guide deployment of		to recursive queries and more work going on to guide deployment of
	specifically DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH)		specifically DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH)
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 31 ¶
	Privacy terminology is as described in Section 3 of [RFC6973].		Privacy terminology is as described in Section 3 of [RFC6973].
	Note that in this document we choose to use the terms 'primary' and		Note that in this document we choose to use the terms 'primary' and
	'secondary' for two servers engaged in zone transfers.		'secondary' for two servers engaged in zone transfers.
	DNS terminology is as described in [RFC8499].		DNS terminology is as described in [RFC8499].
	DoT: DNS-over-TLS as specified in [RFC7858]		DoT: DNS-over-TLS as specified in [RFC7858]
	DoH: DNS-over-HTTPS as specified in [RFC8484]
	XoT: Generic XFR-over-TLS mechanisms as specified in this document		XoT: Generic XFR-over-TLS mechanisms as specified in this document
	AXoT: AXFR-over-TLS		AXoT: AXFR-over-TLS
	IXoT: IXFR over-TLS		IXoT: IXFR over-TLS
	3. Use Cases for XFR-over-TLS		3. Use Cases for XFR-over-TLS
	o Confidentiality. Clearly using an encrypted transport for zone		o Confidentiality. Clearly using an encrypted transport for zone
	transfers will defeat zone content leakage that can occur via		transfers will defeat zone content leakage that can occur via
	skipping to change at page 4, line 52 ¶		skipping to change at page 5, line 4 ¶
	o Authentication. Use of single or mutual TLS authentication (in		o Authentication. Use of single or mutual TLS authentication (in
	combination with ACLs) can complement and potentially be an		combination with ACLs) can complement and potentially be an
	alternative to TSIG.		alternative to TSIG.
	o Performance. Existing AXFR and IXFR mechanisms have the burden of		o Performance. Existing AXFR and IXFR mechanisms have the burden of
	backwards compatibility with older implementations based on the		backwards compatibility with older implementations based on the
	original specifications in [RFC1034] and [RFC1035]. For example,		original specifications in [RFC1034] and [RFC1035]. For example,
	some older AXFR servers don't support using a TCP connection for		some older AXFR servers don't support using a TCP connection for
	multiple AXFR sessions or XFRs of different zones because they		multiple AXFR sessions or XFRs of different zones because they
	have not been updated to follow the guidance in [RFC5836]. Any		have not been updated to follow the guidance in [RFC5936]. Any
	implementation of XFR-over-TLS would obviously be required to		implementation of XFR-over-TLS would obviously be required to
	implement optimized and interoperable transfers as described in		implement optimized and interoperable transfers as described in
	[RFC5936] e.g. transfer of multiple zones-over-one connection.		[RFC5936] e.g. transfer of multiple zones over one connection.
	o Performance. Current usage of TCP for IXFR is sub-optimal in some		o Performance. Current usage of TCP for IXFR is sub-optimal in some
	cases i.e. connections are frequently closed after a single IXFR.		cases i.e. connections are frequently closed after a single IXFR.
	4. Connection and Data Flows in Existing XFR Mechanisms		4. Connection and Data Flows in Existing XFR Mechanisms
	The original specification for zone transfers in [RFC1034] and		The original specification for zone transfers in [RFC1034] and
	[RFC1035] was based on a polling mechanism: a secondary performed a		[RFC1035] was based on a polling mechanism: a secondary performed a
	periodic SOA query (based on the refresh timer) to determine if an		periodic SOA query (based on the refresh timer) to determine if an
	AXFR was required.		AXFR was required.
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 45 ¶
	connections and SHOULD use [RFC7858] to manage persistent		connections and SHOULD use [RFC7858] to manage persistent
	connections.		connections.
	4.3. Data Leakage of NOTIFY and SOA Message Exchanges		4.3. Data Leakage of NOTIFY and SOA Message Exchanges
	This section attempts to presents a rationale for also encrypting the		This section attempts to presents a rationale for also encrypting the
	other messages in the XFR mechanism.		other messages in the XFR mechanism.
	Since the SOA of the published zone can be trivially discovered by		Since the SOA of the published zone can be trivially discovered by
	simply querying the publicly available authoritative servers leakage		simply querying the publicly available authoritative servers leakage
	RR of this is not discussed in the following sections.		of this RR is not discussed in the following sections.
	4.3.1. NOTIFY		4.3.1. NOTIFY
	Unencrypted NOTIFY messages identify configured secondaries on the		Unencrypted NOTIFY messages identify configured secondaries on the
	primary.		primary.
	[RFC1996] also states:		[RFC1996] also states:
	"If ANCOUNT>0, then the answer section represents an unsecure hint at		"If ANCOUNT>0, then the answer section represents an unsecure hint at
	the new RRset for this .		the new RRset for this .
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 27 ¶
	5.1. Performance Considerations		5.1. Performance Considerations
	The details in [RFC7766], [RFC7858] and [RFC8310] about e.g. using		The details in [RFC7766], [RFC7858] and [RFC8310] about e.g. using
	persistent connections and TLS Session Resumption [RFC5077] are fully		persistent connections and TLS Session Resumption [RFC5077] are fully
	applicable to XFR-over-TLS as well.		applicable to XFR-over-TLS as well.
	It is RECOMMENDED that clients and servers that support XoT also		It is RECOMMENDED that clients and servers that support XoT also
	implement EDNS0 Keepalive [RFC7828].		implement EDNS0 Keepalive [RFC7828].
	5.2. AXoT mechanism		It is useful to note that in these mechanisms it is the secondary
			that initiates the TLS connection to the primary for a XFR request,
			so that in terms of connectivity the secondary is the TLS client and
			the primary the TLS server.
			5.2. TLS versions
			For improved security all implementations of this specification MUST
			use only TLS 1.3 [RFC8446] or later.
			5.3. AXoT mechanism
	The figure below provides an outline of the AXoT mechanism including		The figure below provides an outline of the AXoT mechanism including
	NOTIFYs.		NOTIFYs.
	Figure 3: AXoT mechanism [5]		Figure 3: AXoT mechanism [5]
			The connection for AXFR-over-TLS SHOULD be established using port
			853, as specified in [RFC7858], unless there is mutual agreement
			between the secondary and primary to use a port other than port 853
			for XFR-over-TLS.
	All implementations that support XoT MUST fully implement [RFC5953]		All implementations that support XoT MUST fully implement [RFC5953]
	behavior on TLS connections.		behavior on TLS connections.
	Sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] describe guidance for AXFR		Sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] describe guidance for AXFR
	clients and servers with regard to re-use of sessions for multiple		clients and servers with regard to re-use of sessions for multiple
	AXFRs, AXFRs of different zones and using TCP session for other		AXFRs, AXFRs of different zones and using TCP session for other
	queries including SOA.		queries including SOA.
	For clarity we restate here that an AXoT client MAY use an already		For clarity we restate here that an AXoT client MAY use an already
	opened TLS connection to send a AXFR request. Using an existing open		opened TLS connection to send a AXFR request. Using an existing open
	connection is RECOMMENDED over opening a new connection. (Non-AXoT		connection is RECOMMENDED over opening a new connection. (Non-AXoT
	session traffic can also use an open connection.)		session traffic can also use an open connection.)
	For clarity we additionally state here that an AXoT client MAY use an		For clarity we additionally state here that an AXoT client MAY use an
	already opened TLS connection to send a SOA request. Using an		already opened TLS connection to send a SOA request. Using an
	existing open connection is RECOMMENDED over opening a new		existing open connection is RECOMMENDED over opening a new
	connection.		connection.
	The connection for AXFR-over-TLS SHOULD be established using port
	853, as specified in [RFC7858], unless there is mutual agreement
	between the secondary and primary to use a port other than port 853
	for XFR-over-TLS.
	QUESTION: Should there be a requirement that the SOA is always done		QUESTION: Should there be a requirement that the SOA is always done
	on a TLS connection if the XFR is? For the case when no transfer is		on a TLS connection if the XFR is? For the case when no transfer is
	required this could be unnecessary overhead.		required this could be unnecessary overhead.
	5.3. IXoT mechanism		5.4. IXoT mechanism
	The figure below provides an outline of the IXoT mechanism including		The figure below provides an outline of the IXoT mechanism including
	NOTIFYs.		NOTIFYs.
	Figure 4: IXoT mechanism [6]		Figure 4: IXoT mechanism [6]
	The connection for IXFR-over-TLS SHOULD be established using port		The connection for IXFR-over-TLS SHOULD be established using port
	853, as specified in [RFC7858], unless there is mutual agreement		853, as specified in [RFC7858], unless there is mutual agreement
	between the secondary and primary to use a port other than port 853		between the secondary and primary to use a port other than port 853
	for XFR-over-TLS.		for XFR-over-TLS.
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 23 ¶
	request an appropriate timeout from the server (if the server		request an appropriate timeout from the server (if the server
	supports EDNS0 Keepalive). If the server does not support EDNS0		supports EDNS0 Keepalive). If the server does not support EDNS0
	Keepalive the client MAY keep the connection open for a few seconds		Keepalive the client MAY keep the connection open for a few seconds
	([RFC7766] recommends that servers use timeouts of at least a few		([RFC7766] recommends that servers use timeouts of at least a few
	seconds).		seconds).
	An IXoT client MAY pipeline IXFR requests for different zones on a		An IXoT client MAY pipeline IXFR requests for different zones on a
	single TLS connection. AN IXoT server MAY respond to those requests		single TLS connection. AN IXoT server MAY respond to those requests
	out of order.		out of order.
	5.3.1. Fallback to AXFR		QUESTION: Since this is a new specification should there be a
			requirement that IXoT servers are RECOMMENDED to condense responses
			as described in Section 6 of [RFC1995]. [RFC1995] document says this
			is optional and MAY be done but it can significantly reduce the size
			of responses and may have implications for padding?
			5.4.1. Fallback to AXFR
	Fallback to AXFR can happen, for example, if the server is not able		Fallback to AXFR can happen, for example, if the server is not able
	to provide an IXFR for the requested SOA. Implementations differ in		to provide an IXFR for the requested SOA. Implementations differ in
	how long they store zone deltas and how many may be stored at any one		how long they store zone deltas and how many may be stored at any one
	time.		time.
	After a failed IXFR a IXoT client SHOULD request the AXFR on the		After a failed IXFR a IXoT client SHOULD request the AXFR on the
	already open TLS connection.		already open TLS connection.
	6. Zone Transfer with DoT - Authentication		6. Zone Transfer with DoT - Authentication
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 43 ¶
	authentication and end-to-end channel confidentiality.		authentication and end-to-end channel confidentiality.
	6.4. IP Based ACL on the Primary		6.4. IP Based ACL on the Primary
	Most DNS server implementations offer an option to configure an IP		Most DNS server implementations offer an option to configure an IP
	based Access Control List (ACL), which is often used in combination		based Access Control List (ACL), which is often used in combination
	with TSIG based ACLs to restrict access to zone transfers on primary		with TSIG based ACLs to restrict access to zone transfers on primary
	servers.		servers.
	This is also possible with XoT but it must be noted that as with TCP		This is also possible with XoT but it must be noted that as with TCP
	the implementation of such and ACL cannot be enforced on the primary		the implementation of such an ACL cannot be enforced on the primary
	until a XFR request is received on an established connection.		until a XFR request is received on an established connection.
	If control were to be any more fine-grained than this then a separate		If control were to be any more fine-grained than this then a
	port would be required for XoT such that implementations would be		separate, dedicated port would need to be agreed between primary and
	able to refuse connections on that port to all clients except those		secondary for XoT such that implementations would be able to refuse
	configured as secondaries.		connections on that port to all clients except those configured as
			secondaries.
	6.5. ZONEMD		6.5. ZONEMD
	Message Digest for DNS Zones (ZONEMD)		Message Digest for DNS Zones (ZONEMD)
	[I-D.ietf-dnsop-dns-zone-digest] digest is a mechanism that can be		[I-D.ietf-dnsop-dns-zone-digest] digest is a mechanism that can be
	used to verify the content of a standalone zone. It is designed to		used to verify the content of a standalone zone. It is designed to
	be independent of the transmission channel or mechanism, allowing a		be independent of the transmission channel or mechanism, allowing a
	general consumer of a zone to do origin authentication of the entire		general consumer of a zone to do origin authentication of the entire
	zone contents. Note that the current version of		zone contents. Note that the current version of
	[I-D.ietf-dnsop-dns-zone-digest] states:		[I-D.ietf-dnsop-dns-zone-digest] states:
	skipping to change at page 14, line 37 ¶		skipping to change at page 15, line 16 ¶
	TBD		TBD
	12. Security Considerations		12. Security Considerations
	This document specifies a security measure against a DNS risk: the		This document specifies a security measure against a DNS risk: the
	risk that an attacker collects entire DNS zones through eavesdropping		risk that an attacker collects entire DNS zones through eavesdropping
	on clear text DNS zone transfers. It presents a new Security		on clear text DNS zone transfers. It presents a new Security
	Consideration for DNS. Some questions to discuss are:		Consideration for DNS. Some questions to discuss are:
	o Should DoT in this new case be required to use only TLS 1.3 and
	higher to avoid residual exposure?
	o How should padding be used in IXFR?		o How should padding be used in IXFR?
	o Should there be an option to 'pad' an AXFR response (i.e. a set of		o Should there be an option to 'pad' an AXFR response (i.e. a set of
	AXFR responses on a given connection) to hide the zone size?		AXFR responses on a given connection) to hide the zone size?
	13. Acknowledgements		13. Acknowledgements
	The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for		The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for
	review and discussions.		review and discussions.
	14. Changelog		14. Changelog
	draft-ietf-dprive-xfr-over-tls-00		draft-ietf-dprive-xfr-over-tls-00
			o Minor editorial updates
			o Add requirement for TLS 1.3. or later
			draft-ietf-dprive-xfr-over-tls-00
	o Rename after adoption and reference update.		o Rename after adoption and reference update.
	o Add placeholder for SIG(0) discussion		o Add placeholder for SIG(0) discussion
	o Update section on ZONEMD		o Update section on ZONEMD
	draft-hzpa-dprive-xfr-over-tls-02		draft-hzpa-dprive-xfr-over-tls-02
	o Substantial re-work of the document.		o Substantial re-work of the document.
	skipping to change at page 15, line 33 ¶		skipping to change at page 16, line 11 ¶
	draft-hzpa-dprive-xfr-over-tls-00		draft-hzpa-dprive-xfr-over-tls-00
	o Initial commit		o Initial commit
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	[I-D.ietf-dprive-rfc7626-bis]		[I-D.ietf-dprive-rfc7626-bis]
	Bortzmeyer, S. and S. Dickinson, "DNS Privacy		Bortzmeyer, S. and S. Dickinson, "DNS Privacy
	Considerations", draft-ietf-dprive-rfc7626-bis-02 (work in		Considerations", draft-ietf-dprive-rfc7626-bis-05 (work in
	progress), October 2019.		progress), May 2020.
	[I-D.vcelak-nsec5]		[I-D.vcelak-nsec5]
	Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and		Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and
	D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of		D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of
	Existence", draft-vcelak-nsec5-08 (work in progress),		Existence", draft-vcelak-nsec5-08 (work in progress),
	December 2018.		December 2018.
	[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, <https://www.rfc-		DOI 10.17487/RFC1995, August 1996, <https://www.rfc-
	editor.org/info/rfc1995>.		editor.org/info/rfc1995>.
	skipping to change at page 17, line 10 ¶		skipping to change at page 17, line 32 ¶
	[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,		Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
	January 2019, <https://www.rfc-editor.org/info/rfc8499>.		January 2019, <https://www.rfc-editor.org/info/rfc8499>.
	15.2. Informative References		15.2. Informative References
	[I-D.ietf-dnsop-dns-zone-digest]		[I-D.ietf-dnsop-dns-zone-digest]
	Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.		Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
	Hardaker, "Message Digest for DNS Zones", draft-ietf-		Hardaker, "Message Digest for DNS Zones", draft-ietf-
	dnsop-dns-zone-digest-02 (work in progress), October 2019.		dnsop-dns-zone-digest-07 (work in progress), April 2020.
	[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>.
	[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
End of changes. 26 change blocks.
	48 lines changed or deleted		66 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/