Jump to content

RFC 9250

For implications on Internet governance, see DNS over QUIC.

RFC 9250, DNS over Dedicated QUIC Connections, is an IETF standards-track RFC that specifies DNS over QUIC (DoQ) as a general-purpose encrypted transport for the DNS. It maps DNS queries and responses onto the QUIC transport protocol, aiming to provide privacy properties comparable to DNS over TLS (DoT) and latency characteristics close to classic DNS over UDP.[1][2]

Background[edit | edit source]

DNS over UDP and TCP was originally defined without encryption. Concerns about DNS privacy led first to DNS over TLS in RFC 7858 and its usage profiles in RFC 8310, and later to DNS over HTTPS (DoH) in RFC 8484.[1] In parallel, the IETF standardized QUIC (RFC 9000 and RFC 9001) as an encrypted, multiplexed transport designed to reduce latency and head-of-line blocking compared to TCP.[3]

RFC 9250 combines these lines of work by defining a direct mapping of DNS onto QUIC, aiming to provide the same level of DNS privacy as DoT, including support for strict and opportunistic usage profiles from RFC 8310, also improving source address validation and loss recovery compared to classic DNS over UDP. It avoids path MTU limitations that can affect large DNS responses.[1]

The specification explicitly targets three scenarios: stub to recursive resolver, recursive to authoritative server, and nameserver-to-nameserver communication (including zone transfers).[1]

Protocol Overview[edit | edit source]

DoQ uses QUIC as defined in RFC 9000 and RFC 9001, with a dedicated application mapping for DNS.[1] Support for DoQ is signalled during the QUIC handshake using the Application-Layer Protocol Negotiation (ALPN) token "doq".[1][4] Servers normally listen on UDP port 853 and clients connect to that port unless both sides explicitly agree on another value; use of UDP port 53 for DoQ is forbidden in order to avoid ambiguity with classic DNS over UDP.[1][5] A DoQ connection is dedicated to DNS and is not intended to multiplex other application protocols.

DNS messages are carried over QUIC bidirectional streams. Each query–response transaction uses a single client-initiated stream: the client opens a new bidirectional stream, sends a DNS message in the same length-prefixed format used for DNS over TCP, and then signals end-of-stream; the server sends the corresponding response (or sequence of responses, in the case of zone transfers) on that same stream and then closes it.[1] The contents of a DoQ stream therefore match what would appear on a dedicated TCP connection carrying exactly one DNS transaction.

Because the QUIC stream ID already disambiguates concurrent transactions, RFC 9250 requires that the DNS Message ID field be set to zero for all messages sent over DoQ. Proxies that bridge between DoQ and other transports are responsible for inserting or stripping DNS Message IDs as needed.[1] The RFC also defines a small registry of DoQ-specific error codes (such as DOQ_PROTOCOL_ERROR, DOQ_REQUEST_CANCELLED, and DOQ_EXCESSIVE_LOAD) that can be used to abort streams or close connections when protocol or operational errors occur.[1]

Connection Management and Performance[edit | edit source]

DoQ is designed to exploit QUIC’s performance features to provide encrypted DNS with latency close to that of classic DNS over UDP. Clients and servers are expected to maintain long-lived QUIC connections and to run multiple DNS transactions in parallel over those connections, allowing congestion control and loss recovery to operate over a richer set of observations than a single request–response exchange.[1] Mapping each DNS transaction to its own bidirectional stream avoids head-of-line blocking: packet loss that affects one stream does not delay responses on other streams, which is a key advantage over DNS over TLS on a single TCP stream.

Measurements comparing DoQ with DoT and DoH indicate that DoQ can achieve lower query latency and improved Web performance in several environments, while still providing confidentiality on par with DoT.[6]

Usage Scenarios[edit | edit source]

