要点

  • ICANNの初期報告が対象とするのは、gTLDと一つ以上の代替名前システムで同じ文字列を使い、同じ主体が管理し、レジストリ運営者が調整する限定モデルである。
  • 報告は停止計画を必須にするよう勧告し、この統合は緊急バックエンドレジストリ運営者が維持する五つの重要機能には含まれないとみている。
  • 第1回パブリックコメントは2026年9月21日に締め切られる。現時点の文書は最終方針でも承認済みサービスでもなく、障害の発生を示すものでもない。

サービスの終了ボタンと、権限関係の終了は同じではない。

ICANNのTechnical Study Groupが8月10日に公表した初期報告は、代替名前システム全般を評価していない。検討範囲は「string+controller integration」と呼ぶ仕組みに限られる。世界共通DNSのgTLDと別の名前システムで文字列が同じであり、その名前を管理する主体も同じでなければならない。調整主体はレジストリ運営者である。技術運用を委託しても、方針上の責任は運営者から移らない。

報告は、適切な運用管理があれば、この限定モデルがRSEP上の重大なセキュリティーまたは安定性問題を生む可能性は低いとする。ただし危険がないとは述べず、統合そのものを推奨してもいない。他の方式を排除する文書でもない。

名前には複数の終わり方がある

初期報告は、名前を利用可能、登録集合への収容、割当て済み、留保、稼働、非稼働、停止、無効といった状態に分ける。この区別が必要なのは、「止める」という一語では権利の帰結が分からないからだ。

新規受付を止めても、既存名は残る。代替側で応答を止めても、その名が従来の登録者に留保されるのか、解放されるのかは別問題である。画面から消えても、分散台帳、キャッシュ、委託先のデータや契約上の権限が変わったとは限らない。

DNS名が譲渡された後も、代替側の同名IDを前の登録者が管理できれば、二つのシステムは技術的には動き続ける。それでも「同一管理者」という統合の前提は失われる。同じ文字列だけでは衝突を防げない。文字列、状態、管理主体の三つを揃え続ける必要がある。

IETF DNSOPの現行Internet-Draftも、名前のライフサイクル、管理権の検証、網羅性、同期を別々の課題としている。期限切れや譲渡後に同期が古いままだと、現在の登録者ではない人が統合IDを管理し得ると指摘する。この草案は作業中でありICANNの規則ではないが、入口の本人確認だけでは出口を保証できない理由を示している。

EBEROは追加サービスまで継承しない

gTLD運営者が重要機能を維持できなくなるおそれがあるとき、ICANNはEmergency Back-end Registry Operatorを起動できる。EBEROが守るのは、登録名のDNS解決、Shared Registration System、登録データディレクトリー、データエスクロー、DNSSECで正しく署名されたゾーンという五機能である。

代替名前システムとの統合は、その列挙の外にあると初期報告は読む。このため、EBERO運用下で統合を継続することは難しく、停止方法を申請時に準備すべきだとする。

これはEBEROへの批判ではない。緊急運用の権限と能力の境界を明示している。DNSレジストリの継続性を、周辺に追加した全サービスの継続保証として扱ってはならない。EBEROが五機能を維持できても、別の名前システムを運営、同期、解消できる証拠にはならない。

書面は実行結果ではない

報告は、レジストリサービスが何を可能にするかと、統合が成り立たなくなった場合にどう停止するかを明記するよう求める。十分な運用経験が蓄積するまでは、評価の一部として停止計画を必須にすることを勧告している。

よい計画でも、障害時につながらない委託先、失効した認証情報、未定義の中間状態に依存することがある。最後の操作を、すでにサービスを離れた登録者に求めるかもしれない。DNSが先に復旧し、代替側だけが古い状態を残す部分障害もあり得る。

ここから特定の失敗を予測することはできない。言えるのは、計画の存在と試験結果は証拠の種類が違うということだ。

Registry Services Evaluation Policyは、レジストリ運営者がサービスを追加、変更、削除する際の手続きを定め、ICANNが重大なセキュリティー、安定性、競争上の問題を評価する。初期報告は、採算のために最低技術要件を弱めてはならず、弱めた案は別サービスとして別途評価すべきだとも述べる。

停止試験でも同じ線を守るべきである。状態が残った試験は、終了条件を後から狭めて成功に変えるのではなく、例外を記録して設計を直す材料になる。

今回の文書はまだ形成過程にある。第1回コメントは9月21日までで、憲章は10月の第2案と再度の意見募集、2027年1月の最終報告を予定する。将来日程は完了済みの決定ではない。

確認した資料からは、特定レジストリの統合運用、現実の管理権分裂、当該サービスを含むEBERO起動のいずれも確認できない。問題提起は予防的である。事故の物語を作るのではなく、事故の前に必要な証拠を決めるための議論だ。

情報源