RFC 5966

DNS Transport over TCP - Implementation Requirements

📅 published August 2010, from ietf

RFC 5966: DNS Transport over TCP - Implementation Requirements 💖

Okay bestie, this one is the RFC that says TCP is not optional for DNS. It's giving "you thought you could skip it? nope" 💅

Title block 🎀

  • Request for Comments: 5966
  • Title: DNS Transport over TCP - Implementation Requirements
  • Author: R. Bellis, Nominet UK
  • Date: August 2010
  • Category: Standards Track
  • Updates: 1035, 1123 (there's no Obsoletes line in the title block 🧚)
  • Series: Internet Engineering Task Force (IETF)
  • ISSN: 2070-1721

Abstract ✨

This one's short and sweet 🍓 It updates the requirements for supporting TCP as a transport protocol in DNS implementations.

Status of This Memo 📜

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF) 🦋 It represents the consensus of the IETF community, received public review, and has been approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5966.

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.  Terminology Used in This Document . . . . . . . . . . . . . . . 3
3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.  Transport Protocol Selection  . . . . . . . . . . . . . . . . . 4
5.  Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5
6.  Response Reordering . . . . . . . . . . . . . . . . . . . . . . 6
7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
  9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7

1. Introduction 🌸

Most DNS [RFC1034] transactions happen over UDP [RFC0768]. TCP [RFC0793] is always used for zone transfers, and it's often used for messages whose sizes go past the DNS protocol's original 512-byte limit. 👑

Section 6.1.3.2 of [RFC1123] says:

DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries.

But some implementors read that text as meaning TCP support is an optional feature of the DNS protocol. 💀 Not it.

Most DNS server operators already support TCP, and the default configuration for most software implementations is to support TCP too. The main audience for this document is the implementors whose lack of TCP support breaks interoperability and holds back new DNS features 😭

So this document updates the core DNS protocol specifications, and support for TCP is now a REQUIRED part of a full DNS protocol implementation. Main character energy ✨

This document makes no specific recommendations to operators of DNS servers, but it's worth noting that failure to support TCP (or blocking DNS over TCP at the network layer) may result in resolution failure and/or application-level timeouts. ⏰

2. Terminology Used in This Document 📖

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 [RFC2119]. 🎀

3. Discussion 💬

Without EDNS0 (Extension Mechanisms for DNS 0) (see below), the normal behaviour of any DNS server that needs to send a UDP response larger than the 512-byte limit is to truncate the response so it fits within that limit and then set the TC flag in the response header. When the client gets a response like that, it takes the TC flag as a sign that it should retry over TCP instead. 🦋

RFC 1123 also says:

... 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.

Existing deployments of DNS Security (DNSSEC) [RFC4033] have shown that truncation at the 512-byte boundary is now commonplace. For example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost invariably larger than 512 bytes. 🙈

Since the original core DNS specs were written, the Extension Mechanisms for DNS (EDNS0 [RFC2671]) have arrived. These extensions can indicate that the client is ready to receive UDP responses bigger than 512 bytes. An EDNS0-compatible server that gets a request from an EDNS0-compatible client may send UDP packets up to that client's announced buffer size without truncation. ✨

BUT, transporting UDP packets that exceed the path MTU causes IP packet fragmentation, which has been found to be unreliable in some circumstances. Many firewalls routinely block fragmented IP packets, and some don't implement the algorithms needed to reassemble them. Worse still, some network devices deliberately refuse to handle DNS packets containing EDNS0 options. Other issues about UDP transport and packet size are discussed in [RFC5625]. 😤

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. 💀

The future that RFC 1123 anticipated has arrived, and the only standardised UDP-based mechanism that may have solved the packet size issue has been found inadequate. Not ideal, bestie. 😭

4. Transport Protocol Selection 🚦

All general-purpose DNS implementations MUST support both UDP and TCP transport.

  • Authoritative server implementations MUST support TCP so that they do not limit the size of responses to what fits in a single UDP packet.
  • Recursive server (or forwarder) implementations MUST support TCP so that they do not prevent large responses from a TCP-capable server from reaching its TCP-capable clients.
  • Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP, since doing otherwise would limit their interoperability with their own clients and with upstream servers. 🫶

