DNS over QUIC and Oblivious DoH Explained, with Support Status

What DNS over QUIC changes

QUIC is an encrypted transport that runs over UDP. DoT stacks TLS on top of TCP, so one lost packet stalls every query waiting behind it on that connection. DNS over QUIC avoids that head-of-line blocking, because each query travels independently, and RFC 9250 notes that QUIC also recovers from loss more efficiently than TCP does.

The RFC covers three uses. From a device to its resolver, the stub should use the strict profile, authenticating the server as a DoT client would. Between recursive resolvers and authoritative servers, authentication is left for later work. For zone transfers, servers must handle concurrent IXFR requests on one connection, following the zone transfer over TLS rules.

DNS over QUIC streams, ports and 0-RTT

Every DNS query gets its own bidirectional QUIC stream, and the answer comes back on the same stream. Messages keep the two-byte length prefix from DNS over TCP. Because the stream already ties question to answer, the RFC requires the DNS message ID to be set to 0. A connection signals support through the ALPN token doq during the handshake.

The default is UDP port 853. RFC 9250 forbids port 53 for DoQ and mentions 443 as an alternative by agreement, since it is less likely to be blocked. The DNS port guide lists the numbers side by side. Clients may use 0-RTT on resumed connections, though only for replayable queries such as QUERY and NOTIFY.

DoQ vs DoH over HTTP/3

DoH can run over HTTP/3, which is built on QUIC, so the DoQ vs DoH question is mostly about overhead. RFC 9250 argues that a direct mapping fits resolver-to-authoritative traffic and zone transfers better, where HTTP adds little. The DNSCrypt FAQ is cooler: it sees no clear advantage for DoQ over HTTP/3, and its port 853 is easy to filter.

For a client on a restrictive network that point decides a lot. DoH over HTTP/3 uses UDP 443, exactly like ordinary web traffic over QUIC. DoQ on UDP 853 stands out. The DNS over HTTPS page and the DNS over TLS page cover the two older siblings, and the comparison table lines all of them up.

Oblivious DoH: hiding the client from the resolver

Every protocol so far encrypts the path but leaves the resolver knowing who you are and what you asked. Oblivious DoH, RFC 9230 by authors from Apple, Fastly and Cloudflare, separates the two. The client encrypts its query for a target resolver with HPKE (RFC 9180) and sends it through a proxy by HTTP POST as application/oblivious-dns-message.

The proxy knows the client’s address and the target’s name but cannot read the query. The target reads the query but sees only the proxy as its origin. The design depends on the two not colluding. It is published as Experimental, developed outside the IETF to guide interoperability testing, so oblivious DoH is not an Internet Standard.

RFC 9230 makes one cipher suite mandatory: DHKEM(X25519, HKDF-SHA256) with HKDF-SHA256 and AES-128-GCM. Targets publish a public key that clients encrypt to, and answers come back protected with a symmetric key derived from the query context. The RFC recommends that servers rotate those keys daily, which limits how long any single key stays useful.

Support in dnscrypt-proxy and public resolvers

dnscrypt-proxy has supported oblivious DoH since version 2.1.0, according to its ChangeLog, and version 2.1.2 added ODoH servers to the -list output. The example configuration leaves odoh_servers = false by default and ships commented-out sources for ODoH servers and relays. The project’s FAQ is sceptical of relay protocols, though, saying they leak more information than expected.

DoQ is a different story: dnscrypt-proxy does not implement it. What it offers is DoH over HTTP/3, introduced in version 2.1.2 and controlled by the http3 and http3_probe options, which uses UDP 443 like DNSCrypt. On the resolver side, AdGuard DNS publishes DoQ addresses such as quic://dns.adguard-dns.com, while Cloudflare’s 1.1.1.1 documentation lists DoH, DoT and ODoH, but not DoQ.

Trying the newer protocols

To try DNS over QUIC you need a client that speaks it and a resolver that serves it, such as AdGuard’s. For oblivious DoH, set odoh_servers = true in dnscrypt-proxy and enable the ODoH sources. If the goal is hiding your IP address from the resolver, Anonymized DNSCrypt relays do that job, and the route builder writes the configuration.