< draft-ietf-dnsop-edns-tcp-keepalive-04.txt		draft-ietf-dnsop-edns-tcp-keepalive-05.txt >
	dnsop P. Wouters		dnsop P. Wouters
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Intended status: Standards Track J. Abley		Intended status: Standards Track J. Abley
	Expires: April 22, 2016 Dyn, Inc.		Expires: July 9, 2016 Dyn, Inc.
	S. Dickinson		S. Dickinson
	Sinodun		Sinodun
	R. Bellis		R. Bellis
	ISC		ISC
	October 20, 2015		January 6, 2016
	The edns-tcp-keepalive EDNS0 Option		The edns-tcp-keepalive EDNS0 Option
	draft-ietf-dnsop-edns-tcp-keepalive-04		draft-ietf-dnsop-edns-tcp-keepalive-05
	Abstract		Abstract
	DNS messages between clients and servers may be received over either		DNS messages between clients and servers may be received over either
	UDP or TCP. UDP transport involves keeping less state on a busy		UDP or TCP. UDP transport involves keeping less state on a busy
	server, but can cause truncation and retries over TCP. Additionally,		server, but can cause truncation and retries over TCP. Additionally,
	UDP can be exploited for reflection attacks. Using TCP would reduce		UDP can be exploited for reflection attacks. Using TCP would reduce
	retransmits and amplification. However, clients commonly use TCP		retransmits and amplification. However, clients commonly use TCP
	only for fallback and servers typically use idle timeouts on the		only for retries and servers typically use idle timeouts on the order
	order of seconds.		of seconds.
	This document defines an EDNS0 option ("edns-tcp-keepalive") that		This document defines an EDNS0 option ("edns-tcp-keepalive") that
	allows DNS servers to signal a variable idle timeout. This		allows DNS servers to signal a variable idle timeout. This
	signalling facilitates a better balance of UDP and TCP transport		signalling encourages the use of long-lived TCP connections by
	between individual clients and servers, reducing the impact of		allowing the state associated with TCP transport to be managed
	problems associated with UDP transport and allowing the state		effectively with minimal impact on the DNS transaction time.
	associated with TCP transport to be managed effectively with minimal
	impact on the DNS transaction time.
	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 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 April 22, 2016.		This Internet-Draft will expire on July 9, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
	3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5		3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 4
	3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 6		3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5
	3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 6		3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5
	3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6		3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 5
	3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6		3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6
	3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6		3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6
	3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 7		3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6
	3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7		3.4. TCP Session Management . . . . . . . . . . . . . . . . . 6
	3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 8		3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 8
	3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8		3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8
	4. Intermediary Considerations . . . . . . . . . . . . . . . . . 9		4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 11		Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 10
	A.1. Abridged Change History . . . . . . . . . . . . . . . . . 11		A.1. Abridged Change History . . . . . . . . . . . . . . . . . 10
	A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-04 . . . . . . . 11		A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-05 . . . . . . . 10
	A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-03 . . . . . . . 11		A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-04 . . . . . . . 11
	A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 12		A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-03 . . . . . . . 11
	A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 12		A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 12
	A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 12		A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 12
	A.1.6. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 12		A.1.6. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 12
	A.1.7. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 13		A.1.7. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 13
			A.1.8. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	DNS messages between clients and servers may be received over either		DNS messages between clients and servers may be received over either
	UDP or TCP [RFC1035]. Historically, DNS clients used API's that only		UDP or TCP [RFC1035]. Historically, DNS clients used API's that only
	facilitated sending and receiving a single query over either UDP or		facilitated sending and receiving a single query over either UDP or
	TCP. New APIs and deployment of DNSSEC validating resolvers on hosts		TCP. New APIs and deployment of DNSSEC validating resolvers on hosts
	that in the past were using stub resolving only is increasing the DNS		that in the past were using stub resolving only is increasing the DNS
	client base that prefer using long lived TCP connections. Long-lived		client base that prefer using long lived TCP connections. Long-lived
	TCP connections can result in lower request latency than the case		TCP connections can result in lower request latency than the case
	where UDP transport is used and truncated responses are received,		where UDP transport is used and truncated responses are received.
	since clients that have fallen back to TCP transport in response to a		This is because clients that retry over TCP following a truncated UDP
	truncated response typically only uses the TCP session for a single		response typically only use the TCP session for a single (request,
	(request, response) pair, continuing with UDP transport for		response) pair, continuing with UDP transport for subsequent queries.
	subsequent queries. Clients wishing to use other stream-based
	transport protocols for DNS would also benefit from the set-up
	amortisation afforded by long lived connections.
	UDP transport is stateless, and hence presents a much lower resource		UDP transport is stateless, and hence presents a much lower resource
	burden on a busy DNS server than TCP. An exchange of DNS messages		burden on a busy DNS server than TCP. An exchange of DNS messages
	over UDP can also be completed in a single round trip between		over UDP can also be completed in a single round trip between
	communicating hosts, resulting in optimally-short transaction times.		communicating hosts, resulting in optimally-short transaction times.
	UDP transport is not without its risks, however.		UDP transport is not without its risks, however.
	A single-datagram exchange over UDP between two hosts can be		A single-datagram exchange over UDP between two hosts can be
	exploited to enable a reflection attack on a third party. Response		exploited to enable a reflection attack on a third party. Response
	Rate Limiting [RRL] is designed to help mitigate such attacks against		Rate Limiting [RRL] is designed to help mitigate such attacks against
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 44 ¶
	512 bytes. Deployment of DNSSEC [RFC4033] and other protocols		512 bytes. Deployment of DNSSEC [RFC4033] and other protocols
	subsequently increased the observed frequency at which responses		subsequently increased the observed frequency at which responses
	exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than		exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than
	512 bytes to be exchanged over UDP, with a corresponding increased		512 bytes to be exchanged over UDP, with a corresponding increased
	incidence of fragmentation. Fragmentation is known to be problematic		incidence of fragmentation. Fragmentation is known to be problematic
	in general, and has also been implicated in increasing the risk of		in general, and has also been implicated in increasing the risk of
	cache poisoning attacks [fragmentation-considered-poisonous].		cache poisoning attacks [fragmentation-considered-poisonous].
	TCP transport is less susceptible to the risks of fragmentation and		TCP transport is less susceptible to the risks of fragmentation and
	reflection attacks. However, TCP transport as currently deployed has		reflection attacks. However, TCP transport as currently deployed has
	expensive overhead.		expensive setup overhead.
	The overhead of the three-way TCP handshake for a single DNS		The overhead of the three-way TCP handshake for a single DNS
	transaction is substantial, increasing the transaction time for a		transaction is substantial, increasing the transaction time for a
	single (request, response) pair of DNS messages from 1 x RTT to 2 x		single (request, response) pair of DNS messages from 1 x RTT to 2 x
	RTT. There is no such overhead for a session that is already		RTT. There is no such overhead for a session that is already
	established, however, and the overall impact of the TCP setup		established therefore the overhead of the initial TCP handshake is
	handshake when the resulting session is used to exchange N DNS		minimised when the resulting session is used to exchange multiple DNS
	message pairs over a single session, (1 + N)/N, approaches unity as N		message pairs over a single session. The extra RTT time for session
	increases.		setup can be represented as the equation (1 + N)/N, where N
			represents the number of DNS message pairs that utilize the session
			and the result approaches unity as N increases.
	With increased deployment of DNSSEC and new RRtypes containing		With increased deployment of DNSSEC and new RRtypes containing
	application specific cryptographic material, there is an increase in		application specific cryptographic material, there is an increase in
	the prevalence of truncated responses received over UDP with fallback		the prevalence of truncated responses received over UDP with retries
	to TCP.		over TCP. The overhead for a DNS transaction over UDP truncated due
			to RRL is 3x RTT, higher than the overhead imposed on the same
	(It should perhaps be noted that the overhead for a DNS transaction		transaction initiated over TCP.
	over UDP truncated due to RRL is 3x RTT, higher than the overhead
	imposed on the same transaction initiated over TCP.)
	The use of TCP transport requires state to be retained on DNS		The use of TCP transport requires state to be retained on DNS
	servers. If a server is to perform adequately with a significant		servers. If a server is to perform adequately with a significant
	query load received over TCP, it must manage its available resources		query load received over TCP, it must manage its available resources
	to ensure that all established TCP sessions are well-used, and idle		to ensure that all established TCP sessions are well-used, and idle
	connections are closed after an appropriate amount of time.		connections are closed after an appropriate amount of time.
	This document proposes a signalling mechanism between DNS clients and		This document proposes a signalling mechanism between DNS clients and
	servers that provides a means to better balance the use of UDP and		servers that encourages the use of long-lived TCP connections by
	TCP transport (thereby helping to manage the impact of problems		allowing the state associated with TCP transport to be managed
	associated with UDP), whilst constraining the impact of TCP on		effectively with minimal impact on the DNS transaction time.
	response times and server resources to a manageable level.
	This mechanism will be of benefit both for stub-resolver and		This mechanism will be of benefit both for stub-resolver and
	resolver-authoritative TCP connections. In the latter case the		resolver-authoritative TCP connections. In the latter case the
	persistent nature of the TCP connection can provide improved defence		persistent nature of the TCP connection can provide improved defence
	against attacks including DDoS.		against attacks including DDoS.
	The reduced overhead of this extension adds up significantly when		The reduced overhead of this extension adds up significantly when
	combined with other EDNS0 extensions, such as [CHAIN-QUERY] and		combined with other EDNS0 extensions, such as [CHAIN-QUERY] and
	[DNS-over-TLS]. For example, the combination of these EDNS0		[DNS-over-TLS]. For example, the combination of these EDNS0
	extensions make it possible for hosts on high-latency mobile networks		extensions make it possible for hosts on high-latency mobile networks
	skipping to change at page 5, line 9 ¶		skipping to change at page 4, line 48 ¶
	2. Requirements Notation		2. Requirements Notation
	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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. The edns-tcp-keepalive Option		3. The edns-tcp-keepalive Option
	This document specifies a new EDNS0 [RFC6891] option, edns-tcp-		This document specifies a new EDNS0 [RFC6891] option, edns-tcp-
	keepalive, which can be used by DNS clients and servers to signal a		keepalive, which can be used by DNS clients and servers to signal a
	willingness to keep an idle TCP session open for a certain amount of		willingness to keep an idle TCP session open to conduct future DNS
	time to conduct future DNS transactions. This specification does not		transactions, with the idle timeout being specified by the server.
	distinguish between different types of DNS client and server in the		This specification does not distinguish between different types of
	use of this option.		DNS client and server in the use of this option.
	3.1. Option Format		3.1. Option Format
	The edns-tcp-keepalive option is encoded as follows:		The edns-tcp-keepalive option is encoded as follows:
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	! OPTION-CODE ! OPTION-LENGTH !		! OPTION-CODE ! OPTION-LENGTH !
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 4 ¶
	Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT		Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT
	value.		value.
	3.2.2. Receiving Responses		3.2.2. Receiving Responses
	A DNS client that receives a response using UDP transport that		A DNS client that receives a response using UDP transport that
	includes the edns-tcp-keepalive option MUST ignore the option.		includes the edns-tcp-keepalive option MUST ignore the option.
	A DNS client that receives a response using TCP transport that		A DNS client that receives a response using TCP transport that
	includes the edns-tcp-keepalive option MAY keep the existing TCP		includes the edns-tcp-keepalive option MAY keep the existing TCP
	session open when it is idle. It SHOULD honour the timeout and		session open when it is idle. It SHOULD honour the timeout received
	initiate close of the connection before the timeout expires.		in that response (overriding any previous timeout) and initiate close
			of the connection before the timeout expires.
	A DNS client that receives a response that includes the edns-tcp-		A DNS client that receives a response that includes the edns-tcp-
	keepalive option with a TIMEOUT value of 0 SHOULD send no more		keepalive option with a TIMEOUT value of 0 SHOULD send no more
	queries on that connection and initiate closing the connection as		queries on that connection and initiate closing the connection as
	soon as it has received all outstanding responses.		soon as it has received all outstanding responses.
	A DNS client that sent a query containing the edns-keepalive-option		A DNS client that sent a query containing the edns-keepalive-option
	but receives a response that does not contain the edns-keepalive-		but receives a response that does not contain the edns-keepalive-
	option should assume the server does not support keepalive and behave		option SHOULD assume the server does not support keepalive and behave
	following the guidance in [DRAFT-5966bis]. This holds true even if a		following the guidance in [DRAFT-5966bis]. This holds true even if a
	previous edns-keepalive-option exchange occurred on the existing TCP		previous edns-keepalive-option exchange occurred on the existing TCP
	connection.		connection.
	3.3. Use by DNS Servers		3.3. Use by DNS Servers
	3.3.1. Receiving Queries		3.3.1. Receiving Queries
	A DNS server that receives a query using UDP transport that includes		A DNS server that receives a query using UDP transport that includes
	the edns-tcp-keepalive option MUST ignore the option.		the edns-tcp-keepalive option MUST ignore the option.
	skipping to change at page 8, line 47 ¶		skipping to change at page 8, line 23 ¶
	be employed to avoid persistent interference due to non-clean paths.		be employed to avoid persistent interference due to non-clean paths.
	3.6. Anycast Considerations		3.6. Anycast Considerations
	DNS servers of various types are commonly deployed using anycast		DNS servers of various types are commonly deployed using anycast
	[RFC4786].		[RFC4786].
	Changes in network topology between clients and anycast servers may		Changes in network topology between clients and anycast servers may
	cause disruption to TCP sessions making use of edns-tcp-keepalive		cause disruption to TCP sessions making use of edns-tcp-keepalive
	more often than with TCP sessions that omit it, since the TCP		more often than with TCP sessions that omit it, since the TCP
	sessions are expected to be longer-lived. Anycast servers MAY make		sessions are expected to be longer-lived. It might be possible for
			anycast servers to avoid disruption due to topology changes by making
	use of TCP multipath [RFC6824] to anchor the server side of the TCP		use of TCP multipath [RFC6824] to anchor the server side of the TCP
	connection to an unambiguously-unicast address in order to avoid		connection to an unambiguously-unicast address.
	disruption due to topology changes.
	4. Intermediary Considerations		4. Intermediary Considerations
	It is RECOMMENDED that DNS intermediaries which terminate TCP		It is RECOMMENDED that DNS intermediaries which terminate TCP
	connections implement edns-tcp-keepalive. An intermediary that does		connections implement edns-tcp-keepalive. An intermediary that does
	not implement edns-tcp-keepalive but sits between a client and server		not implement edns-tcp-keepalive but sits between a client and server
	that both support edns-tcp-keepalive might close idle connections		that both support edns-tcp-keepalive might close idle connections
	unnecessarily.		unnecessarily.
	5. Security Considerations		5. Security Considerations
	The edns-tcp-keepalive option can potentially be abused to request		The edns-tcp-keepalive option can potentially be abused to request
	large numbers of sessions in a quick burst. When a DNS Server		large numbers of long-lived sessions in a quick burst. When a DNS
	detects abusive behaviour, it SHOULD immediately close the TCP		Server detects abusive behaviour, it SHOULD immediately close the TCP
	connection and free the resources used.		connection and free the resources used.
	Servers could choose to monitor client behaviour with respect to the		Servers could choose to monitor client behaviour with respect to the
	edns-tcp-keepalive option to build up profiles of clients that do not		edns-tcp-keepalive option to build up profiles of clients that do not
	honour the specified timeout.		honour the specified timeout.
	Readers are advised to familiarise themselves with the security		Readers are advised to familiarise themselves with the security
	considerations outlined in [DRAFT-5966bis]		considerations outlined in [DRAFT-5966bis]
	6. IANA Considerations		6. IANA Considerations
	The IANA is directed to assign an EDNS0 option code for the edns-tcp-		The IANA is directed to assign an EDNS0 option code for the edns-tcp-
	keepalive option from the DNS EDNS0 Option Codes (OPT) registry as		keepalive option from the DNS EDNS0 Option Codes (OPT) registry as
	follows:		follows:
	+-------+--------------------+----------+-----------------+		+-------+--------------------+----------+-----------------+
	| Value | Name | Status | Reference |		| Value | Name | Status | Reference |
	+-------+--------------------+----------+-----------------+		+-------+--------------------+----------+-----------------+
	| TBD1 | edns-tcp-keepalive | Optional | [This document] |		| TBD1 | edns-tcp-keepalive | Standard | [This document] |
	+-------+--------------------+----------+-----------------+		+-------+--------------------+----------+-----------------+
	7. Acknowledgements		7. Acknowledgements
	The authors acknowledge the contributions of Jinmei TATUYA and Mark		The authors acknowledge the contributions of Jinmei TATUYA and Mark
	Andrews. Thanks to Duane Wessels for detailed review and the many		Andrews. Thanks to Duane Wessels for detailed review and the many
	others who contributed to the mailing list discussion.		others who contributed to the mailing list discussion.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
			[DRAFT-5966bis]
			Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
			D. Wessels, "DNS Transport over TCP - Implementation
			Requirements", draft-ietf-dnsop-5966bis (work in
			progress), December 2015.
	[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, <http://www.rfc-editor.org/info/rfc1035>.		November 1987, <http://www.rfc-editor.org/info/rfc1035>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	skipping to change at page 10, line 32 ¶		skipping to change at page 10, line 18 ¶
	<http://www.rfc-editor.org/info/rfc6891>.		<http://www.rfc-editor.org/info/rfc6891>.
	[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,		[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
	RFC 7320, DOI 10.17487/RFC7320, July 2014,		RFC 7320, DOI 10.17487/RFC7320, July 2014,
	<http://www.rfc-editor.org/info/rfc7320>.		<http://www.rfc-editor.org/info/rfc7320>.
	8.2. Informative References		8.2. Informative References
	[CHAIN-QUERY]		[CHAIN-QUERY]
	Wouters, P., "Chain Query requests in DNS", draft-ietf-		Wouters, P., "Chain Query requests in DNS", draft-ietf-
	dnsop-edns-chain-query (work in progress), October 2015.		dnsop-edns-chain-query (work in progress), November 2015.
	[DNS-over-TLS]		[DNS-over-TLS]
	Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
	and P. Hoffman, "TLS for DNS: Initiation and Performance		and P. Hoffman, "TLS for DNS: Initiation and Performance
	Considerations", draft-ietf-dprive-dns-over-tls-01 (work		Considerations", draft-ietf-dprive-dns-over-tls (work in
	in progress), October 2015.		progress), December 2015.
	[DRAFT-5966bis]
	Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
	D. Wessels, "DNS Transport over TCP - Implementation
	Requirements", draft-ietf-dnsop-5966bis-03 (work in
	progress), September 2015.
	[fragmentation-considered-poisonous]		[fragmentation-considered-poisonous]
	Herzberg, A. and H. Shulman, "Fragmentation Considered		Herzberg, A. and H. Shulman, "Fragmentation Considered
	Poisonous", arXiv 1205.4011, May 2012.		Poisonous", arXiv 1205.4011, May 2012,
			<http://arxiv.org/abs/1205.4011>.
	[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,		[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
	"TCP Extensions for Multipath Operation with Multiple		"TCP Extensions for Multipath Operation with Multiple
	Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,		Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
	<http://www.rfc-editor.org/info/rfc6824>.		<http://www.rfc-editor.org/info/rfc6824>.
	[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting		[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
	(DNS RRL)", ISC-TN 2012-1-Draft1, April 2012.		(DNS RRL)", ISC-TN 2012-1-Draft1, April 2012,
			<http://ss.vix.su/~vixie/isc-tn-2012-1.txt>.
	Appendix A. Editors' Notes		Appendix A. Editors' Notes
	A.1. Abridged Change History		A.1. Abridged Change History
	[Note to RFC Editor: please remove this section prior to		[Note to RFC Editor: please remove this section prior to
	publication.]		publication.]
	A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-04		A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-05
			Reword Abstract and paragraph 9 in Introduction to remove discussion
			on balancing UDP/TCP and talk about encouraging use of long-lived TCP
			sessions.
			Section 3.2.2: should -> SHOULD
			Changed draft-ietf-dnsop-5966bis to be a normative reference,
			therefore adding a dependancy on publication of that as RFC.
			Reword sentence referring to RFC6824 since it is informational.
			Update IANA option to Standard.
			Remove last sentence from 1st paragraph of introduction.
			Reword paragraph 6 in Introduction, merge paragraph 7 and 8.
			Reword Section 3, first sentence to clarify the timeout is specified
			by the server.
			Correct missing URIs in 2 references.
			Clarify statement in Section 3.2.2 as how clients should handle
			updating the timeout when receiving a response.
			Reworded first paragraph of Introduction discussing TCP vs (UDP +
			retry over TCP). Changed 'fallback' to 'retry' in 2 places.
			A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-04
	Adding wording to sections 3.2.1 and 3.4 to clarify client behaviour		Adding wording to sections 3.2.1 and 3.4 to clarify client behaviour
	on subsequent queries on a TCP connection.		on subsequent queries on a TCP connection.
	Changed the should to a SHOULD in section 3.2.2		Changed the should to a SHOULD in section 3.2.2
	Changed Nameserver to DNS server in section 5.		Changed Nameserver to DNS server in section 5.
	Updated references.		Updated references.
	Changed reference to RFC6824 to be informative.		Changed reference to RFC6824 to be informative.
	Corrected reference to requested EDNS0 option code to be 'TBD1'.		Corrected reference to requested EDNS0 option code to be 'TBD1'.
	A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-03		A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-03
	Clarified that a response to a query with any OPT RR may contain the		Clarified that a response to a query with any OPT RR may contain the
	ends-tcp-keepalive option.		ends-tcp-keepalive option.
	Corrected TIMEOUT length from 4 to 2 in the diagram.		Corrected TIMEOUT length from 4 to 2 in the diagram.
	Updated references, including name change of STARTTLS -> DNS-over-TLS		Updated references, including name change of STARTTLS -> DNS-over-TLS
	and adding reference for cache poisoning.		and adding reference for cache poisoning.
	Updated wording in section on Intermediary Considerations.		Updated wording in section on Intermediary Considerations.
	Updated wording describing RRL.		Updated wording describing RRL.
	Added paragraph to security section describing client behaviour		Added paragraph to security section describing client behaviour
	profiles.		profiles.
	Added wording to introduction on use case for stub/resolver/		Added wording to introduction on use case for stub/resolver/
	authoritative.		authoritative.
	A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-02		A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-02
	Changed timeout value to idle timeout and re-phrased document around		Changed timeout value to idle timeout and re-phrased document around
	this.		this.
	Changed units of timeout to 100ms to allow values less than 1 second.		Changed units of timeout to 100ms to allow values less than 1 second.
	Change specification to remove use of the option over UDP. This is		Change specification to remove use of the option over UDP. This is
	potentially confusing, could cause issues with ALG's and adds only		potentially confusing, could cause issues with ALG's and adds only
	limited value.		limited value.
	skipping to change at page 12, line 37 ¶		skipping to change at page 12, line 44 ¶
	distinct 'connection close'-like signal is potentially more useful.		distinct 'connection close'-like signal is potentially more useful.
	Added more detail on server side requirements when supporting		Added more detail on server side requirements when supporting
	keepalive in terms of resource and connection management.		keepalive in terms of resource and connection management.
	Added discussion of EDNS0 per-message limitation and implications of		Added discussion of EDNS0 per-message limitation and implications of
	this.		this.
	Added reference to STARTTLS draft and RFC7320.		Added reference to STARTTLS draft and RFC7320.
	A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-01		A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-01
	Version bump with no changes		Version bump with no changes
	A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-00		A.1.6. draft-ietf-dnsop-edns-tcp-keepalive-00
	Clarifications, working group adoption.		Clarifications, working group adoption.
	A.1.6. draft-wouters-edns-tcp-keepalive-01		A.1.7. draft-wouters-edns-tcp-keepalive-01
	Also allow clients to specify KEEPALIVE timeout values, clarify		Also allow clients to specify KEEPALIVE timeout values, clarify
	motivation of document.		motivation of document.
	A.1.7. draft-wouters-edns-tcp-keepalive-00		A.1.8. draft-wouters-edns-tcp-keepalive-00
	Initial draft.		Initial draft.
	Authors' Addresses		Authors' Addresses
	Paul Wouters		Paul Wouters
	Red Hat		Red Hat
	Email: pwouters@redhat.com		Email: pwouters@redhat.com
End of changes. 36 change blocks.
	82 lines changed or deleted		110 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/