要約

  • 本稿で利用した調査パッケージは、AS210328とalmazcloud.networkを検証できる30件の公開ソース候補を収録しているが、この実行では現在のHTTP、DNS、一般Web応答を取得できなかった。そのため、現在の経路、DNS存在、ドメインとASの対応、証明書、Web到達性、クラウドサービスのエンドポイントはいずれも未確認である。
  • AS番号の登録やドメインの存在は、運用中のネットワークや顧客向けサービスとは別の事実である。結論を強めるには、登録情報から権威DNS、アドレス、収容プレフィックス、観測されたBGPオリジン、TLS、HTTP、アプリケーション、顧客ワークフローまでを、時刻付きの複数観測で結び付けなければならない。

登録された名前と運用中のネットワークは同じではない

AS210328について最初に確認すべきなのは、RIPE NCCのRDAPおよびRIPE Databaseにどのような管理情報が登録されているかである。自律システム番号の記録は、保持者名、組織参照、連絡先、メンテナー、ステータス、備考、経路ポリシーを示し得る。RIPEの自律システム記録は、行政的な同一性を検討するための出発点になる（RDAP自律システム記録、RIPE Database検索）。

しかし、登録記録は現在のBGP可視性を直接示さない。ASが登録されていても、現在プレフィックスを発信しているとは限らない。逆に、IRRのrouteまたはroute6オブジェクトが存在しても、それは意図された経路情報であり、実際に観測された広告とは異なる。したがって、登録情報、IRRオブジェクト、観測された経路を別々の証拠として扱う必要がある（AS210328をoriginとするrouteオブジェクト検索）。

BGPが示すもの、示さないもの

現在のネットワーク運用を検討する次の層は、RIPEstatのAS概要、発表プレフィックス、routing-status、BGP state、隣接AS、履歴、更新情報である。これらは、AS210328が観測対象のコレクターから見えるか、どのIPv4またはIPv6プレフィックスが同ASから発信されたように見えるか、どの上流や隣接先が確認されるかを検証するための入口になる（AS概要、発表プレフィックス、routing-status、BGP state、隣接AS、経路履歴、BGP更新）。

BGPでAS210328が見えるとしても、それだけでalmazcloud.networkがそのASから提供されているとは言えない。ドメインがCDN、リバースプロキシ、外部ホスティング、別のネットワーク上のフロントエンドを使っている可能性があるからだ。逆に、ドメインのAまたはAAAA応答が別ASのアドレスを返しても、バックエンドがAS210328にある可能性を完全には排除できない。ドメインのアドレス、アドレスを覆うプレフィックス、実際のorigin、AS path、HTTPの応答先を順番に確認しなければならない。

この対応関係を一つの観測点に依存させるべきでもない。BGP.ToolsとHurricane ElectricのBGP Toolkitは、プレフィックス、上流、ピア、履歴、可視性についてRIPEstatとは異なる観測を提供し得る（BGP.ToolsのAS210328プロファイル、Hurricane ElectricのBGP Toolkit）。複数ソースが同じプレフィックスとoriginを、近い時刻に示すことは、単一の古い記録より強い（PeeringDBのAS210328情報）。ただし、コレクターの範囲、更新時刻、集計方法が異なるため、収束していない情報を現在の事実として扱うことはできない。

DNSは存在の手掛かりであって、サービスの証明ではない

ドメイン側では、ICANNの登録情報、A、AAAA、NS、MX、TXT、CAAレコード、DNSチェーン、DNSSEC検査を層別に見る必要がある。登録・有効期限・レジストラ・ネームサーバーは、ドメイン管理の状態を示す。NSは委任先を、AとAAAAはその時点で公開されたアドレスを、MXはメール関連の構成を、TXTは検証や送信者ポリシーなどの手掛かりを、CAAは証明書発行の制御を示す可能性がある（ICANNルックアップ、Aレコード、AAAAレコード、NSレコード、MXレコード、TXTレコード、CAAレコード、RIPEstat DNSチェーン、DNSViz）。

