要約

  • RFC 9910 は 2026 年 1 月の IETF Proposed Standard であり、RIR固有のRDAP検索を、IPネットワーク、AS番号、逆引きDNSオブジェクトに対して定義する。
  • 明示的なパスセグメントと登録済み識別子 rirSearch1 により、基本検索と関係検索を区別する。関係検索の方向、関係種別、任意の状態フィルターが結果の意味を左右する。
  • 単一結果の検索リンクを lookup URL に置き換えても、後のクライアントが見る状態は変わり得る。検索URLとlookup URLは、保存すべき証拠と後続照会の役割が異なる。

仕組み：URLが答えを固定しない理由

基本検索は、選択したオブジェクトクラスに応じた入力を、明示されたRDAPパスセグメントで送る。IPネットワークではIPアドレスまたはCIDRの組、AS番号では単一のASNまたはASN範囲、逆引きDNSオブジェクトではドメイン名を使う。rirSearch1 はこの拡張を示す識別子であり、RFC 9082の基本的な検索・lookupのパスとクエリの考え方と組み合わせて読む必要がある。オブジェクトクラスをまたいでパス規則を流用してはならない。

関係検索は、別の資源が階層のどこに位置するかを基準に、定義された関係を持つオブジェクトを探す。階層の上向き検索と下向き検索は同じではない。親、子、または別の相対位置を求めるとき、方向を反転すれば結果集合の意味も変わる。関係種別と任意の状態フィルターを、入力と一緒に記録することが必要である。

RFC 9083のRDAP JSONでは、検索応答は単一の文字列ではなく、結果オブジェクトやlinkオブジェクトを含む応答として扱われる。検索結果は結果集合になり得る。各結果のリンクは検索を保ったり、対象オブジェクトのlookupに向けたりする。検索URLを保つ場合、後の利用者は元の検索条件をもう一度実行する。一方、lookup URLへ置き換える場合、後の利用者は対象の識別子を再照会する。これは後続の主体と検索動作を変えるが、観測時点を固定するものではない。

T1で単一結果を得て、サーバーから対象のlookup URLを受け取ったとする。T2で再割り当て、関係変更、または状態変更が起き、T3でクライアントがリンクをたどれば、T3の応答はT1の結果と異なる可能性がある。この差はRFC 9910が法的権原や所有権を証明することを意味しない。検索結果はその時点のレジストリ状態を見た記録であり、永続する権利、完全なデータセット、timeless truthではない。

観測時点の証拠台帳

運用台帳には、UTCの検索時刻、RIRまたはサーバーの権威、完全なパスとクエリ、rirSearch1、オブジェクトクラス、入力値、関係種別、階層方向、状態フィルター、元の応答バイト列、結果集合の件数、各link relation、検索URL、lookup URL、実際にリンクをたどった時刻と二回目の応答を残す。応答本文を保管できない場合は、内容のダイジェスト、HTTPメタデータ、保管期間と欠落を明記する。URLだけを保存して証拠とみなしてはならない。

運用者の受入れ判断

最初に目的、依頼者の権限、適用される司法管轄を確認する。次に基本検索か関係検索か、パス、入力、方向、関係種別、状態フィルターを検証する。応答を受けたら、結果集合の意味、認証・認可、プライバシー、秘匿性、レート制限を確認し、必要なら範囲を縮小、間隔を延ばし、追加の許可を得る。最終的に、観測時刻と権威を伴って受け入れるか、検索URLを保全するか、lookup URLを補助的に保存するか、再検索を要求するかを決める。現在性が必要なら行動直前に再照会し、監査が必要なら元の検索を必ず残す。

RFC 9910は所有権や法律上の権利を証明しない。本文はRIRの現在の導入状況、データセットの完全性、特定サーバーのレート制限、認可方針、または司法管轄での許可を推測しない。拡張はRDAPのアクセス制御やプライバシー規則を上書きしない。RFC 7481の認証、認可、機密性、プライバシーの境界を維持し、利用可否は対象サーバーと地域の事実で確認する。

出典