要約

  • draft-brown-epp-deleg-03 は <deleg:rem> の中に空の <deleg:all/> を置く方式を追加した。指定したドメインのDELEGレコード全体を削除する提案であり、第02版の個別指定とは異なる。
  • これはまだ有効な個人提出のInternet-Draftだ。RFCとして承認されたわけでも、レジストリで運用中と確認されたわけでもない。対象はDELEG集合で、従来のNSやドメイン登録そのものではない。

二つのレコードを外す依頼なら、承認する側は対象の二つを見て判断できる。「すべてを外す」という依頼では、最終的に何件が対象になるかは実行時にサーバーが保持している状態で決まる。EPP DELEG草案の今回の改訂は、単なる入力省略ではなく、指示の射程を変える。この違いを新たな事故の報告として読むべきではない。

第5.2.2節はドメインの更新に二通りの削除を示す。deleg:deleg を列挙する方法と、<deleg:rem><deleg:all/></deleg:rem> によって当該ドメインのDELEG全件を対象にする方法だ。草案には全件を削除し、新しいDELEGは追加しない例もある。第02版には後者がなかった。将来実装された場合、クライアントは現在の全件をあらかじめ列挙せずに空の集合を求められることになる。

ただし「全件」が指す範囲は限定される。この操作はDELEG拡張の内部に置かれ、ドメインを廃止したり、EPPのホストオブジェクトやすべてのDNSSECデータを消したりするものではない。第6節は従来のNSとDELEGの併存を想定している。EPPサーバーが要求を受理したとしても、権威DNSに同じ状態が公表済みか、再帰リゾルバーのキャッシュが更新済みかまでは分からない。設定側の受理と外から見える名前解決の状態は、別々に確かめる必要がある。

今回の改訂ではデータ表現も変わった。deleg:params の属性を使う従来の記法から deleg:param 要素へ移り、提案するXML名前空間は deleg-0.01 から deleg-0.02 になった。旧スキーマにあった priority と target も除かれた。BTWは以前、第02版EPPと新しいRDAP案の間でこの二項目が食い違うと報じた。第03版はその特定の文面上のずれを縮めるが、EPPからDNS、RDAPまでの変換が実装され検証された証拠にはならない。本稿の焦点は、追加された集合削除の権限だ。

セキュリティーに関する第7節は、未知のパラメーター名や不正な値をサーバーが拒否し、登録済みキーの一覧を関係者が定期的に更新する設計を示す。入力の妥当性検査と「全件削除を誰が承認したか」は別問題である。またDELEG本体の第11版は、IANAにDelegation Informationレジストリの作成を要請している段階だ。草案にレジストリの言及があっても、既に稼働しているとは言えない。

Datatracker上のEPP文書はRFC系列も担当Area Directorもない個人Internet-Draftで、IESG状態は「I-D Exists」である。9月29日の告知は新稿の公開を示すだけで、IETFの合意や実運用での採用、障害を示さない。今判断すべきなのは将来の権限設計だ。個々のDELEGを書き換える自動化資格情報に、全体を空にする権限まで暗黙に与えるべきではない。

出典