Why do DNS, DHCP and NTP run over UDP rather than TCP, and what does each gain from that choice?

## The shape these three protocols share DNS lookups, DHCP address assignment and NTP time synchronisation have one thing in common: they are built from **small, self-contained requests and responses**. Each question fits in one datagram, each answer usually fits in one datagram, and if either is lost the client can simply ask again. For that shape, TCP's machinery costs more than it returns: - a **handshake** round trip before the question can be delivered, - **per-connection state** (a Transmission Control Block) on the server for every client, - a **teardown** exchange afterwards, - retransmission and in-order delivery that the application can provide more cheaply for a single message. ## DNS: one question, one answer, a server with many clients Over UDP, a lookup costs one round trip: query out, response back. Over a fresh TCP connection it costs two: the handshake, then the query and response. RFC 7766 names the penalty directly as "the added connection setup latency, generally equal to one RTT". A busy recursive or authoritative server also avoids holding connection state for every client it answers. Reliability is rebuilt in a few lines of client logic. RFC 1035 section 4.2.1 says that UDP queries "may be lost, and hence a retransmission strategy is required", and recommends trying other servers or addresses before repeating a query to the same one. DNS is **not UDP-only**, and saying so is part of a good answer: 1. RFC 1035 limits a DNS message carried over UDP to 512 bytes, not counting the IP and UDP headers. A longer response is truncated and the `TC` bit is set, and the client can retry over TCP. (The truncation and size-extension mechanics belong to the DNS transport topics.) 2. Zone transfers use TCP: RFC 1035 says "UDP is not acceptable for zone transfers". 3. RFC 7766 requires all general-purpose DNS implementations to support **both** UDP and TCP, relaxes RFC 1123's rule that a UDP query must be sent first, and says TCP "ought to be considered a valid alternative transport to UDP, not purely a retry option". ## DHCP: the client has no address yet A host joining a network has no IP address configured and does not know where the DHCP server is, so it has to **broadcast**. TCP cannot do that. RFC 9293 states that "TCP supports unicast delivery of data", and a SYN addressed to a broadcast or multicast address is ignored. A TCP connection is also identified by an address and port at each end, and the client does not yet have an address of its own. UDP carries broadcast and multicast traffic; RFC 8085 section 4 notes that multicast and broadcast transmission usually employ UDP. The DHCP message sequence itself belongs to the DHCP topic. ## NTP: a late sample is a bad sample NTP estimates the offset between a client's clock and a server's from timestamps taken as the request leaves and arrives and as the reply leaves and arrives. The estimate is only as good as the assumption that the network delay was about the same in both directions. A reply held back by a TCP retransmission, or queued behind a lost segment, carries timing that is stale and lopsided. Discarding that exchange and taking the next sample is better than recovering it. NTP's own filtering algorithms belong to the NTP topic; the transport lesson is that **timeliness beats completeness** here. ## Side by side | Protocol | Main reason for UDP | What the application rebuilds itself | |---|---|---| | DNS | One round trip instead of two; no per-client connection state on the server | Timeouts, retransmission, trying another server | | DHCP | The client has no address and must broadcast | Retransmitting its own requests | | NTP | A delayed timestamp is worse than a fresh one | Polling again and discarding poor samples | ## What an interviewer is listening for - The **handshake cost relative to the exchange**: one extra round trip doubles the latency of a one-round-trip lookup. - **Statelessness** on a server that talks to huge numbers of clients. - **Broadcast** as a hard requirement that TCP cannot meet. - The nuance that DNS uses TCP too, for truncated responses, zone transfers and, since RFC 7766, any query a resolver chooses to send that way.