draft-ietf-dnsop-edns-tcp-keepalive-06.txt   rfc7828.txt 
dnsop P. Wouters Internet Engineering Task Force (IETF) P. Wouters
Internet-Draft Red Hat Request for Comments: 7828 Red Hat
Intended status: Standards Track J. Abley Category: Standards Track J. Abley
Expires: August 25, 2016 Dyn, Inc. ISSN: 2070-1721 Dyn, Inc.
S. Dickinson S. Dickinson
Sinodun Sinodun
R. Bellis R. Bellis
ISC ISC
February 22, 2016 April 2016
The edns-tcp-keepalive EDNS0 Option The edns-tcp-keepalive EDNS0 Option
draft-ietf-dnsop-edns-tcp-keepalive-06
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 retries and servers typically use idle timeouts on the order only for retries and servers typically use idle timeouts on the order
of seconds. of seconds.
This document defines an EDNS0 option ("edns-tcp-keepalive") that This document defines an EDNS0 option ("edns-tcp-keepalive") that
allows DNS servers to signal a variable idle timeout. This allows DNS servers to signal a variable idle timeout. This
signalling encourages the use of long-lived TCP connections by signalling encourages the use of long-lived TCP connections by
allowing the state associated with TCP transport to be managed allowing the state associated with TCP transport to be managed
effectively with minimal impact on the DNS transaction time. effectively with minimal impact on the DNS transaction time.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 25, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7828.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 5
3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5 3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
A.1. Abridged Change History . . . . . . . . . . . . . . . . . 11
A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-06 . . . . . . . 11
A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-05 . . . . . . . 11
A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-04 . . . . . . . 12
A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-03 . . . . . . . 12
A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 12
A.1.6. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 13
A.1.7. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 13
A.1.8. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 13
A.1.9. 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 APIs 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.
This is because clients that retry over TCP following a truncated UDP This is because clients that retry over TCP following a truncated UDP
response typically only use the TCP session for a single (request, response typically only use the TCP session for a single (request,
response) pair, continuing with UDP transport for subsequent queries. response) pair, continuing with UDP transport for subsequent queries.
The use of TCP transport requires state to be retained on DNS The use of TCP transport requires state to be retained on DNS
servers. If a server is to perform adequately with a significant servers. If a server is to perform adequately with a significant
query load received over TCP, it must manage its available resources query load received over TCP, it must manage its available resources
to ensure that all established TCP sessions are well-used, and idle to ensure that all established TCP sessions are well-used, and idle
connections are closed after an appropriate amount of time. connections are closed after an appropriate amount of time.
UDP transport is stateless, and hence presents a much lower resource UDP transport is stateless, and hence presents a much lower resource
burden on a busy DNS server than TCP. An exchange of DNS messages burden on a busy DNS server than TCP. An exchange of DNS messages
over UDP can also be completed in a single round trip between over UDP can also be completed in a single round trip between
communicating hosts, resulting in optimally-short transaction times. communicating hosts, resulting in optimally short transaction times.
UDP transport is not without its risks, however. UDP transport is not without its risks, however.
A single-datagram exchange over UDP between two hosts can be A single-datagram exchange over UDP between two hosts can be
exploited to enable a reflection attack on a third party. Response exploited to enable a reflection attack on a third party. Response
Rate Limiting [RRL] is designed to help mitigate such attacks against Rate Limiting [RRL] is designed to help mitigate such attacks against
authoritative-only servers. One feature of RRL is to let some amount authoritative-only servers. One feature of RRL is to let some amount
of responses "slip" through the rate limiter. These are returned of responses "slip" through the rate limiter. These are returned
with the TC (truncation) bit set, which causes legitimate clients to with the TC (truncation) bit set, which causes legitimate clients to
re-query using TCP transport. resend the same 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 [fragmentation-considered-poisonous]. cache poisoning attacks [fragmentation-considered-poisonous].
TCP transport is less susceptible to the risks of fragmentation and TCP transport is less susceptible to the risks of fragmentation and
reflection attacks. However, TCP transport for DNS as currently reflection attacks. However, TCP transport for DNS as currently
deployed has expensive setup overhead, compared to using UDP (when no deployed has expensive setup overhead, compared to using UDP (when no
retry is required). retry is required).
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 1x RTT to 2x
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 therefore the overhead of the initial TCP handshake is established; therefore, the overhead of the initial TCP handshake is
minimised when the resulting session is used to exchange multiple DNS minimised when the resulting session is used to exchange multiple DNS
message pairs over a single session. The extra RTT time for session message pairs over a single session. The extra RTT time for session
setup can be represented as the equation (1 + N)/N, where N setup can be represented as the equation (1 + N)/N, where N
represents the number of DNS message pairs that utilize the session represents the number of DNS message pairs that utilize the session
and the result approaches unity as N increases. and the result approaches unity as N increases.
With increased deployment of DNSSEC and new RRtypes containing With increased deployment of DNSSEC and new RR types 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 retries the prevalence of truncated responses received over UDP with retries
over TCP. The overhead for a DNS transaction over UDP truncated due over TCP. The overhead for a DNS transaction over UDP truncated due
to RRL is 3x RTT, higher than the overhead imposed on the same to RRL is 3x RTT higher than the overhead imposed on the same
transaction initiated over TCP. transaction initiated over TCP.
This document proposes a signalling mechanism between DNS clients and This document proposes a signalling mechanism between DNS clients and
servers that encourages the use of long-lived TCP connections by servers that encourages the use of long-lived TCP connections by
allowing the state associated with TCP transport to be managed allowing the state associated with TCP transport to be managed
effectively with minimal impact on the DNS transaction time. effectively with minimal impact on the DNS transaction time.
This mechanism will be of benefit both for stub-resolver and This mechanism will be of benefit for both stub-resolver and
resolver-authoritative TCP connections. In the latter case the resolver-authoritative TCP connections. In the latter case, the
persistent nature of the TCP connection can provide improved defence persistent nature of the TCP connection can provide improved defence
against attacks including DDoS. against attacks including DDoS.
The reduced overhead of this extension adds up significantly when The reduced overhead of this extension adds up significantly when
combined with other EDNS0 extensions, such as [CHAIN-QUERY] and combined with other EDNS0 extensions, such as [CHAIN-QUERY] and
[DNS-over-TLS]. For example, the combination of these EDNS0 [DNS-over-TLS]. For example, the combination of these EDNS0
extensions make it possible for hosts on high-latency mobile networks extensions make it possible for hosts on high-latency mobile networks
to natively and efficiently perform DNSSEC validation and encrypt to natively and efficiently perform DNSSEC validation and encrypt
queries. queries.
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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 to conduct future DNS willingness to keep an idle TCP session open to conduct future DNS
transactions, with the idle timeout being specified by the server. transactions, with the idle timeout being specified by the server.
This specification does not distinguish between different types of This specification does not distinguish between different types of
DNS client and server in the use of this option. DNS client and server in the use of this option.
[DRAFT-5966bis] defines an 'idle' DNS-over-TCP session from both the [RFC7766] defines an 'idle DNS-over-TCP session' from both the client
client and server perspective. The idle timeout described here and server perspective. The idle timeout described here begins when
begins when the idle condition is met per that definition and should the idle condition is met per that definition and should be reset
be reset when that condition is lifted i.e. when a client sends a when that condition is lifted, i.e., when a client sends a message or
message or when a server receives a message on an idle connection. when a server receives a message on an idle connection.
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,
TBD1 11
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
skipping to change at page 6, line 31 skipping to change at page 6, line 31
of the connection before the timeout expires. 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 [RFC7766]. This holds true even if a
previous edns-keepalive-option exchange occurred on the existing TCP previous edns-keepalive-option exchange occurred on the existing TCP
connection. connection.
3.3. Use by DNS Servers 3.3. Use by DNS Servers
3.3.1. Receiving Queries 3.3.1. Receiving Queries
A DNS server that receives a query using UDP transport that includes A DNS server that receives a query using UDP transport that includes
the edns-tcp-keepalive option MUST ignore the option. the edns-tcp-keepalive option MUST ignore the option.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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
A DNS server that receives a query sent using TCP transport that A DNS server that receives a query sent using TCP transport that
includes an OPT RR (with or without the edns-tcp-keepalive option) includes an OPT RR (with or without the edns-tcp-keepalive option)
MAY include the edns-tcp-keepalive option in the response to signal MAY include the edns-tcp-keepalive option in the response to signal
the expected idle timeout on a connection. Servers MUST specify the the expected idle timeout on a connection. Servers MUST specify the
TIMEOUT value that is currently associated with the TCP session. It TIMEOUT value that is currently associated with the TCP session. It
is reasonable for this value to change according to local resource is reasonable for this value to change according to local resource
constraints. The DNS server SHOULD send a edns-tcp-keepalive option constraints. The DNS server SHOULD send an edns-tcp-keepalive option
with a timeout of 0 if it deems its local resources are too low to with a timeout of 0 if it deems its local resources are too low to
service more TCP keepalive sessions, or if it wants clients to close service more TCP keepalive sessions or if it wants clients to close
currently open connections. 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 that
which will limit the extent to which TCP sessions can persist. will limit the extent to which TCP sessions can persist. Effective
Effective limits for the number of active sessions that can be limits for the number of active sessions that can be maintained on
maintained on individual clients and servers should be established, individual clients and servers should be established, either as
either as configuration options or by interrogation of process limits configuration options or by interrogation of process limits imposed
imposed by the operating system. Servers that implement edns-tcp- by the operating system. Servers that implement edns-tcp-keepalive
keepalive should also engage in TCP connection management by should also engage in TCP connection management by recycling existing
recycling existing connections when appropriate, closing connections connections when appropriate, closing connections gracefully, and
gracefully and managing request queues to enable fair use. 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.
However it should be noted that RCF6891 states: However, it should be noted that RFC 6891 states:
Lack of presence of an OPT record in a request MUST be taken as an 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 indication that the requestor does not implement any part of this
specification and that the responder MUST NOT include an OPT specification and that the responder MUST NOT include an OPT
record in its response. record in its response.
Since servers must be faithful to this specification even on a Since servers must be faithful to this specification even on a
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]). [RFC7230]).
If a client includes the edns-tcp-keepalive option in the first If a client includes the edns-tcp-keepalive option in the first
query, it SHOULD include an EDNS0 OPT RR periodically in any further query, it SHOULD include an EDNS0 OPT RR periodically in any further
messages it sends during the TCP session. This will increase the messages it sends during the TCP session. This will increase the
chance of the client being notified should the server modify the chance of the client being notified should the server modify the
timeout associated with a session. The algorithm for choosing when 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 to do this is out of scope of this document and is left up to the
implementor and/or operator. 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
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].
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. It might be possible for sessions are expected to be longer lived. It might be possible for
anycast servers to avoid disruption due to topology changes by making anycast servers to avoid disruption due to topology changes by making
use of TCP multipath [RFC6824] to anchor the server side of the TCP use of TCP multipath [RFC6824] to anchor the server side of the TCP
connection to an unambiguously-unicast address. connection to an unambiguously unicast address.
4. Intermediary Considerations 4. Intermediary Considerations
It is RECOMMENDED that DNS intermediaries which terminate TCP It is RECOMMENDED that DNS intermediaries that 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 long-lived sessions in a quick burst. When a DNS large numbers of long-lived sessions in a quick burst. When a DNS
Server detects abusive behaviour, it SHOULD immediately close the TCP server detects abusive behaviour, it SHOULD immediately close the TCP
connection and free the resources used. connection and free the resources used.
Servers could choose to monitor client behaviour with respect to the Servers could choose to monitor client behaviour with respect to the
edns-tcp-keepalive option to build up profiles of clients that do not edns-tcp-keepalive option to build up profiles of clients that do not
honour the specified timeout. honour the specified timeout.
Readers are advised to familiarise themselves with the security Readers are advised to familiarise themselves with the security
considerations outlined in [DRAFT-5966bis] considerations outlined in [RFC7766]
6. IANA Considerations 6. IANA Considerations
The IANA is directed to assign an EDNS0 option code for the edns-tcp- IANA has assigned an EDNS0 option code for the edns-tcp-keepalive
keepalive option from the DNS EDNS0 Option Codes (OPT) registry as option from the "DNS EDNS0 Option Codes (OPT)" registry as follows:
follows:
+-------+--------------------+----------+-----------------+
| Value | Name | Status | Reference |
+-------+--------------------+----------+-----------------+
| TBD1 | edns-tcp-keepalive | Standard | [This document] |
+-------+--------------------+----------+-----------------+
7. Acknowledgements
The authors acknowledge the contributions of Jinmei TATUYA and Mark
Andrews. Thanks to Duane Wessels for detailed review and the many
others who contributed to the mailing list discussion.
8. References +-------+--------------------+----------+-----------+
| Value | Name | Status | Reference |
+-------+--------------------+----------+-----------+
| 11 | edns-tcp-keepalive | Standard | RFC 7828 |
+-------+--------------------+----------+-----------+
8.1. Normative References 7. References
[DRAFT-5966bis] 7.1. Normative References
Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", draft-ietf-dnsop-5966bis (work in
progress), January 2016.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 10, line 24 skipping to change at page 10, line 10
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <http://www.rfc-editor.org/info/rfc4786>. December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[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, for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013, DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>. <http://www.rfc-editor.org/info/rfc6891>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
RFC 7320, DOI 10.17487/RFC7320, July 2014, Protocol (HTTP/1.1): Message Syntax and Routing",
<http://www.rfc-editor.org/info/rfc7320>. RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
8.2. Informative References [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<http://www.rfc-editor.org/info/rfc7766>.
7.2. Informative References
[CHAIN-QUERY] [CHAIN-QUERY]
Wouters, P., "Chain Query requests in DNS", draft-ietf- Wouters, P., "Chain Query requests in DNS", Work in
dnsop-edns-chain-query (work in progress), January 2016. Progress, draft-ietf-dnsop-edns-chain-query-07, February
2016.
[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, "Specification for DNS over TLS", Work in
Considerations", draft-ietf-dprive-dns-over-tls (work in Progress, draft-ietf-dprive-dns-over-tls-09, March 2016.
progress), January 2016.
[fragmentation-considered-poisonous] [fragmentation-considered-poisonous]
Herzberg, A. and H. Shulman, "Fragmentation Considered Herzberg, A. and H. Shulman, "Fragmentation Considered
Poisonous", arXiv 1205.4011, May 2012, Poisonous", arXiv: 1205.4011, May 2012,
<http://arxiv.org/abs/1205.4011>. <http://arxiv.org/abs/1205.4011>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>. <http://www.rfc-editor.org/info/rfc6824>.
[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
(DNS RRL)", ISC-TN 2012-1-Draft1, April 2012, (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012,
<http://ss.vix.su/~vixie/isc-tn-2012-1.txt>. <https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>.
Appendix A. Editors' Notes
A.1. Abridged Change History
[Note to RFC Editor: please remove this section prior to
publication.]
A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-06
Introduction: Moved paragraph 8 to paragraph 2 for readability.
Introduction: clarified that TCP has expensive setup overhead
compared to UDP.
Section 3: Add explicit description of the idle timeout.
Section 3.3.2, 1st para: make explicit that query may or may not
contain edns-tcp-keepalive option.
Section 3.3.2: remove discussion of intermediary behaviour.
A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-05
Reword Abstract and paragraph 9 in Introduction to remove discussion
on balancing UDP/TCP and talk about encouraging use of long-lived TCP
sessions.
Section 3.2.2: should -> SHOULD
Changed draft-ietf-dnsop-5966bis to be a normative reference,
therefore adding a dependancy on publication of that as RFC.
Reword sentence referring to RFC6824 since it is informational.
Update IANA option to Standard.
Remove last sentence from 1st paragraph of introduction.
Reword paragraph 6 in Introduction, merge paragraph 7 and 8.
Reword Section 3, first sentence to clarify the timeout is specified
by the server.
Correct missing URIs in 2 references.
Clarify statement in Section 3.2.2 as how clients should handle
updating the timeout when receiving a response.
Reworded first paragraph of Introduction discussing TCP vs (UDP +
retry over TCP). Changed 'fallback' to 'retry' in 2 places.
A.1.3. 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.4. draft-ietf-dnsop-edns-tcp-keepalive-03
Clarified that a response to a query with any OPT RR may contain the
ends-tcp-keepalive option.
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.5. 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.1.6. draft-ietf-dnsop-edns-tcp-keepalive-01
Version bump with no changes
A.1.7. draft-ietf-dnsop-edns-tcp-keepalive-00
Clarifications, working group adoption.
A.1.8. draft-wouters-edns-tcp-keepalive-01
Also allow clients to specify KEEPALIVE timeout values, clarify
motivation of document.
A.1.9. draft-wouters-edns-tcp-keepalive-00 Acknowledgements
Initial draft. The authors acknowledge the contributions of Jinmei TATUYA and Mark
Andrews. Thanks to Duane Wessels for detailed review and the many
others who contributed to the mailing list discussion.
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 103-186 Albert Street
London, ON N6C 2C2 London, ON N6A 1M1
Canada Canada
Phone: +1 519 670 9327 Phone: +1 519 670 9327
Email: jabley@dyn.com Email: jabley@dyn.com
Sara Dickinson Sara Dickinson
Sinodun Internet Technologies Sinodun Internet Technologies
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
UK United Kingdom
Email: sara@sinodun.com Email: sara@sinodun.com
URI: http://sinodun.com URI: http://sinodun.com
Ray Bellis Ray Bellis
Internet Systems Consortium, Inc Internet Systems Consortium, Inc
950 Charter Street 950 Charter Street
Redwood City CA 94063 Redwood City, CA 94063
USA United States
Phone: +1 650 423 1200 Phone: +1 650 423 1200
Email: ray@isc.org Email: ray@isc.org
URI: http://www.isc.org URI: http://www.isc.org
 End of changes. 51 change blocks. 
246 lines changed or deleted 98 lines changed or added

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