要約

  • 新gTLDの増加、数百のドメインを持つ管理ポートフォリオ、DNSSEC更新の頻発によって、RZMSが扱う業務の形は変わった。
  • 再構築では申請種別ごとの承認基準、並行申請、API、独立して進化する技術検査が加わった。運用規則とアカウントの継続性を保つ責任は各TLD管理者に残る。

分析

申請の増加が業務の形を変えた

旧RZMSは機能不全に陥っていたわけではない。処理工程の自動化で正確性を高め、所要時間を短縮し、TLD管理者向けに一般的な作業を行えるセルフサービス画面も提供していた。変化したのは業務量と種類だ。新gTLDプログラムで委任数が増え、一部の組織は数百のドメインを管理し、DNSSEC署名鍵の更新も以前より頻繁になった。

Daviesは2022年5月、ICANNのエンジニアリング・情報技術チームがモジュール型の再構築を決め、小規模な横断チームが数年かけて進めたと説明した。彼の記事は背景と運用上の選択を記録したもので、本人が単独で開発したという主張ではない。目的は、固定された一つの処理手順に縛られず、新しい申請パターンを受け止めることだった。

拡大する業務と分割された機能

旧RZMSは処理の自動化で正確性を高め、時間を短縮し、TLD管理者がよく使う手続きを自分で進めるポータルも備えていた。その後、新gTLDの増加により、数百のドメインを管理する組織が現れ、DNSSEC署名鍵の更新のような依頼も増えた。Daviesによれば、ICANNのエンジニアリング・IT部門が再構築を決め、部門横断の小規模チームがモジュール型の基盤を開発した。彼の文章は設計の説明であり、本人がソフトウェアを書いたという主張ではない。

IANAの変更履歴では、2022年版に2人を超える承認者、依頼種別ごとの承認閾値、API、同時進行する依頼への対応が記録されている。技術的な適合性検査も別システムとなり、依頼処理とテストを個別に改良しやすくなった。

この仕組みは根区全体の判断を一つの画面に置き換えるものではない。IANAはTLD管理者の指定、技術的な委任情報の記録、関連名簿の公開を担う。公式の概要は、管理者や連絡先を記録するRoot Zone Databaseと、別に配布されるDNS根区ファイルを区別する。RZMS上の承認は申請を進めるための手続きであり、それだけで変更の妥当性や実装が決まるわけではない。

多要素認証は後から段階的に加わった

多要素認証（MFA）は2022年の初期設計では延期された。Daviesは、各国で使えること、数年単位でログインしない顧客にも対応することを理由に挙げた。普段使わないアカウントほど、必要な瞬間に戻れるかが重要になる。

同年の根区更新プロセス研究では、回答者の82%が当時の安全策を十分と評価し、18%が潜在的な弱点を挙げた。その一部はMFAを提案した。これはその調査に回答した人々の意見であり、現在の全利用者に当てはまる評価ではない。研究は当時の申請手続きが固定の承認者だけに限定されていない点も扱い、Daviesはその制約を踏まえて一律のMFAを急がなかった。

2025年、DaviesはMFAと本人確認を任意機能として発表した。2026年7月改訂のIANA現行案内では、本人確認はMFAの有効化とAPI利用には必要だが、その他の用途では義務ではない。APIはアカウント権限の範囲内で動作する。OTE環境は連携を試す場所で、本番には反映されないとAPIガイドは説明する。

本人確認はアカウント回復を助ける一方、情報の流れを生む。第三者事業者が身分証と自撮り画像を保持するのは最長7日。IANAはアカウント有効中、法的氏名、生年月日、確認結果を保持する。本人確認と個人情報の扱いは、同じアクセス設計の両面だ。

規模への適応は運用側の責任も増やす

承認基準を設定でき、複数の申請を並行して扱えるようになっても、各組織に適した方針をソフトウェアが選ぶことはできない。TLD管理者は承認者を最新に保ち、申請種別ごとに必要な人数を決め、まれにしか使われないアカウントの復旧手段も維持する。承認者が少なすぎれば継続性が一人に依存し、多すぎれば通常の変更が調整待ちになる。

APIはプログラムからの操作を可能にするが、利用者の権限を迂回しない。IANAのOperational Test and Evaluation環境では、本番に影響させず連携を試せる。技術適合性検査も承認とは別の工程だ。技術条件を満たしていても申請が承認されたことにはならず、承認も検査や実装の代わりにはならない。

RZMSはルートゾーン管理の一部にすぎない。IANAはTLD管理者を指定し、技術的な委任データを記録し、DNSルートゾーンファイルとは別のRoot Zone Databaseを公開する。2026年6月の変更履歴ではバージョン3.6.1に達している。再構築が残したのは適応可能な作業基盤であり、各組織が適切に設定する保証ではない。ローカルの承認規則、アカウント復旧、技術検査が実際の業務量に追いつくかが運用の質を左右する。

参考資料