要約

  • 2026 年 2 月の最終モデルでは、将来の Governance Phase において、違反が RSS に重大な脅威をもたらす極端な場合、Security Incident Reporting が RSO の運用を停止できる。もっとも、最初の 11 のマイルストーン、公開評価、意見募集、Council の正式投票を経て初めて有効になる権限であり、現時点で発動済みだと示す公文書は確認できない。
  • 恒久的な除外は Designation and Removal の別経路である。是正の機会、Council への勧告、最終承認、RSSAC030 が示す三つの DNS ルート情報源からの秩序ある削除を伴う。SIR の一時停止がそれらの情報源に及ぶのか、異議申立てに執行停止効果があるのか、復帰を誰が決めるのかは書かれていない。
  • Milestone 12 の前に、停止から復帰または DNR 移管までを追う版管理された継続性記録が必要である。公開部分は権限、範囲、期限、是正、異議申立て、終結状態を示し、攻撃に役立つ証拠は保護された別紙に置けばよい。

「停止する」の後に文が続かない

Root Server System Governance Working Group の最終報告書は、単なる理念文書ではない。Council、Secretariat、参加するステークホルダー、五つの機能、三段階の実装、十三のマイルストーンを具体的に並べている。

その中で最も強い動詞が SIR の権限に現れる。将来の SIR は、セキュリティ事故を調査し、データと協力を求め、脆弱性が見つかれば改善を命じ、セキュリティ方針への適合を執行し、是正措置を課す。さらに、違反が Root Server System に重大な脅威を及ぼす極端な場合には、RSO の運用を停止できる。

緊急時の手段としては理解できる。重大な危険を把握しても、統治機関が報告書を作るだけで封じ込められないなら、その監督は実務に届かない。

しかし、最終モデルは停止の対象を定義していない。新しい統治構造における資格だけが停止するのか、特定のサービス義務なのか、一部の設備やインスタンスなのか、あるいはルートサービスを世界に知らせる情報源まで変更するのかが不明である。

そして報告書には reinstatement に相当する明示的な状態がない。調査、是正、異議申立て、恒久的除外はある。危険が解消したとき、誰がどの基準で停止を解除し、技術的な準備と制度上の復帰をどう結ぶかは将来の手続きに残されている。

これは現行 RSO の安全性を疑う話ではない。ICANN や RSSAC、IANA が今すぐ停止命令を出せるという話でもない。権限の入口に対して出口を同じ精度で設計する必要がある、という実装前の論点である。

提案の受領と権限の発動は別である

このモデルの防波堤は、段階的な実装にある。

Initiation Phase では Council と Secretariat を設けるが、権限は意図的に限定される。Establishment Phase で初めて、SAP、FRM、PME、SIR、DNR の各機能を確定し、憲章、セキュリティ方針、性能評価、資金、指定と除外、適正手続き、異議申立てを整備する。

Governance Phase への移行条件も軽くない。各機能が設置され、実際に動いていること。主要方針を Council が批准していること。Milestones 1–11 の達成を包括的な公開評価書にまとめること。移行前に公開意見募集を行い、参加ステークホルダー・コミュニティーの合意を確認し、Council が正式投票で準備完了を決めること。Milestone 12 は、その後に初めて完全な統治権限を認める。

確認できる公開記録はその地点に達していない。GWG は 2026 年 2 月 18 日に報告書を合意で承認し、20 日に ICANN コミュニティー、Board、IETF/IAB、RSSAC、RSO へ提出した。ICANN Board 議長は感謝を伝え、今後の道筋に期待すると返信した。採択や発効を宣言した文書ではない。運営計画も将来の Board 採択を前提にしており、その後の実装を別の決定に委ねている。

したがって、本文で扱うのは「将来、停止を可能にするモデル」である。提案に書かれた能力と、現行組織が持つ実行権限を混同してはならない。

SIR の時計と DNR の時計

最終モデルが SIR と DNR を分けたことには意味がある。

SIR は事故から始まる。可用性、完全性、機密性に重大な悪影響が生じたとき、事実が揃う前でも封じ込めが必要になる。報告、事後検証、統制、監査、脆弱性対策、対外説明を担い、Governance Phase では緊急行動と一時停止に踏み込む。

DNR は運用者の適格性と地位を扱う。PME が見つけた性能問題や違反を調査し、期限を定めて是正を求め、十分な是正機会を与えても基準を満たさない場合にのみ Council へ除外を勧告する。最終承認は Council が行い、IANA と連絡しながら秩序ある停止と DNS ルート情報源からの削除を調整する。

