要約

  • RFC 5625は2009年8月にBCP 152として公表され、BCP 152の子シリーズにはRFCが一つしか含まれない。著者はR. Bellis（Nominet UK）一人であり、状態文は「議論と提案を求める」で終わる。
  • RFC 8490は2019年3月のProposed Standardで、三つのMUST NOTが二台の間の共同的状態を構成する。著者は六人。いずれも採用を選ばない者を拘束せず、本稿が確認した範囲では、どちらが実際のネットワークを変えたかを示す実装証拠は得られていない。

状態文が語る二つの統治形態

標準文書の性格は、付帯する状態文にはっきり現れる。RFC 5625の状態文はこう書く。「This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.」つまり、これは現時点で最良と考える運用上の助言であり、異論は歓迎する、という表明である（RFC 5625 情報ページ、RFC 5625 本文）。

対してRFC 8490の状態文は標準化過程の定型句をとる。文書はIETFコミュニティの合意を代表し、公開のレビューを受け、インターネット技術運営委員会（IESG）の承認を得て公表された、と。ここで行使される権威は、査読者を内部に抱えた手続きから借りたものであり、著者が自称したものではない（RFC 8490 本文）。

この対比は重要である。片方は読者に異議を促し、片方は合意の代表を名乗る。にもかかわらず、両者に共通する限界がある。どちらも、実装しないと決めた者を拘束しない。

干渉を禁じる動詞、状態を作る動詞

RFC 5625の義務は、代理（プロキシ）が理解できないものに手を出さないことに向けられている。

  • 第4.1節：プロキシは未知のDNSフラグを無視し、そのパケットをそのまま転送しなければならない（MUST）。
  • 第4.4節：応答を一方的に切り詰める必要がある場合、プロキシはTCビットを立てなければならない（MUST）。
  • 第4.5節：DNSプロキシはTKEY資源レコードを含むパケットを転送できる能力を持たなければならない（MUST）。

いずれも干渉の禁止であり、機能の追加命令ではない。積極的な目標はもっと弱い言葉で書かれている。第3節は「可能な限り透過的であること」を推奨（RECOMMENDED）し、第4.4.1節はTCPで受けた要求をTCPで転送すべき（SHOULD）とし、第5.2節は記述するオプションの既定値を空にすることを推奨する。

これは臆病ではない。家庭用ゲートウェイのファームウェアは、DNSが変化をやめるよりずっと早く更新を止める。著者は将来の拡張がその機器に何を求めるかを知り得ない。だから唯一擁護できる規則は、彼が書いたものになる。理解できないものはそのまま運び、切り詰めるときは正直に申告せよ、と。

RFC 8490の三つの義務は、これとは構造的に別のことをする（RFC 8490 情報ページ）。

  • 第5.1節：DSOセッションが相互に確立されるまで、サーバーはDSO要求メッセージも一方向メッセージも開始してはならない（MUST NOT）。
  • 第5.1.1節：DSOを実装するサーバーは、DSO Keepalive要求に対してDSOTYPENIを返してはならない（MUST NOT）。KeepaliveのTLVは実装が必須だからである。
  • 第5.4.1節：MESSAGE IDがゼロのDSO応答を受けた場合、これは致命的エラーであり、受信側は直ちに接続を強制切断しなければならない（MUST）。

三つを続けて読むと、二名で構成される制度が見えてくる。セッションは相互確立によってのみ存在する。ある拒否コードは、別の部品が必須であるために、特定の要求に対して使えなくなる。不正な識別子は警告ではなく切断である。以後、二台はどちらも単独では宣言できない状態を共有し、その共同性が書き留められている場所が文書なのである。

禁止の周囲には裁量が残され、裁量として明示された。応答が来なければクライアントは30秒待つべき（SHOULD）であり、サーバーが接続を切ったならそのサービス実体をDSO非対応と記すべき（SHOULD）である。これらは沈黙の読み方を指示するものであり、セッションの構成規則とは種類が違う。

空のエラータ欄という弱い信号

訂正の記録を確認した。2026年10月18日時点で、RFC 5625のエラータページにもRFC 8490のエラータページにも項目は表示されず、どちらの情報ページにも廃止や後継文書の表示はなかった。空欄は強い証拠ではない。文書が持ちこたえたことを意味する場合と、誰も訂正を提出していないだけの場合があり、外から見ると同じ姿をしている。

生成の記録も部分的にしか見えない。草案追跡システムのRFC 5625の記録と、同じくRFC 8490の記録は、ここでは完全な改訂履歴ではなくページ要約として参照できた。作業部会の系譜は読み取れる。代理の指針はDNSEXT、状態を持つ運用はDNSOPである。だが、どの草稿がどの一文を変えたのかは見えない。

そして最も重要な点として、どちらの文書についても実装の証拠は得ていない。本稿は、RFC 5625がゲートウェイの転送方法を変えたとも、DSOが販売中のリゾルバに載っているとも主張しない。それはソフトウェアについての経験的問いであり、ソフトウェアは今回調べた資料に痕跡を残していない。

番号が証明しないもの

IANAのDNSパラメータ登記は、オペコード値6を「DNS Stateful Operations (DSO)」としてRFC 8490に紐づけ、隣接するDSO Type Codes表に0x0001 KeepAlive、0x0002 RetryDelay、0x0003 EncryptionPaddingを並べる。登記項目は、著者が関与を続けるかに依存せず、退職で失効せず、誰の同意も要らずに台帳に残る。だが、どのソフトウェアがその値を送るかは語らない。

ベリスのようなエンジニアを扱うときの誘惑は、RFC番号をネットワークの証拠として読むことである。そうではない。番号は文書が公表され、レビューされ、目録に載ったことを記録する。記述されたものをどの機械が実行しているかは記録しない。適合は配備に現れ、配備は他者の決定である。

彼が確かに制御したのは、より狭く、より興味深い範囲である。文言を制御した。どの義務がMUSTになり、どれがRECOMMENDEDに留まるか。とりわけRFC 5625では、最も強い動詞を損害の禁止に使うか、機能の要求に使うか。五人との共著では、セッション確立を礼儀ではなく前提条件にするという選択を制御した。これらは実在する行為であり、名前のある個人に帰属でき、テキストの中に見える。

制御しなかったのは、それが意味を持つかどうかを決める部分である。実装者はRFC 8490を読み、セッション状態のコストをファームウェアの日程と秤にかけ、断ることができる。文書のどの一句も彼には届かない。それでも登記は番号を保持する。だからこそ登記は持続性の証人として、本文が採用の証人となるより信頼できる。