Agree on a dedicated encrypted connection
01DNS 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.
This Strict-profile example authenticates the resolver before ordinary queries. The resolver can still read the DNS names it answers.
Source for this drawing: RFC 9250 · Read RFC section 4.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Negotiate doq before sending DNS on this connection.
- The handshake selects the ALPN token doq. ALPN means Application-Layer Protocol Negotiation. QUIC integrates TLS; doq is not the HTTP/3 protocol token.
- By default, both peers MUST use server UDP port 853 unless another port is mutually agreed. DoQ MUST NOT use UDP port 53, even by agreement.
- For stub-to-recursive use, clients SHOULD use the Strict authentication profile. Resolver authentication and fallback depend on the usage profile; encryption alone does not choose a trustworthy resolver.
- Implementations MUST follow QUIC address validation. Retry is a SHOULD-level consideration, not a required extra round trip on every connection.
The example chooses a configured recursive resolver and Strict authentication. RFC9250 leaves recursive-to-authoritative authentication unspecified; zone-transfer authentication follows RFC9103. Fallback is profile-dependent, not automatic permission to send cleartext.
Read the RFC section ↗