摘要

  • AS210860（as-name edeka_digital，org ORG-EDG14-RIPE，联系角色 DFINFRA / nic-hdl DA9499-RIPE）自2026年3月26日起未再出现在全球路由表中，通告前缀为零，IPv4 与 IPv6 均无。
  • 第三方镜像对同一组织对象 ORG-EDG14-RIPE 的渲染互相矛盾：IPIP.NET 给出 EDEKA Verwaltungs- und Beteiligungs GmbH（HRB 90516，汉堡），最后修改2026年5月13日；ip.cc 给出 EDEKA DIGITAL GmbH，最后修改2021年10月27日。
  • 权威的 RIPEstat announced-prefixes 与 routing-status JSON 端点以及 RIPE 数据库 DA9499-RIPE 查询在本轮核查中再次无法直接获取，注册字段值全部来自镜像。

本报告追踪的对象是 AS210860，一个在 RIPE 数据库中以 as-name edeka_digital 登记、组织对象为 ORG-EDG14-RIPE、管理与技术联系角色均为 DFINFRA（nic-hdl DA9499-RIPE）的自治系统。它并非一个正在扩张的网络：恰恰相反，它是路由表中的一处静默。但正因其静默，围绕它的每一条注册记录都成了身份判断的全部依据——而当这些依据彼此冲突时，问题就不再只是这一条记录的归属，而是整个二手核验体系的可靠性。

先看路由事实。RIPEstat 的渲染页面（数据日期为2026年9月14日00:00:00 UTC）报告该资源没有任何 RIS 可见的起源或中转通告，并将 RIR 注册状态渲染为 RESERVED，未列出任何持有人（https://stat.ripe.net/resource/AS210860）。路由状态端点与通告前缀端点在本轮核查中无法直接取得（https://stat.ripe.net/data/routing-status/data.json?resource=AS210860、https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS210860），但 Hurricane Electric BGP Toolkit 与 CIDR Report 两面独立镜像是一致的：AS210860 历史上只起源过一个 IPv4 前缀 193.21.248.0/21，归属于 EDEKA DIGITAL GmbH 名下，唯一观测到的 BGP 对等端为 AS9211（Nawork Internet Informationssysteme GmbH），RPKI 有效与无效计数均为零（https://bgp.he.net/AS210860）；CIDR Report 将 AS210860（EDEKA_DIGITAL，DE）列为 NOT Announced，即该系统既不通告前缀，也没有可见的中转用途（https://www.cidr-report.org/cgi-bin/as-report?as=AS210860&view=2.0）。

再看注册事实——这正是本期新增矛盾所在。IPIP.NET 镜像完整复现了 RIPE aut-num 对象：as-name edeka_digital，org ORG-EDG14-RIPE，状态 ASSIGNED，admin-c 与 tech-c 均为 DA9499-RIPE，创建于2021年8月24日08:30:41Z，最后修改于2021年10月27日08:53:15Z，维护者为 RIPE-NCC-END-MNT 与 EDDI-MNT，声明的 import/export 策略中提及 AS9211 与 AS13237（https://whois.ipip.net/AS210860）。但同在 IPIP.NET 上，组织对象 ORG-EDG14-RIPE 被渲染为 org-name EDEKA Verwaltungs- und Beteiligungs GmbH，注册地为汉堡地方法院 HRB 90516，最后修改日期为2026年5月13日。而 ip.cc 镜像在复现同一个 aut-num 对象时与 IPIP.NET 完全一致，渲染 ORG-EDG14-RIPE 时却给出 org-name EDEKA DIGITAL GmbH、最后修改2021年10月27日——名称与日期双重矛盾（https://ip.cc/topic/asn/AS210860/）。

两个镜像不可能同时正确。要么2026年5月13日确有一次组织对象修改、且修改后的组织名称是 IPIP.NET 所显示的那个，而 ip.cc 的缓存停留在2021年；要么其中一面镜像对组织对象的渲染本身有误。仅凭公开镜像无法裁决——而这恰恰是问题所在：当权威的 RIPE 数据库查询端点（https://apps.db.ripe.net/db-web-ui/query?searchtext=DA9499-RIPE）无法直接获取时，研究者被迫在两个互相矛盾的二手来源之间选择，核验成本被悄然推高了一整个量级。

需要明确的是对象归属。DFINFRA 是 RIPE 数据库中的角色对象名称（nic-hdl DA9499-RIPE），是 AS210860 的管理与技术联系人。组织对象 ORG-EDG14-RIPE 在不同镜像中被渲染为上述两个不同的法人名称。另有单独存在的德国法律实体 DINFRA GmbH（位于锡根），与本报告对象无关，任何阅读相关记录的人都不应将两者混淆。2021年前的注册事实在两面镜像中是稳定的：DFINFRA 角色对象创建于2021年6月10日07:41:42Z，最后修改于2021年10月27日08:56:42Z，维护者 EDDI-MNT——这一字段值 IPIP.NET 与 ip.cc 完全一致。

BTW 在2026年9月26日至30日的此前报道中已确立基线：自2026年3月26日起通告前缀为零、aut-num 与角色对象自2021年10月27日后冻结、当时观测到的唯一2026年注册变化是5月13日的一次组织对象修改，以及一份来自 PeeringDB 的、与任何可观测路由证据均未对齐的自报数据——10个 IPv4 前缀、1个 IPv6 前缀、开放的 peering 政策（https://btw.media/en/dfinfra-as210860-state-difference-september-2026）。后续对同一对象的生命周期台账报道进一步固化了这一证据结构（https://btw.media/en/governance/rir-watchdog/ripe-ncc/story/dfinfra-as210860-lifecycle-ledger）。本期的可观测新条件，正是镜像层对组织对象的内部不一致——此前报道记录的是镜像对路由、自报对路由的矛盾，而非核验层自身在同一对象上的名称与日期分裂。

这一矛盾的可检验后果是清晰的。若 IPIP.NET 正确，则 ORG-EDG14-RIPE 在2026年5月13日被修改为 EDEKA Verwaltungs- und Beteiligungs GmbH，这意味着注册持有人层面的法人身份已经变更或更正，而 ip.cc 的组织对象渲染已滞后超过四个月；若 ip.cc 正确，则 IPIP.NET 的组织对象渲染存在实质性错误。下一个可观测条件是：权威 RIPE 数据库查询恢复可获取后，直接读取 ORG-EDG14-RIPE 的 org-name 与 last-modified 字段，即可一锤定音。在此之前，任何将该组织对象与特定法人名称绑定的表述，都应明确其来源镜像。