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

Keep the scope of an error clear

04

A 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.

RFC 9250 · § 4.3EXAMPLE
4 / 4
04
Case4: stop a fatal mapping violation.

A nonzero DNS ID violates DoQ. This example sends CONNECTION_CLOSE with 0x2; all in-progress transactions on that connection are abandoned.

Keep the scope of an error clearA nonzero DNS ID violates DoQ. This example sends CONNECTION_CLOSE with 0x2; all in-progress transactions on that connection are abandoned.Case4: invalid ID causes a fatal errorClientDNS serverReceived DNS ID7Required DoQ ID is0fatal errorChosen: CONNECTION_CLOSE · code0x2Abandon all in-progress transactionsExplicit close is SHOULD; silent abandon is MAY

Source for this drawing: RFC 9250 · Read RFC section 4.3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Cancel a transaction on its stream; a failed connection abandons every in-progress transaction.

  • A DNS error such as SERVFAIL normally travels as a DNS response. RCODE means the DNS response-code field; a client SHOULD be notified with that field set to SERVFAIL. It is not automatically a QUIC protocol failure.
  • To cancel an outstanding request, a client MUST send STOP_SENDING and SHOULD use DOQ_REQUEST_CANCELLED(0x3). The transaction MUST be abandoned; the server SHOULD NOT continue processing. A response already sent cannot be recalled and is discarded by the client.
  • If a client RESET_STREAM arrives before its FIN, the server MUST NOT continue processing and MUST send RESET_STREAM, unless it already reset or already sent both the response and FIN. If unable to send a DNS response due to an internal error, a server SHOULD reset with DOQ_INTERNAL_ERROR(0x1).
  • Nonzero DNS IDs, premature FIN, an extra query on a stream, unexpected response counts, forbidden stream types or edns-tcp-keepalive are fatal protocol errors. A peer SHOULD close with DOQ_PROTOCOL_ERROR(0x2); in some cases it MAY silently abandon the connection.
  • Unknown or context-inappropriate error codes MUST be treated as DOQ_UNSPECIFIED_ERROR(0x5). If a connection fails, all its in-progress transactions MUST be abandoned.
DETAILS

Case4 chooses the recommended explicit connection close for an ID 7 violation. It does not turn SHOULD into MUST or deny silent abandonment. A successful cancellation cannot undo a response already sent. No real network requests are made by these teaching drawings.

Read the RFC section ↗

All chapters in RFC 9250

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