DNS-over-TLS and DNS-over-HTTPS solved the encryption problem, but they inherited the performance characteristics of their underlying transports. DoT runs over TCP+TLS. DoH runs over TCP+TLS+HTTP/2. Both require a TCP handshake followed by a TLS handshake before the first DNS query can be sent — and both suffer from TCP’s head-of-line blocking problem.
DNS-over-QUIC promises to fix both issues. Built on the QUIC transport protocol (RFC 9000), DoQ combines the encryption guarantees of DoT with the performance properties that DNS actually needs: fast connection establishment, no head-of-line blocking, and seamless connection migration.
QUIC Protocol Basics
To understand DoQ, you need to understand QUIC. Originally developed by Google and standardized by the IETF in RFC 9000 (May 2021), QUIC is a general-purpose transport protocol built on UDP that integrates encryption at the transport layer.
What QUIC Replaces
Traditional encrypted connections require two sequential handshakes:
TCP: SYN → SYN-ACK → ACK (1 RTT)
TLS: ClientHello → ServerHello → Finished (1 RTT with TLS 1.3)
Total: 2 RTTs before data can flow
QUIC combines both into a single handshake:
QUIC: Initial → Handshake → Ready (1 RTT)
Total: 1 RTT before data can flow
For resumed connections (where the client has previously connected to the server), QUIC supports 0-RTT — sending encrypted data in the very first packet. This is particularly valuable for DNS, where clients frequently reconnect to the same resolver.
Key QUIC Properties
Encryption is mandatory. Unlike TCP, where TLS is optional, every QUIC connection is encrypted. There is no plaintext QUIC. This eliminates the “opportunistic vs. strict” debate that plagues DoT deployment.
Multiplexed streams without head-of-line blocking. QUIC supports multiple independent streams within a single connection. If one stream experiences packet loss, the other streams continue unaffected. In TCP, a single lost packet blocks all data on the connection until it’s retransmitted.
For DNS, this means multiple in-flight queries don’t interfere with each other. A slow or lost response to one query doesn’t delay responses to other queries on the same connection — a significant improvement over DoT, where TCP head-of-line blocking can introduce latency spikes.
Connection migration. QUIC connections are identified by connection IDs, not by the traditional 4-tuple (source IP, source port, destination IP, destination port). This means a QUIC connection survives network changes — switching from Wi-Fi to cellular, for example — without requiring a new handshake.
For mobile devices that frequently switch networks, connection migration eliminates the latency penalty of re-establishing TCP+TLS connections to the DNS resolver after every network transition.
Built on UDP. QUIC runs over UDP, which means it traverses NATs and firewalls that already allow UDP traffic. However, this also means it faces the same middlebox interference that sometimes affects UDP-based protocols.
How DoQ Works
DNS-over-QUIC is defined in RFC 9250 (May 2022). The protocol is refreshingly straightforward: each DNS query-response pair uses a separate QUIC stream.
Connection Establishment
The DoQ client connects to the server on a dedicated port — 853, the same port used by DoT. (The protocols are distinguished by whether the initial packet is a TCP SYN or a QUIC Initial packet.)
RFC 9250 specifies that DoQ uses the ALPN (Application-Layer Protocol Negotiation) token doq during the QUIC handshake. This allows a server to support both DoT and DoQ on the same port, distinguishing between them at the transport layer.
Query-Response Model
Client DoQ Server (port 853)
│ │
│──── QUIC Initial (1-RTT or 0-RTT) ──>│
│<─── QUIC Handshake ──────────────────│
│ │
│──── Stream 0: DNS Query A ──────────>│
│──── Stream 4: DNS Query B ──────────>│
│──── Stream 8: DNS Query C ──────────>│
│ │
│<─── Stream 4: DNS Response B ────────│ (responses arrive in any order)
│<─── Stream 0: DNS Response A ────────│
│<─── Stream 8: DNS Response C ────────│
└───────────────────────────────────────┘
Each DNS query is sent on a new QUIC stream. The client sends the DNS message (in the standard wire format, with the two-byte length prefix), and the server responds on the same stream. After the response is sent, the stream is closed.
This one-query-per-stream model has several advantages:
- No head-of-line blocking — each query is independent; a lost packet for Query A doesn’t delay Query B
- Natural multiplexing — no need for the HTTP/2 framing layer that DoH requires
- Clear lifecycle — each stream has an unambiguous start and end, simplifying error handling
0-RTT Queries
RFC 9250 supports 0-RTT data, allowing DNS queries to be sent in the very first QUIC packet on resumed connections. The server can begin processing the query immediately, returning a response potentially in a single round trip including the handshake.
However, 0-RTT data has a security caveat: it’s replayable. An attacker who captures the initial packet can replay it to the server, causing the query to be processed again. For DNS queries (which are idempotent read operations), this is generally acceptable — a replayed query just generates a duplicate response. RFC 9250 acknowledges this and allows 0-RTT for DNS queries while recommending that servers implement replay protection where practical.
How DoQ Improves on DoT and DoH
Latency Comparison
| Protocol | Initial Connection | Resumed Connection |
|---|---|---|
| Traditional DNS (UDP) | 0 RTT | 0 RTT |
| DoT (TCP+TLS 1.3) | 2 RTT | 1 RTT (TLS resumption) |
| DoH (TCP+TLS 1.3+HTTP/2) | 2 RTT | 1 RTT (TLS resumption) |
| DoQ (QUIC) | 1 RTT | 0 RTT |
DoQ’s 0-RTT resumption matches the latency of traditional plaintext DNS — encrypted queries with no additional round trips. This is the holy grail that DoT and DoH couldn’t achieve.
Head-of-Line Blocking
With DoT, all queries share a single TCP stream. If a packet carrying Response A is lost, the TCP layer halts delivery of all subsequent data — including Response B and Response C — until the lost packet is retransmitted. This is TCP head-of-line blocking, and it can add hundreds of milliseconds of delay to queries that have nothing to do with the lost packet.
DoH partially mitigates this through HTTP/2 stream multiplexing, but HTTP/2 still runs over TCP, so the underlying head-of-line blocking persists at the transport layer.
DoQ eliminates this entirely. Each query runs on an independent QUIC stream with independent loss recovery. Packet loss on one stream has zero impact on other streams.
Connection Migration
When a mobile device switches from Wi-Fi to cellular, TCP connections break — they’re identified by IP addresses, which change during the transition. The device must establish new TCP+TLS connections to the DNS resolver, adding latency to the first queries on the new network.
QUIC connections survive network changes transparently. The connection continues with no additional handshake, no latency spike, and no service interruption. For always-connected mobile devices, this is a meaningful improvement in user experience.
Protocol Design Decisions
RFC 9250 makes several noteworthy design choices:
No HTTP Layer
Unlike DoH, DoQ does not use HTTP. DNS messages are carried directly over QUIC streams, with just a two-byte length prefix (the same format as DNS over TCP). This eliminates the HTTP framing overhead and keeps the protocol simple.
The tradeoff is that DoQ doesn’t benefit from HTTP caching infrastructure, CDN routing, or the ability to hide within HTTPS traffic. DoQ is identifiable as DoQ — it uses a dedicated port and a distinct ALPN token.
Padding
RFC 9250 requires that implementations support padding DNS messages to mitigate traffic analysis attacks. Even though queries are encrypted, the size of a query can reveal the length of the domain name being looked up. Padding queries and responses to fixed sizes (or adding random padding) reduces this information leakage.
Session Resumption and 0-RTT
QUIC’s session resumption and 0-RTT mechanisms allow DoQ to maintain performance across connection restarts. When a device reconnects to a resolver it has previously used, the 0-RTT handshake allows encrypted DNS queries to flow immediately — performance equivalent to plaintext UDP.
Current Adoption Status
As of 2025, DoQ adoption is early but growing:
Resolver support:
- AdGuard DNS — one of the earliest DoQ adopters, supporting DoQ since 2020
- NextDNS — supports DoQ alongside DoH and DoT
- Cloudflare — experimental DoQ support
- Quad9 — DoQ support in testing
Client support:
- AdGuard apps (iOS, Android, macOS, Windows) — native DoQ support
- dnscrypt-proxy — supports DoQ as a client
- quiche (Cloudflare’s QUIC implementation) — provides DoQ library support
- Operating system-level support remains limited; no major OS has integrated DoQ natively yet
Standards progress:
- RFC 9250 was published as a Proposed Standard in May 2022
- IETF work continues on operational guidance and interoperability testing
The adoption trajectory mirrors early DoT: resolver support comes first, followed by client libraries, then application integration, and eventually OS-level support. DoQ is currently in the resolver/library phase.
Challenges
Middlebox interference. QUIC runs over UDP, and some corporate firewalls and middleboxes block or throttle non-DNS UDP traffic. While UDP port 853 may be permitted, some networks block all UDP traffic to unfamiliar ports, requiring fallback to DoT or DoH.
Implementation complexity. QUIC is a significantly more complex protocol than TCP. Implementing a full QUIC stack (or integrating a library like quiche or ngtcp2) is more work than adding TLS to an existing TCP implementation. This has slowed DoQ adoption compared to DoT.
Competing with established protocols. DoH and DoT have significant deployment momentum. Browser vendors have invested heavily in DoH; Android has invested heavily in DoT. DoQ needs to demonstrate clear, measurable benefits to justify the switching cost.
Port sharing with DoT. Both DoQ and DoT use port 853, which creates potential confusion. While the protocols are distinguishable at the transport layer (TCP vs. UDP), some network configurations may not handle this gracefully.
Key Takeaways
- DoQ carries DNS messages directly over QUIC streams — no HTTP layer, no TCP
- 1-RTT initial connections and 0-RTT resumption match plaintext DNS latency
- Independent QUIC streams eliminate head-of-line blocking between concurrent queries
- Connection migration keeps DNS working seamlessly through network transitions
- RFC 9250 (May 2022) defines the protocol; adoption is early but growing
- DoQ combines the transparency of DoT (dedicated port, identifiable) with the performance properties DNS actually needs