要約

  • 顧客 X が削除対象のドメインとその配下ホストを管理していても、顧客 Y の別ドメインがそのホストをネームサーバーとして使っていることがある。
  • 改名、pendingDelete、通知、復元、最終消去、DNS の回復は別々の出来事であり、一つの成功応答では安全性を証明できない。

削除コマンドは局所的に見える。スポンサーである顧客が自分のオブジェクトの削除を求め、サーバーが規則を確認して応答する。しかし RFC 9874 の中心事例では、顧客 X がドメインとその配下ホストをスポンサーする一方、顧客 Y のドメインも同じホストに関連付けられている。X は自分の関連を外せても、Y のドメインを書き換える権限はない。

RFC 5731 は配下ホストが残るドメインを削除しないよう求め、RFC 5732 は他オブジェクトに関連するホストを削除しないよう求める。これは整然とした削除が DNS 障害へ化けるのを防ぐが、正当な終了を望む顧客に無期限のサービス責任を負わせることもできない。

そこで実際に観測されてきたのが、ホストを削除対象ドメインの外へ改名する方法だ。保存された関連は残せる。しかし新しい親ドメインが登録可能なら、将来の登録者がそのホストを作り、依存ドメイン宛ての問い合わせを受け取る可能性がある。改名はリスクを消すのではなく、潜在的な制御権を移すことになる。RFC 9874 は、存在しないと推測した外部名への改名を明確に禁じる。

著名な公開再帰サービスを指すことも解決ではない。再帰サーバーは委任先が必要とする権威サーバーではない。AS112 名の流用も、汎用の犠牲ホストサービスではなく、本来の用途を外れて地域的な乗っ取りと保守負担を生み得る。

BCP 244 となった RFC 9874 は、安全な道を三系統に絞る。顧客が親ドメイン、アドレス、実際の権威 DNS を維持する専用犠牲ホスト。影響対象の詳細、他顧客への通知、復元能力を伴う明示的なホスト・関連削除。そして、将来利用可能になれば sacrificial.invalid を候補とする特殊用途ドメインである。文書は後二者が現在運用されているとは報告していない。

復元可能な方式では、ドメイン、配下ホスト、ドメイン間関連を pendingDelete の間も保持できる。公開 DNS はすでに停止して損害を予告するかもしれないが、最終消去前なら RFC 3915 の猶予期間に基づいて戻せる。要求受付、可逆状態、対応期限、不可逆な消去は、それぞれ別の時刻でなければならない。

通知にも限界がある。削除する顧客に影響対象を示せば、承認前に範囲を評価できる。RFC 8590 の change poll で他のスポンサーへ知らせることもできる。ただし poll の生成は、レジストラの読取、登録者への連絡、委任の修復、利用者の回復を証明しない。

関連数は無制限になり得るため、停止、復元、消去を非同期の小分け作業にする必要もある。これは負荷の解法であって権限の解法ではない。作業完了は、全関係の同時変更や全通知の到達、リゾルバーの収束を意味しない。

Heng Lu の現実の層に従えば、削除意図、保存された関係、受理された遷移、権威ゾーン、リゾルバー観測、利用者結果を分けて記録する。最小の初期仕様は狭い相互運用契約と地域ごとの承認・速度・復元判断を両立させる。動くコードを第一とする原則が求めるのは、成功コードではなく再現可能な証跡だ。

DNSSEC も万能ではない。複数ネームサーバーと署名は一部の失敗を抑えるが、攻撃者が握る一台の CDS/CDNSKEY を自動採用すれば、不一致をより深い制御移転へ変えかねない。

SAC125 と IETF 115 の Risky BIZness 資料は、レジストラによるネームサーバー管理の背景を示す。特定の事業者が現在脆弱だと立証する資料ではない。RFC 9874 はリスク類型への設計回答であり、事故報告ではない。

出典