摘要

  • 多个独立路由观测方一致显示:AS210860 自 2026 年 3 月 26 日起没有出现在全球路由表中,当前公告的前缀为零,历史上唯一发出的 IPv4 前缀是 193.21.248.0/21。
  • 权威的 RIPE 数据库查询端点在本轮检索中再次只返回一个 JavaScript 应用外壳,没有返回任何第一方字段值;所有登记字段值仍然来自第三方镜像。
  • 两个相互独立的 RIPE WHOIS 镜像在 aut-num 对象上一致:as-name 为 edeka_digital,状态 ASSIGNED,组织 ORG-EDG14-RIPE,管理联系人与技术联系人均为 DA9499-RIPE(即 DFINFRA 角色),创建于 2021 年 8 月 24 日,最后修改于 2021 年 10 月 27 日。
  • 两个镜像在组织对象上并不一致:一个显示 org-name 为 EDEKA Verwaltungs- und Beteiligungs GmbH、最后修改 2026-05-13;另一个显示 EDEKA DIGITAL GmbH、最后修改 2021-10-27。
  • RIPEstat 将 AS210860 的状态渲染为 RESERVED 且无持有人,但 RIPE 第一方文档明确说明 aut-num 的 status 属性只可能是 ASSIGNED、LEGACY 或 OTHER;这更可能指向数据层差异,而不是注册状态的改变。

一个沉默的 ASN 不是一个无足轻重的 ASN。AS210860 登记在 RIPE 服务区域内,as-name 为 edeka_digital,组织句柄为 ORG-EDG14-RIPE,而它的行政与技术联系人是一个名为 DFINFRA 的角色对象(nic-hdl DA9499-RIPE)。这个结构本身没有问题——企业集团内部的网络部门以一个功能性名称出现在登记册上是常见做法。问题在于:公开记录能够证明什么,不能证明什么。

路由层面:零公告状态自 2026 年 3 月以来没有变化

三个相互独立的路由观测方,在本轮检索中对 AS210860 的当前路由行为给出了互相印证的答案。Hurricane Electric 的 BGP 工具记录该 ASN 自 2026 年 3 月 26 日起未出现在全球路由表中,当前公告的前缀为零,RPKI 有效与无效的发起条目均为零,历史上仅发起过一个 IPv4 前缀 193.21.248.0/21,该前缀归属标签为 EDEKA DIGITAL GmbH( Hurricane Electric 观测,IPv4 视图同样记录该结论 IPv4 视图)。CIDR Report 将其分类为 NOT Announced,即既不公告前缀、也不是可见的过渡 AS CIDR Report 分类。RIPEstat 的 RIS 面板同样显示该 AS 不发起任何 RIS 可见的前缀,也不是 RIS 可见的过渡 AS RIPEstat 面板。

这三个来源的口径不同:HE 是路由表与历史记录的聚合视图,CIDR Report 基于周期性的全球路由表快照,RIPEstat 引用的是 RIS 路由探测网络。它们共同指向同一个可观察事实:自 2026 年 3 月 26 日以来,AS210860 在公开可测量的层面上是沉默的。本轮检索没有发现任何相反的观测。

登记层面:权威端点仍然读不到,镜像承担了全部证据责任

这一轮研究中最大的局限,与 2026 年 9 月 BTW 的调查所遇到的完全相同:RIPE 数据库的权威查询界面(apps.db.ripe.net 的 db-web-ui)是一个客户端渲染的 JavaScript 应用,本轮直接访问该 URL 只返回了页面外壳,没有任何 RPSL 对象文本 权威查询端点。这意味着,截至本文撰写,AS210860 的登记状态没有一份第一方字段值。

