まず明確にしましょう。調べたいのは登録、ルーティング、位置、それともリスクですか？
IP 照会ツールには多くの種類がありますが、核心となる違いは、それぞれが異なる問いに答えている点です。あるアドレス範囲がどの組織の名義にあるか、連絡先メールや不正利用報告窓口を知りたい場合は、RDAP 登録データを参照すべきです。現在のネットワークでどの自律システムが特定のプレフィックスをアナウンスしているかを知りたい場合は、BGP ルーティングテーブルのスナップショットを参照します。特定のプレフィックスに有効なルート起源認可があるかを知りたい場合は、RPKI 検証状態を確認します。ある IP の不正利用やプロキシのリスクを評価したい場合は、IP レピュテーションレポート（IP 純度レポート）を参考にできます。これらの問いを混同したり、1 つのツールで正確な物理的位置、リアルタイム経路、商用リスクスコアを同時に得ようと期待したりすると、誤った判断につながりがちです。
ページ内の国フィールドは、リソース登録に由来する場合もあれば、GeoIP データベースに由来する場合もあるため、まず出典を読み取る必要があります。あるユーザーが国、ページ言語、ネットワークブランドの不一致を見て、VPN や Anycast の使用を推測したとしても、証拠としては十分ではありません。まず IPアドレス検索 で各フィールドを記録し、その後 RDAP、BGP、位置推定を個別に確認します。信頼性を重視する場合は IPレピュテーションの確認方法：リスクスコアとブロックリスト を参照します。これらのツールは同じ問いに答えているわけではありません。
運用担当者が障害やセキュリティインシデントに対処する際は、各ツールの結論をその証拠範囲内に限定すべきです。たとえば、BGP ルート照会でわかるのは、観測されたルートアナウンスと AS_PATH 属性のみであり、パケットがエンドツーエンドで経由する物理リンクを直接証明するものではありません。照会出力を手がかりとして扱い、traceroute、フローデータ、インターフェースカウンタなどの他の証拠と組み合わせることで、初めて信頼できる判断ができます。1 つの照会結果で他のすべての情報を否定しないことが、IP データを読み解く上での基本的な規律です。
RDAP が答えられる登録の問いとは？
RDAP（Registration Data Access Protocol）は、構造化された応答を通じて登録データを提供します。インターネット番号リソースとドメイン登録の両方に用いられますが、本記事では IP ネットワークと自律システムリソースに焦点を当てます。応答にはアドレス範囲、オブジェクトハンドル、連絡先の役割、イベントが含まれ得ますが、フィールドの公開度と完全性はレジストリのポリシーと個々の記録に依存します。すべての照会に最終ユーザー、完全な履歴、利用可能な不正利用報告メールアドレスが含まれると前提してはいけません。
注意すべきは、RDAP の連絡先住所は公開登録住所であり、通常は登録組織のオフィス所在地または法的住所であって、IP 機器の設置場所やユーザーの現在位置とは同一視できません。たとえば、多国籍企業の RDAP 住所は本社のある都市に登録されている一方、実際にその IP を使用するサーバーは他国のデータセンターにある場合があります。RDAP 住所の地図をそのまま「IP 位置情報」として使うと、位置精度を過大評価することになります。プロトコル仕様 RFC 9082 と RFC 9083 は RDAP の照会と応答構造を定めていますが、登録データに物理的な位置を含めることは要求していません。
プレフィックスの登録責任者を確認する必要がある場合は、二次的な要約に頼るよりも、RDAP検索 ツールで直接元の記録を確認する方が信頼できます。照会結果には、ネットワーク名、国コード、レジストリ、状態（allocated、assigned など）、イベント履歴、不正利用報告用メールアドレスが表示されます。これらのフィールドから、あるアドレス範囲に長期間更新されていない登録情報があるか、特定の種類の割り当てに属するかを判断できますが、そのアドレス範囲が攻撃を開始しているか、悪意のあるサービスをホストしているか、特定の最終ユーザーに属するかを推測することはできません。RDAP 証拠は登録ライフサイクルのみを対象とし、リアルタイムの挙動は対象外です。
ASN がサービスプロバイダーのブランドとは限らない理由
ASN（自律システム番号）は、1 つ以上のネットワーク事業者の管理下にあるルーティングポリシードメインを識別します。同じ ASN 配下のプレフィックスは、データセンターホスティング、クラウドサービス、CDN、コンテンツネットワーク、さらには異なる小売ブランドやテナント向けの透過プロキシサービスなど、さまざまな業務に使用され得ます。したがって、ASN だけでは、ある IP がどの消費者ブランドや具体的な場所に属するかを断定できません。大規模なクラウドプロバイダーの ASN は数十社の企業の IP アドレスを同時に収容している場合があり、登録組織名はそれらの企業と直接の関係がないこともあります。
1 つの自律システムは複数の地域や事業をカバーでき、組織名は小売ブランド、顧客、クラウドテナントと異なる場合があります。多国籍事業者は複数の国でプレフィックスをアナウンスする可能性があり、同一企業が複数の ASN を管理することもあります。Anycast はそのようなサービス展開方法の 1 つであり、運用境界は RFC 4786 を参照できますが、ASN 登録国や企業名から直接、特定の IP の地理的位置、テナントの身元、Anycast 展開を推測することはできません。
セキュリティ分析では、小規模な ASN を単純に高リスクと同一視すべきではありません。少数のプレフィックスと短い履歴を持つ自律システムは、正当な新興コンテンツプロバイダー、研究ネットワーク、地域 ISP である可能性があります。リスク判断は、ルーティング挙動、過去のアナウンス安定性、RPKI 検証状態、実際の不正利用報告記録に基づくべきであり、ASN の規模や登録情報の新しさのみに依存すべきではありません。特定の ASN の BGP ルートと履歴を確認することでアナウンスの習慣を理解できますが、それも判断を助ける証拠の 1 つに過ぎません。
BGP プレフィックス、起源 ASN、AS_PATH
BGP 照会は、特定の観測点が受信したコントロールプレーン情報（プレフィックス、起源 ASN、AS_PATH、時刻）を示します。単一 IP を照会する場合、ツールはその IP をカバーする最長プレフィックスを選ぶことがあります。最長プレフィックス一致は転送テーブル参照の重要なルールです。転送テーブルにより具体的な一致がある場合、パケットはそのエントリに従って転送されます。これは、BGP が同一プレフィックスに対する複数の候補ルートから最適経路を選ぶプロセスとは異なります。どちらも完全な物理リンクのリストを直接示すものではありません。
AS_PATH属性はルートが経由した自律システムのシーケンスを示しますが、データプレーンにおけるパケットの実際の転送経路と同一ではありません。ルーティングポリシー、ローカルプリファレンス、MED値、BGPコンフェデレーション、MPLSトンネルにより、実際のパケット経路はコントロールプレーンのAS_PATHと異なる場合があります。例えば、あるパケットがAS_PATHに登場しないリモートピアを経由することがあります。したがって、BGP経路検索を用いて特定のプレフィックスの現在の広告者を確認することはルート制御権の判断に役立ちますが、エンドツーエンドのトラフィック経路を正確に推測することはできません。
プレフィックスの広告履歴を確認する必要がある場合、例えば以前にオリジンASNが変更されたか、またはより具体的な広告が行われたかどうかは、BGP履歴データを参照できます。履歴スナップショットは、ある時点におけるプレフィックスの広告状態とAS_PATHの変化を示しますが、履歴データの欠落は観測点が不完全であるか、ルートが収集されなかったことが原因の場合もあります。単一のルートコレクタのビューは、インターネット全体のルーティング状態の一部にすぎず、完全な真実とはみなせません。複数の観測点のデータを組み合わせることで、ルートの安定性についてより信頼性の高い認識が得られます。
RPKI: Valid、Invalid、NotFound
RPKI(Resource Public Key Infrastructure)は、ROA(Route Origin Authorization)を発行することで、特定のASNが特定のプレフィックスを広告することを承認し、必要に応じて最大プレフィックス長maxLengthを指定できます。オリジン検証を実行する際、ルーターまたは検証ツールは、BGPルート内のプレフィックスとオリジンASNを、有効なROAから生成されたVRP(Validated ROA Payload)セットと比較します。検証結果はValid、Invalid、NotFoundの3つの状態に分けられます。
Valid状態は、少なくとも1つのVRPが存在し、そのVRPが承認するプレフィックスがルート広告のプレフィックスをカバーし、オリジンASNが一致し、プレフィックス長が許可範囲内(通常maxLengthを考慮)であることを意味します。Invalid状態は、1つ以上のVRPがそのプレフィックスをカバーしているものの、オリジンASNが一致しないか、プレフィックス長が承認範囲を超えていることを意味します。RFC 6811によれば、Invalidは自動的にルートハイジャックや悪意のある行為と同等ではなく、設定ミス、ROA更新の遅延、または運用者自身の操作ミスが原因でInvalidとなる可能性があります。
NotFound状態は、そのプレフィックスをカバーするVRPが存在しないことを示し、通常はリソース保持者がROAを作成していないか、検証器が最新のROAデータをまだ取得していないことが原因です。NotFoundを攻撃のシグナルと解釈すべきではなく、RPKIによってオリジン承認を確認できないことのみを示します。RPKI検証ツールを使用すると、特定のIPプレフィックスの検証状態、一致するROAの詳細、検証時刻を確認できます。運用担当者は、RPKIデータが動的に変化するため、各検証のタイムスタンプを記録する必要があります。プレフィックスの状態はROAの発行や失効に伴って変化する可能性があります。
なぜValidがセキュリティ証明ではないのか?
RPKIオリジン検証では、その時点で検証済みのROAペイロードに照らして、経路のオリジンASNとプレフィックス長が認可されているかを確認します。Validという結果はAS_PATHの残りの部分を認証せず、パケットの安全性や端末の信頼性も証明しません。ユーザーの行動やコンテンツの安全性を評価するものでもありません。悪意のあるネットワークが自らのプレフィックスに対して有効なROAを保有し、経路の検証結果がValidになっていても、そのインフラ上で有害な活動を行うことは可能です。したがって、あるIPアドレスを含む経路がValidであっても、そのアドレスが悪用されないことや、サービスが信頼できることは保証されません。
同様に、Invalid状態も直接ルートハイジャックと判定することはできません。一般的なエンジニアリングシナリオには、運用者がプレフィックスを移行する際にROAを適時更新しなかった場合や、maxLengthを誤って設定したために、より具体的な広告が許可されなかった場合が含まれます。これらはルート登録設定の問題であり、ROAを修正することでValid状態に戻すことができます。一方、実際のハイジャッカーは、カバーされていないプレフィックス(すなわちNotFound)を利用して広告を行う可能性があり、状態自体がセキュリティ上の結論を構成しないことをさらに示しています。
運用者に報告する際は、観測時刻、具体的なプレフィックス、オリジンASN、カバーするVRPの承認ASNとmaxLength、および検証器またはデータソースを保持する必要があります。表現例:「記載された時刻に、203.0.113.0/24、origin AS64496はInvalidと検証されました。カバーするVRPが存在しますが、オリジンと長さの要件を同時に満たすレコードはありません。」ここではドキュメント用の例示リソースを使用しており、実際のルートアラートではありません。受信者は完全な一致セットを照合する必要があり、1つの不一致VRPだけを見て別の有効な承認を無視してはなりません。
登録国と位置国が異なるのはなぜか?
登録国と位置国が一致しないことは、自動的に位置情報の誤りやAnycastの存在を示すものではありません。IPアドレスは地域インターネットレジストリによって多国籍組織に割り当てられ、組織は本社所在国で登録することを選択できますが、実際の使用は世界中の支社やデータセンターで行われます。例えば、ある欧州企業がIPレンジ全体をオランダで登録し、借りているサーバーがシンガポールにある場合、照会時に登録国はオランダと表示されますが、ネットワーク遅延とルート観測はシンガポールを示します。これは通常のことであり、異常ではありません。
上流ISPが大きなリソースブロックを取得した後、異なる顧客や地域に割り当てることがあり、登録レコード、商用ロケーションライブラリ、Webサイトのキャッシュはそれぞれ更新されます。リソースの移転、割り当ての変更、または資料の改訂は時間差を生じさせる可能性があり、固定された週数や月数後に同期されると想定することはできません。具体的な照会時刻とソースを記録し、現在の登録オブジェクト、履歴スナップショット、および位置推定を区別し、あるフィールドを別の意味で上書きしないようにする必要があります。
ネットワークレイアウトの要因には、CDN、クラウドサービスプロバイダー、多国籍専用線が含まれ、これらは複数の国で同じプレフィックスのアドレスを展開します。この場合、単一の「登録国」だけでは実際のトラフィック入口を表すことはできません。特定のIPが特定の国でサービスを提供しているかどうかを判断するには、BGPルートのASパス、アクティブなping/traceroute測定、クラウドベンダーの公開リージョン情報を組み合わせる必要があります。国が一致しないことだけからAnycastを推測するのは証拠不足です。
Anycast(エニーキャスト)とブロードキャストの違いは何か?
Anycast(エニーキャスト)は、複数のサービスインスタンスが同じアドレスを使用し、ルーティングによって1回のリクエストを到達可能なインスタンスの1つに送信することを可能にします。一般的なインターネット展開では、そのアドレスを運ぶプレフィックスを複数の場所で広告します。選択されるインスタンスはルーティングポリシーに依存し、地理的に最も近い、遅延が最も低い、または負荷が最も小さいことを保証しません。ブロードキャストは、パケットをブロードキャストドメイン内の複数の受信者に送信するものであり、両者はまったく異なります。エニーキャストのエンジニアリング実践については、RFC 4786を参照してください。
エニーキャストの判断は、運用者がそのサービスアドレスについて明確に文書化していること、および複数地点・同時刻の測定とインスタンス識別子を組み合わせて行うことができます。同じASNが複数のエニーキャストサイトに現れることがあるため、終点ASNが異なる必要はありません。また、異なるASNや異なるtraceroute経路も、ルーティングの変動、トンネリング、測定の制限などが結果に影響しうるため、自動的にエニーキャストを証明するものではありません。証拠がどの段階まで裏付けられるかを説明すべきであり、数カ国のラベルだけでアドレスを断定してはなりません。
よくある誤りは、「国フィールドの差異」をエニーキャストの証明とみなすことです。例えば、同じIPが異なる商用データベースで米国とドイツと表示される場合があります。これは位置情報データソースの不一致を示すに過ぎず、登録、ルーティング、またはデータベース更新の問題である可能性があり、エニーキャストの十分条件ではありません。運用上の判断では、可能性と証明を明確に区別し、未検証の仮定を結論として書くことを避ける必要があります。
想定事例：登録者、運用者、テナントはそれぞれ誰でしょうか？
以下は実測に基づかない想定シナリオです。文書の例示アドレス192.0.2.10を問い合わせると、RDAPでは登録国が米国、登録機関がExample Corpと表示され、BGPルート広告の送信元ASNはある欧州のクラウドサービス事業者に属するとします。この差異は、Example Corpがアドレスブロックをクラウドサービス事業者に貸し出し、その事業者がフランクフルトと東京にエッジノードを展開したものの、登録情報を更新していないために生じる可能性があります。これらの情報だけでは、そのIPの現在の物理的な位置やエニーキャストの使用有無を確認できません。
この仮定を続けます。フランクフルトと東京付近の2つの測定点がそれぞれ現地のサービスインスタンスに到達し、照合可能な異なるインスタンス識別子を取得し、リクエスト先がどちらも文書の例示アドレス192.0.2.10であるとします。運用者がそのアドレスについてエニーキャストを明確に説明していることと合わせると、複数地点への展開判断を裏付けることができます。ここでは論理的な例を述べているだけで、世界中のどこからでも10ミリ秒未満の遅延が得られるとは主張していません。RPKI Validは依然としてプレフィックス起源の認可を検証するのみであり、インスタンスの位置を証明するものではありません。
このケースにおける未知の問題には、テナントの具体的な身元、サービス ポートがすべての地域に開かれているかどうか、インスタンス間の状態同期メカニズム、中間ネットワーク パケット フィルタリングの有無が含まれます。運用担当者はこれらの未知項目をありのままに記録し、「エニーキャスト」というラベルで証拠の欠如を覆い隠してはなりません。分類は悪意を意味せず、未検出は攻撃を意味しないため、境界を明確に説明することが専門的判断の基礎となります。
履歴記録と現在の結果が一致しないのはなぜですか?
RDAP のイベントは通常、eventAction と eventDate などのフィールドで記述されます。たとえば registration または last changed です。一部のインターフェースでは「updated」と要約表示されることもあります。これらの日付は登録オブジェクトのイベントを表し、サーバーの物理的な移転時刻と同じではありません。メールアドレス、ステータス、または管理情報の変更によって更新時刻が変わる可能性があり、サービス場所も変化するのに当該フィールドに反映されない場合があります。元のイベント名を保持し、すべての日付をアドレス移転と一律に解釈してはなりません。
プレフィックス分割とリソース移転はよくある原因です。1 つの /16 大きなブロックが複数の /24 に分割された後、一部の小さなブロックが他の機関に割り当てられる可能性がありますが、親レベルの登録情報の国フィールドには元の値が残ります。このとき、ある /24 の RDAP を照会すると、親国の履歴値が返される一方、BGP ルートではその小さなブロックが別の国の ASN によってアナウンスされていると表示される場合があります。観測点の違いも不整合を引き起こします。商用 IP データベースは異なるデータソースと収集時刻に基づいており、スナップショットの差は数か月に及ぶことがあります。
以下は、記録方法を説明するための架空の例です。正しい対処法は、すべての元記録を保持し、クエリ時刻を注記することです。例えば、2024年1月のRDAPでは国が英国、2024年6月のBGP経路はドイツ経由、2024年9月のある観測点のtraceroute終点はオランダでした。「このIPはオランダに移動した」と単純に言うのではなく、「異なる時刻と観測点で差異があり、経路調整やデータベースの遅延が関係する可能性がある」と述べるべきです。これにより証拠を残しつつ、過度な推測を避けられます。
証拠をどのように組み合わせ、未知の項目を残すにはどうすればよいですか？
完全なIPクエリ判断は、4種類の証拠に分けられます。登録背景はRDAPとWHOISから得られ、登録機関、国、登録日時、連絡先メール、状態を含みますが、物理的な位置やエンドユーザーの身元は含みません。経路状態はBGPとRPKIから得られ、アナウンスされたASN、ASパス、RPKIの有効・無効、可視性を含み、制御プレーンの到達可能性のみを反映し、データプレーンの完全な経路を保証しません。位置推定は商用IPデータベース、遅延、tracerouteから得られ、確率的な判断です。
直接的な行動は独立して記録する必要があります。例えば、能動的にスキャンを開始したか、悪意のあるドメイン解決があるか、特定のポートに応答するかなどです。住宅ISPの登録情報を持つIPは、地理的位置がある都市と一致しても、そのIPが実際の家庭ユーザーに属するとは限りません。プロキシやホスティングサービスが存在する可能性があるためです。住宅とネイティブIPの識別ポイントについては、住宅用IP・ISPホスティングIP・データセンターIPの違いを参照してください。観測点のカバレッジが不足している場合、同じIPが一部の地域で経路到達不能と表示されることがありますが、これは全世界で到達不能であることを証明できません。/24サブネットのIPレピュテーション：観測範囲とリスク率を参照してください。
登録国がカナダ、ASNがカナダのISPによって管理され、RPKIがValid、商用データベースがトロントと推定し、一部のカナダの測定ポイントで遅延が低いと仮定します。これらの結果はカナダのサービス位置と一致すると説明できますが、物理的な位置の証明として記述してはならず、RPKIから業務が正常であると推測することもできません。登録は資料、経路は観測、位置は推定、行動記録にも出典と測定境界があります。すべての結論には、時点、条件、そして依然として確認できない部分を注記する必要があります。
よくある質問とレビュー資料
よくある質問1：ASNが変わった場合、事業者が変わったことを意味しますか？必ずしもそうとは限りません。ASNは経路ポリシードメインを表し、大規模事業者は複数のASNを所有する場合があり、企業はクラウドサービスプロバイダーに移行しても元のIPセグメントを使い続けることがあります。IPプレフィックスが同じBGP経路内で異なるASNによってアナウンスされているか、ASパスの変化があるかを確認し、登録情報と組み合わせて、実際にネットワーク提供者が変わったかどうかを判断する必要があります。
RPKI起点検証はすべての経路攻撃を防ぐものではなく、完全なAS_PATHを認証するものでもありません。厳密な記述は「経路は現在のVRP集合に対してValid、Invalid、またはNotFoundです」であり、Invalidを「ROAが無効」と略してはなりません。両者は同じ概念ではありません。RDAPもエンドユーザーの個人を特定するツールではありません。公開オブジェクトに個人や連絡先情報が含まれていても、それは依然としてリソース登録資料であり、現在リクエストを開始した人や正確な住所を識別するために使用することはできません。
チケットレビューフレームワークでは、提出者にクエリ時刻（UTC）、具体的なIPまたはプレフィックス、RDAP/WHOISスナップショット、BGP経路表またはtraceroute観測ソース、現在の状態（接続失敗や経路リークなど）、具体的な要望を提供するよう求めるべきです。運用担当者はこれに基づいて、まず登録フィールドを照合し、次にRPKIとASパスを確認し、最後に位置情報と能動的測定を参照します。このフレームワークを使用することで、「国のフィールドが一致しないからハッキングされた」といった誤判断を減らせます。