一時停止を恒久的除外の簡易版にしないための分離である。同時に、恒久手続きを待つ間に重大な危険を放置しないための分離でもある。

問題は二つの時計をつなぐ記録がないことだ。SIR の停止は、是正完了、異議申立ての成功、より狭い措置への変更、あるいは DNR の正式審査へ進み得る。どの時点で案件の管理責任が移り、中間状態を誰が更新し、どの決定が SIR 案件を閉じるのかは示されていない。

「是正済み」は技術的・手続的な証拠である。「復帰承認」は権限を持つ者の決定である。両者を別の状態として記録しなければ、修復が終わっても停止だけが残る可能性がある。

RSSAC030 が示す三つの層

RSSAC030 は、制度上の言葉が技術上の結果に変わる地点を短く示している。

IANA Functions Operator は、root hints ファイル、ルートゾーン、root-servers.net ゾーンという三つの主要情報源を管理する。そこにはルートサービスの名称と RSO が管理する IPv4・IPv6 アドレスの関係が含まれる。組織の情報がこれらに掲載されることは、その組織を RSO として識別し、通常の DNS の仕組みからサービスを見つけられるようにする。

Functional Model は DNR の恒久的除外について RSSAC030 を明示的に引用している。一方、SIR の停止について同じ記述はない。

したがって、少なくとも三つの層を区別しなければならない。

一つ目は統治上の状態で、権限ある機能が RSO を停止中とする。二つ目は運用上の状態で、事故対応のため特定の設備、インスタンス、義務が制限される。三つ目は情報源の状態で、IANA が管理するファイルやゾーンが変更される。

統治上の停止から情報源の削除を自動的に推定してはならない。事故時の技術的隔離は永久的除外ではない。もし一時的な SIR 措置が情報源を変えるなら、DNR と Council の正式手続きを先取りしない独立した根拠、範囲、復元方法が必要である。

継続性記録が決めるのは、どの層を使うべきかではない。実際にどの層が変わったかを曖昧にしないことである。

異議申立ては運用復帰命令ではない

モデルには、SIR の決定を Council に異議申し立てできる仕組みがある。DNR の決定にも直接の異議申立てがあり、除外勧告には Council の最終承認が必要である。SIR には年次報告、ピアレビュー、定期的な外部評価も課される。

それでも、異議申立てが提出された瞬間の運用状態は決まらない。

申立てによって停止は自動的に止まるのか。Council は暫定的な執行停止を命じられるのか。審査中に影響のない部分のサービスを続けられるのか。判断が覆った場合、すべての地位は直ちに戻るのか、それとも脆弱性対応後の技術確認が必要か。是正が十分であることを誰が認定するのか。

ネットワークの時間と適正手続きの時間は一致しない。封じ込めは分単位、証拠の検討と反論は日単位になることがある。同じ速度を強制するのではなく、即時措置、審査中の暫定状態、最終判断を分け、その間の移行を記録すべきである。

この連結がなければ、Council が法的・制度的な結論を検討する一方で、SIR、RSO、IANA、RZM は別々の理解で技術状態を扱うことになる。

事故の詳細を隠しても、権限の状態は示せる

RSSAC062 は公開範囲を考える上で重要である。報告対象は RSS の可用性、完全性、機密性に重大な悪影響を与える事故であり、事故対応を報告作業が妨げてはならない。最優先は解決である。

詳細な説明には Traffic Light Protocol を使える。将来の攻撃を助ける情報は報告から除外すべきであり、提出経路には認証と機密性が必要とされる。その一方で、RSS GS は TLP:Clear の公開版を適時に出すべきだとされている。

停止と復帰の記録も同じ二層構造にできる。公開するのは、権限、一般化した発動理由、措置の範囲、開始時刻、見直し期限、現在の結論である。秘密鍵、未修正の脆弱性、内部構成、非匿名の問い合わせログ、攻撃の再現手順は保護された別紙に置く。

別紙の管理者、アクセス区分、必要に応じた完全性ハッシュは公開できる。公開すべきなのは権力の行使であって、攻撃面ではない。

モデルを擁護するなら、出口を完成させるべきだ

Functional Model がすべての事故手順を書かないことには合理性がある。Establishment Phase で、実運用を知る人々が SIR と DNR の憲章、IANA との連携、機密証拠の扱い、RSO の自律性を具体化する方がよい。

