要約

  • RFC 8490では、DNSの接続とDSOセッションは別物である。ソケットの存在ではなく、成功した要求と応答が永続状態の出発点になる。
  • 一つのPrimary TLV、明示的なMESSAGE ID、非活動時間とkeepaliveの分離、Retry Delayが、状態の作成・維持・終了を観測可能にする。
  • 回線が生きていることは到達性の証拠にすぎず、保持中の操作の必要性や権限を証明しない。

ソケットには自動の権限がない

従来のDNSは質問と応答を中心にしている。TCPなら同じ接続を再利用できるが、それだけで購読を作ったり、後から変更を送りつけたり、応答後もアプリケーション状態を保持したりする権限は生まれない。

2019年3月のRFC 8490は、Ray Bellis、Stuart Cheshire、John Dickinson、Sara Dickinson、Ted Lemon、Tom Pusateriの共著である。OPCODE 6としてDNS Stateful Operations（DSO）を定義し、RFC 1035とRFC 7766を更新した。重要なのは、永続的な操作が存在し、その規則を双方が理解している状態に名前を与えたことだ。

最初にあるのは接続だけである。限定されたearly dataの場合を除き、クライアントがDSO要求を送り、同じ識別子を持つ成功応答を受けて初めてDSOセッションになる。古いサーバーが沈黙したとき、受理されたと推定してはならない。所定時間後に接続を破棄し、既知状態から始め直す。

一つのメッセージに一つの主操作

DSOは12バイトのDNSヘッダーを使うが、操作はType-Length-Valueで表す。メッセージにはPrimary TLVが一つだけあり、それが応答を要する要求か、応答してはならない一方向通知かを決める。

要求のMESSAGE IDはゼロ以外で、応答は同じ値を返す。一方向通知はゼロを使う。複数要求は連続送信でき、応答順は入れ替わり得るが、受信側の処理順は到着順である。未知のPrimary TLVにはDSOTYPENIを返し、未知のAdditional TLVは無視する。理解できない意味を受理したふりをせずに拡張できる。

沈黙を測る二つの時計

静かな接続は放棄済みかもしれないし、変化を待つ有効な購読かもしれない。そこでRFCはinactivity timeoutとkeepalive intervalを分ける。

前者は有意味な操作を見る。長期操作は取り消されるまで有効で、無通信でも直ちに非活動とはならない。後者は経路の到達性を確かめ、NATやファイアウォールの状態を保つ。keepaliveは脈拍だが、操作の目的を更新する承認ではない。

二つを混ぜると、静かな購読を壊すか、古い状態を永久化する。運用者はタイマーだけでなく、状態を保持する理由となる未完了操作も確認しなければならない。

再接続の殺到を避ける終了

Retry Delayは、サーバーが終了時に再接続までの待ち時間を伝える。理由コードは通常の再起動、致命的な形式不良、資源枯渇、再設定を分ける。制御された停止が一斉再接続へ変わるのを防ぐ仕組みである。

ただしコードは限定的な証拠だ。SERVFAILは負荷軽減を示し得るが内部原因までは証明せず、REFUSEDは不正や永久撤回を意味しない。DSOは信頼できる順序付き運搬路、すなわちDNS over TCPまたはTLSを必要とする。UDPにはセッション性がなく、HTTPSには別の管理機構がある。

RFC 8765はDNS Push NotificationsにDSOを利用した。価値は長い接続ではなく、別のプロトコルが共有できるライフサイクルにある。IANA登録簿はDSOコードの割当を示すが、普及率や実装品質は示さない。

Ray Bellisらの設計は、確立、沈黙、到達、過負荷、終了、再試行を別々の出来事にした。永続性を利用しながら、それを見えない権限にしないための境界である。

出典