要約

  • RFC 5731のclientTransferProhibitedとserverTransferProhibitedは、ドメインオブジェクトの移管要求を拒否しなければならないという、狭く強い効力を持つ。
  • 接頭辞から状態を管理する側は分かるが、政策上の理由、人による承認、見直し期限、解除経路の安全性は分からない。理由の付記さえ任意である。
  • 移管拒否を説明するには、時刻付きの状態記録と、権限・根拠・期間・通知・解除手順を示す意思決定記録を結び付ける必要がある。

まず「拒否される」という事実を守る

移管禁止を単なる表示だと扱うのは誤りだ。RFC 5731は、clientTransferProhibitedまたはserverTransferProhibitedが付いたドメインについて、移管要求を拒否しなければならないと定める。規格に適合したサーバーの同一時点の状態を読めば、ある種類のコマンドが通らないことを確かめられる。

問題は、その事実に説明を付け足すときに起きる。画面上の「所有者が保護」「不正を検知」「レジストリロック」「安全」という言葉は、状態コードそのものではない。プロトコルが答えるのは、移管要求をどう扱うかであって、なぜその判断に至ったかではない。

RFC 5731では、状態の理由を説明する人間可読の文を添えてもよい。しかし必須ではない。案件番号、登録者の依頼、終了日、直近の審査記録がなくても、EPPオブジェクトは適合し得る。この空白は状態の効力を弱めない。理由を別の記録から取得すべきことを示している。

狭い意味は欠点ではない。異なる実装でも同じコマンド制約として比較できるからだ。同意、本人確認、契約、紛争履歴まで一語に背負わせれば、共通の状態コードは各組織固有の物語に変わってしまう。

接頭辞が示すのは操作面

clientで始まる状態は、スポンサーであるクライアントが追加・削除する。レジストリとレジストラの関係では、通常このクライアントがレジストラだ。serverで始まる状態はEPPサーバー、通常はレジストリが管理する。クライアントはサーバー設定の状態を変更できず、サーバーはローカルポリシーに従ってクライアント設定の状態を変更または上書きできる。

この構造から、どちら側の扉で制御されているかは分かる。だが、その扉を動かした人物や規則までは分からない。レジストラは新規登録時の既定値として設定することも、登録者の依頼で設定することも、期限付きのポリシーを反映することもある。レジストリ側の禁止は、紛争、償還期間、登録者が依頼したサービス、その他の運用条件から生じ得る。

ICANNの登録者向け説明も、クライアント状態はレジストラ、サーバー状態はレジストリが設定すると整理している。前者の解除は通常レジストラに求める。後者ではレジストラからレジストリへの連絡が必要になり、時間が延びる場合がある。これは問い合わせ先を示す情報であり、個別案件の理由を証明する情報ではない。

理由はポリシー側に残る

ICANNの移管ポリシーは、その適用範囲において、RFC 5731が扱わない判断手続きを記述する。登録名保持者の権限、移管先レジストラによる要求、現在のレジストラが拒否できる場合、理由を伝える義務が区別されている。

拒否理由は一種類の「セキュリティ」ではない。不正の証拠と保持者の本人性をめぐる合理的な争いは違う。所定の不払いと、保持者本人の明示的な異議も違う。裁判所命令や紛争手続、登録・移管直後の期間、登録者変更後の60日ロックには、それぞれの権限と期限がある。

同ポリシーでは、登録者に事前の合理的な解除機会と手段がない場合、Registrar Lockという状態だけを理由に移管を拒否できない。保持者の一般的な異議に基づくなら、明示的かつ十分な説明を受けた同意や、利用可能な解除方法も重要になる。状態は現在の拒否を実行する。ポリシー記録は、その拒否がなぜ正当で、どう終了するかを説明する。

したがって二つの記録が要る。状態記録には、ドメイン、正確な値、取得元、観測時刻、次に置き換えた状態を含める。意思決定記録には、適用したポリシーまたは契約、依頼者、責任を負う役割、承認証拠、開始時刻、期限または見直し条件、通知、解除経路を含める。

