レジストリ状態のエクスポート：インターネット番号資源の記録を復元可能にするには

有用なエクスポートは、別の運用者が記録された状態とその履歴を検証できるものです。コピーを保管することは出発点にすぎません。引き継ぎも、理解でき、テストできるものでなければなりません。

レジストリが利用できるとき、インターネット番号資源は単純な検索で把握できるものに思えます。IPプレフィックスや自律システム番号を問い合わせると、記録が返ってきます。その記録は有用ですが、もっと大きな状態の一つの見え方にすぎません。レジストリが誰を認めていたのか、何が変わったのか、どのサービスが委任されていたのか、どの経路広告の認可が存在したのか、そして現在の回答をどの証拠が裏づけているのか、という状態です。

より難しい問いが現れるのは、レジストリが利用不能になったとき、その正当性が争われたとき、侵害されたとき、あるいは別のレジストリに置き換えられるときです。元のデータベースや内部手順を持たない人にも、資源の正当な状態を引き続き理解し、検証できるでしょうか。

継続性をめぐる問い：現在のレジストリシステムが明日から応答しなくなったら、正当な保有者や承継者が、新たな状態をでっち上げることなく、最後に検証された状態を再構成するには、どのような情報が必要でしょうか。

まず、三つの異なる状態を分ける

レジストリをめぐる議論が混乱しやすいのは、異なる三つの問いが一つとして扱われるためです。

• レジストリの状態：資源、認められた保有者、連絡先、イベント、委任、ステータスについて、権限を持つ機関が現在記録している内容。
• 運用状態：逆引きDNS、プロバイダーとの関係、サービスの継続性を含め、その資源が実際にどのように利用されているか。
• 経路状態：どの自律システムが経路の起点となっており、関連する経路広告の認可が有効かどうか。

これらの状態は一致することもありますが、同時に変わるとは限りません。認められた保有者が同じまま、プレフィックスがプロバイダー間を移ることもあります。レジストリの記録は正しくても、経路の設定が誤っている場合もあります。経路広告の認可は有効でも、連絡先オブジェクトが古くなっている場合もあります。有用なエクスポートは、これらの状態の関係を保持し、各証拠がどの記述を裏づけるのかを示す必要があります。

RDAPが提供するもの、しないもの

RDAPは、登録データを照会するための標準的な層です。そのJSONモデルは、IPネットワーク、自律システム番号、エンティティ、イベント、リンクなどのオブジェクトを記述します。これによって、レジストリが異なっても、現在の記録を照会して解釈しやすくなります。その構造はRFC 9083で定義されています。

RDAPが答えるのは、現在時点の照会です。このオブジェクトについて、応答しているレジストリは今何を返すのか、という問いです。回答には現在の記録やイベント情報が含まれる場合がありますが、リアルタイムの応答が、そのまま独立した継続性のための情報一式になるわけではありません。それだけでは、過去の状態を順に並べた、可搬性と真正性のある記録、完全な移行記録、あるいは秩序ある承継プロセスに必要な資料を、保有者が持っていることは保証されません。

この違いは重要です。稼働中のディレクトリは、システムをのぞく窓です。レジストリ状態のエクスポートは、その窓、システム、組織との関係が変わったときにも継続性を検討できるよう、十分な検証済み状態を保存する手段です。

RPKIが証明すること、しないこと

RPKIはルーティングに関する問いに答えます。経路起点認可（ROA）は、アドレス空間の保有者が、一つ以上のプレフィックスの経路起点となることを認可した自律システムを示します。そのプロファイルと検証規則はRFC 9582で説明されています。

これは有用な証拠ですが、レジストリに関するあらゆる問いへの完全な答えではありません。有効なROAだけでは、資源の法的・管理上の全履歴を証明すること、すべての運用連絡先を特定すること、逆引きDNSの継続性を確立すること、どのレジストリ状態を認めるべきかという紛争を解決することはできません。RPKIの認可は、継続性の記録を構成する一つの層であり、その記録の代わりではありません。