RFC 9250 treats DoQ as a general-purpose encrypted transport for DNS and explicitly supports several communication patterns:[1]

  • Stub to recursive – End-user devices or local forwarders connect to recursive resolvers over QUIC, in a role similar to DoT but using QUIC’s stream and loss-recovery model.
  • Recursive to authoritative – Recursive resolvers query authoritative servers over DoQ. The mapping is intentionally lightweight and avoids HTTP semantics that are unnecessary in resolver–authority communication.
  • Zone transfers – Nameserver-to-nameserver communication, including AXFR and IXFR, can use a single DoQ stream per transfer, benefiting from QUIC’s handling of large responses without path MTU constraints and without TCP head-of-line blocking.

The specification does not try to make DoQ indistinguishable from other traffic. It notes that padding can obscure message sizes but does not prevent middleboxes from classifying DoQ as DNS, and it does not support server-initiated transactions of the kind defined in DNS Stateful Operations.[1]

Security and Privacy Properties[edit | edit source]

Because QUIC integrates TLS 1.3 for connection security, DoQ provides confidentiality, integrity protection, and server authentication for DNS traffic between its endpoints, in a manner broadly comparable to DNS over TLS.[1] An on-path observer between client and resolver, or between resolver and authoritative server, can no longer read or modify DNS messages, although it can still infer information from IP addresses, timing patterns and packet sizes. Clients authenticate resolvers using an authentication domain name and the usage profiles already defined for DoT in RFC 8310, which RFC 9250 reuses for DoQ.[1][7]

The privacy analysis in RFC 9250 highlights the impact of 0-RTT data, session resumption, address validation tokens and long-lived connections on linkability and traffic analysis. Operators that treat DoQ as a privacy-enhancing technology are expected to balance these features against their potential to expose stable identifiers over time.[1] As with DoT and DoH, encryption is applied hop-by-hop: DoQ protects each segment where it is deployed but does not, on its own, provide end-to-end encryption from stub resolvers all the way to every authoritative server.

Relationship to DoT and DoH[edit | edit source]

RFC 9250 presents DoQ as complementary to DNS over TLS and DNS over HTTPS, not as a replacement for either.[1] Compared with DoT (RFC 7858), DoQ offers similar privacy properties while taking advantage of QUIC’s multiplexing and loss-recovery features, and it is explicitly designed for use beyond the stub-to-recursive hop, including recursive-to-authoritative traffic and zone transfers. Compared with DoH (RFC 8484) over HTTP/3, DoQ avoids the HTTP layer and its associated semantics in cases where DNS does not require intermediaries, caching proxies, or web-specific features.

Subsequent technical and measurement work generally treats DoT, DoH and DoQ as a family of encrypted DNS transports, with deployment choices determined by operational context: whether resolution is controlled by applications or by the network, whether intermediaries such as HTTP proxies are needed, and how performance and failure modes are balanced.[6][8]

See Also[edit | edit source]

References[edit | edit source]

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 C. Huitema, S. Dickinson, A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, IETF, May 2022.
  2. ↑ RFC Editor, "Information on RFC 9250" (accessed 2025-11-28).
  3. ↑ RFC Editor, "Information on RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport" (accessed 2025-11-28).
  4. ↑ C. Huitema et al., "Specification of DNS over Dedicated QUIC Connections" (Internet-Draft version, 2020).
  5. ↑ PotentPages, "DNS Over QUIC: Enhancing DNS Speed & Security" (accessed 2025-11-28).
  6. ↑ 6.0 6.1 M. Košek et al., "DNS Privacy with Speed? Evaluating DNS over QUIC and its Impact on Web Performance", IMC 2022.
  7. ↑ S. Dickinson et al., "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, IETF, March 2018.
  8. ↑ G. Huston, "DoH, DoT and plain old DNS", APNIC Blog, 2 September 2022.

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP) (RFC 768).

Allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery (RFC 8446).

Hypertext Transfer Protocol. Application-level protocol for distributed, collaborative, hypermedia information systems (RFC 2616).

HTTP over Transport Layer Security (TLS), distinguishing secured traffic from insecure traffic by the use of a different server port (RFC 2818).

Retrieved from "https://icannwiki.org/index.php?title=RFC_9250&oldid=1398391"
Semantic properties for "RFC 9250"
RDF feed