< draft-ietf-dnsop-edns-tcp-keepalive-01.txt		draft-ietf-dnsop-edns-tcp-keepalive-02.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 30, 2015 Dyn, Inc.		Expires: January 4, 2016 Dyn, Inc.
	October 27, 2014		S. Dickinson
			Sinodun
			R. Bellis
			ISC
			July 3, 2015
	The edns-tcp-keepalive EDNS0 Option		The edns-tcp-keepalive EDNS0 Option
	draft-ietf-dnsop-edns-tcp-keepalive-01		draft-ietf-dnsop-edns-tcp-keepalive-02
	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 are currently		retransmits and amplification. However, clients commonly use TCP
	limited in their use of the TCP transport as RFC 5966 suggests		only for fallback and servers typically use idle timeouts on the
	closing idle TCP sessions "in the order of seconds", making use of		order of seconds.
	TCP only suitable for individual queries generated as a fallback
	protocol for truncated UDP answers.
	This document defines an EDNS0 option ("edns-tcp-keepalive") that		This document defines an EDNS0 option ("edns-tcp-keepalive") that
	allows DNS clients and servers to signal their respective readiness		allows DNS servers to signal a variable idle timeout. This
	to conduct multiple DNS transactions over individual TCP sessions.		signalling facilitates a better balance of UDP and TCP transport
	This signalling facilitates a better balance of UDP and TCP transport
	between individual clients and servers, reducing the impact of		between individual clients and servers, reducing the impact of
	problems associated with UDP transport and allowing the state		problems associated with UDP transport and allowing the state
	associated with TCP transport to be managed effectively with minimal		associated with TCP transport to be managed effectively with minimal
	impact on the DNS transaction time.		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 30, 2015.		This Internet-Draft will expire on January 4, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
	3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 4		3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 4
	3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5		3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5
	3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . . . . . . 6		3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6
	3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7		3.4. TCP Session Management . . . . . . . . . . . . . . . . . 6
	3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 7		3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 7
	3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 7		3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 7
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
	Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . 9
	A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 9		Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 10
	A.2. Abridged Change History . . . . . . . . . . . . . . . . . 9		A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	A.2.1. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 9		A.2. Abridged Change History . . . . . . . . . . . . . . . . . 10
	A.2.2. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 9		A.2.1. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 10
	A.2.3. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 9		A.2.2. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 11
	A.2.4. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 9		A.2.3. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		A.2.4. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 11
			A.2.5. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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		since clients that have fallen back to TCP transport in response to a
	truncated response typically only uses the TCP session for a single		truncated response typically only uses the TCP session for a single
	(request, response) pair, continuing with UDP transport for		(request, 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. Mitigation		exploited to enable a reflection attack on a third party. Mitigation
	of such attacks on authoritative-only servers is possible using an		of such attacks on authoritative-only servers is possible using an
	skipping to change at page 4, line 6 ¶		skipping to change at page 4, line 10 ¶
	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, however, and the overall impact of the TCP setup
	handshake when the resulting session is used to exchange N DNS		handshake when the resulting session is used to exchange N DNS
	message pairs over a single session, (1 + N)/N, approaches unity as N		message pairs over a single session, (1 + N)/N, approaches unity as N
	increases.		increases.
	(It should perhaps be noted that the overhead for a DNS transaction		(It should perhaps be noted that the overhead for a DNS transaction
	over UDP truncacated due to RRL is 3x RTT, higher than the overhead		over UDP truncated due to RRL is 3x RTT, higher than the overhead
	imposed on the same transaction initiated over TCP.)		imposed on the same transaction initiated over TCP.)
	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 fallback
	to TCP.		to TCP.
	The use of TCP transport requires considerably more state to be		The use of TCP transport requires considerably more state to be
	retained on DNS servers. If a server is to perform adequately with a		retained on DNS servers. If a server is to perform adequately with a
	significant query load received over TCP, it must manage its		significant query load received over TCP, it must manage its
	available resources to ensure that all established TCP sessions are		available resources to ensure that all established TCP sessions are
	well-used, and that those which are unlikely to be used for the		well-used, and those that remain idle for long periods are closed
	exchange of multiple DNS messages are closed promptly.		promptly.
	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 provides a means to better balance the use of UDP and
	TCP transport, reducing the impact of problems associated with UDP		TCP transport, reducing the impact of problems associated with UDP
	whilst constraining the impact of TCP on response times and server		whilst constraining the impact of TCP on response times and server
	resources to a manageable level.		resources to a manageable level.
	The reduced overhead of this extension adds up significantly when		The reduced overhead of this extension adds up significantly when
	combined with other edns extensions, such as [CHAIN-QUERY]. The		combined with other edns extensions, such as [CHAIN-QUERY] and
	combination of these two EDNS extensions make it possible for hosts		[STARTTLS]. For example, the combination of these EDNS extensions
	on high-latency mobile networks to natively perform DNSSEC		make it possible for hosts on high-latency mobile networks to
	validation.		natively perform DNSSEC validation and encrypt queries.
	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		willingness to keep an idle TCP session open for a certain amount of
	of time to conduct future DNS transactions. This specification does		time to conduct future DNS transactions. This specification does not
	not distinguish between different types of DNS client and server in		distinguish between different types of DNS client and server in the
	the use of this option.		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 !
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| TIMEOUT |		| TIMEOUT |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	where:		where:
	OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive,		OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive,
	[TBD]		[TBD]
	OPTION-LENGTH: the value 2;		OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2
			if it is present;
	TIMEOUT: a timeout value for the TCP connection, specified in		TIMEOUT: an idle timeout value for the TCP connection, specified in
	seconds, encoded in network byte order.		units of 100 milliseconds, encoded in network byte order.
	3.2. Use by DNS Clients		3.2. Use by DNS Clients
	3.2.1. Sending Queries		3.2.1. Sending Queries
	DNS clients MAY include the edns-tcp-keepalive option in queries sent		DNS clients MUST NOT include the edns-tcp-keepalive option in queries
	using UDP transport to signal their general ability to use individual		sent using UDP transport.
	TCP sessions for multiple DNS transactions with a particular server.
	DNS clients MAY include the edns-tcp-keepalive option in the first		DNS clients MAY include the edns-tcp-keepalive option in the first
	query sent to a server using TCP transport to signal their desire		query sent to a server using TCP transport to signal their desire to
	that that specific TCP session be used for multiple DNS transactions.		keep the connection open when idle.
	Clients MAY specify a TIMEOUT value that is representative of the
	minimum expected time an individual TCP session should remain
	established for it to be used by multiple DNS transactions.
	In the case where there are multiple candidate servers available to
	service a particular transaction, clients MAY include data associated
	with all servers when computing a TIMEOUT value to be signalled to
	any one of those servers.
	If the client has insufficient data to be able to provide a		Clients MUST specify a OPTION-LENGTH of 0 and omit the TIMEOUT value.
	meaningful estimate, the TIMEOUT value MUST be set to zero.
	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 MAY record the presence of the		includes the edns-tcp-keepalive option MUST ignore the option.
	option and the associated TIMEOUT value, and use that information as
	part of its server selection algorithm in the case where multiple
	candidate servers are available to service a particular query.
	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.		session open when it is idle. It SHOULD honour the 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 is allowed to keep the TCP		keepalive option with a TIMEOUT value of 0 should send no more
	connection open indefinately.		queries on that connection and initiate closing the connection as
			soon as it has received all outstanding responses.
			A DNS client that sent a query containing the edns-keepalive-option
			but receives a response that does not contain the edns-keepalive-
			option should assume the server does not support keepalive and behave
			following the guidance in [DRAFT-5966bis]. This holds true even if a
			previous edns-keepalive-option exchange occurred on the existing TCP
			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 MAY record the presence of the option		the edns-tcp-keepalive option MUST ignore the option.
	for statistical purposes, but should not otherwise modify its usual
	behaviour in sending a response.
	A DNS server that receives a query using TCP transport that includes		A DNS server that receives a query using TCP transport that includes
	the edns-tcp-keepalive option SHOULD extend the timeout normally		the edns-tcp-keepalive option MAY modify the local idle timeout
	associated with TCP sessions if resources permit, using the TIMEOUT		associated with that TCP session if resources permit.
	value supplied by the client as a guide.
	3.3.2. Sending Responses		3.3.2. Sending Responses
	DNS servers MAY include the edns-tcp-keepalive option in responses		DNS servers MAY include the edns-tcp-keepalive option in responses
	sent using UDP transport to signal their general ability to use		sent using TCP transport to signal their expected idle timeout on a
	individual TCP sessions for multiple DNS transactions with a		connection. Servers MUST specify the TIMEOUT value that is currently
	particular server. The TIMEOUT value should be indicative of what a		associated with the TCP session. It is reasonable for this value to
	client might expect if it was to open a TCP session with the server		change according to local resource constraints or in consideration of
	and receive a response with the edns-tcp-keepalive option present.		intermediary behaviour (for example TCP middleboxes or NATs). The
	The DNS server MAY omit including the edns-tcp-keepalive option if it		DNS server SHOULD send a edns-tcp-keepalive option with a timeout of
	is running too low on resources to service more TCP keepalive		0 if it deems its local resources are too low to service more TCP
	sessions.		keepalive sessions.
	DNS servers MAY include the edns-tcp-keepalive option in responses
	sent using TCP transport to signal their ability to use that specific
	session to exchange multiple DNS transactions. Servers MUST specify
	the TIMEOUT value that is currently associated with the TCP session.
	It is reasonable for this value to change according to local resource
	constraints. The DNS server MAY omit including the edns-tcp-
	keepalive option if it deems its local resources are too low to
	service more TCP keepalive sessions.
	3.4. TCP Session Management		3.4. TCP Session Management
	Both DNS clients and servers are subject to resource constraints		Both DNS clients and servers are subject to resource constraints
	which will limit the extent to which TCP sessions can persist.		which will limit the extent to which TCP sessions can persist.
	Effective limits for the number of active sessions that can be		Effective limits for the number of active sessions that can be
	maintained on individual clients and servers should be established,		maintained on individual clients and servers should be established,
	either as configuration options or by interrogation of process limits		either as configuration options or by interrogation of process limits
	imposed by the operating system.		imposed by the operating system. Servers that implement keepalive
			should also engage in TCP connection management by recycling existing
			connections when appropriate, closing connections gracefully and
			managing request queues to enable fair use.
	In the event that there is greater demand for TCP sessions than can		In the event that there is greater demand for TCP sessions than can
	be accommodated, servers may reduce the TIMEOUT value signalled in		be accommodated, servers may reduce the TIMEOUT value signalled in
	successive DNS messages to avoid abrupt termination of a session.		successive DNS messages to minimise idle time on existing sessions.
	This allows, for example, clients with other candidate servers to
	query to establish new TCP sessions with different servers in		This also allows, for example, clients with other candidate servers
			to query to establish new TCP sessions with different servers in
	expectation that an existing session is likely to be closed, or to		expectation that an existing session is likely to be closed, or to
	fall back to UDP.		fall back to UDP.
			Based on TCP session resources servers may signal a TIMEOUT value of
			0 to request clients to close connections as soon as possible. This
			is useful when server resources become very low or a denial-of-
			service attack is detected and further maximises the shifting of
			TIME_WAIT state to well-behaved clients.
			However it should be noted that RCF6891 states:
			Lack of presence of an OPT record in a request MUST be taken as an
			indication that the requestor does not implement any part of this
			specification and that the responder MUST NOT include an OPT
			record in its response.
			Since servers must be faithful to this specification even on a
			persistent TCP connection it means that (following the initial
			exchange of timeouts) a server may not be presented with the
			opportunity to signal a change in the idle timeout associated with a
			connection if the client does not send any further requests
			containing EDNS0 OPT RRs. This limitation makes persistent
			connection handling via an initial idle timeout signal more
			attractive than a mechanism that establishes default persistence and
			then uses a connection close signal (in a similar manner to HTTP 1.1
			[RFC7320]).
	DNS clients and servers MAY close a TCP session at any time in order		DNS clients and servers MAY close a TCP session at any time in order
	to manage local resource constraints. The algorithm by which clients		to manage local resource constraints. The algorithm by which clients
	and servers rank active TCP sessions in order to determine which to		and servers rank active TCP sessions in order to determine which to
	close is not specified in this document.		close is not specified in this document.
	3.5. Non-Clean Paths		3.5. Non-Clean Paths
	Many paths between DNS clients and servers suffer from poor hygiene,		Many paths between DNS clients and servers suffer from poor hygiene,
	limiting the free flow of DNS messages that include particular EDNS0		limiting the free flow of DNS messages that include particular EDNS0
	options, or messages that exceed a particular size. A fallback		options, or messages that exceed a particular size. A fallback
	strategy similar to that described in [RFC6891] section 6.2.2 SHOULD		strategy similar to that described in [RFC6891] section 6.2.2 SHOULD
	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].
	Successive DNS transactions between a client and server using UDP
	transport may involve responses generated by different anycast nodes,
	and the use of anycast in the implementation of a DNS server is
	effectively undetectable by the client. The edns-tcp-keepalive
	option SHOULD NOT be included in responses using UDP transport from
	servers provisioned using anycast unless all anycast server nodes are
	capable of processing the edns-tcp-keepalive option.
	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. Anycast servers MAY make
	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 in order to avoid
	disruption due to topology changes.		disruption due to topology changes.
	4. Security Considerations		4. Intermediary Considerations
			It is RECOMMENDED that DNS intermediaries which terminate TCP
			connections implement keepalive. Should a non-keepalive-aware
			intermediary sit between a client and server that both support
			keepalive a potential side effect will be an increased frequency of
			the proxy closing idle client connections.
			5. Security Considerations
	The edns-tcp-keep-alive option can potentially be abused to request		The edns-tcp-keep-alive option can potentially be abused to request
	large numbers of sessions in a quick burst. When a Nameserver		large numbers of sessions in a quick burst. When a Nameserver
	detects abusive behaviour, it SHOULD immediately close the TCP		detects abusive behaviour, it SHOULD immediately close the TCP
	connection and free all buffers used.		connection and free all buffers used.
			Readers are advised to familiarise themselves with the security
			considerations outlined in [DRAFT-5966bis]
	This section needs more work. As usual.		This section needs more work. As usual.
	5. 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 |
	+-------+--------------------+----------+-----------------+		+-------+--------------------+----------+-----------------+
	| [TBA] | edns-tcp-keepalive | Optional | [This document] |		| [TBA] | edns-tcp-keepalive | Optional | [This document] |
	+-------+--------------------+----------+-----------------+		+-------+--------------------+----------+-----------------+
	6. Acknowledgements		7. Acknowledgements
	The authors acknowledge the contributions of Ray Bellis, Jinmei
	TATUYA and Mark Andrews.
	7. References		The authors acknowledge the contributions of Jinmei TATUYA and Mark
			Andrews.
	7.1. Normative References		8. References
	[CHAIN-QUERY]		8.1. Normative References
	Wouters, P., "chain Query requests in DNS", draft-ietf-
	dnsop-edns-chain-query (work in progress), October 2014.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements", RFC		Rose, "DNS Security Introduction and Requirements", RFC
	4033, March 2005.		4033, March 2005.
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 32 ¶
	[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation		[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
	Requirements", RFC 5966, August 2010.		Requirements", RFC 5966, August 2010.
	[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, January 2013.		Addresses", RFC 6824, January 2013.
	[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms		[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
	for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.		for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
	7.2. Informative References		[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC
			7320, July 2014.
			8.2. Informative References
			[CHAIN-QUERY]
			Wouters, P., "Chain Query requests in DNS", draft-ietf-
			dnsop-edns-chain-query (work in progress), October 2014.
			[DRAFT-5966bis]
			Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
			D. Wessels, "DNS Transport over TCP - Implementation
			Requirements", draft-ietf-dnsop-5966bis-02 (work in
			progress), July 2015.
	[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.
			[STARTTLS]
			Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
			and P. Hoffman, "TLS for DNS: Initiation and Performance
			Considerations", draft-ietf-dprive-start-tls-for-dns-02
			(work in progress), May 2015.
	Appendix A. Editors' Notes		Appendix A. Editors' Notes
	A.1. Venue		A.1. Venue
	An appropriate venue for discussion of this document is		An appropriate venue for discussion of this document is
	dnsop@ietf.org.		dnsop@ietf.org.
	A.2. Abridged Change History		A.2. Abridged Change History
	A.2.1. draft-ietf-dnsop-edns-tcp-keepalive-01		A.2.1. draft-ietf-dnsop-edns-tcp-keepalive-02
			Changed timeout value to idle timeout and re-phrased document around
			this.
			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
			potentially confusing, could cause issues with ALG's and adds only
			limited value.
			Changed semantics so the client no longer sends a timeout. The
			client timeout is of limited value as servers should be managing
			connections based on their view of their resources, not on client
			requests as this is open to abuse. Additionally this identifies
			cases were the option is simply being reflected back.
			Changed semantics for the meaning of a server sending a timeout of 0.
			The maximum timeout value of 6553.5s (~1.8h) is already large and a
			distinct 'connection close'-like signal is potentially more useful.
			Added more detail on server side requirements when supporting
			keepalive in terms of resource and connection management.
			Added discussion of EDNS0 per-message limitation and implications of
			this.
			Added reference to STARTTLS draft and RFC7320.
			A.2.2. draft-ietf-dnsop-edns-tcp-keepalive-01
	Version bump with no changes		Version bump with no changes
	A.2.2. draft-ietf-dnsop-edns-tcp-keepalive-00		A.2.3. draft-ietf-dnsop-edns-tcp-keepalive-00
	Clarifications, working group adoption.		Clarifications, working group adoption.
	A.2.3. draft-wouters-edns-tcp-keepalive-01		A.2.4. 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.2.4. draft-wouters-edns-tcp-keepalive-00		A.2.5. 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
	Joe Abley		Joe Abley
	Dyn, Inc.		Dyn, Inc.
	470 Moore Street		470 Moore Street
	London, ON N6C 2C2		London, ON N6C 2C2
	Canada		Canada
	Phone: +1 519 670 9327		Phone: +1 519 670 9327
	Email: jabley@dyn.com		Email: jabley@dyn.com
			Sara Dickinson
			Sinodun Internet Technologies
			Magdalen Centre
			Oxford Science Park
			Oxford OX4 4GA
			UK
			Email: sara@sinodun.com
			URI: http://sinodun.com
			Ray Bellis
			Internet Systems Consortium, Inc
			950 Charter Street
			Redwood City CA 94063
			USA
			Phone: +1 650 423 1200
			Email: ray@isc.org
			URI: http://www.isc.org
End of changes. 45 change blocks.
	119 lines changed or deleted		184 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/