摘要

  • 公开注册资料将 DFINFRA 这一名称与 AS210860 联系起来，但这本身不能证明受益所有权、法律所有权、实际操作权限或持续服务。
  • IRR 路由对象、RPKI 授权、RIPEstat、RIS 和第三方 BGP 聚合器回答的是不同问题；它们不能单独证明面向客户的服务、商业控制或网络连续性。
  • 要证明可归因的运营足迹，需要在时间范围内把登记身份、技术权限、观察到的路由、互联或设施存在、服务机制和运营或商业后果连接起来。

登记关联只是调查的起点

RIPE 的 RDAP 记录和 RIPE Database 中的 aut-num 对象，是有关 AS210860 的行政和登记证据。它们可以说明公开数据库如何记录一个自治系统，以及其中的名称、联系人或相关属性如何与 DFINFRA 发生关联。RIPE RDAP 记录和RIPE Database 的 AS210860 对象因此是调查的第一层证据。

但第一层证据不能自动回答后续问题。登记名称可能代表组织、品牌、管理账户、客户关系或历史遗留信息。即使某个名称出现在自治系统对象中，也不能仅凭这一点确认最终受益所有人、实际持有设备的人、负责网络日常运维的团队，或某项服务是否仍在持续。IANA 的号码分配背景可以帮助界定自治系统号码的制度位置，但它同样不是 DFINFRA 运营能力的证明。IANA 的 AS 号码资料提供的是编号体系的公共背景，而不是该实体的客户、设施、带宽或收入记录。

这一区分很重要，因为“与 AS210860 相关联”是一个可以由公开登记支持的有限陈述；“DFINFRA 拥有并持续运营一张面向客户的网络”则是一个更强的判断，需要额外证据。两者之间不能用推断填补。

技术权限不等于运营结果

调查的第二层是资源和路由权限。RIPE 的 route 和 route6 对象、IRR 政策、RPKI 的 ROA，以及 RIPEstat 的相关接口，可以分别显示申报的路由意图、某些资源授权关系或在特定时间窗口内可见的控制平面状态。RIPE 的 route 对象检索、AS 概览、已宣布前缀数据和路由状态数据属于不同类型的观测，不能被压缩成一个“运营商证明”。

IRR 对象表达的是申报的路由政策或对象关系。RPKI ROA 表达的是某个前缀是否被授权由某个 origin AS 宣布，以及验证系统如何处理这一授权。两者都可能对路由安全有意义，但都不说明网络是否拥有自己的路由器、是否为客户提供接入、是否有足够容量，也不说明服务是否连续可用。

同样，某个前缀在某个时间点出现在 BGP 观测中，只能说明观察者在那个时间点看到了相关控制平面信号。它不能单独证明发布者拥有物理链路，也不能证明该发布对应一项商业服务。对任何宣布记录，都需要问：由谁发布、从哪些观测点可见、持续多久、是否发生变化、是否有同一实体的其他证据能够解释这一行为。

路径相邻关系不自动等于供应商依赖

AS-path 邻接是调查依赖结构的有用线索，但不是依赖关系本身。RIPE 的 looking glass 和 ASN neighbour 数据，以及 BGP.Tools、Cloudflare Radar、CAIDA AS Rank、Hurricane Electric 和 BGPView 等来源，可以从不同观察位置呈现路径、邻接或网络关系。RIPE looking glass 数据、RIPE ASN neighbours 数据、BGP.Tools 的 AS210860 页面、Cloudflare Radar 路由页面、CAIDA AS Rank、Hurricane Electric 的 BGP 页面和BGPView 上游数据都需要结合时间、观察点和方法解释。

相邻 ASN 可能是付费 transit 提供商、对等网络、客户、同一控制集团内的另一网络，或者只是在某一时刻出现的备用路径。单个 AS-path 不能揭示合同关系、计费关系、容量承诺或故障转移责任。即使多个来源显示相同邻接，也仍然需要独立材料说明这一邻接在业务上是什么。

因此，严谨的表达应当是“某些观测显示 AS210860 与某个 ASN 存在路径邻接”，而不是“该 ASN 是 DFINFRA 的上游供应商”。后者只有在合同、运营者声明并得到技术观测支持时才成立。路由图能够显示控制平面的可见关系，却不必然显示组织、财务和服务层面的关系。

PeeringDB 是线索，不是独立证明

PeeringDB 的网络记录、网络互联记录和相关文档，可能包含网络名称、交换点、互联设施或联络信息。PeeringDB 网络 API、AS 页面、网络互联 API和PeeringDB 文档对于寻找运营足迹很有价值，但它们通常属于运营者维护或提交的信息。

