要点
- 15時47分 UTC の NANOG メーリングリスト返信は、裁判所命令による
.com制限の実行層を訂正した。テキサス州当局の発表が名指ししたのは、顧客のレジストラではなくレジストリ運用者の Verisign だった。 - ICANN によれば、EPP の
clientステータスはレジストラ、serverステータスはレジストリが設定し、後者が優先する。serverHoldではドメインが DNS で有効化されない。 - その後の Verisign RDAP には、
server holdに加えて削除、移管、更新を禁止するサーバー側ステータスが表示された。観測時の状態は確認できるが、各制限の開始時刻までは分からない。 - レジストラは本人確認と上位への連絡に不可欠だが、レジストリ設定を自力で消せない。継続計画にはレジストリ監視、法務経路、単一ドメインが失われても使える連絡手段が必要になる。
レジストラの管理画面に入れても、ドメインが DNS に残っているとは限らない。
日曜日の NANOG メーリングリストで得られた運用上の成果は、この単純な区別だった。議論は、テキサス州の命令が州外のサイトに及ぶことをめぐる政治的、法的な主張から始まった。David Conrad はそこに制御面の訂正を加えた。政府発表を読む限り、制限を実行したのは顧客側のレジストラではなく、.comレジストリを運用する Verisign だったという指摘だ。
これは一人の参加者による投稿であり、NANOG の公式見解でもコミュニティの合意でもない。それでも障害対応図を正確にする効果がある。「レジストラに連絡できるか」だけでは不十分で、サーバー側ステータスを誰が変更できるのか、その組織はどの法域にあり、レジストラからどの経路で上申できるのかを把握しなければならない。
一つの名前を二つの層が管理する
テキサス州司法長官室は7月1日、.comレジストリを維持する Verisign に対し、motherless.comを「registry lock、hold、または類似の状態」に置くよう命じる令状を得たと発表した。これは同室による説明である。今回、令状本文そのものは確認していないため、発表文の法的評価を裁判所の判断理由として扱うことはできない。
技術的な境界は ICANN の EPP ステータス解説の方が明快だ。clientで始まるコードはレジストラが設定する。serverコードはレジストリが設定し、クライアント側コードより優先する。ICANN はserverHoldについて、レジストリ運用者が設定し、対象ドメインを DNS で有効化しない状態だと説明している。
ICANN の.com契約ページは VeriSign, Inc.を運用者としている。後に Verisign の RDAP を照会すると、server hold、server delete prohibited、server transfer prohibited、server update prohibitedの四つが返った。この照会はサーバー側制御が存在したことを示すが、各コードがいつ付与されたかは示さない。
したがって「ドメインがロックされた」という表現だけでは事故記録として足りない。不正移管対策として任意に利用する Registry Lock サービスとserverHoldは同じではない。serverHoldだけで、ほかの三つの禁止状態を代表させることもできない。運用、セキュリティ、法務は、正確なコードと変更権限を持つ主体を共有する必要がある。
レジストラは必要だが最終スイッチではない
訂正によってレジストラの役割が消えるわけではない。ICANN はサーバー側ステータスに問題がある場合でも、登録者がまずレジストラへ連絡するよう案内している。レジストラは登録者を認証し、見えている状態を説明し、レジストリに解除を求める。しかし、上申できることと自ら解除できることは別だ。
サーバー側で移管が禁止されていれば、別のレジストラへ移る方法は使えない。親ゾーン側にserverHoldがあれば、権威 DNS 事業者を変えたりゾーン内容を書き換えたりしても復旧しない。レジストラの支援は不可欠でありながら、それだけでは足りない場合がある。
.comの依存関係には、登録者アカウント、レジストラ、Verisign、権威 DNS 運用者、そして措置を命じたり争ったりできる法的主体が含まれる。別の TLD を使えば、レジストリ運用者、契約、法域も変わり得る。末尾の文字列はブランドだけでなく、制度上の制御経路も選んでいる。
Web 監視だけでは制御点を特定できない
最初の症状は名前解決失敗や Web サイトへの接続不能だろう。しかし、その症状だけでは、ゾーン設定ミス、DNSSEC 検証失敗、権威サーバー障害、レジストラによるclientHold、レジストリによるserverHoldを区別できない。登録データにネームサーバーが残っていても、親側が委任を有効化しないことがある。
運用者はリゾルバーの追跡結果と同時に、時刻付き RDAP 応答を保存すべきだ。server hold、サーバー側の移管、更新、削除禁止の変化には個別のアラートが必要になる。その担当者はレジストラで本人確認を行え、レジストリへの上申経路と法務担当を、停止したドメインのメールに頼らず呼び出せなければならない。
この区別は、セキュリティ保護と法的措置の混同も防ぐ。登録者が購入するレジストリロックは不正な変更を難しくするが、有効な命令からの免責を約束しない。逆に、サーバー側コードは技術状態を示すだけで、命令の適法性や妥当性を決める証拠ではない。
一つのドメイン停止は Web サイトだけで終わらない
企業メール、パスワード再設定、SSO コールバック、API、ソフトウェア更新、証明書検証、障害広報が同じ名前に依存することは多い。復旧連絡先までそのドメインのメールなら、組織は支配権を証明すべき瞬間に証明手段を失う。
強い計画は、障害前に依存関係を一覧化する。レジストラ、レジストリ、法律顧問の連絡先を対象ドメイン外にも保管し、緊急変更を承認できる人物を決め、独立した告知経路を試す。重要サービスを別名や別チャネルに分ける方法もあるが、二つ目のドメインがブランド、検索評価、契約上の同一性まで自動的に引き継ぐわけではない。
複数レジストラは、アカウント侵害やサポート集中のリスクを下げる。同じ TLD にある限り、レジストリは分散されない。複数 TLD ならこの層を分けられる一方、異なる運用者、方針、法域を抱える。目的は正当な命令を回避することではなく、故障境界を見えるようにし、停止後の即興を減らすことだ。
次の訓練は親側ステータスから始める
NANOG の投稿だけで、テキサス州法の妥当な範囲、事件の法的結論、.comの望ましい統治を決めることはできない。それには裁判記録と法的分析が必要だ。
今回確定できるのは、より狭い運用上の点である。レジストラがドメインを止めたとだけ説明するのは正確ではなかった。政府発表は.comレジストリ運用者を名指しし、ICANN のモデルではサーバー側コードが優先し、RDAP にもその層の制限が現れた。
次の継続性訓練は、こう始めるべきだ。今夜レジストリが自社名を DNS から外したら、誰が正確なコードを発見し、誰が変更権限者まで上申し、スイッチがレジストラより上にある間も何が動き続けるのか。