要約

  • ドメイン登録、DNS委任、AS登録、ルーティングポリシー、観測されたプレフィックス、PeeringDBの自己申告は、同じ運用事実を示す代替指標ではない。
  • 今回の取得では、各エンドポイントの現在値が検証されていない。したがって、公開記録の不在ではなく、観測の不成立として扱う必要がある。

まず分けるべき五つの層

クラウドサービスの利用者が見るのは、最終的にはアプリケーションが応答するかどうかだ。しかし、その応答に至るまでには、少なくとも五つの層がある。第一は、ブランドとドメイン名の関係である。第二は、そのドメインに対するDNSの委任と応答である。第三は、インターネット番号資源の登録、ここではAS209045に関するレジストリ情報である。第四は、そのASがどのような経路を宣言し、どこから観測されるかというルーティング層だ。第五は、PeeringDBなどに記録された施設、交換ポイント、ポリシー、トラフィック情報である。

この五つは、運用支配の連続した証明ではない。ドメインを管理する主体が、必ずしもASを運用する主体とは限らない。ASの登録主体が、すべての経路を自ら発信するとも限らない。PeeringDBに記載された接続関係も、現在のBGPセッション、経路伝播、契約関係、ましてアプリケーションの到達性を単独で証明しない。

今回確認できなかったことの意味

2026年9月11日の調査で用いたのは、VerisignのRDAP、Google Public DNSのNSおよびSOA応答、RIPE NCCのRDAPとRIPE Database、RIPEstatのプレフィックス観測、PeeringDBのネットワーク情報である。保存された取得結果は、現在のHTTP応答値が検証されなかったことを明示している。これは、登録、委任、ASオブジェクト、経路、ピアリング記録が存在しないという意味ではない。

ドメイン登録については、Verisign RDAPの取得結果で、現在の登録、ステータス、ネームサーバー、イベント情報を確認できなかった。DNSについても、Google Public DNSのNS応答では権威ネームサーバーの委任と応答メタデータを、SOA応答ではプライマリサーバー、責任者メールボックス、シリアル、タイマー、TTLなどを検証できなかった。

ここで重要なのは、「値が空だった」と「値を取得できなかった」を区別することだ。後者から、Genesis Cloudのドメインが失効した、DNSが停止した、または別の事業者へ移管されたという結論は導けない。

AS登録とルーティングは別の主張である

AS209045についても、登録記録と経路観測を分けて読む必要がある。RIPE RDAPのスナップショットでは、ASの登録主体、ステータス、連絡先、remarks、イベント日付を確認できなかった。RIPE Databaseのaut-numスナップショットでも、ルーティングポリシー、maintainer、データソース、変更メタデータは検証されていない。

仮にこれらの値が取得できたとしても、登録されたAS番号は、それ自体では現在のサービス経路を意味しない。レジストリは、番号資源と宣言された管理情報の層を示す。aut-numオブジェクトは、ポリシーや維持主体に関する別の層を示す。BGPの観測は、ある時点に、ある観測地点から見えた経路という測定の層を示す。三つは関係するが、同一ではない。

今回のRIPEstat announced-prefixesスナップショットでは、AS209045について現在観測されたIPv4またはIPv6プレフィックス、観測期間、APIステータスメタデータを確認できなかった。したがって、ASが経路を発信していないとも、世界的に経路が伝播しているとも断定できない。観測地点、取得時刻、経路の一時性、フィルタリングによって、見える範囲は変わるからだ。

PeeringDBは宣言であって、セッション証明ではない

PeeringDBのネットワーク情報も、別の種類の証拠である。そこに記録されるネットワーク識別情報、トラフィックプロファイル、ポリシー、施設、IX、セッション、更新時刻は、参加者が申告する情報である。申告は、組織がどのような接続関係を示そうとしているかを理解するうえで有用だが、現時点でのBGPセッションや、実際の経路伝播を単独で証明しない。

PeeringDBに名前があることは、施設内のポートが現在稼働していることを意味しない。交換ポイントが記載されていることは、特定の相手とのトラフィックが現在流れていることを意味しない。AS番号と施設情報が結び付いていることも、アプリケーションの利用者が同じ経路を通ってサービスへ到達できることを示さない。

何が揃えば、より強い判断ができるのか

運用支配や到達性を評価するには、同じ時間軸で複数の層を照合しなければならない。まずドメインの登録・委任を確認し、次にDNS応答の内容と権威サーバーの挙動を調べる。そのうえで、AS登録とaut-numポリシーを読み、複数の観測地点からプレフィックスと経路を確認する。PeeringDBの申告は、その経路や施設情報と照合する。最後に、アプリケーションのTLS、HTTP応答、名前解決、複数地域からの接続を検証する。

この連鎖の一部だけが成立しても、全体の成立は保証されない。DNSが応答していても、経路がない可能性はある。経路が見えていても、サービスが停止している可能性はある。HTTPが一地点から応答しても、地域やISPによって到達性が異なる可能性がある。逆に、一つの測定地点で失敗しても、世界全体の停止を意味しない。

読者が公開記録から得られるもの

今回の調査が示すのは、Genesis Cloudの現在のネットワーク構成を断定することではない。公開記録をどう分解し、どの主張にどの証拠が必要かという調査設計である。ドメイン、DNS、AS、経路、ピアリングは、同じ制御チェーンに属するように見えても、異なる管理境界と観測限界を持つ。

Genesis Cloudの地域アーキテクチャや、Terraformが強制退去時に持つ限界を調べる記事とは異なり、本稿の焦点は、公開インフラ記録がどこまで運用主体とサービス到達性を結び付けられるかにある。結論は限定的だ。今回の取得結果は、現在の値を検証していない。そのため、Genesis CloudとAS209045、DNS委任、経路、ピアリングの間に運用上の連続性があるかは、追加の同期観測なしには確定できない。