要約

  • ICANNのTechnical Study Group（TSG）が検討した例では、DNS名は世界のDNSから外れても、別の名前システムにある同じ名前を登録者が維持できる場合がある。そのシステムの規則が継続を認め、登録者もそれを望むことが条件だ。
  • 「同じ文字列、同じ管理者」という原則を運用するには、各変更を誰が認めるのか、どの記録で完了を確かめるのか、途中の不一致をどう封じ込めるのかを決めておく必要がある。

期限日に何が終わるのか

登録者が example.tld のDNS登録を更新せず、別の名前システムにある同じ名前は残したいとする。これはTSGの初期報告書が扱う想定例であり、実際の事故を記録したものではない。DNS名は世界のDNSで引けなくなる。一方、別のシステムでその名前が失効しない仕組みなら、登録者の希望に応じてそちらだけを有効のまま保つことができる。

反対に、別の名前も残さないなら、一つのDNSレコードを消すだけでは済まない。報告書が描く順序では、すべてのシステムで名前を無効にし、割り当てを解除し、連携対象から外す。その後にはじめて、名前を再び取得可能にする。期限切れは単一の削除命令ではなく、どの状態を残し、誰が決定し、次の登録者へいつ渡すかという一連の判断になる。

だから失効は、技術的な後片付け以上の意味を持つ。「同じ文字列、同じ管理者」は有用な条件だが、ある時点で記録が一致しているだけでは足りない。更新、登録者変更、登録業者の移管、停止、外部からの措置があれば、誰が制御しているかも変わりうる。変更を始めたのは誰か、両方のシステムが受理したか、古い管理者の対応名がまだ動いている間に新しい登録者へ渡していないかを追える必要がある。

技術報告が承認を意味するわけではない

ICANNは、世界のDNSにある汎用トップレベルドメイン（gTLD）と代替名前システムが同じ文字列を使うサービスについて、DNSの安全性と安定性を保てるかをTSGに検討させた。2026年8月10日の初期報告書は草案として公開されている。特定のサービスを承認した文書ではなく、統合の採用を推奨するものでも、特定方式だけを求めるものでもない。登録局の共有登録システム（SRS）に集約する方式と、統合元帳に相当するUnified Source of Truth（USoT）を使う分散方式が検討されている。

ICANNの公開コメントページは、この種の登録局サービスを提供する登録局がそれぞれRegistry Services Evaluation Policy（RSEP）を通じて審査を受けると明記する。TSG報告書は将来の個別審査や契約条項づくりの材料となり、契約案は別の公開コメントにかけられる。コメント期間は9月21日に終了し、同ページでは報告書の期限を2026年11月16日としている。

共通の技術検討で同じ質問を繰り返さずに済んでも、個々のサービスが必要な情報を持つか、別システムの状態を観測できるか、食い違いを解消する権限を持つかまでは分からない。一般原則を検証可能な約束へ変える場所は、個別のサービス申請と契約だ。

集約方式にも分散方式にも証明責任がある

変更が登録局のSRSを通るなら、DNS名と代替名の公開を登録局が調整しやすくなる。一つのドメインオブジェクトと一人の登録者を対応づける設計は、関係を読み取りやすくする。それでも、共有SRSがあるだけで管理者の同一性まで証明できるわけではない。報告書は、そのために十分な情報か信頼できる契約上・技術上の保証が必要だとする。

USoTによる分散方式では、記録や実行を複数のシステムに置ける。その代わり、更新中に片方だけが新しい状態になった場合に何を正とするのか、各参加者へどう通知するのか、遅延や応答の食い違いを誰が判断するのかを示さなければならない。共通の情報源という名称だけでは、障害中の利用可否は決まらない。

登録者の内部移転は、観測できる範囲の違いをよく表している。登録業者が自社の業務システムだけで登録者を変更すると、登録局がその事実を知らない可能性がある。継続的な識別子などがなければ、「同じ管理者」という保証は契約遵守に委ねられる。DNS名と代替名が別々のオブジェクトで、異なる管理者にひもづく場合、報告書は一つの命令で双方を移転する登録局の手続を解決策の一つとして挙げる。

停止の意味も分けておくべきだ。TSG報告書は、統合名のサスペンションをすべての名前システムに同時適用するとしている。濫用や裁判所命令のような外部理由による無効化についても、関係するシステム全体で止める考えを示す。一方、登録業者がDNS解決だけを止めるclientHoldは、代替名まで自動的に無効にする理由にならない。原因と操作を一つの「停止」表示にまとめると、利用者には適用された規則も残る権利も見えなくなる。

公開コメントは利用者に見える状態を問う

UnregistryがICANNのコメント欄に提出した意見は、TSGの結論を支持しつつ、登録局側と比べて利用者側の要件が薄いと指摘する。統合の状態を見えるようにし、同期が解決できないときの安全な振る舞いを決めることを提案した。これは一提出者の意見であり、合意済みのルールではない。

インド電子情報技術省の提出は、RSEP審査の前に要件を測定・検証できるようにすることを求めた。例として、取引状態の明確化、未解決取引の上限、障害時の保護、試験済みの停止計画、失効後の再割り当て対策、独立した安全性試験を挙げている。ここに書いたのは同省の提案であり、ICANNが採用した要件ではない。

Intellectual Property Constituencyの意見は、権利保護の問題がより広い政策議論に残されていると述べた。技術的な記録を同期できても、誰が名前を持つべきか、衝突にどう救済を与えるか、影響を受けた人がどこに申し立てるかは決まらない。

個別サービスを審査するなら、誰が更新、移転、停止、削除を許可するのか、各システムに何の確認が届くのか、未完了の処理を何時間放置するのかを問う必要がある。対応する代替名がまだ動いている間にDNS名が再割り当てされない仕組みも必要だ。問題が起きた後に誰が記録を修正し、異議を審査するのかも、運用開始前に示すべきだ。

状態遷移を記録に残す

必要なのは登録情報の複製ではない。変更をたどれる記録である。どの役割が、どの規則の版を根拠に開始したのか。変更前と目標の状態は何か。どのシステムが対象で、どの確認がいつ届いたのか。応答がなければ再試行するのか、対象を封じ込めるのか、元に戻すのか。利用者への通知と再審査の道筋はどこか。こうした情報を残せば、公開画面は「有効」「保留」「停止」「未確定」といった必要最小限の状態を示し、個人情報を含む監査証拠は限定された相手が確認できる。

これはTSGが採択した要件ではなく、今後のサービス設計に対する提案だ。責任は複数の組織にまたがる。登録業者は顧客関係を把握し、登録局はDNSの公開を制御し、代替システムの運営者はもう一方の記録を実行する。状態が分かれた場合の実害は、二つの内部記録を見られない登録者や利用者に及ぶ。後から経緯を再構成できなければ、契約に書かれた役割も実際には追及しにくい。

ICANNのRSEPポリシーと実施メモは、サービスの説明と外部利用者への影響評価を求めている。次の審査では、TSGの共通原則を、開始前に試験でき、開始後にも再検証できる条件へ落とし込めるかが焦点になる。「同じ文字列、同じ管理者」は静止画の条件だ。ガバナンスの仕事は、その関係が異なるシステム、権限、失敗を越えて続くことを示す点にある。

出典