DNS over Dedicated QUIC Connections
Extracted elements (30)
A lightweight direct DNS-to-QUIC mapping (DoQ) is preferred over DNS over HTTPS (DoH with HTTP/3) for recursive-to-authoritative and zone transfer scenarios because these rarely involve intermediaries. The additional overhead of HTTP is not offset by proxying and caching benefits in these scenarios.
DoQ does not support server-initiated transactions (required by DNS Stateful Operations, DSO/RFC 8490) because QUIC does not guarantee in-order delivery of messages, which is a criterion for applicable DSO transports. Only the initiator of the DoQ connection may send queries over it.
DoQ explicitly does not include any measures to avoid protocol classification by middleboxes. Padding is intended to obfuscate the content of DNS queries and responses, not to disguise the fact that the traffic is DNS. This non-goal is stated explicitly and is not an endorsement of middlebox classification practices.
The edns-tcp-keepalive EDNS(0) Option (RFC 7828) MUST NOT be sent over DoQ and its receipt is a fatal protocol error requiring CONNECTION_CLOSE. This has implications for proxies bridging TCP/DoT/DoH to DoQ, since this option cannot be forwarded through a DoQ leg.
A DNS server supporting DoQ MUST listen on UDP port 853 by default. A DoQ client MUST connect to UDP port 853 by default. DoQ connections MUST NOT use UDP port 53 to avoid confusion with classic DNS over UDP.
By default, clients SHOULD be configured to prioritize privacy and start new sessions if connectivity changes, rather than using QUIC connection migration features. Connection migration trades privacy for latency since it allows servers to track client location via successive IP addresses.
Clients and servers MUST NOT send the edns-tcp-keepalive EDNS(0) Option (RFC 7828) in any messages on a DoQ connection, as it is specific to TCP/TLS transport; receiving it is a fatal protocol error. Clients wanting long-duration connections SHOULD use QUIC's idle timeout mechanisms instead.
Clients SHOULD use resumption tickets only once (per RFC 8446 Appendix C.4) and SHOULD NOT use session resumption if connectivity has changed. Servers SHOULD issue session resumption tickets with a sufficiently long lifetime (e.g., 6 hours) and SHOULD implement anti-replay mechanisms from RFC 8446 Section 8. Address validation tokens SHOULD only be used in conjunction with session resumption.
DoQ enforces a maximum DNS message size of 65535 bytes, consistent with DNS over TCP and DoT. The EDNS(0) UDP message size parameter is ignored by DoQ; implementations always assume a maximum message size of 65535 bytes regardless of the EDNS(0) UDP size value advertised.
DoQ implementations MUST conform to QUIC's address validation specification (RFC 9000 Section 8), which limits the worst-case amplification factor to 3. Implementations SHOULD consider configuring Address Validation using Retry Packets, imposing a 1-RTT delay for verifying the source address routability of a client.
DoQ servers MUST be able to handle multiple concurrent IXFR and AXFR requests on a single QUIC connection. Implementations SHOULD use the same QUIC connection for both AXFR and IXFR requests to the same primary, send requests in parallel without waiting for prior responses, and interleave response streams as they become available.
DoQ stubs SHOULD use a Strict usage profile for server authentication, aligning with DoH's authentication model. DNS privacy services SHOULD provide credentials that clients can use to authenticate the server. Authentication requirements for zone transfer follow RFC 9103.
Implementations MUST protect against traffic analysis attacks by injecting padding, either using the EDNS(0) Padding Option (RFC 7830) per DNS message or via QUIC packet-level padding APIs. If QUIC packet-level padding is unavailable or unused, DoQ MUST pad all DNS queries and responses to a small set of fixed sizes using EDNS(0) padding; the padding policies of RFC 8467 SHOULD be followed.
Protocol errors including a non-zero Message ID, receiving STREAM FIN before all bytes, multiple queries on one stream, use of edns-tcp-keepalive, unidirectional streams, or a server-initiated bidirectional stream are fatal. The peer SHOULD forcibly abort the connection using CONNECTION_CLOSE with error code DOQ_PROTOCOL_ERROR. Unknown error codes MUST be treated as equivalent to DOQ_UNSPECIFIED_ERROR.
The 0-RTT mechanism MUST NOT be used to send DNS requests that are not replayable transactions. Only QUERY and NOTIFY opcodes are considered replayable; all other OPCODES MUST NOT be sent in 0-RTT data. Servers supporting 0-RTT MUST NOT immediately process non-replayable transactions received in 0-RTT data and must queue them, refuse with REFUSED and EDE 'Too Early', or close the connection.
The DNS Message ID MUST be set to 0 for all queries sent over DoQ connections. QUIC stream mapping provides unambiguous correlation of queries and responses, making the Message ID field unnecessary. When forwarding from another transport to DoQ, the Message ID MUST be set to 0; when forwarding from DoQ to another transport, a Message ID MUST be generated per that transport's rules.
To cancel an outstanding DNS transaction, a DoQ client MUST issue a QUIC STOP_SENDING and SHOULD use error code DOQ_REQUEST_CANCELLED; the corresponding DNS transaction MUST be abandoned. Servers MUST NOT continue processing a transaction if they receive RESET_STREAM before STREAM FIN from the client, and MUST issue RESET_STREAM in response.
0-RTT data can be replayed by adversaries, potentially revealing queried names via observation of recursive resolver outgoing traffic triggered by a replayed query. Only QUERY and NOTIFY are permitted in 0-RTT to limit server state changes. TLS 1.3 replay protection limits but does not eliminate this risk; the replay window is limited to clock skew and network transmission variance.
Address validation tokens (NEW_TOKEN) are typically tied to IP addresses and may create linkability risk if clients inadvertently use them after changing location due to NAT or IPv6 address changes. Tokens should only be used in conjunction with session resumption to avoid introducing additional tracking risk beyond that already accepted.
Even with QUIC encryption, adversaries can infer information from packet lengths and timing. A simple one-query-per-packet mapping could enable website fingerprinting since loading a web page may require resolving dozens of names with a characteristic succession of packet lengths. Implementations SHOULD use padding as specified in Section 5.4 to mitigate this attack.
QUIC session resumption can be used to track clients across sessions if the same resumption token is used multiple times, or if the server correlates resumed sessions with initial sessions to build a virtual long-duration session. Mitigations include using tickets only once and refusing resumption when the client's IP address has changed.
DoQ connections are established using QUIC and identified by the ALPN token 'doq' (0x64 0x6F 0x71) negotiated during the TLS/QUIC crypto handshake. This token is registered in the TLS ALPN Protocol IDs registry.
DoQ defines seven error codes for stream termination and connection closing: DOQ_NO_ERROR (0x0), DOQ_INTERNAL_ERROR (0x1), DOQ_PROTOCOL_ERROR (0x2), DOQ_REQUEST_CANCELLED (0x3), DOQ_EXCESSIVE_LOAD (0x4), DOQ_UNSPECIFIED_ERROR (0x5), and DOQ_ERROR_RESERVED (0xd098ea5e) for testing.
Each DNS query/response transaction is mapped to a separate client-initiated bidirectional QUIC stream. The client selects the next available stream for each query; the server uses the same stream for all responses to that query. STREAM FIN is used to signal completion of sending on each side. The client's first query is on stream 0, the second on stream 4, and so on.
IANA created the 'DNS-over-QUIC Error Codes' registry on the DNS Parameters page, governing a 62-bit space. Values 0x00–0x3f require Standards Action or IESG Approval; values above 0x3f use Specification Required for permanent or Expert Review for provisional registrations. Provisional registrations include a date field and may be reclaimed.
IANA registered Extended DNS Error Code 26 with purpose 'Too Early' in the Extended DNS Error Codes registry (RFC 8914). This code is used when a server refuses to process a non-replayable transaction received in 0-RTT data.
IANA registered the ALPN identification string 'doq' (0x64 0x6F 0x71) in the 'TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs' registry to identify the DNS over QUIC protocol.
IANA updated the port 853/UDP entry in the Service Name and Transport Protocol Port Number Registry to add DoQ, changing the description to 'DNS query-response protocol run over DTLS or QUIC'. UDP port 853 is now shared between DoD (RFC 8094) and DoQ; QUIC version 1 can coexist with DTLS on the same port via the second most significant bit in the UDP payload.
The security considerations of DoQ are comparable to those of DoT (RFC 7858), including protection against person-in-the-middle attacks and middleboxes. DoQ relies on QUIC, which uses TLS 1.3 and inherits protections against downgrade attacks per BCP 195. QUIC-specific security issues and mitigations are described in RFC 9000 Section 21.
All DNS messages (queries and responses) sent over DoQ MUST be encoded as a 2-octet length field followed by the message content, exactly as specified for DNS over TCP in RFC 1035. The practical result is that each QUIC stream's content is identical to a TCP connection managing exactly one query.