Stub resolver implementations MAY omit support for TCP when they're specifically designed for deployment in restricted environments where truncation can never occur or where truncated DNS responses are acceptable. 🧚

On choosing when to use UDP or TCP, Section 6.1.3.2 of RFC 1123 also says:

... a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first.

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 sent over UDP (with or without EDNS0), or for other operational reasons, in particular if it already has an open TCP connection to the server. 🔥

5. Connection Handling 🔌

Section 4.2.2 of [RFC1035] says:

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. In particular, the server should allow the SOA and AXFR request sequence (which begins a refresh operation) to be made on a single connection. Since the server would be unable to answer queries anyway, a unilateral close or reset may be used instead of a graceful close.

Other, more modern protocols (e.g., HTTP [RFC2616]) support persistent TCP connections, and operational experience has shown that long timeouts can easily cause resource exhaustion and poor response under heavy load. Deliberately opening many connections and leaving them dormant can easily create a "denial-of-service" attack. 🚨

So it is RECOMMENDED that the default application-level idle period be of the order of seconds, but no particular value is specified. In practise, the idle period may vary dynamically, and servers MAY allow dormant connections to remain open for longer periods as resources permit. ⏳

To lower the risk of unintentional server overload, DNS clients MUST take care to minimise the number of concurrent TCP connections made to any individual server. Similarly, servers MAY impose limits on the number of concurrent TCP connections being handled for any particular client. 🛡️

Further recommendations for tuning TCP stacks to allow higher throughput or better resiliency against denial-of-service attacks are outside the scope of this document. 🙅‍♀️

6. Response Reordering 🔀

RFC 1035 is ambiguous about whether TCP queries may be reordered. The only relevant text is in Section 4.2.1, which is about UDP:

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.

For the avoidance of future doubt, this requirement is clarified. Client resolvers MUST be able to process responses that arrive in a different order from the one in which the requests were sent, regardless of the transport protocol in use. 💅

7. Security Considerations 🔐

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 (DoS) attacks. 😰

Although there is a higher risk of such attacks against TCP-enabled servers, techniques for mitigating DoS attacks at the network level have improved substantially since DNS was first designed. 📈

At the time of writing, the vast majority of Top Level Domain (TLD) authority servers and all of the root name servers support TCP, and the author knows of no evidence that TCP-based DoS attacks against existing DNS infrastructure are commonplace. 🌐

That said, readers are advised to familiarise themselves with [CPNI-TCP]. 📚

Operators of recursive servers should ensure that they only accept connections from expected clients, and do not accept them from unknown sources. For UDP traffic, this helps protect against reflector attacks [RFC5358]. For TCP traffic, it prevents an unknown client from exhausting the server's limits on the number of concurrent connections. This part is serious, so please don't skip it 🙏

8. Acknowledgements 🫶

The author would like to thank the document reviewers from the DNSEXT Working Group, and in particular George Barwood, Alex Bligh, Alfred Hoenes, Fernando Gont, Olafur Gudmondsson, Jim Reid, Paul Vixie, and Nicholas Weaver. Iconic squad 🌈✨

9. References 📚

(Part 1 ends here 🧚 Part 2 picks up with the reference entries.)

9.1. Normative References 📚✨

okay so these are the docs you NEED to have read before any of this makes sense, bestie 🫶 they're the load-bearing ones 💅

  • [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
  • [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
  • [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.

9.2. Informative References 🧚💜

these ones are more like extra reading, lowkey still super worth it 🍓

  • [CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf>.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
  • [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
  • [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008.
  • [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.

Author's Address 🎀

this is who wrote it, and yes, the whole thing was ray being an absolute legend 👑

Ray Bellis
Nominet UK
Edmund Halley Road
Oxford  OX4 4DQ
United Kingdom

Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI:   http://www.nominet.org.uk/

and that's a wrap, bestie!! 🌈💖✨

📦 where this page comes from