同じバッジの背後で三つの時計が動く

サーバーの時計は、権威あるEPP状態に禁止が入った時刻を示す。ポリシーの時計は、理由が成立した時点と、見直し・終了の時点を示す。観測者の時計は、RDAP、Whois、レジストラの画面、監視サービスが状態を取得して表示した時刻しか示さない。

公開応答はキャッシュされることがある。管理画面は内部変更後も以前のラベルを残すかもしれない。理由の有効期間が終わっても技術的状態の解除が遅れることも、逆にサーバー側の解除が集約サービスに届かないこともある。画面の画像は、ある時点の表示を証明するだけで、現在の権威状態、設定者、理由までは証明しない。

RFC 5731には時系列の崩れを検出する手掛かりもある。pendingTransferは、二つの移管禁止状態のどちらとも併存してはならない。前者は移管処理が受理され未完了であること、後者は要求を拒否することを意味する。同じデータに両方が出たら、まずキャッシュ、観測時刻、複数ソースの混在、表示処理を調べるべきだ。矛盾は再構成の必要性を示すが、それだけで不正やサーバー違反を断定できない。

「ロック中」は全操作の停止ではない

日常語のロックは、何も動かない印象を与える。EPPが移管、更新、削除、更新期間の延長に別々の禁止状態を用意し、DNS委任の公開にはholdを用いるのは、制御する動詞が違うからだ。移管を拒否していても、アカウント侵害による連絡先変更やクライアント状態の解除まで防げるとは限らない。

反対に、商用のregistry lockには、電話確認、別資格情報、複数承認、強制待機時間が加わる場合がある。契約と実運用で確認できるなら、それらは実質的な防御だ。ただしserverTransferProhibitedという表示だけから存在を推測してはいけない。

ICANNの安全管理に関する案内も、移管ロックを有用な追加層としつつ、絶対的な防御とはしていない。アカウント情報の保護や多段階認証を別に勧めている。評価では、アカウント認証、権限変更、authInfo、更新・削除状態、DNS委任、更新、回復連絡先を別々に記録する必要がある。

Hollenbeckの名前が証明する範囲

RFC 5730とRFC 5731の著者はScott Hollenbeckである。IETF Datatrackerの公開プロフィールでは、1990年代半ばからIETFに参加し、複数の作業部会で議長を務め、2004年から2006年までApplications Area Directorを務めたとされる。現在の一覧には39本のRFCがある。

これは大きな標準化貢献の証拠だが、Hollenbeckが個別のレジストリを運用し、ICANNの案件理由を決め、ドメインを管理している証拠ではない。氏名は仕様の来歴を示す。状態変更の来歴には、それを実施したレジストラやレジストリが必要だ。貢献と運用権限を分けることも、証拠を狭く読む実践である。

拒否結果と理由を、混ぜずに結ぶ

最小限の証拠束は、正確な状態、ソース、時刻、後続状態、利用できる場合はEPPのトランザクションまたは照会識別子から始まる。そこにポリシー版、依頼者、責任者、権限証拠、有効期間、見直し、通知、例外、解除手順を関連付ける。

実際に移管を試みたなら、要求時刻、認可情報の扱い、サーバー応答、pendingの有無、適用ポリシーに基づいて伝えた拒否理由、最終結果を第三の記録にする。秘密や不要な個人情報を公開する必要はない。許可された監査者が、正当な保護、運用ミス、紛争、侵害を区別できる来歴は失ってはならない。

最も強い反論は正しい。移管禁止は実際に役立つ。適合した状態なら移管要求を止め、既定のレジストラロックや厳格なレジストリロックは乗っ取りの摩擦を増やす。問題はプロトコルを信じることではなく、プロトコルのフィールド外にある判断まで証言させることだ。

Hollenbeckの仕様は「この要求を拒否する」と明確に答える。状態を付けた組織は、誰が、何を根拠に、いつまで、どの手順で解除できるかを答えなければならない。ロックは移管を止める。説明を成立させるのは帰属可能な証拠である。

出典