要約

  • draft-brown-epp-deleg-03 は、ドメインに結び付く DELEG レコードの照会、作成、追加、個別削除、全削除を EPP に載せる提案である。
  • 草案は DELEG と従来の NS が長く併存すると見込むため、レジストリが受理した一つの状態から、未整合の二つの公開委任が生じうる。
  • 変更完了の証拠は、EPP 取引からゾーン生成、親での公開、DNSSEC、権威応答、リゾルバ能力、キャッシュ、アプリケーション確認まで続かなければならない。

夜間作業のチェックリストには「EPP 更新成功」と「NS 応答正常」が並ぶ。両方にチェックが付けば、担当者は終了を宣言したくなる。しかし deleg:all で DELEG を全削除した作業なら、この二項目は同じ経路を見ていない。NS しか理解しない監視は、新しい委任経路が消えたことを検知しない。

第 03 版の原文は、パラメータを名前付きの deleg:param 要素として表し、XML 名前空間を更新し、deleg:all を追加した。未知の名前や不正な値を拒否する運用規定も入った。Datatracker の現行ページと履歴によれば、これは個人 Internet-Draft であり RFC stream を持たない。IETF 標準、IANA 割当済み拡張、実装済みサービスとして扱ってはならない。

EPP が確定するのはリポジトリの出来事

提案された操作は分かりやすい。info は保存済み DELEG 表現を返しうる。create はドメイン作成時に複数の DELEG レコードを含めうる。update は追加、指定削除、全削除を行いうる。要求と応答のトランザクション ID は、誰が何を送り、サーバが何を受け付けたかを追跡する重要な証拠になる。

RFC 5730 は EPP のコマンドと応答を、RFC 5731 はドメイン写像を、RFC 5732 はホスト写像を定める。ここでの成功はレジストリ取引の成功である。ゾーン生成ジョブ、DNSSEC 署名、各権威サーバのロード、再帰リゾルバの判断までは含まれない。

サーバが「sponsoring client」と認めたことも、対象オブジェクトを管理する権限の証拠ではある。だが、その権限がリゾルバのキャッシュやアプリケーション結果まで及ぶわけではない。

併存期間には受け手が二種類いる

第 03 版は、多くのドメインが当面 DELEG と従来の NS の両方を必要とすると述べる。そのため EPP サーバは DELEG とホストオブジェクトまたはホスト属性を同時に設定できることが望ましい。移行は一列の置換ではなく、能力の異なる受け手に向けた二列の公開になる。

基礎となる WG 草案 Extensible Delegation for DNS は、親と子にある NS がずれる従来の問題を改めようとする。DELEG は親側で権威を持ち、拡張可能で、DNSSEC により保護可能になる。一方、DELEG は NS と共存しても、NS なしで存在してもよい。NS がなければ DELEG 非対応ソフトウェアは子ゾーンを解決できない。

したがって全削除は「常に危険」でも「常に安全」でもない。NS-only へ戻す意図的な操作かもしれず、試行のロールバックかもしれず、新方式だけを誤って消す操作かもしれない。NS 監視の緑色だけでは区別できない。

DNSOP の委任拡張プロトコル草案は能力通知とダウングレード対策を扱う。EPP リポジトリへの格納成功は、権威側とリゾルバ側でその手順が実行された証明にはならない。

DelegInfoKey の更新も変更管理である

第 03 版では、一つの DELEG レコード内でパラメータ名を重複させず、未知の名前や不正な内容をサーバが拒否する。さらにクライアントとサーバの双方が、登録済み DelegInfoKey の一覧を定期的に更新しなければならない。

この規則により拡張の語彙は統制されるが、更新時差も生じる。新しいクライアントだけが新キーを知れば拒否が起きる。両者が知っていてもゾーン生成器が未対応なら、受理済みデータは公開できない。生成器が対応しても権威サーバ群が同時に更新されるとは限らない。

DELEG 草案は新しい IANA 情報レジストリを、EPP 草案は XML 名前空間と拡張登録を要求する。RFC 7451は EPP 拡張レジストリの枠組みを定め、実際の割当はIANA の現行レジストリで確認する。本稿が固定した時点で、提案された DELEG 拡張は掲載されていない。草案の IANA Considerations は申請予定であり、割当結果ではない。

親ゾーンから先は別の台帳になる

DELEG 基礎草案は、子ゾーンの apex に DELEG RRset を置くことを禁じる。誤配置は DNSSEC 検証失敗につながりうる。RFC 4035が定める検証成功は、所定の信頼連鎖における受信データの性質を示す。しかし、それが最新の EPP 意図を反映しているか、NS と同じ委任先を表しているかは別問題である。

変更記録には、まずドメイン所有者の意図、承認者、EPP クライアント、要求バイト列、名前空間、DelegInfoKey の版、双方のトランザクション ID を残す。次にレジストリのコミット版、DELEG と既存ホスト／NS の整合規則、ゾーン生成の入力と出力を残す。

その後に親ゾーン serial、署名結果、各権威サーバのロードと実応答が続く。DELEG 対応・非対応の両経路を観測し、リゾルバの版、能力通知、検証、キャッシュ時点、フォールバックを記録する。最終項目はアプリケーションの到達性と、継続または復旧の判断である。

Lu Heng の三文献はプロトコルの根拠ではなく、明示した編集上の視座である。動くコードの優先は実応答を要求し、最小仕様とローカル判断は共通形式と運用方針を分け、現実の層は一層の記号を次層の事実にしない。EPP 成功と DNS 到達性を分けるための方法論である。

参照した公式記録

資料一式は、Datatracker、改訂履歴、第03版、DELEG、DELEXT、EPP のコア、ドメイン、ホスト、拡張登録、DNSSEC、IANAから成る。特定の導入、障害、性能を示すものではない。