One Packet Out, One Packet Back.

Why UDP is the default

A DNS query is tiny, often under a hundred bytes, and it sits in front of every connection you make. TCP would spend three packets on a handshake before the question is even asked, then more to tear the connection down, and the server would have to hold state for every client in the meantime. UDP spends nothing: the resolver gets a datagram, sends a datagram back, and forgets you existed. For a service that answers billions of questions a day, that difference is the design.

The price of skipping the handshake is that nothing proves who sent a reply, which is the opening that spoofing and cache poisoning attacks use. The other price is more mundane: a datagram has to fit in one piece, so the size of an answer suddenly matters.

The 512-byte ceiling and EDNS0

The original 1987 specification capped a UDP answer at 512 bytes, a safe size for the networks of the time. It held for years, and then answers started growing: IPv6 addresses, more records per name, and above all DNSSEC, whose signatures can multiply the size of a response several times over.

Rather than break the packet format, EDNS0 extended it from the inside. A client adds a pseudo-record (OPT) to its query saying, in effect, “I can accept UDP answers up to this many bytes,” and the server can respond in kind. The same extension became the carrier for other per-query signals: the DNSSEC-OK flag that requests signatures, DNS cookies, and the client-subnet option that attaches a slice of your network address. Without EDNS0, modern DNS simply does not fit.

Advertising a huge buffer turned out to have its own problem. A UDP datagram larger than the path allows gets chopped into IP fragments, fragments are dropped by a lot of network equipment and are easier to tamper with, and the result was answers that silently never arrived. In 2020 the major resolver and server operators coordinated a change known as DNS Flag Day and settled on 1232 bytes as the default advertised size, small enough to avoid fragmentation on practically any path. Anything bigger takes the other road.

The TC bit: how DNS changes lanes

When an answer will not fit in the buffer the client advertised, the server does not squeeze or split it. It sends back a reply with the truncation flag (TC=1) set, which tells the client: the answer exists, but not this way. The client then opens a TCP connection to the same server on the same port 53, asks the identical question, and gets the full answer with no size limit, at the cost of the handshake it was trying to avoid.

This is why “DNS is UDP” is only mostly true, and why firewalls that block TCP port 53 on the theory that DNS never needs it break real lookups. TCP support is a required part of the protocol, not an optional extra, and it has one more traditional job: zone transfers, where one nameserver copies an entire zone from another and a single datagram was never going to be enough.

What encrypted DNS changes

Encrypted transports redraw this whole map. DNS over TLS and DNS over HTTPS run on TCP from the start, so the truncation dance disappears: any answer, however large, just streams through. The handshake cost that made TCP unattractive in 1987 is paid once and then amortized, because the encrypted connection stays open and carries query after query, and session resumption makes reconnecting cheap.

DNS over QUIC and DNS over HTTP/3 close the circle: they run over UDP again, but with encryption and reliability built into QUIC itself. A lost packet delays only its own query instead of everything behind it, and a resumed connection can send the first query with no waiting at all. Forty years later the answer to “TCP or UDP?” has become: UDP again, but this time with the handshake, the proof of who is answering, and no packet-size cliff.