这使 PeeringDB 适合作为调查线索，而不是未经核实的独立事实。一个记录可以帮助记者提出问题：该实体是否声称在某个设施、交换点或网络环境中存在？这种声明能否由交换点成员名单、设施方资料、流量观测、地址使用记录或其他独立来源证实？如果不能，就应明确标注为自报信息，而不能把它改写成已确认的物理存在。

“在数据库中有一条网络记录”和“在一个设施中有可运作的互联设备”是不同命题。前者是数据库事实；后者需要时间范围、设施归属、端口或互联证据，以及能够归因给 AS210860 的技术活动。

当前材料没有闭合运营足迹证据链

本次研究汇集了 IANA、RIPE、RIPEstat、RIS、PeeringDB、BGP 观察工具、RPKI 和 IPinfo 等来源候选，但研究运行时没有取得这些来源的实时内容。因此，本文不声称当前前缀数量、具体上游、具体对等方、设施、交换点、ROA 状态或独立记录的 DFINFRA 服务机制。Cloudflare RPKI 数据、IPinfo 的 AS210860 页面、RIPE RIS和RIPE 数据 API 文档被列为后续核验入口，而不是已经在本文中完成的实时取证。

这不是说相关事实必然不存在，而是说在当前证据边界内，不能把它们写成已经核实的事实。没有实时前缀数量，就不能可靠描述规模变化；没有命名并独立核实的上游，就不能描述商业依赖；没有设施或端口证据，就不能描述物理存在；没有可归因的服务机制，就不能推断客户服务、容量或收入；没有连续时间序列，就不能判断持续运营、恢复能力或放弃。

什么证据才足以证明运营控制？

一个更强的运营足迹结论至少需要六个相互连接的层次。

第一，登记身份必须明确：公开注册信息中的 DFINFRA、AS210860 和相关资源之间要有可核查的关联。第二，技术权限必须明确：路由授权、资源对象或其他控制关系要能在特定时间点得到证实。第三，控制平面活动必须得到观察：多个观测点或独立系统应显示稳定、可解释且有时间边界的路由行为。第四，运营环境必须可归因：互联设施、交换点、托管环境或设备存在应有独立证据。第五，服务机制必须具体：需要知道网络究竟向谁提供什么服务，通过何种资源、链路或运营流程提供。第六，后果必须可观察：变更、故障、恢复、流量、公告或客户影响应能与该运营者的行为建立合理联系。

这六层不是一张简单的核对表。它们之间可能出现不一致：登记关系很清楚，但路由活动不稳定；路由可见，却没有可证实的设施；PeeringDB 声称存在互联，但没有独立观测；某个邻接长期出现，却无法确定是供应商还是集团关系。调查的价值正是在于保留这些断裂，而不是用最强的结论覆盖最弱的证据。

依赖结构应当以失败机制来检验

如果目标是判断 AS210860 的依赖结构，最有信息量的问题不是“它连接了谁”，而是“当某个关系消失时，什么会发生”。这要求时间序列和事件证据：某条路径是否在变更前后消失？是否存在替代路径？替代路径是否由不同网络、不同设施或不同法域提供？某次中断是否影响公告、可达性或服务端点？谁发布了事件解释，解释是否与观测数据一致？

在没有这些材料之前，只能把邻接和拓扑视为待验证的机制假设。一个网络可能使用租赁地址空间、托管路由器、转售带宽或软件定义的边缘服务；也可能只是拥有登记关系而没有可观察的持续服务。相同的 BGP 图形可以来自完全不同的商业和技术安排。

结论：公开数据目前能证明什么

截至这次研究的证据边界，公开登记资料支持这样一个有限结论：DFINFRA 这一名称与 AS210860 存在可观察的行政关联。技术数据库和路由观测工具提供了一组能够继续验证资源权限、路由活动和潜在依赖的入口。但当前材料没有闭合从登记身份到实际服务机制的证据链，因此不能据此确认受益所有权、自有设备、客户、收入、持续可用性或故障恢复能力。

真正有分量的后续证据应当是时间限定、相互独立并可归因的：一组连续的路由观测，一份能说明权限关系的资源记录，独立确认的设施或交换点存在，明确的服务或合同机制，以及与变更或故障相对应的运营后果。在这些证据出现之前，最准确的判断不是“DFINFRA 没有网络”，也不是“DFINFRA 已被证明运营网络”，而是：公开资料提出了一个可检验的运营假设，但尚未证明其完整的运营足迹。

来源与目录

本文使用的公开来源入口包括：

DFINFRA 的 BTW 目录条目