Find message boundaries in a byte stream
02TCP delivers an ordered stream of bytes, not DNS-sized packets. A two-byte length prefix tells the receiver where each DNS message ends.
A later read completes the first query and contains the whole second frame. Deliver the two messages separately, in stream order, with no leftover bytes.
Source for this drawing: RFC 7766 · Read RFC section 8 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Count message bytes, not TCP reads.
- The two-octet length prefix counts the DNS message only, excluding the prefix itself (RFC 1035 §4.2.2). Octet means eight-bit byte.
- Clients and servers SHOULD pass the length prefix and its message to TCP together, for example in one write. This does not guarantee one network segment or one read.
- Servers MUST NOT close merely because the first read lacks a complete DNS message. Buffer incomplete bytes and apply appropriate timeouts; multiple complete messages can share a read.
The drawing uses real fictional query encodings: picnic.example. IN A has 32 message bytes; tea.example. IN AAAA has 29. IN is the Internet class; A requests an IPv4 address and AAAA an IPv6 address. Byte counts include the 12-byte header and question fields. Schematic widths are not packet proportions. This is DNS framing, not TLS records. The teaching decoder is bounded test code, not a production DNS parser.
Read the RFC section ↗