DNS over QUIC can look like a small variation on DNS over TLS. Both encrypt DNS, both use port 853 by default, and both can authenticate the resolver. The important difference sits below DNS itself.
DoQ replaces the TCP transport used by DoT with QUIC. That changes how concurrent DNS transactions share a connection, how packet loss affects other queries, and how the transport recovers when packets disappear. The privacy goal stays close to DoT, but the transport behavior doesn’t.
DoQ maps DNS directly onto QUIC
DNS over QUIC, usually shortened to DoQ, is defined in RFC 9250. QUIC is a secure transport built over UDP. It incorporates TLS 1.3 for cryptographic protection while providing its own streams, congestion control, and loss recovery.
A DoQ client establishes a QUIC connection to a DNS server and can send many DNS transactions over that connection. Each DNS query, together with every response message it produces (a zone transfer can produce several), uses one client-initiated bidirectional QUIC stream. The client sends its single query and closes its side, and the server closes its side after the final response.
That per-transaction stream model is one of DoQ’s defining choices. The message content keeps the normal DNS wire format, with two adjustments at the edges. Like DNS over TCP and DoT, each message carries a two-octet length prefix, and RFC 9250 requires the DNS message ID to be zero, since QUIC streams already associate each response with its request. DoQ changes how the message moves between client and server and leaves the records inside it untouched.
Independent streams change how concurrent queries fail
A long-lived DNS connection is useful because creating a new secure connection for every query would add unnecessary setup work. The difficulty with carrying many transactions over one TCP connection is that TCP exposes a single ordered byte stream.
If a TCP segment is lost, later bytes can’t be delivered to the application until the missing data is recovered. That is transport-level head-of-line blocking. When multiple DNS transactions share the same TCP connection, loss affecting one part of the byte stream can delay delivery of data belonging to other transactions.
QUIC handles this differently. Multiple QUIC streams share a connection, but delivery ordering is maintained within each stream rather than across the entire connection. Because DoQ maps each DNS transaction to its own stream, packet loss affecting one query doesn’t necessarily stop another completed stream from being delivered to the DNS application.
Packet loss still affects the connection. Lost data needs recovery, congestion control still reacts, and streams still share a network path. The improvement is that one missing piece of stream data doesn’t impose TCP’s connection-wide delivery ordering on every other DNS transaction.
DoQ keeps the privacy model close to DoT
RFC 9250 describes DoQ as providing privacy properties similar to DNS over TLS. For the common stub-to-recursive case, its resolver authentication requirements follow the same model used by DoT.
When the client authenticates the DNS server, an on-path observer can see that encrypted traffic is being exchanged with a particular endpoint, along with metadata such as packet sizes and timing. The observer can’t directly read the DNS questions and answers carried inside the protected QUIC connection.
That makes DoQ another encrypted DNS transport, not a new anonymity system. The resolver still receives the client’s network connection and the DNS queries carried over it. That’s the same privacy boundary every direct encrypted transport shares. Encryption protects the path between the two parties without removing the resolver from the trust relationship.
That boundary shows up concretely with stub resolvers and application-controlled DNS. Encrypting the transport changes who can observe DNS in transit, but the client still has to choose a resolver and establish a relationship with it.
DoQ uses a dedicated UDP port
By default, DoQ servers listen on UDP port 853. Clients using DoQ with a particular server also connect to UDP port 853 unless both sides have agreed to use something else. RFC 9250 explicitly says DoQ must not use UDP port 53.
That gives DoQ a recognizable transport footprint. A network doesn’t need to decrypt a DoQ connection to identify ordinary UDP/853 traffic as likely encrypted DNS. The port number matches DoT’s, over UDP instead of TCP. DoH shares HTTPS transport on port 443 with ordinary web traffic, so it’s far less distinguishable by port alone, while DoQ, like DoT, stands out on a dedicated port.
RFC 9250 also states that evading blocking by middleboxes isn’t a goal of the protocol. A network that blocks UDP/853 can therefore prevent a conventional DoQ connection from being established. What happens next is a client decision rather than a protocol rule. RFC 9250 permits falling back to DoT, and potentially to cleartext depending on the client’s configured usage profile, but it mandates no universal fallback sequence.
DoQ is more than a stub-to-recursive transport
Encrypted DNS discussions often focus on the path from an endpoint to a recursive resolver, but RFC 9250 defines DoQ as a general-purpose DNS transport.
It includes three broad scenarios:
- Stub resolver to recursive resolver
- Recursive resolver to authoritative server
- Name server to name server, including DNS zone transfer use cases
DoH is closely tied to HTTP semantics, while DoQ provides a direct mapping between DNS transactions and QUIC streams. RFC 9250 describes that lighter mapping as a natural fit for recursive-to-authoritative traffic and zone transfers where HTTP intermediaries are usually not part of the path.
Deployment support still varies by software and environment. Defining a transport in an RFC doesn’t mean every resolver, authoritative server, operating system, or network uses it.
QUIC also changes connection setup and recovery
QUIC provides features beyond independent streams. DoQ can use long-lived connections, QUIC’s loss-detection and recovery mechanisms, and optional 0-RTT data during session resumption.
The 0-RTT feature can reduce setup delay for a client reconnecting to a server it has contacted before, but it comes with replay considerations. RFC 9250 restricts early data to transactions whose opcode is QUERY or NOTIFY, the ones considered safe to replay, rather than treating 0-RTT as equivalent to a normal fully established connection.
These features are transport optimizations. A query for example.com A asks the same question whether it traveled over UDP, TCP, DoT, DoH, or DoQ, even though each transport frames and carries it differently.
DoQ and DoT solve the same privacy problem differently
The clearest comparison is at the transport layer:
| Property | DoT | DoQ |
|---|---|---|
| Underlying transport | TCP | QUIC over UDP |
| Encryption | TLS | QUIC with TLS 1.3 |
| Default port | TCP/853 | UDP/853 |
| Concurrent DNS transactions | Share a TCP byte stream | Separate QUIC streams |
| Application delivery after packet loss | A missing TCP segment can delay later bytes across the connection | Independent streams avoid connection-wide delivery ordering |
| Stub-to-recursive authentication | Supported | Supported using the DoT authentication model |
DoQ’s main contribution isn’t stronger DNS confidentiality than DoT but a similar privacy model carried over a transport designed for concurrent secure exchanges without TCP’s single ordered byte stream.
Summary
DNS over QUIC carries ordinary DNS messages over QUIC, giving each transaction its own stream so one lost packet doesn’t hold up every other answer on the connection.
DoQ belongs in the encrypted DNS family beside DoT and DoH, but its distinctive contribution is transport behavior. It changes how encrypted DNS moves, not what DNS means.