要約

  • Client Xが親ドメインと配下ホストを管理していても、Client Yのドメインがそのホストを権威サーバーとして利用している場合、Xだけでは依存関係を解消できない。
  • 存在しないと想定した外部名や非権威の再帰サービスへの改名は、障害や乗っ取りの危険を他者へ移すため、RFC 9874は使用を禁じている。
  • クライアント横断削除記録は、権限、依存範囲、DNS状態、通知、redemption期限、復元、最終パージを別々の証拠で閉じるべきである。

Client Xはdomain1.exampleを削除したい。配下のns1.domain1.exampleもXの管理下にある。ところがClient Yのdomain2.exampleがそのホストをネームサーバーとして使っている。XはYのドメインを更新できず、その関連自体を参照できないこともある。レジストリのEPPサーバーだけが両側を知る。

ここで返る成功応答は、サーバーが当時の方針に従って要求を受理したという証拠である。Yの委任が安全なままか、通知が届いたか、復元できるか、バックグラウンドの削除が終わったかまでは証明しない。

削除制約が守ってきた三つの整合性

RFC 5731は、関連する配下ホストが残るドメインを削除すべきではないとする。RFC 5732も、他のオブジェクトに関連付けられたホストを削除すべきではないとする。理由は単なるデータ整理ではない。

第一はDNSである。親ドメインを消せば配下ホスト名が解決不能になり、ホストを消せばそれを参照する委任が失敗する。第二はクライアントとサーバーの状態差である。サーバーが暗黙に関係を消すと、クライアント側の登録記録が現実から外れる。第三はレジストリ内部の参照整合性である。

クライアントをまたぐと、決定主体と損失主体が分かれる。Xを永久に止めることも、Yに無告知で負担を押しつけることも解決ではない。必要なのは、誰が何を知り、何を承認し、どこまで戻せるかを残すことだ。

sacrificial hostは無人地帯ではない

ホスト名を変更して元のドメインから外部化すれば、削除条件を満たせる。この移された名前がsacrificial hostである。しかし依存関係は消えず、新しい名前の管理者へ移る。

「存在しないはず」の外部ドメインを使えば、削除側はDNSを運用しなくてよい。だが後から第三者が親ドメインを登録し、ホストを作れば、残った委任への問い合わせを制御できる。RFC 9874は、この観測済み手法をMUST NOTとしている。

有名な再帰DNSサービスのアドレスをglueに入れても権威サービスにはならない。SERVFAILなどが返り、再試行が増幅する可能性がある。これも使用してはならない。

許容される自主管理方式では、クライアントが親ドメインを保持し、指定アドレスで権威DNSを運用する。乗っ取りは避けられるが、更新、ロック、サービス継続、組織変更時の承継が長期義務になる。改名成功は責任の終了ではなく、保管先の変更である。

復元可能な削除は中間状態を作る

別の方式では、サーバーが他クライアントのドメインとの関連を扱いながら明示的削除を許す。実行前に影響の詳細を提示し、EPP Change Pollなどで当事者へ通知し、RFC 3915のredemption期間に復元可能性を残せる。

ドメイン、配下ホスト、他ドメインとの関連をpendingDeleteとして保持すれば、DNSからは一時的に外れても関係グラフは直ちに失われない。誤操作、悪意ある操作、想定外の影響が判明したとき、期限内ならrestoreで戻せる。期間の終了後に初めて完全なパージへ進む。

関連数に上限がないため、無効化、再有効化、パージは複数の非同期処理になり得る。要求受理時刻と、全対象の完了時刻は同じではない。

記録はコマンドではなく依存グラフを追う

最小の記録には、認証クライアント、transaction ID、対象、時刻、サーバー方針、他者へ影響を及ぼす権限根拠が要る。次に、列挙時刻と方法、配下ホスト、影響ドメイン数、開示可能なスポンサー、見えない範囲を固定する。プライバシーのため名称を伏せても、件数と処理有無まで曖昧にする必要はない。

DNSについては、変更前後の権威名とアドレス、想定されるゾーン状態、実測、DNSSECとDSの条件、採用したRFC 9874方式を残す。判断については、警告、提示された影響詳細、必要な人手承認、選択理由を残す。

他クライアントへの通知は、キュー投入、配信、確認を追う。可逆性についてはredemption期限、restore権限、保持した関連、復元試験を記す。最後に非同期task ID、部分失敗、再試行、最終パージ、事後DNS観測と完了承認者を結ぶ。

これはRFC 9874が定める新しいEPPフィールドではない。BCPが示した統治上の空白に対するDaniel Kadeの運用提案である。

DNSSECも証拠の一貫性に依存する

DNSSECや複数サーバーは一部の危険を軽減する。しかし一台を攻撃者が支配し、自動DS更新が全サーバーのCDS/CDNSKEY整合性を確認しなければ、攻撃者の情報がDSへ反映される可能性がある。CSYNCにより正規サーバーが外されることもあり得るとRFC 9874は警告する。

したがって、DS自動化の有無、問い合わせ先、回答の一致、変更を受理した権限を記録する。「DNSSECあり」は機能の表示であって、今回の管理移行が安全だった証明ではない。

成功を一文に押し込まない

RFC 9874は、クライアント維持の権威sacrificial host、詳細・通知・restoreを伴う明示的削除、または適切な特殊用途名を推奨する。便利さの費用を将来の登録者、resolver、無関係な設備へ渡す手法は退ける。

削除そのものを禁じる必要はない。「サーバーが受理した」「依存を数えた」「当事者へ通知した」「まだ復元できる」「パージが完了した」を別々に証明すればよい。一つの緑色表示が五つを代弁した瞬間、成功は監査不能になる。

出典