< draft-wouters-edns-tcp-keepalive-00.txt   draft-wouters-edns-tcp-keepalive-01.txt >
Network Working Group P. Wouters Network Working Group P. Wouters
Internet-Draft Red Hat Internet-Draft Red Hat
Intended status: Standards Track J. Abley Intended status: Standards Track J. Abley
Expires: April 18, 2014 Dyn Inc. Expires: August 18, 2014 Dyn, Inc.
October 15, 2013 February 14, 2014
The edns-tcp-keepalive EDNS0 Option The edns-tcp-keepalive EDNS0 Option
draft-wouters-edns-tcp-keepalive-00 draft-wouters-edns-tcp-keepalive-01
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 are currently
limited in their use of the TCP transport as most implementations limited in their use of the TCP transport as RFC 5966 suggests
limit the TCP session to a single DNS query and answer, making use of closing idle TCP sessions "in the order of seconds", making use of
TCP only suitable as a fallback protocol for UDP. 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 clients and servers to signal their respective readiness
to conduct multiple DNS transactions over individual TCP sessions. to conduct multiple DNS transactions over individual TCP sessions.
This 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.
skipping to change at page 1, line 47 skipping to change at page 1, line 48
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 18, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 6 3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 9 Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 9
A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 9 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 9
A.2. Abridged Change History . . . . . . . . . . . . . . . . . 9 A.2. Abridged Change History . . . . . . . . . . . . . . . . . 9
A.2.1. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 9 A.2.1. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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]. Generally, DNS clients prefer to send queries UDP or TCP [RFC1035]. Historically, DNS clients used API's that only
over UDP, and fall back to TCP only if a query over UDP resulted in a facilitated sending and receiving a single query over either UDP or
truncated response (see [RFC1035] Section 4.1.1). A client that has TCP. New APIs and deployment of DNSSEC validating resolvers on hosts
resorted to TCP transport as a reaction to a truncated response from that in the past were using stub resolving only is increasing the DNS
a server typically closes the session after exchanging a single client base that prefer using long lived TCP connections. Long-lived
(request, response) DNS message pair, and continues with UDP TCP connections can result in lower request latency than the case
transport for subsequent queries. Although [RFC1035] specifies that where UDP transport is used and truncated responses are received,
a single TCP session may be used to exchange multiple DNS messages, since clients that have fallen back to TCP transport in response to a
in practice this is rarely seen. truncated response typically only uses the TCP session for a single
(request, response) pair, continuing with UDP transport for
subsequent queries.
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 6
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 truncacated 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
UDP truncation with fallback to TCP. the prevalence of truncated responses received over UDP with fallback
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 that those which are unlikely to be used for the
exchange of multiple DNS messages are closed promptly. exchange of multiple DNS messages are closed 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 for servers to better balance the use servers that provides a means to better balance the use of UDP and
of UDP and TCP transport, reducing the impact of problems associated TCP transport, reducing the impact of problems associated with UDP
with UDP whilst constraining the impact of TCP on response times and whilst constraining the impact of TCP on response times and server
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]. The
combination of these two EDNS extensions make it possible for hosts combination of these two EDNS extensions make it possible for hosts
on high-latency mobile networks to natively perform DNSSEC on high-latency mobile networks to natively perform DNSSEC
validation. validation.
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 conduct multiple DNS transactions over a single TCP willingness to keep an (idle) TCP session open for a certain amount
session. This specification does not distinguish between different of time to conduct future DNS transactions. This specification does
types of DNS client and server in the use of this option. not distinguish between different types of DNS client and server in
the use of this option.
3.1. Option Format 3.1. Option Format
The edns-tcp-keepalive option is encoded as follows: The edns-tcp-keepalive option is encoded as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
! OPTION-CODE ! OPTION-LENGTH ! ! OPTION-CODE ! OPTION-LENGTH !
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| 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 2;
TIMEOUT: a timeout value for the TCP connection specified by DNS TIMEOUT: a timeout value for the TCP connection, specified in
servers, specified in seconds, encoded in network byte order. DNS seconds, encoded in network byte order.
clients set this value to 0.
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 MAY include the edns-tcp-keepalive option in queries sent
using UDP transport to signal their general ability to use individual using UDP transport to signal their general ability to use individual
TCP sessions for multiple DNS transactions with a particular server. 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
that that specific TCP session be used for multiple DNS transactions. that that specific TCP session be used for multiple DNS transactions.
DNS Clients MUST specify a TIMEOUT value of zero. 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
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 MAY record the presence of the
option and the associated TIMEOUT value, and use that information as option and the associated TIMEOUT value, and use that information as
part of its server selection algorithm in the case where multiple part of its server selection algorithm in the case where multiple
candidate servers are available to service a particular query. 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
skipping to change at page 6, line 18 skipping to change at page 6, line 22
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 MAY record the presence of the option
for statistical purposes, but should not otherwise modify its usual for statistical purposes, but should not otherwise modify its usual
behaviour in sending a response. behaviour in sending a response.
A DNS server that receives a query that includes the edns-tcp- A DNS server that receives a query using TCP transport that includes
keepalive option MUST ignore the TIMEOUT value the edns-tcp-keepalive option SHOULD extend the timeout normally
associated with TCP sessions if resources permit, using the TIMEOUT
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 UDP transport to signal their general ability to use
individual TCP sessions for multiple DNS transactions with a individual TCP sessions for multiple DNS transactions with a
particular server. The TIMEOUT value should be indicative of what a particular server. The TIMEOUT value should be indicative of what a
client might expect if it was to open a TCP session with the server client might expect if it was to open a TCP session with the server
and receive a response with the edns-tcp-keepalive option present. and receive a response with the edns-tcp-keepalive option present.
The DNS server MAY omit including the edns-tcp-keepalive option if it The DNS server MAY omit including the edns-tcp-keepalive option if it
skipping to change at page 7, line 34 skipping to change at page 7, line 46
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 Successive DNS transactions between a client and server using UDP
transport may involve responses generated by different anycast nodes, transport may involve responses generated by different anycast nodes,
and the use of anycast in the implementation of a DNS server is and the use of anycast in the implementation of a DNS server is
effectively undetectable by the client. The edns-tcp-keepalive effectively undetectable by the client. The edns-tcp-keepalive
option SHOULD NOT be included in responses using UDP transport from option SHOULD NOT be included in responses using UDP transport from
servers provisioned using anycast unless all anycast server nodes are servers provisioned using anycast unless all anycast server nodes are
capable of processing the edns-tcp-keepalive option. The TIMEOUT capable of processing the edns-tcp-keepalive option.
values in UDP responses from anycast servers MUST be zero to indicate
that there is no useful value that can be specified.
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. Security Considerations
skipping to change at page 8, line 21 skipping to change at page 8, line 30
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 6. Acknowledgements
empty for now The authors acknowledge the contributions of Ray Bellis, Jinmei
TATUYA and Mark Andrews.
7. References 7. References
7.1. Normative References 7.1. Normative References
[CHAIN-QUERY] [CHAIN-QUERY]
Wouters, P., "TCP chain query requests in DNS", draft- Wouters, P., "chain Query requests in DNS", draft-wouters-
wouters-edns-tcp-chain-query (work in progress), October edns-chain-query (work in progress), February 2014.
2013.
[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.
[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, December 2006.
[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
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 7.2. Informative References
[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
skipping to change at page 9, line 31 skipping to change at page 9, line 44
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
 End of changes. 19 change blocks. 
41 lines changed or deleted 58 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/