承担证据责任的,是两个相互独立的第三方 RIPE WHOIS 镜像。whois.ipip.net 返回了基本逐字的 RPSL 文本 ipip.net 镜像:aut-num AS210860,as-name edeka_digital,org ORG-EDG14-RIPE,status ASSIGNED,admin-c 与 tech-c 均为 DA9499-RIPE,mnt-by 为 RIPE-NCC-END-MNT 与 EDDI-MNT,创建 2021-08-24T08:30:41Z,最后修改 2021-10-27T08:53:15Z,并声明了对 AS9211 与 AS13237 的对称 import/export 关系。ip.cc 镜像复现的 aut-num 字段与之逐字一致 ip.cc 镜像。IPinfo 的独立页面同样将该 ASN 标记为 Inactive、当前前缀为零（https://ipinfo.io/AS210860）。RIPE 文档对机器可读查询路径的规范说明可见于 RESTful 查询文档（https://docs.db.ripe.net/How-to-Query-the-RIPE-Database/RESTful-API-Queries）。本实体名录背景可参见（https://btw.media/zh/directory/dfinfra）。两个独立镜像在同一对象上的逐字一致,是镜像证据能达到的最强形态——但它仍不是第一方证据。

镜像同时暴露了两处真实分歧。第一,组织对象的名称:ipip.net 镜像显示 ORG-EDG14-RIPE 的 org-name 为 EDEKA Verwaltungs- und Beteiligungs GmbH,注册号为汉堡地方法院 HRB 90516,org-type 为 LIR,地址为 New-York-Ring 6, 22297 Hamburg,最后修改 2026-05-13T07:28:38Z;ip.cc 镜像对同一句柄显示 org-name 为 EDEKA DIGITAL GmbH,最后修改 2021-10-27T08:58:29Z。第二,自治域块记录:ipip.net 显示包含 AS210860 的块为 AS208189–AS214345,创建/修改于 2026-02-12;另一个聚合页面则显示 AS208885–AS214345、修改于 2026-07-13 ipgeolocation.io 页面。在无法读取第一方对象的情况下,这些分歧只能被记录,不能被裁决。

状态之争:RESERVED 与 ASSIGNED 是不是同一枚硬币的两面

RIPEstat 的 RIR 表格将 AS210860 渲染为状态 RESERVED,持有人字段为空,快照时间戳为 2026-09-14。这与镜像显示的 ASSIGNED 与具名 EDEKA 组织直接冲突。但裁决这个冲突的钥匙不在镜像里,而在 RIPE 自己的文档中:aut-num 的 status 属性是软件生成的,合法取值只有三个——ASSIGNED、LEGACY、OTHER,用户不能设置或更改它 RIPE 数据库文档。RESERVED 不是这三个值之一,这强烈提示 RIPEstat 渲染的是一个不同的数据层(资源状态查询),而不是 aut-num 对象本身的 status 属性。换言之,最合理的解释不是注册状态发生了改变,而是两个服务在回答两个不同的问题。

前缀与控制链:缺的仍然是 route 对象那一环

RIPE 框架下,前缀不是 aut-num 的属性,而是通过独立的 route/route6 对象绑定到发起方,授权由 mnt-by 或 mnt-routes 维护者控制(同一份 RIPE 文档对此有明确说明)。这意味着,要回答"DFINFRA 能否控制哪些前缀与 AS210860 绑定",必须查到 route 对象本体。本轮检索的三个镜像输出中均未出现 route 或 route6 对象文本;但 aut-num 键的查询范围本来就不覆盖 route 对象,所以这个缺席不能证明其不存在。历史上唯一发出的前缀 193.21.248.0/21 的归属标签,HE 给的是 EDEKA DIGITAL GmbH,与 ip.cc 镜像的组织名一致,与 ipip.net 镜像的母公司名不同——这个标签分歧与组织对象的分歧同源,同样未被裁决。

结论:状态差异为零,证据链的缺口也保持原状

回答本轮的核心问题:自 2026 年 9 月的 BTW 调查以来,AS210860 的公开可观察状态没有发生任何变化。路由沉默持续,登记字段(按镜像)未变,权威端点依旧不可读,新的组织对象分歧与 9 月时相同。如果有什么增加了,是方法论上的:RIPE 文档为解释 RESERVED 渲染提供了第一方依据,使"状态冲突"更可能被读为数据层差异而非注册事件。但四层链条——记录、授权、观测、控制——的最后两层之间的缺口,仍然没有被任何公开证据闭合。下一个能真正改变局面的事件,是 RIPE REST API 或 port-43 查询成功返回第一方对象字段,或该 ASN 重新出现在路由表中。