メインコンテンツまでスキップ

4. Specifications (仕様)

4.1. Connection Establishment (接続確立)​

DoQ 接続は、QUIC トランスポート仕様 [RFC9000] に記載されているように確立されます。接続確立中、DoQ サポートは、暗号ハンドシェイクでアプリケーション層プロトコルネゴシエーション (ALPN) トークン "doq" を選択することによって示されます。

4.1.1. Port Selection (ポート選択)​

デフォルトでは、DoQ をサポートする DNS サーバーは、相互の合意で別のポートを使用する場合を除き、専用 UDP ポート 853 (第 8 節) で QUIC 接続をリッスンし、受け入れなければなりません (MUST)。

デフォルトでは、特定のサーバーで DoQ を使用したい DNS クライアントは、相互の合意で別のポートを使用する場合を除き、サーバーの UDP ポート 853 への QUIC 接続を確立しなければなりません (MUST)。

DoQ 接続は UDP ポート 53 を使用してはなりません (MUST NOT)。DoQ にポート 53 を使用しないこの推奨は、DoQ と DNS over UDP [RFC1035] の使用との混同を避けるためです。

4.2. Stream Mapping and Usage (ストリームマッピングと使用)​

QUIC ストリーム上の DNS トラフィックのマッピングは、[RFC9000] の第 2 節で詳述されている QUIC ストリーム機能を利用します。

DoQ 接続を介して送信されるすべての DNS メッセージ (クエリとレスポンス) は、[RFC1035] で規定されているように、2 オクテット長フィールドとそれに続くメッセージコンテンツとしてエンコードされなければなりません (MUST)。

クライアントは、QUIC 接続上の各後続クエリに対して、次に利用可能なクライアント開始双方向ストリームを選択しなければなりません (MUST)。クライアントは、選択されたストリーム上で DNS クエリを送信し、STREAM FIN メカニズムを通じてそのストリーム上でこれ以上データが送信されないことを示さなければなりません (MUST)。

サーバーは、同じストリーム上でレスポンスを送信し、最後のレスポンスの後、STREAM FIN メカニズムを通じてそのストリーム上でこれ以上データが送信されないことを示さなければなりません (MUST)。

4.2.1. DNS Message IDs (DNS メッセージ ID)​

QUIC 接続を介してクエリを送信する場合、DNS メッセージ ID は 0 に設定しなければなりません (MUST)。DoQ のストリームマッピングにより、クエリとレスポンスの明確な相関が可能になるため、メッセージ ID フィールドは必要ありません。

4.3. DoQ Error Codes (DoQ エラーコード)​

以下のエラーコードが定義されています:

  • DOQ_NO_ERROR (0x0): エラーなし
  • DOQ_INTERNAL_ERROR (0x1): 内部エラー
  • DOQ_PROTOCOL_ERROR (0x2): プロトコルエラー
  • DOQ_REQUEST_CANCELLED (0x3): リクエストがキャンセルされた
  • DOQ_EXCESSIVE_LOAD (0x4): 過度な負荷
  • DOQ_UNSPECIFIED_ERROR (0x5): 未指定のエラー
  • DOQ_ERROR_RESERVED (0xd098ea5e): テスト用に予約済み

4.3.1. Transaction Cancellation (トランザクションのキャンセル)​

DoQ クライアントが未完了のリクエストをキャンセルしたい場合、QUIC STOP_SENDING を発行しなければならず (MUST)、エラーコード DOQ_REQUEST_CANCELLED を使用すべきです (SHOULD)。

4.3.2. Transaction Errors (トランザクションエラー)​

サーバーは通常、トランザクションのストリーム上で DNS レスポンスを送信することによってトランザクションを完了します。サーバーが内部エラーのために DNS レスポンスを送信できない場合、エラーコード DOQ_INTERNAL_ERROR で QUIC RESET_STREAM フレームを発行すべきです (SHOULD)。

4.3.3. Protocol Errors (プロトコルエラー)​

プロトコルエラーには、非ゼロメッセージ ID を持つメッセージの受信、すべての期待されるデータの前の STREAM FIN の受信、またはその他のプロトコル違反が含まれます。ピアがそのようなエラーに遭遇した場合、エラーコード DOQ_PROTOCOL_ERROR で QUIC の CONNECTION_CLOSE メカニズムを使用して接続を強制的に中止すべきです (SHOULD)。

4.3.4. Alternative Error Codes (代替エラーコード)​

予期しないコンテキストでのエラーコードの使用、または未知のエラーコードの受信は、DOQ_UNSPECIFIED_ERROR と同等として扱わなければなりません (MUST)。

4.4. Connection Management (接続管理)​

DoQ を実装するクライアントとサーバーは、アイドルタイムアウトの使用をネゴシエートすべきです (SHOULD)。クライアントは接続上のアイドル時間を監視し、アイドルタイムアウトが近づいている場合は新しい接続を確立すべきです (SHOULD)。

4.5. Session Resumption and 0-RTT (セッション再開と 0-RTT)​

サーバーがサポートしている場合、クライアントはセッション再開と 0-RTT メカニズムを利用してもかまいません (MAY)。0-RTT メカニズムは、「再生可能」なトランザクションでない DNS リクエストを送信するために使用してはなりません (MUST NOT)。OPCODE が QUERY または NOTIFY のトランザクションのみが再生可能と見なされます。

4.6. Message Sizes (メッセージサイズ)​

DoQ クエリとレスポンスは QUIC ストリーム上で送信され、理論上は最大 2^62 バイトを運ぶことができます。しかし、DNS メッセージは実際には最大 65535 バイトに制限されています。DoQ 実装は常に最大メッセージサイズが 65535 バイトであると仮定します。

に最終更新