Visual RFC.
ALL RFCs / RFC 7766
Read the RFC ↗

RFC 7766 / START HERE

DNS over TCP, before the details

DNS means Domain Name System; TCP means Transmission Control Protocol. This RFC specifies how DNS implementations use TCP.

DNS clients ask servers for records, such as a website’s address. TCP supplies a reliable, ordered byte stream. RFC 7766 explains how to split that stream into DNS messages and use a connection for several questions.

Start the guide See the 5 chapters ↓

The idea in one picture

  1. Ask several questions

  2. One TCP connection

  3. Match each reply

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

Large DNS answers need a dependable alternative to UDP datagrams. This RFC requires TCP support and makes reuse and pipelining practical; it is complementary to general DNS, DNSSEC and DNS over TLS.

A familiar example

Your resolver can ask about picnic.example. and tea.example. over one TCP connection without waiting between questions. If tea’s answer is ready first, its message ID matches it to the right question. Plain TCP adds no DNS encryption or authentication.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

DNS wireRFC 1035 · beginner overview ↗TCPRFC 9293 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. TCP is a first-class DNS transportDNS turns names into records. A resolver is a client that asks a DNS server for those records. Both ends need a working TCP path, not just UDP.
  2. Find message boundaries in a byte streamTCP delivers an ordered stream of bytes, not DNS-sized packets. A two-byte length prefix tells the receiver where each DNS message ends.
  3. Pipeline queries and match reordered repliesPipelining means sending another query before the earlier reply arrives. A fast second lookup may finish first, even though TCP preserves the bytes in each direction.
  4. Reuse connections without exhausting the serverOne persistent connection can carry many ordinary questions. Connection limits also need to allow for multiple real clients sharing one public address.
  5. Manage idleness and recover from closureAn idle session has no work left for that endpoint. Partial bytes and interrupted replies need careful handling so idle connections do not consume resources forever.
Start with chapter one →

This introduction explains RFC 7766 (2016). Read the original RFC ↗