Visual RFC.
ALL RFCs / RFC 9250
Read the RFC ↗

RFC 9250 / START HERE

DNS over QUIC, before the details

DNS over QUIC (DoQ) means Domain Name System messages carried by the QUIC transport. QUIC is the transport’s name. RFC9250 calls this DNS over Dedicated QUIC Connections: the connection carries DNS directly, without HTTP.

DNS lets a client ask a server for information about a name. DoQ encrypts that exchange using QUIC. A bidirectional stream is an ordered conversation whose two endpoints can both send bytes. One such stream carries one query and its response or responses.

Why it exists

DoQ reuses an encrypted connection for many independent questions. A ready answer on one stream need not wait for missing data on another stream. This is a different mapping from DNS over TLS or DNS over HTTPS; it does not replace the DNS message format or give each stream separate network capacity.

A familiar example

A configured client might ask for picnic.example on stream0 and another name on stream4. The second answer can arrive first. Each message has a length prefix and DNS ID0, and each sender ends its direction with FIN. The chosen resolver can still read the names; encryption, padding and faster reuse do not promise anonymity.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Agree on a dedicated encrypted connectionDNS over QUIC (DoQ) sends DNS messages directly on QUIC, without an HTTP exchange. A DNS client first establishes a QUIC connection to its chosen DNS server.
  2. Put one transaction on one streamA client-initiated bidirectional stream carries one DNS query and its response or responses. Bidirectional means both endpoints can send bytes on that same stream.
  3. Let independent questions finish independentlyOne persistent QUIC connection can carry many DNS transactions at once. Each has its own ordered stream; an earlier unanswered question need not hold up a later answer.
  4. Keep the scope of an error clearA DNS failure response, a cancelled transaction and a fatal transport-mapping violation have different outcomes. These four drawings are separate cases, not one continuous exchange.
  5. Balance early data, padding and privacySession resumption may permit zero-round-trip(0-RTT) data: a client sends before this handshake finishes. Replay and linkability risks remain even though the transport is encrypted.
Start with chapter one →

This introduction explains RFC 9250 (2022). Read the original RFC ↗