DNS over UDP: Does Packet Loss Cause a Problem?

Short answer: Yes, a lost query or reply would stall name resolution if nothing else acted, but DNS deliberately places recovery in the application layer (the stub resolver) instead of in the transport layer, so the loss is handled without ever opening a TCP connection.

Why UDP is preferred anyway

• A lookup is normally one small request/response pair. Setting up TCP first (SYN, SYN-ACK, ACK) would add a full handshake plus teardown, roughly doubling the messages and adding 1-2 extra RTTs to every web access.
• DNS needs no long-lived stream, no ordering across messages, and each message is self-contained.
• UDP lets one name server answer thousands of clients concurrently with no per-client connection state.

How the loss is solved

1. Client retransmission with timeout (primary fix): every query is sent with a timer. If no reply arrives, the stub resolver retransmits the same query (typically after 1 s, 2 s, 4 s, ... up to 5 attempts) and finally returns SERVFAIL/time-out to the application. This is essentially stop-and-wait with timeout implemented by DNS itself.
2. Transaction ID + source-port matching: each query carries a random 16-bit ID (and is sent from an ephemeral port), so the client can match the eventual reply to the outstanding query and discard stray, duplicate or forged responses. Late duplicates are harmless because replies are idempotent.
3. TCP fallback for large responses: if an answer exceeds the message-size limit (512 bytes classically) the server sets the TC (truncation) bit and the resolver retries the same query over TCP; zone transfers (AXFR/IXFR) always use TCP. EDNS0 also allows larger UDP payloads.
4. Redundant name servers: each zone is served by at least two authoritative servers (and there are multiple root/TLD servers), so the query can simply be sent to another server.

Conclusion

Loss only costs one retransmission timeout of delay, not correctness. Reliability is recovered by application-level retries and ID matching, and by TCP whenever responses are large - so using UDP costs nothing in accuracy while saving connection setup on the critical path of every request.