要約

  • draft-ranjbar-regext-rdap-subordinate-referrals-01は、登録オブジェクトの下にある名前、ネットワーク、アドレスを扱う保有者指定RDAPサービスへ、方向付き関係で到達する案である。
  • 下流データを主張するのは保有者であり、レジストリ運用者ではない。厳格な下位範囲、逆向きリンク、一段の参照上限が発言範囲を区切る一方、保有者は到着した照会を観測できる。
  • クライアントは権限の継ぎ目を保存し、レジストリの被覆オブジェクト、指定行為、保有者の下位回答を別々の根拠として提示すべきである。

通常のRDAP探索は、IANAのブートストラップ情報から始まる。TLDや番号資源範囲を担当するサービスへ進み、その運用者が保持する最も具体的なオブジェクトを得る。登録階層を下るため、結果全体が一つの権威から出たように感じられる。

しかし中央側の記録は意図的に途中で終わる。ドメインレジストリは登録ドメインを保持しても、その下で大量に自動生成される名前までは保持しない。RIRは被覆割り振りや集約割り当てを保持しても、保有者が内部で配る個別アドレスやより具体的なネットワークを記録しない場合がある。細かな情報は、それを生成する現場のシステムにある。

個人ドラフトは、その次の情報源を発見可能にする。資源保有者が自身または委託先のRDAPサーバーを指定し、レジストリ応答から下向きに案内する。保有者側の応答は被覆レジストリへ戻る道を持つ。変化の速いデータを中央へ移さず、探索だけを延長できる。

問題は、移動が見えないと指定が承認に見えることだ。

下向きという方向は権限の継承ではない

第01版はrdap-base-downとrdap-base-upを提案する。前者は下位または委任データを持つ下流RDAPサービスのベースURLへ、後者は被覆レジストリサービスのベースURLへ戻る。名前が示すのはサービス間の方向であり、下流運用者がレジストリになったという意味ではない。

範囲は厳しい。指定サーバーは参照元オブジェクトに完全に従属する資源だけの候補情報源であり、HTTPSを使わなければならない。クライアントは兄弟、親、無関係な資源にまで権威を広げてはならない。逆リンクは親への経路を保ち、参照回数も制限される。記述された用途では保有者レベルの一段で足りる。

それでも二つの主張が残る。レジストリは「この保有者が、この範囲のために、このサービスを指定した」と述べる。保有者は「この下位オブジェクトを私はこう記録している」と述べる。画面が両方を一括して「レジストリデータ」と表示すれば、指定という事実を内容保証へ変えてしまう。

後方互換性は話者交代を隠しやすい

提案は古いクライアントを切り捨てない。ポインターが登録されていれば、レジストリは下位資源の照会を指定サービスへ引き続きリダイレクトし、関係名を知らないクライアントにも最も具体的な記録を返す。対応クライアントはリンクを発見して意識的に越えられ、被覆記録も見たい場合は関連ドラフトで議論されるリダイレクト抑止を使える。

互換性としては合理的だが、HTTPリダイレクトは目立たない。ライブラリは自動追従し、利用者は提供主体、可用性責任、プライバシー、証拠価値が途中で変わったことに気付かない。最終画面だけを見れば、ブートストラップ先がすべてを回答したように見える。

作業部会文書draft-ietf-regext-rdap-referrals-04は、関連RDAP資源への明示的リダイレクト要求を定義する。適切なリンクが一つありクライアントが許可されれば、標準HTTPリダイレクトとLocationを返す。関係選択、コンテンツ交渉、キャッシュ、多段制限も扱う。完全なレコードを取得してリンクだけ抜き出す無駄は減るが、最終回答の帰属までは決めない。

保有者は発行者であると同時に観測者になる

セキュリティ節は、指定サーバーのデータは保有者の主張であってレジストリ運用者の主張ではないと明記する。これは単なる表示名ではない。訂正主体、継続責任、紛争時の証拠、キャッシュの寿命が変わる。

照会が保有者の設備へ届けば、保有者は自らの下位資源への関心を観測できる。ドラフトはDNS運用者がゾーンについて持つ可視性になぞらえ、機密性を必要とするクライアントは参照を断れるとする。ソフトウェアが移動前に選択を示し、レジストリの被覆記録を取得できるようにして初めて有効な選択になる。

可用性も分離される。保有者サービスが停止すれば追加の下位情報は失われるが、レジストリ自身の応答は影響を受けない。「RDAP障害」とだけ報告すれば、レジストリ停止、壊れた指定、下流停止という別々の責任を混同する。

指定手続きが仕様外の権力点になる

保有者が指定先をレジストリへ伝える方法は範囲外である。ポータルや将来のEPP拡張は例にすぎない。RDAP文書を絞る判断として理解できても、誰が照会経路を動かせるかという統治上の要点はそこに残る。

誰が作成、変更、取消しを行えるのか。運用委託先はサーバーを動かせても指定を変えられないようにできるか。新しい宛先はいつ有効になるのか。親資源の移転で旧指定は自動失効するのか。侵害時にどの承認記録が残るのか。

レジストリは案内前に、対象が保有者資源について適合したRDAPを返すか検証すべきだとされる。ただし形式適合は所有の証明ではない。正しいJSONで範囲外の対象を語ることはできる。認証された登録、範囲確認、対象試験、有効化、更新、取消し、移転後処理が別途必要である。

権限の継ぎ目を取得時に保存する

私は、追従した参照ごとに「権限の継ぎ目記録」を残すことを提案する。ドラフト本文の要件ではない。発見を黙示の保証に変えないための運用証拠である。

第一層はレジストリ側を記録する。ブートストラップ経路、被覆オブジェクト、サービス、関係、指定先、指定主体と手段、有効化時刻、範囲、直近の適合確認である。不明な項目は推測せず不明とする。

第二層は横断自体を記録する。照会パス、通常転送か明示関係か、HTTP状態、抑止選択、対象URL、TLS結果、取得時刻、ホップ数、照会が保有者へ見えることを通知したかを残す。

第三層は保有者の主張を別に保存する。応答サービス、下位オブジェクト、応答時刻、適合トークン、キャッシュ期限、被覆レジストリへの逆リンクである。画面は詳細を見せつつ「保有者の主張」と示し、親記録と並べる。

下流障害時は被覆記録を保持して障害層を示す。指定取消しや保有者変更の後は古い主張を期限切れにする。厳格な下位範囲を越える応答は、参照済みだからと信用せず拒否する。

関係名は保有者という役割に固定せず、委任・ハイブリッドRPKIやRWhois/SWIPの置換にも再利用できるよう設計されている。語彙の節約は有用だが、「下流」は位相を示すだけで法的権限、品質、サービス保証を同一化しない。

第01版は2026年7月21日付の個人Internet-Draftである。Datatrackerでは正式なIETF上の地位、RFCストリーム、予定ステータスがなく、文書ヘッダーはStandards Trackとする。著者はREGEXTの参照ドラフトへの統合を望む。実装節は保有者側サービスの稼働を報告する一方、レジストリ側の参照を欠けた一段としている。広範な導入や合意の証明ではない。

下位情報へ進めることと、上位機関の権限を借りることは違う。優れたクライアントは経路を延ばしながら、話者が替わった瞬間を消さない。

情報源