発動要件も無限定ではない。「極端な場合」「不履行」「重大な脅威」という三つの限定がある。モデルは機能を分離し、Council への異議申立て、ピアレビュー、外部評価、除外前の是正機会、全面移行前の公開協議を置いている。

また RSS 全体には冗長性と多様性がある。実際に一つの運用者から重大な危険が生じたとき、限定的な隔離によって集合的サービスを守る選択肢が必要になる可能性はある。

だからこそ、出口は権限付与の条件にすべきである。Milestone 7 はセキュリティ方針、事故対応、エスカレーションを作る。Milestone 8 は指定、除外、適正手続き、異議申立てを作る。Milestone 10 は追加の説明責任と審査を整える。三つを別々に「完了」とせず、一つの停止から復帰または DNR への状態遷移として検査する必要がある。

Heng Lu の Running-Code Primacy は、制度上の宣言を実際の運用効果で限定する視点を与える。「停止中」という象徴的地位だけでは、独立した運用者や IANA が同じ結果を実行する保証はない。最小限の技術作用を明示し、局所的に確認できる形にしなければならない。

継続性についての指摘も同様である。守るべき対象はルートサービス、記録、セキュリティ連鎖、利用者であり、統治機関の全権限や個々の運用者の地位そのものではない。全体を守るための停止はあり得る。全体を守り続けるためには、停止後の有効な状態も必要である。

停止から復帰までの継続性記録

Milestone 12 より前に、Council は SIR の停止ごとに共通の版管理記録を義務づけるべきである。緊急措置と同時に最小限の項目を開き、事故が安定してから補完する。記録作成が封じ込めを遅らせてはならない。

公開部分には次を含める。

  • 固定された案件番号と対象 RSO；
  • 決定機能、根拠、適用方針の版、責任を持つ役割；
  • 機微情報を除いた発動分類と緊急手続きの有無；
  • 統治上の地位、サービス義務、設備範囲、ルート情報源への作用；
  • 発効時刻、初回の最長期間、次回の強制見直し；
  • RSS 全体の継続性を守る措置；
  • 是正項目と公開可能な完了状態；
  • 保護証拠の管理者と区分；
  • 異議申立て、執行停止申請、実際の判断；
  • 復帰を決める権限と基準；
  • 技術的な準備確認と独立・ピアレビュー；
  • 延長ごとの新しい決定、日付、理由；
  • 復帰、縮小、代替措置、DNR 移管のいずれかの終結；
  • IANA、RZM、ルート情報源への別個の行為と、その取消・復元状態。

言葉を状態として厳格に扱う必要がある。異議申立て済みは執行停止済みではない。是正完了は復帰承認ではない。DNR 移管は除外決定ではない。除外決定は情報源の変更完了ではない。

否定形も記録する。「ルート情報源への行為なし」「異議申立てなし」「復帰判断待ち」は、空欄よりはるかに正確である。空欄は未発生、遅延、担当不在を区別できない。

この記録は RSO に拒否権を与えない。公開者に事故対応を任せない。危険な証拠を出さない。緊急権限を、責任主体、範囲、期限、終結のある状態にするだけである。

証拠の限界

確認した公文書は、ICANN Board による正式採択、Governance Phase への移行、このモデルに基づく RSO の停止を示していない。現行の運用者について、安全性、違反、能力の判断を行う根拠もない。

最終モデルに復帰という語がないことは、将来の憲章が手続きを作れないという意味ではない。作成と検証を権限発動前の条件にすべきだという意味である。また停止の技術的対象が定義されていないため、本稿は root hints、ルートゾーン、root-servers.net が必ず変更されるとは主張しない。

公開を求めるのは権限と状態である。攻撃を助ける情報や正当に保護される運用データは、非公開のままでよい。

情報源

  1. ICANN — The Root Server System Governance Structure、2026 年 2 月 18 日
  2. ICANN — Governance Principles for the Root Server System
  3. Brad Verd — GWG 最終報告書の提出
  4. Tripti Sinha — ICANN Board 議長から GWG への返信
  5. ICANN Public Comment — Functional Model for Root Server System Governance
  6. RSSAC030 — Statement on Entries in DNS Root Sources
  7. RSSAC058 — Success Criteria for the RSS Governance Structure
  8. RSSAC062 — Security Incident Reporting
  9. RSSAC055 — Principles Guiding the Operation of the Public Root Server System
  10. ICANN — FY2027–2031 運営・財務計画案
  11. Heng Lu — Running-Code Primacy
  12. Heng Lu — The Registry Continuity Fallacy
  13. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile