Skip to main content

4. Specifications

4.1. Connection Establishment

DoQ connections are established as described in the QUIC transport specification [RFC9000]. During connection establishment, DoQ support is indicated by selecting the Application-Layer Protocol Negotiation (ALPN) token "doq" in the crypto handshake.

4.1.1. Port Selection

By default, a DNS server that supports DoQ MUST listen for and accept QUIC connections on the dedicated UDP port 853 (Section 8), unless there is a mutual agreement to use another port.

By default, a DNS client desiring to use DoQ with a particular server MUST establish a QUIC connection to UDP port 853 on the server, unless there is a mutual agreement to use another port.

DoQ connections MUST NOT use UDP port 53. This recommendation against use of port 53 for DoQ is to avoid confusion between DoQ and the use of DNS over UDP [RFC1035].

4.2. Stream Mapping and Usage

The mapping of DNS traffic over QUIC streams takes advantage of the QUIC stream features detailed in Section 2 of [RFC9000].

All DNS messages (queries and responses) sent over DoQ connections MUST be encoded as a 2-octet length field followed by the message content as specified in [RFC1035].

The client MUST select the next available client-initiated bidirectional stream for each subsequent query on a QUIC connection. The client MUST send the DNS query over the selected stream and MUST indicate through the STREAM FIN mechanism that no further data will be sent on that stream.

The server MUST send the response(s) on the same stream and MUST indicate, after the last response, through the STREAM FIN mechanism that no further data will be sent on that stream.

4.2.1. DNS Message IDs

When sending queries over a QUIC connection, the DNS Message ID MUST be set to 0. The stream mapping for DoQ allows for unambiguous correlation of queries and responses, so the Message ID field is not required.

4.3. DoQ Error Codes

The following error codes are defined:

  • DOQ_NO_ERROR (0x0): No error
  • DOQ_INTERNAL_ERROR (0x1): Internal error
  • DOQ_PROTOCOL_ERROR (0x2): Protocol error
  • DOQ_REQUEST_CANCELLED (0x3): Request cancelled
  • DOQ_EXCESSIVE_LOAD (0x4): Excessive load
  • DOQ_UNSPECIFIED_ERROR (0x5): Unspecified error
  • DOQ_ERROR_RESERVED (0xd098ea5e): Reserved for tests

4.3.1. Transaction Cancellation

If a DoQ client wishes to cancel an outstanding request, it MUST issue a QUIC STOP_SENDING, and it SHOULD use the error code DOQ_REQUEST_CANCELLED.

4.3.2. Transaction Errors

Servers normally complete transactions by sending a DNS response on the transaction's stream. If a server is incapable of sending a DNS response due to an internal error, it SHOULD issue a QUIC RESET_STREAM frame with error code DOQ_INTERNAL_ERROR.

4.3.3. Protocol Errors

Protocol errors include receiving a message with a non-zero Message ID, receiving a STREAM FIN before all expected data, or other protocol violations. If a peer encounters such an error, it SHOULD forcibly abort the connection using QUIC's CONNECTION_CLOSE mechanism with error code DOQ_PROTOCOL_ERROR.

4.3.4. Alternative Error Codes

Use of an error code in an unexpected context or receipt of an unknown error code MUST be treated as equivalent to DOQ_UNSPECIFIED_ERROR.

4.4. Connection Management

Clients and servers implementing DoQ SHOULD negotiate use of the idle timeout. Clients SHOULD monitor the idle time on their connection and establish a new connection if the idle timeout is approaching.

4.5. Session Resumption and 0-RTT

A client MAY take advantage of session resumption and 0-RTT mechanisms if the server supports them. The 0-RTT mechanism MUST NOT be used to send DNS requests that are not "replayable" transactions. Only transactions with OPCODE of QUERY or NOTIFY are considered replayable.

4.6. Message Sizes

DoQ queries and responses are sent on QUIC streams, which can carry up to 2^62 bytes. However, DNS messages are restricted to a maximum size of 65535 bytes. DoQ implementations always assume that the maximum message size is 65535 bytes.