DNS Transport Protocols

DNS started with UDP, and UDP is still king

DNS was born on UDP port 53. A query goes out as a single UDP datagram; a response comes back as a single datagram. No handshake. No connection state. No overhead. This is the original DNS transport, and it still carries the vast majority of DNS traffic between resolvers and authoritative servers.

UDP’s appeal for DNS is straightforward: a DNS query and response are typically small enough to fit in a single packet, and the overhead of establishing a TCP connection (a minimum of two additional round trips for the handshake and teardown) would add unacceptable latency to a protocol where every millisecond matters. A resolver handling millions of queries per second cannot afford to maintain TCP connections to every authoritative server it contacts.

But UDP has costs. It provides no encryption — queries travel in plaintext, visible to every network device between client and resolver. It provides no authentication — any device on the network path can forge a response. And it has a size constraint: without EDNS, responses are limited to 512 bytes; with EDNS, they’re limited to the advertised buffer size (typically 1232 bytes post-Flag Day 2020).

TCP: the reliable fallback

DNS has supported TCP on port 53 since RFC 1035. Originally, TCP was specified for two scenarios: zone transfers (AXFR/IXFR) between primary and secondary nameservers, and retries when a UDP response was truncated (TC flag set).

RFC 7766 (2016) elevated TCP from “fallback” to “first-class transport.” It required all DNS implementations to support TCP and allowed clients to send queries over TCP as the initial transport, not just as a retry mechanism. This was essential because:

• DNSSEC responses routinely exceed the 1232-byte EDNS buffer
• Some firewalls and middleboxes drop large UDP packets
• TCP provides reliable delivery, eliminating silent packet loss

TCP connection reuse (RFC 7766) allows multiple DNS queries and responses over a single TCP connection, amortizing the handshake cost. A resolver can open one TCP connection to an authoritative server and pipeline multiple queries through it.

TCP Fast Open (RFC 7413) reduces TCP latency by allowing data in the initial SYN packet, eliminating one round trip for subsequent connections to the same server. Support in DNS is specified in RFC 7858.

Despite these improvements, TCP remains a minority transport for stub-to-resolver traffic (roughly 5–10% of queries) and even less common for resolver-to-authoritative traffic. The overhead — both in latency and server-side connection state — keeps UDP dominant for routine queries.

DNS over TLS (DoT)

DNS over TLS, defined in RFC 7858 (2016), wraps DNS queries in a TLS session on a dedicated port 853. The resolver authenticates the server using its TLS certificate, and all query/response data is encrypted.

Client                              Resolver (port 853)
  |                                     |
  |--- TCP SYN ----------------------> |
  |<-- TCP SYN-ACK ------------------- |
  |--- TLS ClientHello -------------> |
  |<-- TLS ServerHello + Cert -------- |
  |--- TLS Finished ----------------> |  (connection established)
  |                                     |
  |--- DNS Query (encrypted) -------> |
  |<-- DNS Response (encrypted) ------ |
  |--- DNS Query (encrypted) -------> |  (connection reuse)
  |<-- DNS Response (encrypted) ------ |

Advantages:

• Full encryption prevents eavesdropping on queries
• Server authentication prevents man-in-the-middle attacks
• Connection reuse amortizes the TLS handshake cost
• Simple to implement — standard TLS over TCP

Disadvantages:

• Dedicated port 853 is easily blocked by firewalls and censors
• TLS handshake adds 1–2 round trips of latency on the first query
• Head-of-line blocking: a lost TCP packet delays all subsequent queries on the connection
• Server-side state overhead: each client connection consumes memory

DoT is the default encrypted DNS transport on Android 9+ (Private DNS feature). It’s widely supported by major public resolvers and is the most common encrypted DNS protocol between resolvers and clients today.

DNS over HTTPS (DoH)

DNS over HTTPS, defined in RFC 8484 (2018), sends DNS queries as HTTP requests over standard HTTPS on port 443. Because it uses the same port as regular web traffic, DoH queries are indistinguishable from normal HTTPS connections to network observers.

A DoH query can be sent as either:

• HTTP GET with the DNS query encoded in base64url as a query parameter
• HTTP POST with the DNS wire format in the request body

The content type is application/dns-message.

Advantages:

