One document matched: draft-ietf-dnsop-edns-tcp-keepalive-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc1035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc4033 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY rfc4786 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4786.xml'>
<!ENTITY rfc5966 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5966.xml'>
<!ENTITY rfc6824 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6824.xml'>
<!ENTITY rfc6891 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6891.xml'>
<!ENTITY rfc7320 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7320.xml'>
]>
<rfc category="std" ipr="trust200902"
docName="draft-ietf-dnsop-edns-tcp-keepalive-02">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>The edns-tcp-keepalive EDNS0 Option</title>
<author initials='P.' surname="Wouters" fullname='Paul Wouters'>
<organization>Red Hat</organization>
<address>
<email>pwouters@redhat.com</email>
</address>
</author>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization>Dyn, Inc.</organization>
<address>
<postal>
<street>470 Moore Street</street>
<city>London</city>
<region>ON</region>
<code>N6C 2C2</code>
<country>Canada</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>jabley@dyn.com</email>
</address>
</author>
<author fullname="Sara Dickinson" initials="S." surname="Dickinson">
<organization abbrev="Sinodun">Sinodun Internet Technologies</organization>
<address>
<postal>
<street>Magdalen Centre</street>
<street>Oxford Science Park</street>
<city>Oxford</city>
<region/>
<code>OX4 4GA</code>
<country>UK</country>
</postal>
<email>sara@sinodun.com</email>
<uri>http://sinodun.com</uri>
</address>
</author>
<author fullname="Ray Bellis" initials="R." surname="Bellis">
<organization abbrev="ISC">Internet Systems Consortium, Inc</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<code>CA 94063</code>
<country>USA</country>
</postal>
<phone>+1 650 423 1200</phone>
<email>ray@isc.org</email>
<uri>http://www.isc.org</uri>
</address>
</author>
<date month="July" day="3" year="2015" />
<area>ops</area>
<workgroup>dnsop</workgroup>
<abstract>
<t>DNS messages between clients and servers may be received
over either UDP or TCP. UDP transport involves keeping less
state on a busy server, but can cause truncation and retries
over TCP. Additionally, UDP can be exploited for reflection
attacks. Using TCP would reduce retransmits and amplification.
However, clients commonly use TCP only for fallback and servers
typically use idle timeouts on the order of seconds.</t>
<t>This document defines an EDNS0 option ("edns-tcp-keepalive")
that allows DNS servers to signal a variable idle timeout.
This signalling facilitates a better balance of
UDP and TCP transport between individual clients and servers,
reducing the impact of problems associated with UDP transport and
allowing the state associated with TCP transport to be managed
effectively with minimal impact on the DNS transaction time.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>DNS messages between clients and servers may be received
over either UDP or TCP <xref target="RFC1035"/>. Historically,
DNS clients used API's that only facilitated sending and receiving
a single query over either UDP or TCP. New APIs and deployment
of DNSSEC validating resolvers on hosts that in the past were
using stub resolving only is increasing the DNS client base that
prefer using long lived TCP connections. Long-lived TCP connections
can result in lower request latency than the case where UDP
transport is used and truncated responses are received, since
clients that have fallen back to TCP transport in response to a
truncated response typically only uses the TCP session for a
single (request, response) pair, continuing with UDP transport
for subsequent queries. Clients wishing to use
other stream-based transport protocols for DNS would also benefit
from the set-up amortisation afforded by long lived connections.</t>
<t>UDP transport is stateless, and hence presents a much
lower resource 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 communicating hosts, resulting
in optimally-short transaction times. UDP transport is not
without its risks, however.</t>
<t>A single-datagram exchange over UDP between two hosts
can be exploited to enable a reflection attack on a third
party. Mitigation of such attacks on authoritative-only
servers is possible using an approach known as Response
Rate-Limiting <xref target="RRL"/>, an approach designed
to minimise the frequency at which legitimate responses are
discarded by truncating responses that appear to be motivated
by an attacker, forcing legitimate clients to re-query using
TCP transport.</t>
<t><xref target="RFC1035"/> specified a maximum DNS message
size over UDP transport of 512 bytes. Deployment of DNSSEC
<xref target="RFC4033"/> and other protocols subsequently
increased the observed frequency at which responses exceed
this limit. EDNS0 <xref target="RFC6891"/> allows DNS
messages larger than 512 bytes to be exchanged over UDP,
with a corresponding increased incidence of fragmentation.
Fragmentation is known to be problematic in general, and
has also been implicated in increasing the risk of cache
poisoning attacks.</t>
<t>The use of TCP transport does not suffer from the risks
of fragmentation nor reflection attacks. However, TCP
transport as currently deployed has expensive overhead.</t>
<t>The overhead of the three-way TCP handshake for a single
DNS transaction is substantial, increasing the transaction
time for a 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 established, however, and the overall impact of
the TCP setup handshake when the resulting session is used
to exchange N DNS message pairs over a single session, (1
+ N)/N, approaches unity as N increases.</t>
<t>(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.)</t>
<t>With increased deployment of DNSSEC and new RRtypes containing
application specific cryptographic material, there is an increase
in the prevalence of truncated responses received over UDP with
fallback to TCP.</t>
<t>The use of TCP transport requires considerably more state
to be retained on DNS 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 those that remain
idle for long periods are closed promptly.</t>
<t>This document proposes a signalling mechanism between DNS
clients and servers that provides a means to
better balance the use of UDP and TCP transport, reducing
the impact of problems associated with UDP whilst constraining
the impact of TCP on response times and server resources
to a manageable level.</t>
<t>The reduced overhead of this extension adds up significantly
when combined with other edns extensions, such as
<xref target="CHAIN-QUERY"/> and <xref target="STARTTLS"/>. For example,
the combination of
these EDNS extensions make it possible for hosts on
high-latency mobile networks to natively perform DNSSEC validation and encrypt queries.
</t>
</section>
<section title="Requirements Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
</section>
<section title="The edns-tcp-keepalive Option" anchor="overview">
<t>This document specifies a new <xref target="RFC6891">EDNS0</xref>
option, edns-tcp-keepalive, which can be used by DNS clients and
servers to signal a willingness to keep an idle TCP session open
for a certain amount of time to conduct future DNS transactions.
This specification does not distinguish between different types
of DNS client and server in the use of this option.</t>
<t>
<vspace blankLines="12"/>
</t>
<section title="Option Format" anchor="format">
<t>The edns-tcp-keepalive option is encoded as follows:</t>
<figure><artwork align="left"><![CDATA[
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
+-------------------------------+-------------------------------+
! OPTION-CODE ! OPTION-LENGTH !
+-------------------------------+-------------------------------+
| TIMEOUT |
+---------------------------------------------------------------+
]]></artwork></figure>
<t>where:
<list style="hanging">
<t hangText="OPTION-CODE: ">the EDNS0 option code
assigned to edns-tcp-keepalive, [TBD]</t>
<t hangText="OPTION-LENGTH: ">the value 0 if the TIMEOUT is omitted, the value 2 if it
is present;</t>
<t hangText="TIMEOUT: ">an idle timeout value for the TCP connection, specified in units
of 100 milliseconds, encoded in network byte order.</t>
</list>
</t>
</section>
<section title="Use by DNS Clients">
<section title="Sending Queries">
<t>DNS clients MUST NOT include the edns-tcp-keepalive option
in queries sent using UDP transport.</t>
<t>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 keep the connection open when idle.</t>
<t>Clients MUST specify a OPTION-LENGTH of 0 and omit the TIMEOUT value.</t>
</section>
<section title="Receiving Responses">
<t>A DNS client that receives a response using UDP transport
that includes the edns-tcp-keepalive option MUST ignore the
option.</t>
<t>A DNS client that receives a response using TCP transport
that includes the edns-tcp-keepalive option MAY keep the
existing TCP session open when it is idle. It SHOULD honour the
timeout and initiate close
of the connection before the timeout expires.</t>
<t>A DNS client that receives a response that includes the edns-tcp-keepalive option
with a TIMEOUT value of 0 should send no more queries on that connection and initiate
closing the connection as soon as it has received all outstanding responses.</t>
<t> A DNS client that sent a query containing the edns-keepalive-option
but receives a response that does not contain the edns-keepalive-option should assume the
server does not support keepalive and behave following the guidance in <xref target="DRAFT-5966bis"/>.
This holds true even if a previous edns-keepalive-option exchange occurred on
the existing TCP connection.</t>
</section>
</section>
<section title="Use by DNS Servers">
<section title="Receiving Queries">
<t>A DNS server that receives a query using UDP transport
that includes the edns-tcp-keepalive option MUST ignore the option.</t>
<t>A DNS server that receives a query using TCP transport that includes
the edns-tcp-keepalive option MAY modify the local idle timeout
associated with that TCP session if resources permit.</t>
</section>
<section title="Sending Responses">
<t>DNS servers MAY include the edns-tcp-keepalive option
in responses sent using TCP transport to signal their
expected idle timeout on a connection. Servers MUST specify the TIMEOUT value
that is currently associated with the TCP session. It is
reasonable for this value to change according to local
resource constraints or in consideration of intermediary behaviour (for example TCP
middleboxes or NATs). The 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 keepalive sessions.</t>
</section>
</section>
<section title="TCP Session Management">
<t>Both DNS clients and servers are subject to resource
constraints which will limit the extent to which TCP
sessions can persist. Effective limits for the number of
active sessions that can be maintained on individual
clients and servers should be established, either as
configuration options or by interrogation of process
limits imposed by the operating system. Servers
that implement keepalive should also engage in TCP connection
management by recycling existing connections when appropriate, closing connections gracefully
and managing request queues to enable fair use.</t>
<t>In the event that there is greater demand for TCP sessions
than can be accommodated, servers may reduce
the TIMEOUT value signalled in successive DNS messages
to minimise idle time on existing sessions. This also allows,
for example, clients with other candidate servers to query
to establish new TCP sessions with different servers in
expectation that an existing session is likely to be
closed, or to fall back to UDP.</t>
<t>Based on TCP session resources servers may signal a
TIMEOUT value of 0 to request clients to close
connections as soon as possible. This is useful when server resources
become very low or a
denial-of-service attack is detected and further maximises the shifting of
TIME_WAIT state to well-behaved clients. </t>
<t>However it should be noted that RCF6891 states:
<list><t>Lack of presence of an OPT record in a request MUST be taken as an
indication that the requestor does not implement any part of this
specification and that the responder MUST NOT include an OPT record
in its response.</t></list>
Since servers must be faithful to this specification even on a persistent TCP connection it
means that (following the initial exchange of timeouts) a server may not be presented with
the opportunity to signal a change in the idle timeout associated with a connection if the
client does not send any further requests containing EDNS0 OPT RRs. This limitation makes
persistent connection handling via an initial idle timeout signal more attractive than a
mechanism that establishes default persistence and then uses a connection close signal (in
a similar manner to HTTP 1.1 <xref target="RFC7320"/>).</t>
<t>DNS clients and servers MAY close a TCP session at any
time in order to manage local resource constraints. The
algorithm by which clients and servers rank active TCP
sessions in order to determine which to close is not
specified in this document.</t>
</section>
<section title="Non-Clean Paths">
<t>Many paths between DNS clients and servers suffer from
poor hygiene, limiting the free flow of DNS messages that
include particular EDNS0 options, or messages that exceed
a particular size. A fallback strategy similar to that
described in <xref target="RFC6891"/> section 6.2.2 SHOULD
be employed to avoid persistent interference due to
non-clean paths.</t>
</section>
<section title="Anycast Considerations">
<t>DNS servers of various types are commonly deployed using
anycast <xref target="RFC4786"/>.</t>
<t>Changes in network topology between clients and anycast
servers may cause disruption to TCP sessions making use
of edns-tcp-keepalive more often than with TCP sessions
that omit it, since the TCP sessions are expected to be
longer-lived. Anycast servers MAY make use of TCP multipath
<xref target="RFC6824"/> to anchor the server side of the
TCP connection to an unambiguously-unicast address in
order to avoid disruption due to topology changes.</t>
</section>
</section>
<section title="Intermediary Considerations">
<t>It is RECOMMENDED that DNS intermediaries which terminate TCP connections
implement keepalive. Should a
non-keepalive-aware intermediary sit between a client and server that both support
keepalive a potential side effect will be an increased frequency
of the proxy closing idle client connections.</t>
</section>
<section title="Security Considerations">
<t>The edns-tcp-keep-alive option can potentially be abused
to request large numbers of sessions in a quick burst. When
a Nameserver detects abusive behaviour, it SHOULD immediately
close the TCP connection and free all buffers used.</t>
<t>Readers are advised to familiarise themselves with the security
considerations outlined in <xref target="DRAFT-5966bis"/></t>
<t>This section needs more work. As usual.</t>
</section>
<section title="IANA Considerations">
<t>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 follows:</t>
<texttable>
<ttcol>Value</ttcol>
<ttcol>Name</ttcol>
<ttcol>Status</ttcol>
<ttcol>Reference</ttcol>
<c>[TBA]</c>
<c>edns-tcp-keepalive</c>
<c>Optional</c>
<c>[This document]</c>
</texttable>
</section>
<section title="Acknowledgements">
<t>The authors acknowledge the contributions of Jinmei TATUYA and Mark Andrews.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc1035;
&rfc2119;
&rfc4033;
&rfc4786;
&rfc5966;
&rfc6824;
&rfc6891;
&rfc7320;
</references>
<references title="Informative References">
<reference anchor="RRL">
<front>
<title>DNS Response Rate Limiting (DNS RRL)</title>
<author initials="P." surname="Vixie" fullname="Paul Vixie">
<organization>ISC</organization>
<address>
<email>vixie@isc.org</email>
</address>
</author>
<author initials="V." surname="Schryver" fullname="Vernon Schryver">
<organization>Rhyolite</organization>
<address>
<email>vjs@rhyolite.com</email>
</address>
</author>
<date year="2012" month="April"/>
</front>
<seriesInfo name="ISC-TN" value="2012-1-Draft1"/>
<format type="TXT" target="http://ss.vix.su/~vixie/isc-tn-2012-1.txt"/>
</reference>
<reference anchor='CHAIN-QUERY'>
<front>
<title>Chain Query requests in DNS</title>
<author initials='P' surname='Wouters' fullname='P. Wouters'>
<organization>Red Hat</organization>
</author>
<date month='October' day='27' year='2014' />
<abstract><t>
This document defines an EDNS0 extension that can be used by a DNSSEC
enabled Recursive Nameserver configured as a forwarder to send a
single DNS query requesting to receive a complete validation path
along with the regular DNS answer, without the need to rapid-fire
many UDP requests in an attempt to attain a low latency.
</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-edns-chain-query' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dnsop-edns-chain-query-01.txt' />
</reference>
<reference anchor='STARTTLS'>
<front>
<title>TLS for DNS: Initiation and Performance Considerations</title>
<author initials='Z' surname='Hu' fullname='Z. Hu'>
<organization>USC/Information Sciences Institute</organization>
</author>
<author initials='L' surname='Zhu' fullname='L. Zhu'>
<organization>USC/Information Sciences Institute</organization>
</author>
<author initials='J' surname='Heidemann' fullname='J. Hiedemann'>
<organization>USC/Information Sciences Institute</organization>
</author>
<author initials='A' surname='Mankin' fullname='A. Mankin'>
<organization>Verisign Labs</organization>
</author>
<author initials='D' surname='Wessels' fullname='D. Wessels'>
<organization>Verisign Labs</organization>
</author>
<author initials='P' surname='Hoffman' fullname='P. Hoffman'>
<organization>VPN Consortium</organization>
</author>
<date month='May' day='5' year='2015' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dprive-start-tls-for-dns-02' />
<format type='TXT'
target='https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-02' />
</reference>
<reference anchor='DRAFT-5966bis'>
<front>
<title>DNS Transport over TCP - Implementation Requirements</title>
<author initials='J' surname='Dickinson' fullname='J. Dickinson'>
<organization>Sinodun Internet Technologies</organization>
</author>
<author initials='S' surname='Dickinson' fullname='S. Dickinson'>
<organization>Sinodun Internet Technologies</organization>
</author>
<author initials='R' surname='Bellis' fullname='R. Bellis'>
<organization>ISC</organization>
</author>
<author initials='A' surname='Mankin' fullname='A. Mankin'>
<organization>Verisign Labs</organization>
</author>
<author initials='D' surname='Wessels' fullname='D. Wessels'>
<organization>Verisign Labs</organization>
</author>
<date month='July' day='?' year='2015' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-5966bis-02' />
<format type='TXT'
target='https://tools.ietf.org/html/draft-ietf-dnsop-5966bis-02' />
</reference>
</references>
<section title="Editors' Notes">
<section title="Venue">
<t>An appropriate venue for discussion of this document is
dnsop@ietf.org.</t>
</section>
<section title="Abridged Change History">
<section title="draft-ietf-dnsop-edns-tcp-keepalive-02">
<t>Changed timeout value to idle timeout and re-phrased document around this.</t>
<t>Changed units of timeout to 100ms to allow values less than 1 second.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Added more detail on server side requirements when supporting keepalive in terms
of resource and connection management.</t>
<t>Added discussion of EDNS0 per-message limitation and implications of this.</t>
<t>Added reference to STARTTLS draft and RFC7320.</t>
</section>
<section title="draft-ietf-dnsop-edns-tcp-keepalive-01">
<t>Version bump with no changes</t>
</section>
<section title="draft-ietf-dnsop-edns-tcp-keepalive-00">
<t>Clarifications, working group adoption.</t>
</section>
<section title="draft-wouters-edns-tcp-keepalive-01">
<t>Also allow clients to specify KEEPALIVE timeout values, clarify motivation of document.</t>
</section>
<section title="draft-wouters-edns-tcp-keepalive-00">
<t>Initial draft.</t>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 14:51:43 |