1. はじめに

本文書は、ステートフルな DNS 接続を管理するためのメカニズムを規定します。DNS は最も一般的には UDP トランスポート上で動作しますが、ストリーミングトランスポート上でも動作可能です。オリジナルの DNS RFC は DNS-over-TCP [RFC1035] を規定しており、DNS-over-TLS [RFC7858] のプロファイルも規定されています。これらのトランスポートは永続的な長寿命セッションを提供できるため、DNS メッセージの転送に使用する場合、タイムアウトなどのセッションに関連するパラメータを確立できるメカニズムを持つことが有益です。このような状況では、サーバー主導のメッセージ（DNS プッシュ通知 [Push] など）をサポートすることも有利です。

既存の DNS 拡張メカニズム (EDNS(0)) [RFC6891] は、「メッセージごと」のセマンティクスのみを持つように明示的に定義されています。EDNS(0) は少なくとも1つのセッション関連パラメータ (edns-tcp-keepalive EDNS(0) オプション [RFC7828]) を通知するために使用されてきましたが、EDNS(0) セマンティクスによって課される制限とサーバー主導のシグナリングの欠如により、結果は最適とは言えません。例えば、サーバーは EDNS(0) オプションを含むクエリへの応答でのみ EDNS(0) オプションを送信できるため、サーバーがクライアントに接続を閉じるよう任意に指示することはできません。

本文書は、値が 6 の DNS ステートフル操作 (DSO) 用の新しい DNS OPCODE を定義します。DSO メッセージは、Type Length Value (TLV) 構文を使用して表現される、永続的なステートフルセッション内での操作を通信するために使用されます。本文書は、セッションのタイムアウト、終了、および暗号化パディングを管理するために使用される3つの TLV の初期セットを定義します。

ここで定義される3つの TLV はすべて、DSO のすべての実装において必須です。さらなる TLV が追加の仕様で定義される場合があります。

DSO メッセージは確認応答される場合とされない場合があります。DSO メッセージが確認応答されるべきか（DSO 要求メッセージ）、確認応答されないべきか（DSO 一方向メッセージ）は、その特定の DSO メッセージタイプの定義で指定されます。MESSAGE ID は、DSO 要求メッセージの場合は非ゼロ、DSO 一方向メッセージの場合はゼロです。メッセージはパイプライン化され、複数の要求が並行して処理されている場合、応答が順序不同で表示されることがあります。

DSO メッセージの形式（セクション 5.4）は、標準的なクエリと応答に使用される従来の DNS メッセージ形式とは多少異なります。標準の12バイトヘッダーが使用されますが、4つのカウントフィールド（QDCOUNT、ANCOUNT、NSCOUNT、ARCOUNT）はゼロに設定され、したがってそれに対応するセクションは存在しません。

DNS ステートフル操作に関連する実際のデータ（TLV 構文で表現）は、DNS メッセージヘッダーの末尾に追加されます。従来の DNS-over-TCP [RFC1035] [RFC7766] と同様に、DSO メッセージ（これは単なる別の種類の DNS メッセージです）を運ぶストリームプロトコルは、開始時に16ビットのメッセージ長を配置することでそれらをフレーム化します。したがって、DSO メッセージの長さは、DNS ヘッダーカウントのいずれかからではなく、その長さから決定されます。

DSO 形式を認識するように更新されていないパケットアナライザツールを使用して表示する場合、これは DSO データが DNS メッセージの終わりの後の不明な余分なデータとして表示される結果になります。

この新しい形式は、より明示的でコンパクトであるため、RR ベースの形式よりも明確な利点があります。各 TLV 定義はそのユースケースに固有であり、その結果、冗長またはオーバーロードされたフィールドを含みません。重要なことに、これは DNS ステートフル操作を通常の DNS 操作や既存の EDNS(0) ベースの機能と何らかの形で混同することを完全に回避します。このアプローチの目標は、EDNS(0) に降りかかった運用上の問題、特にミドルボックスの動作に関連する問題を回避することです（EDNS(0) を議論するセクション、および DNS 障害の原因を説明する最近の作業 [Fail] におけるファイアウォールやロードバランサによって引き起こされる問題を参照）。

EDNS(0) では、複数のオプションを単一の OPT 疑似 RR にパックすることができ、サーバーが結合された OPT 疑似 RR 内の個々のオプションを処理したか、またはその他の方法で作用したかをクライアントが知ることができる一般的なメカニズムはありません。個々のオプションの仕様は、必要に応じて、それぞれの異なるオプションがどのように確認応答されるかを定義する必要があります。

EDNS(0) とは対照的に、DSO では、効率上の理由から複数の操作を単一のメッセージにパックする説得力のある動機はありません。なぜなら、DSO は常に接続指向のトランスポートプロトコルを使用して動作するからです。各 DSO 操作は独自の個別の DNS メッセージで通信され、トランスポートプロトコルは適切な場合、複数の DNS メッセージを単一の IP パケットにパックすることができます。例えば、TCP は複数の小さな DNS メッセージを単一の TCP セグメントにパックできます。この単純化により、より明確なセマンティクスが可能になります。各 DSO 要求メッセージは1つの主要な操作のみを通信し、対応する応答メッセージの RCODE はその操作の成功または失敗を示します。