要約

  • RDAP DELEGの第05版はpriorityとtargetを削り、構造名をDelegInfosに改め、例をDELEG-11に合わせた。
  • 規範参照先のEPP DELEG第02版は、「完全な」XMLスキーマのdelegTypeに今も二つの属性を定義している。
  • RDAP草案はdnsDelegという適合性識別子を要求する一方、JSONに入るキーと値の完全な仕様をTBDのままにしている。
  • 公開資料から確認できるのは文書間のずれであり、本番での欠落や事故ではない。EPPからDNSを経てRDAPへ戻る往復試験はまだ定義できない。

05版が直したのは出口である

I-Dの告知によれば、draft-albanna-regext-rdap-deleg-05は2026年9月4日に公開された。目的は、ドメインのRDAP応答に、開発中のDELEGおよびDELEGPARAM情報を載せることだ。DNS委任の仕組みそのものではなく、その状態を登録データの利用者に見せる接口を扱う。

変更履歴は明快だ。04版から05版でpriorityとtargetへの参照を外し、delegInfoをDelegInfosに変更し、例をDELEG-11に基づくものへ差し替えた。DELEG-11は、SVCBの形式を下敷きにしながらもSvcPriorityとTargetNameを持たない、と明記している。残るのはDelegInfoのキーと値の列である。

初期の名前サーバー情報はserver-ipv4、server-ipv6、server-name、include-delegparamの四種類で、これにmandatoryキーが加わる。将来のキーについては、番号、表示名、意味、安定した参照文書、変更管理者を記録する専用IANAレジストリも提案されている。拡張の余地を残しつつ、勝手な方言を抑える設計だ。

したがって05版のRDAP出力は、現在のDELEGの形に近づいた。問題は、入口が同時には動いていないことにある。

EPP側の正式スキーマには旧モデルが残る

RDAP草案は、DELEG本体だけでなくEPP DELEGマッピングも規範参照している。EPP側は、レジストラなどのスポンサー・クライアントがレジストリのドメイン情報を作成、更新、照会するための表現を追加する。RFC 5731のドメイン名マッピングの上に置かれる層だ。

EPP DELEG第02版は、形式構文を自動検証に使える完全なXMLスキーマと説明する。そのdelegTypeには、符号なし短整数のpriority属性とtarget属性が残っている。パラメータ型はprocessContents="skip"で任意属性も許容する。

日付を見ると、EPP-02は7月21日、DELEG-11は7月23日、RDAP-05は9月4日である。単純な追随遅れである可能性は高い。しかし「次版で直るだろう」は変換規則ではない。現行EPPスキーマに適合する入力が二つの属性を含む場合、橋渡し役が拒否、無視、私用保持、別項目への移行のどれを選ぶべきか、現行文書から一意に決められない。

実際のレジストラやレジストリがこの形を実装した証拠は確認していない。RDAPサーバーがデータを失ったという証拠もない。ここで検査できる対象は公表文書だけである。

dnsDelegは履歴書ではない

RDAP-05は、新しい値を含む応答のrdapConformanceにdnsDelegを入れるよう求める。RFC 9083では、この文字列は応答構築に使った拡張仕様を示す。クライアントが未知のJSONを識別するには役立つが、元の書き込みや途中の変換まで証明するものではない。

しかも05版は、DelegInfosに現れるキーと値の完全な仕様をTBDとしている。DELEGとEPPの進展を待って、どちらかまたは双方を参照する可能性があるという。例は出力イメージを示すが、EPP XML、DNSの表示・wire形式、RDAP JSONを結ぶ規範的な表ではない。

調査時点のIANA RDAP ExtensionsレジストリにdnsDelegはなかった。草案は適用運用者を「Any」として登録を求めている。未掲載は拒否を意味せず、提案がまだ登録済み識別子になっていないという時点情報にすぎない。

REGEXTには別のRDAPバージョン管理草案があり、機械可読な版、前版・後継版の関係、非推奨情報、移行方針を扱う。RDAP DELEG第05版は現在、その仕組みで自らのペイロード版を明示していない。

文書の手続上の位置もそろっていない

RDAP DELEGのDatatrackerは、RFC streamも担当Area Directorもない個人Internet-Draftと表示する。EPPマッピングも個人草案である。I-Dは誰でも提出でき、公開はIETFの承認を意味しない。

DELEG-11はDELEG作業部会文書で、Working Group Last Callに進んでいる。ただしRFCではなく、DNS RR番号や新しいキー・レジストリには要求中・暫定の値が残る。基礎文書の手続上の進展が、個人草案二本へ自動的に移るわけではない。

現時点で言えるのは、修正可能な継ぎ目が見えていることだ。脆弱性、停止、破損と呼べる根拠はない。

欠けているのは意味の保管記録だ

必要なのは新しい略称ではない。各項目をどの版が定義し、EPP入力がどのDNS状態になり、その状態がどのRDAP JSONに写り、どこで何を意図的に失うかを固定する経路である。

それがなければ、同じdnsDelegを名乗る二つの応答が別々の変換方針で作られても、利用者には区別できない。どの意図が公開記録に残るかを決めるのは変換の管理者である。形式の不一致が統治の問題になるのは、その地点だ。