One document matched: draft-ietf-dnsext-dns-tcp-requirements-00.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-00"
updates="1123, 1035">
<?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 some 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>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>Some implementors have taken the <xref target="RFC1123"/> text quoted above to mean
that TCP support is truly optional for typical DNS operation.</t>
<t>However, whilst RFC 1123 predates the current RFC 2119 terminology document it uses
exactly the same text:<list>
<t><vspace/>SHOULD - This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a particular
item, but the full implications must be understood and carefully weighed
before choosing a different course.</t>
</list></t>
<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 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 is now here, 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> On a case by case basis, authoritative DNS server operators MAY elect to disable DNS
transport over TCP if all of the conditions below are satisfied:</t>
<t>
<list style="symbols">
<t>the server is authoritative only</t>
<t>the server does not support AXFR</t>
<t>the server does not support DNSSEC</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 will not 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> Otherwise, all DNS implementations MUST support TCP transport.</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> This requirement is no longer mandatory. 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, 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. With modern high performance networks 2 to 4 seconds should be sufficient
to allow significant numbers (i.e. thousands) of concurrent dormant connections
without impacting service performance.</t>
<t>Servers MAY allow idle 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>
</section>
<section title="Response re-ordering" anchor="re-ordering">
<t>[Potential text to be added regarding whether TCP responses can come back in a
different order to requests. I'm not aware whether this is specified anywhere]</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-00<list>
<t>Initial draft</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:49:38 |