• Unblockable without blocking all HTTPS traffic — port 443 cannot be selectively filtered
• Benefits from HTTP/2 multiplexing (multiple queries over one connection without head-of-line blocking at the HTTP layer)
• Can traverse HTTP proxies and CDN infrastructure
• Browser integration is natural — browsers already speak HTTPS

Disadvantages:

• Higher overhead than DoT — HTTP framing adds bytes to every query
• More complex to implement (requires an HTTP stack)
• Controversial: bypasses enterprise and parental DNS filtering by routing queries through the browser rather than the operating system’s resolver
• Still subject to TCP head-of-line blocking at the transport layer

DoH is supported in Firefox (enabled by default in the US, using Cloudflare), Chrome (enabled by default if the system resolver supports it), Edge, and Safari. The browser-native support makes DoH the encrypted DNS protocol with the largest end-user footprint.

The controversy around DoH is real. By moving DNS resolution into the browser, DoH can bypass enterprise security policies, parental controls, and split-horizon DNS configurations that rely on the operating system’s resolver. Network administrators who use DNS filtering to block malware or enforce acceptable-use policies may find their controls circumvented when browsers send queries directly to Cloudflare or Google.

DNS over QUIC (DoQ)

DNS over QUIC, defined in RFC 9250 (2022), uses the QUIC transport protocol on UDP port 853. QUIC provides encryption, authentication, and multiplexing — with a critical advantage over TCP-based transports: no head-of-line blocking.

In TCP, if a single packet is lost, all subsequent data on the connection is delayed until the lost packet is retransmitted. This is “head-of-line blocking.” For DNS, where each query is independent, this means a lost packet for one query delays the response for an unrelated query sharing the same connection.

QUIC solves this with independent streams. Each DNS query gets its own stream within the QUIC connection. A lost packet for one stream does not affect other streams.

Client                              Resolver (UDP port 853)
  |                                     |
  |--- QUIC Initial (includes TLS) --> |
  |<-- QUIC Handshake + 0-RTT -------- |  (1 RTT to establish)
  |                                     |
  |--- DNS Query (stream 0) ---------> |
  |--- DNS Query (stream 4) ---------> |  (concurrent, independent)
  |<-- DNS Response (stream 0) ------- |
  |<-- DNS Response (stream 4) ------- |

Advantages:

• Zero head-of-line blocking between queries
• 1-RTT connection establishment (vs. 2-3 RTT for TCP+TLS)
• 0-RTT resumption for repeat connections
• Built-in encryption (TLS 1.3 is mandatory in QUIC)
• Connection migration — survives IP address changes (important for mobile devices)

Disadvantages:

• Newest protocol — less widely deployed and tested
• UDP-based, which some corporate firewalls block
• Shares port 853 with DoT, requiring ALPN negotiation to differentiate

Cloudflare’s 1.1.1.1 was among the first resolvers to support DoQ. Adoption is early but growing, particularly among privacy-focused resolvers and mobile applications where connection migration is valuable.

Comparing the transports

Transport	Port	Encrypted	Standard	Head-of-Line Blocking	Censorship Resistant
UDP	53	No	RFC 1035	N/A (single packet)	No
TCP	53	No	RFC 7766	Yes	No
DoT	853/TCP	Yes	RFC 7858	Yes	Low (port 853 blockable)
DoH	443/TCP	Yes	RFC 8484	Partial (HTTP/2 helps)	High (same as HTTPS)
DoQ	853/UDP	Yes	RFC 9250	No	Medium

The path forward

The DNS transport landscape is stratifying. Between resolvers and authoritative servers, plain UDP remains dominant — encryption at this layer adds latency without clear privacy benefits, since the resolver already knows the query. Between clients and resolvers, encrypted transports are growing rapidly, driven by browser defaults and mobile OS integration.

The fundamental shift is that DNS privacy is moving from “opt-in for the technically savvy” to “on by default for everyone.” When Firefox enables DoH for all US users, or Android uses DoT by default, hundreds of millions of people gain encrypted DNS without changing a setting or understanding what DNS is.

What hasn’t changed is the protocol inside the encryption. Whether a DNS message travels over UDP, TCP, TLS, HTTPS, or QUIC, the wire format is the same 12-byte header, the same question section, the same resource records. The transport changes how the message gets there; the message itself has been the same since 1987.