< draft-ietf-dnsop-edns-tcp-keepalive-03.txt		draft-ietf-dnsop-edns-tcp-keepalive-04.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 2, 2016 Dyn, Inc.		Expires: April 22, 2016 Dyn, Inc.
	S. Dickinson		S. Dickinson
	Sinodun		Sinodun
	R. Bellis		R. Bellis
	ISC		ISC
	September 30, 2015		October 20, 2015
	The edns-tcp-keepalive EDNS0 Option		The edns-tcp-keepalive EDNS0 Option
	draft-ietf-dnsop-edns-tcp-keepalive-03		draft-ietf-dnsop-edns-tcp-keepalive-04
	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 fallback and servers typically use idle timeouts on the
	order of seconds.		order of seconds.
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 2, 2016.		This Internet-Draft will expire on April 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
	3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 4		3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5
	3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5		3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 6
	3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5		3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 6
	3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6		3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . 7
	3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7		3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . . . . . 8		4. Intermediary Considerations . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . . . . . . . 10		Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 11
	A.1. Abridged Change History . . . . . . . . . . . . . . . . . 10		A.1. Abridged Change History . . . . . . . . . . . . . . . . . 11
	A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-03 . . . . . . . 10		A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-04 . . . . . . . 11
	A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 11		A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-03 . . . . . . . 11
	A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 11		A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 12
	A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 11		A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 12
	A.1.5. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 12		A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 12
	A.1.6. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 12		A.1.6. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		A.1.7. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 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
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 29 ¶
	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]		TBD1
	OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2		OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2
	if it is present;		if it is present;
	TIMEOUT: an idle timeout value for the TCP connection, specified in		TIMEOUT: an idle timeout value for the TCP connection, specified in
	units of 100 milliseconds, 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 MUST NOT include the edns-tcp-keepalive option in queries		DNS clients MUST NOT include the edns-tcp-keepalive option in queries
	sent using UDP transport.		sent using UDP transport.
	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 to		query sent to a server using TCP transport to signal their desire to
	keep the connection open when idle.		keep the connection open when idle.
			DNS clients MAY include the edns-tcp-keepalive option in subsequent
			queries sent to a server using TCP transport to signal their
			continued desire to keep the connection open when idle.
	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 and
	initiate close of the connection before the timeout expires.		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.
	skipping to change at page 8, line 16 ¶		skipping to change at page 8, line 18 ¶
	persistent TCP connection it means that (following the initial		persistent TCP connection it means that (following the initial
	exchange of timeouts) a server may not be presented with the		exchange of timeouts) a server may not be presented with the
	opportunity to signal a change in the idle timeout associated with a		opportunity to signal a change in the idle timeout associated with a
	connection if the client does not send any further requests		connection if the client does not send any further requests
	containing EDNS0 OPT RRs. This limitation makes persistent		containing EDNS0 OPT RRs. This limitation makes persistent
	connection handling via an initial idle timeout signal more		connection handling via an initial idle timeout signal more
	attractive than a mechanism that establishes default persistence and		attractive than a mechanism that establishes default persistence and
	then uses a connection close signal (in a similar manner to HTTP 1.1		then uses a connection close signal (in a similar manner to HTTP 1.1
	[RFC7320]).		[RFC7320]).
			If a client includes the edns-tcp-keepalive option in the first
			query, it SHOULD include an EDNS0 OPT RR periodically in any further
			messages it sends during the TCP session. This will increase the
			chance of the client being notified should the server modify the
			timeout associated with a session. The algorithm for choosing when
			to do this is out of scope of this document and is left up to the
			implementor and/or operator.
	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
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 14 ¶
	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 Nameserver		large numbers of sessions in a quick burst. When a DNS Server
	detects abusive behaviour, it SHOULD immediately close the TCP		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 |
	+-------+--------------------+----------+-----------------+		+-------+--------------------+----------+-----------------+
	| [TBA] | edns-tcp-keepalive | Optional | [This document] |		| TBD1 | edns-tcp-keepalive | Optional | [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
	[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, DOI 10.17487/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, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<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.
	Rose, "DNS Security Introduction and Requirements", RFC		Rose, "DNS Security Introduction and Requirements",
	4033, March 2005.		RFC 4033, DOI 10.17487/RFC4033, March 2005,
			<http://www.rfc-editor.org/info/rfc4033>.
	[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast		[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
	Services", BCP 126, RFC 4786, December 2006.		Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
			December 2006, <http://www.rfc-editor.org/info/rfc4786>.
	[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
	Requirements", RFC 5966, August 2010.
	[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
	"TCP Extensions for Multipath Operation with Multiple
	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,
			DOI 10.17487/RFC6891, April 2013,
			<http://www.rfc-editor.org/info/rfc6891>.
	[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC		[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
	7320, July 2014.		RFC 7320, DOI 10.17487/RFC7320, July 2014,
			<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), March 2015.		dnsop-edns-chain-query (work in progress), October 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-00 (work		Considerations", draft-ietf-dprive-dns-over-tls-01 (work
	in progress), September 2015.		in progress), October 2015.
	[DRAFT-5966bis]		[DRAFT-5966bis]
	Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and		Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
	D. Wessels, "DNS Transport over TCP - Implementation		D. Wessels, "DNS Transport over TCP - Implementation
	Requirements", draft-ietf-dnsop-5966bis-03 (work in		Requirements", draft-ietf-dnsop-5966bis-03 (work in
	progress), September 2015.		progress), September 2015.
	[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
	(DNS RRL)", ISC-TN 2012-1-Draft1, April 2012.
	[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.
			[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
			"TCP Extensions for Multipath Operation with Multiple
			Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
			<http://www.rfc-editor.org/info/rfc6824>.
			[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
			(DNS RRL)", ISC-TN 2012-1-Draft1, April 2012.
	Appendix A. Editors' Notes		Appendix A. Editors' Notes
	A.1. Abridged Change History		A.1. Abridged Change History
	A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-03		[Note to RFC Editor: please remove this section prior to
			publication.]
			A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-04
			Adding wording to sections 3.2.1 and 3.4 to clarify client behaviour
			on subsequent queries on a TCP connection.
			Changed the should to a SHOULD in section 3.2.2
			Changed Nameserver to DNS server in section 5.
			Updated references.
			Changed reference to RFC6824 to be informative.
			Corrected reference to requested EDNS0 option code to be 'TBD1'.
			A.1.2. 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-		Updated references, including name change of STARTTLS -> DNS-over-TLS
	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.2. draft-ietf-dnsop-edns-tcp-keepalive-02		A.1.3. 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 11, line 47 ¶		skipping to change at page 12, line 37 ¶
	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.3. draft-ietf-dnsop-edns-tcp-keepalive-01		A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-01
	Version bump with no changes		Version bump with no changes
	A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-00		A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-00
	Clarifications, working group adoption.		Clarifications, working group adoption.
	A.1.5. draft-wouters-edns-tcp-keepalive-01		A.1.6. 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.6. draft-wouters-edns-tcp-keepalive-00		A.1.7. 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. 33 change blocks.
	52 lines changed or deleted		91 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/