レジストリ状態のエクスポートの実務的な定義

レジストリ状態のエクスポートとは、IPv4、IPv6、ASN資源の本質的な検証済み状態を、持ち運べ、理解でき、テストできる形にするために提案されている、継続性のための情報一式です。独立した立場の読者が、次の四つの問いに答えられるものであるべきです。

1. 対象はどの資源で、認められた保有者は誰か。
2. 最後に検証された状態は何で、いつ発効したか。
3. その状態の後に、どのような重要な変更があったか。
4. 正当な移行や承継プロセスを、どの証拠と権限が裏づけているか。

これはデータベースのダンプよりも目的が明確で、スクリーンショットよりも有用です。エクスポートには承継者が必要とする状態を含める一方、無関係な顧客データ、非公開の事業戦略、その資源の状態の立証に関係しない内部実装の詳細は含めるべきではありません。

最低限必要なエクスポートの内容

実用的なエクスポートは、相互に関連づけられた少数の記録群として構成できます。各記録には、安定した識別子、発効時刻、情報源、説明のつかない変更を検知するのに十分な情報を付けるべきです。

• 資源の識別情報：IPv4プレフィックス、IPv6プレフィックスまたはASN、該当する場合には上位資源や割り振りとの関係、レジストリ上の識別子。
• 認められた保有者：検証済み状態で認められていた組織または主体、レジストリ上の識別子、その認定の発効日とステータス。
• 連絡先：承継者や、その記録に依拠する者が実際に必要とする、管理、技術、不正利用、セキュリティの連絡先。
• 重要な履歴：移転、名称または組織の変更、委任、ステータス変更、紛争、および各イベントに関連する証拠や認可。
• 運用上の関係：関連するプロバイダー、委任先の利用者、逆引きDNS、サービスの関係と、それぞれの有効期間および終了状態。
• ルーティングとセキュリティの参照情報：関連する起点ASN、ROAまたはRPKIオブジェクトの参照情報、公開状態、その状態を観測した時刻。
• 競合状態：紛争、保留措置、競合する主張の有無、その対象となる資源、最後に争いのなかった状態。
• 監査証跡：誰が、何を、いつ、どの権限に基づき、どの値からどの値へ変更し、検証結果がどうだったか。
• 完全性に関する情報：受領者が出所を検証し、改変を検知できるようにするための、バージョン番号、タイムスタンプ、オブジェクトのハッシュ、署名、エクスポートのマニフェスト。

内部データベースのすべてのテーブルを再現する必要はありません。公開される回答に意味を与え、移行を監査可能にする関係を保持する必要があります。

バックアップだけでは不十分な理由

バックアップは通常、同じ運用者がシステムを復元するために設計されています。レジストリ状態のエクスポートは、元のシステム、組織、運用体制を単純には復元できない場合に、権限を持つ別の主体が状態を理解し、検証できるようにするためのものです。

• バックアップには、独自仕様のソフトウェア、文書化されていない関係、元の認証情報が必要な場合があります。
• エクスポートは、独立した承継者が読めるもので、重要な主張ごとに、その根拠となる証拠を示すべきです。
• バックアップには、資源保有者が受け取る権利を持つ、または受け取りたいと考える範囲をはるかに超えるデータが含まれる場合があります。
• エクスポートは、対象資源に範囲を絞り、真正性が確認でき、機械可読で、可搬性のあるものにすべきです。

この区別は、技術上の好みではありません。機械を保存することと、正当な状態を認識できる能力を保存することの違いです。

継続性の確保が必要になったときに行うこと

継続性を確保するプロセスは、二つのシステムが同じ資源について主張することを認めるところから始めるべきではありません。最後に検証された状態を固定し、移行を明示することから始めるべきです。