ただし、DNS委任が残っていることは、Webサービスが稼働していることを意味しない。Aレコードが返ることも、TLS接続やアプリケーション応答の成功を意味しない。第三者のDNS、メール、CDNを使う構成は一般的であり、レコードの存在だけでは運用主体を特定できない。Google Public DNSの結果も、地域、キャッシュ、名前解決時刻によって変わり得るため、取得時刻を必ず併記しなければならない。

証明書とWebアーカイブの位置付け

証明書透明性ログ、Cert Spotter、SSL Labs、urlscan、Internet Archive、Censys、Shodanは、ドメイン名が過去または現在の公開面に現れたかを調べる材料になる（対象Webサイト、crt.sh、Cert Spotter、urlscan、SSL Labs、Internet Archive、Censys、Shodan）。

証明書の発行は、ドメイン制御または発行時点の検証を示し得るが、顧客向けクラウドサービスの提供を示さない。証明書が最近発行されたとしても、HTTPサービスが現在応答するとは限らない。反対に、過去のアーカイブやスキャン記録は、ある時点の存在を補強できるが、今日の連続稼働を証明しない。単一の成功スナップショットは瞬間的な存在を示すだけであり、連続性には複数地点からの反復的で時刻付きの観測が必要である。

「クラウドサービス」の証拠に必要な最後の層

顧客向けクラウドサービスを主張するには、公開WebサイトやAS番号を超える証拠が必要になる。少なくとも、サービスの入口、認証または登録フロー、APIや管理画面、利用条件、料金または提供地域、障害時の挙動、実際に利用できる顧客ワークフローが確認対象になる。公開されたネットワークがあっても、それがトランジット、ホスティング、研究、内部接続、セキュリティ監視、メール、Webサイトのどれに使われているかは、BGPだけでは判別できない。

このため、検証の因果鎖は次のように分解すべきである。第一に、登録主体または自己申告がASとドメインを結び付けているか。第二に、DNSがどのエンドポイントを返すか。第三に、そのアドレスをどのプレフィックスとoriginが収容するか。第四に、TLSとHTTPがどの名前、証明書、サーバー、アプリケーション面を返すか。第五に、利用者が実際の顧客ワークフローを完了できるか。各リンクは別の運用者に依存する可能性があり、前のリンクが確認されても次のリンクは自動的には確認されない。

今回の結論は「未確定」である

今回の調査パッケージは、30件の公開ソース候補を列挙し、AS210328の登録、経路、DNS、証明書、Web履歴、スキャン記録を検証できる構成になっている。しかし、実行時には現在のHTTP、DNS、一般Web応答を取得できなかった。したがって、AS210328の現在のプレフィックス、現在のBGP可視性、almazcloud.networkのDNS存在、ドメインのアドレスとAS210328の対応、最近の証明書活動、Web到達性、顧客向けクラウドエンドポイントのいずれも、今回の実行では観測済みの事実として記録できない。

この「未確定」は、停止や不存在の証明でもない。プローブが応答を得られなかった場合に言えるのは、そのプローブが結果を取得できなかったということだけである。逆に、将来一度だけ応答が得られても、長期的な連続運用までは示さない。現在の可視性を主張するには、複数の独立ソース、複数の観測時刻、アドレスからoriginまでの対応、そしてアプリケーションまたは顧客ワークフローを組み合わせる必要がある。

読者が次に確認すべき指標

今後の再調査では、RIPEstat、BGP.Tools、Hurricane ElectricでAS210328の発表プレフィックスとoriginが同じ時刻帯に一致するかを確認する。次に、複数の公開リゾルバーからalmazcloud.networkのA、AAAA、NS、MX、TXT、CAAを取得し、TTL、CNAME、地域差を記録する。そのアドレスをBGP観測に照合し、CDNまたは外部ホスティングの存在を切り分ける。最後に、TLS証明書、HTTP応答、リダイレクト、アプリケーション面、利用可能な顧客フローを時刻付きで保存する。

この順序を守れば、行政的な名前、ネットワークの存在、Webの存在、クラウドサービスの存在を混同せずに済む。現時点で最も正確な判断は、公開情報の検証経路は定義できるが、AS210328とalmazcloud.networkの独立に観測可能な運用フットプリントは、この実行では確定していない、というものだ。