draft-ietf-dnsop-edns-tcp-keepalive-02.txt   draft-ietf-dnsop-edns-tcp-keepalive-03.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: January 4, 2016 Dyn, Inc. Expires: April 2, 2016 Dyn, Inc.
S. Dickinson S. Dickinson
Sinodun Sinodun
R. Bellis R. Bellis
ISC ISC
July 3, 2015 September 30, 2015
The edns-tcp-keepalive EDNS0 Option The edns-tcp-keepalive EDNS0 Option
draft-ietf-dnsop-edns-tcp-keepalive-02 draft-ietf-dnsop-edns-tcp-keepalive-03
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 January 4, 2016. This Internet-Draft will expire on April 2, 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 6
3.4. TCP Session Management . . . . . . . . . . . . . . . . . 6 3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7
3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 7 3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 8
3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 7 3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8
4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8 4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 10 Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 10
A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.1. Abridged Change History . . . . . . . . . . . . . . . . . 10
A.2. Abridged Change History . . . . . . . . . . . . . . . . . 10 A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-03 . . . . . . . 10
A.2.1. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 10 A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 11
A.2.2. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 11 A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 11
A.2.3. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 11 A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 11
A.2.4. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 11 A.1.5. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 12
A.2.5. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 11 A.1.6. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 3, line 29 skipping to change at page 3, line 29
transport protocols for DNS would also benefit from the set-up transport protocols for DNS would also benefit from the set-up
amortisation afforded by long lived connections. 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. Response
of such attacks on authoritative-only servers is possible using an Rate Limiting [RRL] is designed to help mitigate such attacks against
approach known as Response Rate-Limiting [RRL], an approach designed authoritative-only servers. One feature of RRL is to let some amount
to minimise the frequency at which legitimate responses are discarded of responses "slip" through the rate limiter. These are returned
by truncating responses that appear to be motivated by an attacker, with the TC (truncation) bit set, which causes legitimate clients to
forcing legitimate clients to re-query using TCP transport. re-query using TCP transport.
[RFC1035] specified a maximum DNS message size over UDP transport of [RFC1035] specified a maximum DNS message size over UDP transport of
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. cache poisoning attacks [fragmentation-considered-poisonous].
The use of TCP transport does not suffer from the risks of TCP transport is less susceptible to the risks of fragmentation and
fragmentation nor reflection attacks. However, TCP transport as reflection attacks. However, TCP transport as currently deployed has
currently deployed has expensive overhead. expensive 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, 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
over UDP truncated due to RRL is 3x RTT, higher than the overhead
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 (It should perhaps be noted that the overhead for a DNS transaction
retained on DNS servers. If a server is to perform adequately with a over UDP truncated due to RRL is 3x RTT, higher than the overhead
significant query load received over TCP, it must manage its imposed on the same transaction initiated over TCP.)
available resources to ensure that all established TCP sessions are
well-used, and those that remain idle for long periods are closed The use of TCP transport requires state to be retained on DNS
promptly. servers. If a server is to perform adequately with a significant
query load received over TCP, it must manage its available resources
to ensure that all established TCP sessions are well-used, and idle
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 provides a means to better balance the use of UDP and
TCP transport, reducing the impact of problems associated with UDP TCP transport (thereby helping to manage the impact of problems
whilst constraining the impact of TCP on response times and server associated with UDP), whilst constraining the impact of TCP on
resources to a manageable level. response times and server resources to a manageable level.
This mechanism will be of benefit both for stub-resolver and
resolver-authoritative TCP connections. In the latter case the
persistent nature of the TCP connection can provide improved defence
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 edns extensions, such as [CHAIN-QUERY] and combined with other EDNS0 extensions, such as [CHAIN-QUERY] and
[STARTTLS]. For example, the combination of these EDNS extensions [DNS-over-TLS]. For example, the combination of these EDNS0
make it possible for hosts on high-latency mobile networks to extensions make it possible for hosts on high-latency mobile networks
natively perform DNSSEC validation and encrypt queries. to natively and efficiently 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-
skipping to change at page 5, line 14 skipping to change at page 5, line 18
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 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
skipping to change at page 5, line 39 skipping to change at page 6, line 9
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.
Clients MUST specify a OPTION-LENGTH of 0 and omit the TIMEOUT value. Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT
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.
skipping to change at page 6, line 27 skipping to change at page 6, line 47
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.
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 MAY modify the local idle timeout the edns-tcp-keepalive option MAY modify the local idle timeout
associated with that TCP session if resources permit. associated with that TCP session if resources permit.
3.3.2. Sending Responses 3.3.2. Sending Responses
DNS servers MAY include the edns-tcp-keepalive option in responses A DNS server that receives a query sent using TCP transport that
sent using TCP transport to signal their expected idle timeout on a includes an OPT RR MAY include the edns-tcp-keepalive option in the
connection. Servers MUST specify the TIMEOUT value that is currently response to signal the expected idle timeout on a connection.
associated with the TCP session. It is reasonable for this value to Servers MUST specify the TIMEOUT value that is currently associated
change according to local resource constraints or in consideration of with the TCP session. It is reasonable for this value to change
according to local resource constraints or in consideration of
intermediary behaviour (for example TCP middleboxes or NATs). The intermediary behaviour (for example TCP middleboxes or NATs). The
DNS server SHOULD send a edns-tcp-keepalive option with a timeout of DNS server SHOULD send a edns-tcp-keepalive option with a timeout of
0 if it deems its local resources are too low to service more TCP 0 if it deems its local resources are too low to service more TCP
keepalive sessions. keepalive sessions, or if it wants clients to close currently open
connections.
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. Servers that implement keepalive imposed by the operating system. Servers that implement edns-tcp-
should also engage in TCP connection management by recycling existing keepalive should also engage in TCP connection management by
connections when appropriate, closing connections gracefully and recycling existing connections when appropriate, closing connections
managing request queues to enable fair use. 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 minimise idle time on existing sessions. successive DNS messages to minimise idle time on existing sessions.
This also allows, for example, clients with other candidate servers This also allows, for example, clients with other candidate servers
to query to establish new TCP sessions with different servers in 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 Based on TCP session resources servers may signal a TIMEOUT value of
0 to request clients to close connections as soon as possible. This 0 to request clients to close connections as soon as possible. This
is useful when server resources become very low or a denial-of- is useful when server resources become very low or a denial-of-
service attack is detected and further maximises the shifting of service attack is detected and further maximises the shifting of
TIME_WAIT state to well-behaved clients. TIME_WAIT state to well-behaved clients.
skipping to change at page 8, line 16 skipping to change at page 8, line 45
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. 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 keepalive. Should a non-keepalive-aware connections implement edns-tcp-keepalive. An intermediary that does
intermediary sit between a client and server that both support not implement edns-tcp-keepalive but sits between a client and server
keepalive a potential side effect will be an increased frequency of that both support edns-tcp-keepalive might close idle connections
the proxy closing idle client connections. unnecessarily.
5. Security Considerations 5. Security Considerations
The edns-tcp-keepalive 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 the resources used.
Servers could choose to monitor client behaviour with respect to the
edns-tcp-keepalive option to build up profiles of clients that do not
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]
This section needs more work. As usual.
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] | | [TBA] | 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. Andrews. Thanks to Duane Wessels for detailed review and the many
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, 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.
skipping to change at page 9, line 39 skipping to change at page 10, line 22
[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.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC
7320, July 2014. 7320, July 2014.
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 2014. dnsop-edns-chain-query (work in progress), March 2015.
[DNS-over-TLS]
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "TLS for DNS: Initiation and Performance
Considerations", draft-ietf-dprive-dns-over-tls-00 (work
in progress), September 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-02 (work in Requirements", draft-ietf-dnsop-5966bis-03 (work in
progress), July 2015. progress), September 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] [fragmentation-considered-poisonous]
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., Herzberg, A. and H. Shulman, "Fragmentation Considered
and P. Hoffman, "TLS for DNS: Initiation and Performance Poisonous", arXiv 1205.4011, May 2012.
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. Abridged Change History
An appropriate venue for discussion of this document is A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-03
dnsop@ietf.org.
A.2. Abridged Change History Clarified that a response to a query with any OPT RR may contain the
ends-tcp-keepalive option.
A.2.1. draft-ietf-dnsop-edns-tcp-keepalive-02 Corrected TIMEOUT length from 4 to 2 in the diagram.
Updated references, including name change of [STARTTLS] -> [DNS-over-
TLS] and adding reference for cache poisoning.
Updated wording in section on Intermediary Considerations.
Updated wording describing RRL.
Added paragraph to security section describing client behaviour
profiles.
Added wording to introduction on use case for stub/resolver/
authoritative.
A.1.2. 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 5 skipping to change at page 11, line 47
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.2.2. draft-ietf-dnsop-edns-tcp-keepalive-01 A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-01
Version bump with no changes Version bump with no changes
A.2.3. draft-ietf-dnsop-edns-tcp-keepalive-00 A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-00
Clarifications, working group adoption. Clarifications, working group adoption.
A.2.4. draft-wouters-edns-tcp-keepalive-01 A.1.5. 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.5. draft-wouters-edns-tcp-keepalive-00 A.1.6. 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. 38 change blocks. 
88 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/