One document matched: draft-ietf-dnsext-dns-tcp-requirements-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc792 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml'>
<!ENTITY rfc793 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml'>
<!ENTITY rfc1035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc1123 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1123.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2616 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY rfc2671 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2671.xml'>
<!ENTITY rfc4033 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY rfc5155 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5155.xml'>
<!ENTITY rfc5358 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5358.xml'>
<!ENTITY rfc5452 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5452.xml'>
<!ENTITY rfc5625 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5625.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-ietf-dnsext-dns-tcp-requirements-01"
updates="1035, 1123">
<?rfc toc='yes' ?>
<?rfc tocompact='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<?rfc sortrefs='yes' ?>
<?rfc symrefs='yes' ?>
<front>
<title>DNS Transport over TCP</title>
<author initials="R.P." surname="Bellis" fullname="Ray Bellis">
<organization>Nominet UK</organization>
<address>
<postal>
<street>Edmund Halley Road</street>
<city>Oxford</city>
<code>OX4 4DQ</code>
<country>United Kingdom</country>
</postal>
<phone>+44 1865 332211</phone>
<email>ray.bellis@nominet.org.uk</email>
<uri>http://www.nominet.org.uk/</uri>
</address>
</author>
<date year="2009"/>
<area>Internet Area</area>
<workgroup>DNSEXT</workgroup>
<keyword>DNS</keyword>
<keyword>TCP/IP</keyword>
<abstract>
<t> This document updates the requirements for the support of the TCP protocol for the
transport of DNS traffic.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t> Most <xref target="RFC1035">DNS</xref> transactions take place over the <xref
target="RFC0792">UDP</xref> protocol. The <xref target="RFC0793">TCP</xref>
protocol is used for zone transfers and is supported by many implementations for the
transfer of other packets which exceed the protocol's original 512 byte packet-size
limit.</t>
<t> Section 6.1.3.2 of <xref target="RFC1123"/> states: <list>
<t><vspace/>DNS resolvers and recursive servers MUST support UDP, and SHOULD
support TCP, for sending (non-zone-transfer) queries.</t>
</list>
</t>
<t>However, some implementors have taken the text quoted above to mean that TCP support
is truly optional for typical DNS operation.</t>
<t>This document normatively updates the core DNS protocol specifications such that
(except in very limited circumstances) support for the TCP protocol is henceforth
REQUIRED.</t>
</section>
<section anchor="terminology" title="Terminology used in this document">
<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="Discussion">
<t> In the absence of EDNS0 (see below) the normal behaviour of any DNS server needing
to send a UDP response that exceeds that 512 byte limit is for the server to
truncate the response at the 512 byte limit and set the TC flag in the response
header. When the client receives such a response it takes the TC flag as notice that
it should retry over TCP instead.</t>
<t> RFC 1123 also says: <list>
<t><vspace/>... it is also clear that some new DNS record types defined in the
future will contain information exceeding the 512 byte limit that applies to
UDP, and hence will require TCP. Thus, resolvers and name servers should
implement TCP services as a backup to UDP today, with the knowledge that
they will require the TCP service in the future.</t>
</list>
</t>
<t> Existing deployments of <xref target="RFC4033">DNSSEC</xref> have shown that
truncation at the 512 byte boundary is now commonplace. For example an NXDOMAIN
(RCODE == 3) response from a DNSSEC signed zone using <xref target="RFC5155"
>NSEC3</xref> is almost invariably longer than 512 bytes.</t>
<t> Since the original core specifications for DNS were written, the Extension
Mechanisms for DNS (<xref target="RFC2671">EDNS0</xref>) have been introduced. These
extensions can be used to indicate that the client is prepared to receive UDP
responses longer than 512 bytes. An EDNS0 compatible server receiving a request from
an EDNS0 compatible client may send UDP packets up to that client's announced buffer
size without truncation.</t>
<t> However, transport of UDP packets which exceed the size of the path MTU has been
found to be unreliable in some circumstances because of IP packet fragmentation.
Many firewalls routinely block fragmented IP packets, and some implementations lack
the software logic necessary to reassemble a fragmented datagram. Worse still, some
devices deliberately refuse to handle DNS packets containing EDNS0 options. Other
issues relating to UDP transport and packet size are discussed in <xref
target="RFC5625"/>.</t>
<t>The MTU most commonly found in the core of the Internet is around 1500 bytes, and
even that limit is routinely exceeded by DNSSEC signed responses. </t>
<t> The future that was anticipated in RFC 1123 has arrived, and the only standardised
mechanism which may have resolved the packet size issue has been found inadequate.</t>
</section>
<section title="Transport Protocol Selection" anchor="selection">
<t> All DNS implementations MUST support both UDP and TCP transport protocols, except as
set out below.</t>
<t> On a case by case basis, authoritative DNS server operators MAY elect to disable DNS
transport over TCP if all of the following conditions are satisfied:</t>
<t>
<list style="symbols">
<t>the server is authoritative only</t>
<t>the server does not support AXFR</t>
<t>all requests and responses are guaranteed to be <= 512 bytes</t>
</list>
</t>
<t> A general purpose stub resolver implementation (e.g. an operating system's DNS
resolution library) MUST support TCP since to do otherwise would limit its
interoperability with its own clients and with upstream servers. </t>
<t> A proprietary stub resolver implementation MAY omit support for TCP if it is
operating in an environment where truncation can never occur, or if it is prepared
to accept a DNS lookup failure should truncation occur.</t>
<t> A recursive resolver or forwarder MUST support TCP so that it does not prevent long
responses from a TCP-capable server from reaching its TCP-capable clients.</t>
<t> Regarding the choice of when to use UDP or TCP, RFC 1123 says:<list>
<t><vspace/>... a DNS resolver or server that is sending a non-zone-transfer
query MUST send a UDP query first.</t>
</list></t>
<t> That requirement is hereby relaxed. A resolver SHOULD send a UDP query first, but
MAY elect to send a TCP query instead if it has good reason to expect the response
would be truncated if it were sent over UDP (with or without EDNS0) or for other
operational reasons.</t>
</section>
<section title="Dormant Connection Handling" anchor="timeouts">
<t> Section 4.2.2 of <xref target="RFC1035"/> says:<list>
<t><vspace/>If the server needs to close a dormant connection to reclaim
resources, it should wait until the connection has been idle for a period on
the order of two minutes.</t>
</list></t>
<t> Other more modern protocols (e.g. <xref target="RFC2616">HTTP</xref>) have support
for persistent TCP connections and operational experience has shown that long
timeouts can easily cause resource exhaustion and poor response under heavy load.
Intentionally opening many connections and leaving them dormant can trivially create
a "denial of service" attack.</t>
<t> This document therefore RECOMMENDS that the idle period should be of the order of
TBD seconds.</t>
<t> Servers MAY allow dormant connections to remain open for longer periods, but for the
avoidance of doubt persistent DNS connections should generally be considered to be
as much for the server's benefit as for the client's. Therefore if the server needs
to unilaterally close a dormant TCP connection it MUST be free to do so whenever
required.</t>
<t> Further recommendations for the tuning of TCP parameters to allow higher throughput
or improved resiliency against denial of service attacks are (currently) outside the
scope of this document.</t>
</section>
<section title="Response re-ordering" anchor="re-ordering">
<t> RFC 1035 is ambiguous on the question of whether TCP queries may be re-ordered - the
only relevant text is in Section 4.2.1 which relates to UDP:<list>
<t><vspace/> Queries or their responses may be reordered by the network, or by
processing in name servers, so resolvers should not depend on them being
returned in order.</t>
</list></t>
<t> For the avoidance of future doubt, this requirement is clarified. Client resolvers
MUST be able to process responses which arrive in a different order to that in which
the requests were sent, regardless of the transport protocol in use.</t>
<t/>
</section>
<section title="Security Considerations" anchor="security">
<!-- <section title="Spoofing resistance" anchor="spoofing">
<t> It should be noted that TCP traffic is substantially harder to spoof than UDP
traffic. Use of TCP can make DNS significantly <xref target="RFC5452">more
resilient</xref> against forged answers.</t>
</section> -->
<!-- <section title="Denial of Service Attacks" anchor="dos"> -->
<t> Some DNS server operators have expressed concern that wider use of DNS over TCP will
expose them to a higher risk of "denial of service" attacks.</t>
<t> Many large authoritative DNS operators including all but one of the root servers and
the vast majority of TLDs already support TCP and attacks against them are
infrequent and very rarely successful.</t>
<t> Operators of recursive servers should ensure that they only accept connections from
expected clients, and do not accept them from unknown sources. In the case of UDP
traffic this will protect against <xref target="RFC5358">reflector attacks</xref>
and in the case of TCP traffic it will prevent an unknown client from exhausting the
server's limits on the number of concurrent connections.</t>
<!-- </section> -->
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document requests no IANA actions.</t>
</section>
<!-- <section title="Acknowledgements"> </section> -->
</middle>
<back>
<references title="Normative References"> &rfc792; &rfc793; &rfc1035;
&rfc1123; &rfc2119; &rfc2671; </references>
<references title="Informative References"> &rfc2616; &rfc4033; &rfc5155;
&rfc5358; <!-- &rfc5452; --> &rfc5625; </references>
<section title="Change Log" anchor="changelog">
<t>NB: to be removed by the RFC Editor before publication.</t>
<t>draft-ietf-dnsext-dns-tcp-requirements-01<list>
<t>Addition of response ordering section</t>
<t>Various minor editorial changes from WG reviewers</t>
</list>
</t>
<t>draft-ietf-dnsext-dns-tcp-requirements-00<list>
<t>Initial draft</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:32:05 |