1. 契機を特定する：障害、支払不能、侵害、移行、紛争、その他あらかじめ定義された継続性に関わる事象を特定します。
2. 最後に検証された状態を保存する：資源、認められた保有者、連絡先、重要な履歴、そのスナップショットを裏づける証拠を記録します。
3. エクスポートを検証する：署名、ハッシュ、タイムスタンプ、認可の参照情報、マニフェストの完全性を確認します。
4. 証拠の層を分ける：一つの層を他のすべての証明とするのではなく、レジストリの状態を、運用上の利用、逆引きDNS、経路の観測、RPKIの状態と比較します。
5. 承継先を記録する：以前の状態をどのように置き換えるか、競合をどう扱うか、その記録に依拠するシステムが正式な承継先をどう発見するかを定めます。
6. 移行を公開する：新しい状態とその発効時刻を発見可能にし、以前の状態も監査可能な履歴として保持します。

このプロセスは、障害を、未検証の主張者が履歴を書き換える機会にすることなく、継続性を守るために設計されます。

レジストリ状態のエクスポートがしてはいけないこと

継続性のためのエクスポートは、受領者全員に所有を主張する力を与える第二のレジストリではありません。並行する権利主張を生み出したり、適用される資源ポリシーを迂回したり、顧客のトラフィックや機密の戦略を露出させたり、運用上の利用を黙って正式な管理権限へと変換したりしてはいけません。

エクスポートは、自らの限界も明示すべきです。あるフィールドが取得不能、非開示、または係争中なら、記録にそう書くべきです。根拠がないのに完全に見える値を記載するより、正直に不明とする方が安全です。

危機の前にエクスポートをテストする方法

資源保有者や運用者は、次の簡単な確認によって、この考え方をテストできます。

• 独立した立場の読者が、正確なIPv4、IPv6、ASN資源を特定できるか。
• 最後に検証された正式な保有者と発効日を特定できるか。
• 重要な移転、委任、組織変更を再構成できるか。
• レジストリの状態と、現在のルーティングおよび運用上の利用を区別できるか。
• 関連するRPKIと逆引きDNSの証拠を見つけられるか。
• 紛争や競合する主張が存在するか確認できるか。
• 誰がエクスポートを作成し、その後に変更されたかどうかを検証できるか。
• 正当な承継者が、元の非公開データベースを取り込まずに、その記録を利用できるか。

これらの問いに答えられないなら、その組織には稼働中の照会サービスやバックアップはあるかもしれませんが、テスト済みの継続性の記録は、まだありません。

IPv4のライフサイクルとの関係

IPv4資源のライフサイクルには、レジストリの記録、移転、運用上の委任、ルーティング、そしてその後の用途変更が含まれます。エクスポートは、これらの局面をつなぐものです。まずレジストリデータからIPv4のライフサイクルについて何が分かるかを読み、続いてRIR間移転における地域間の移動と、BGPリホーミングにおける経路の変更を区別してください。

同じ考え方は、より広いガバナンスの問いにも当てはまります。一意の資源を調整するシステムでは、状態を検証し、持ち運べる能力を、利用不能になり得る一つの管理拠点に全面的に依存させるべきではありません。だからこそ、レジストリ状態のエクスポートは、インターネットレジストリが機能しなくなったらどうなるか、管理権限の証明は実際に何を示せるかという実務上の問いと並べて考える必要があります。

結論

レジストリ状態のエクスポートは、継続性を具体的なものにする方法です。RDAP、RPKI、経路データ、逆引きDNS、レジストリのポリシーに取って代わるものではありません。関連する証拠を結びつけ、真正性を確認でき、バージョン管理され、持ち運べる記録にするものです。元のシステムをそのまま信頼したり復元したりできないときにも、正当な利用者が理解できる記録です。

レジストリが消えたとき、目指すべきなのは、誰にでもその資源に対する権利を主張させることではありません。正当な答えを引き続き認識し、検証し、引き継げるように、十分な検証済み状態を保存することです。