Number Resource Society

登记资料与 BGP 路由为什么对不上?

登记的是哪家机构、哪个网络正在通告、谁获准作为路由起源,是三个不同的问题。把这些证据分开核对,才能判断差异来自正常安排、未完成的变更,还是需要立即处理的风险。

Ann Yong首次发表 更新
本页内容
登记记录与 BGP 路由的关系示意图

沿用英文原文配图。

先分清:你手里的证据究竟在说明什么

你查到一个地址块登记在甲公司名下,却发现 BGP 中的起源 ASN 属于另一家网络。这样的差异值得解释,但不能仅凭这一点就认定资源被劫持,或登记资料有误。企业可能把路由交给上游、托管商或其他基础设施伙伴;登记关系与运营安排并不一定由同一个主体承担。

登记记录描述资源与组织的行政关联;BGP 观测描述某个位置、某个时刻看到的路由通告;RPKI 的 ROA 描述获准的路由起源;IRR 保存登记的路由政策信息;内部台账说明企业原本打算怎样使用资源。它们需要互相印证,却不能互相替代。

五种证据,五个不同的问题
证据层主要回答什么

登记记录/RDAP

哪个组织、登记对象或联系人与这项资源关联?

BGP 观测

从这个观测点看,哪个 ASN 正在作为这个前缀的起源?

RPKI/ROA

哪些 ASN 获准以什么前缀长度作为路由起源?

IRR

登记了哪些路由对象和政策信息?

内部台账与变更记录

企业预期谁来运营,为什么这样安排,谁负责变更和恢复?

RDAP 可以返回 IPv4、IPv6 或 ASN 的登记资料,例如地址范围、标识、网络名称、关联实体、状态、联系人、事件和上级资源。字段结构可参阅 RFC 9083,具体阅读方法见 如何读取 IP 地址的 RDAP 记录。status 为 active,不等于这个前缀此刻一定能从互联网访问。

BGP 用于自治系统之间交换可达性信息,协议定义见 RFC 4271。下面是一条经过简化的示例路径,最后的 AS64500 是所示起源。真实排查还要记录采集器、对等网络和时间;一个采集器的可见结果,不是整个互联网的完整视图。

前缀:203.0.113.0/24
观测到的简化 AS 路径:AS64496 AS64497 AS64500
所示起源:AS64500

BGP 能帮助你查明谁在通告,却不直接证明资源登记在谁名下、合同允许谁使用,或通告是否获准。查证方法见 如何检查谁在 BGP 中通告一个前缀。

本版示例采用文档专用的地址和 ASN,范围分别见 RFC 5737 和 RFC 5398,避免把虚构场景写成真实运营网络的行为。

六种常见场景:名称不同,不一定有问题

上游代为通告

企业持有或管理地址资源,但由接入服务商的 ASN 发起路由。RDAP 显示企业,BGP 显示服务商,是两项可以同时成立的事实。关键是这项安排是否得到授权、是否符合预期,而不是两处名称是否相同。

托管与代运维

企业把系统放在另一家运营者的基础设施上,双方约定由托管商通告客户的地址。资源登记关系没有因此自动改变,实际路由却由服务商承担。检查时要把合同、授权和技术配置连起来看。

DDoS 清洗

遭遇攻击时,清洗服务商可能临时通告客户的前缀。平时由 AS64500 起源,清洗期间改由 AS64501 起源,登记资料可以始终不变。这类切换应有事先约定,并检查相应 ROA、过滤策略及恢复安排;不能因为“是在做清洗”就省略核验。

网络迁移

更换服务商或起源 ASN 时,旧、新网络可能在过渡阶段同时出现。资源对应的组织没有变,改变的是路由架构。保留迁移窗口、批准记录和回退方案,才能解释过渡状态。

Anycast

同一个前缀可以从多个地点提供服务。具体架构可能使用同一 ASN,也可能涉及不同 ASN。登记记录描述资源关系,BGP 观测描述各观测位置看到的通告;多地点服务与多起源 ASN 不能简单画等号。

并购与组织重组

公司已经完成收购,原网络可能仍按原样运行;也可能先更新了登记,网络迁移几个月后才完成。公司变更、登记变更和路由变更并不天然同步。进一步阅读 并购时,IP 地址会发生什么变化?。

登记改了,路由可能没改;反过来也一样

一个 IPv4 地址块从甲公司转给乙公司后,乙公司可能暂时继续使用原服务商和原 ASN。登记已经变更,BGP 通告却保持不动。这可以是有计划的过渡,但前提是安排有据可查、授权有效,相关人员知道当前处于什么阶段。

转移后的登记组织:乙公司
过渡期的预期起源:AS64500
观测到的 BGP 起源:AS64500
需要另查:乙公司是否认可并授权这项过渡安排

相反,企业更换上游、改变起源 ASN、接入清洗、调整流量工程、迁移网络或外包路由运营,都可能改变 BGP,而不改变资源登记的组织。不要把“登记没变”当成“网络没有发生变化”的证据。

RDAP 中的 startAddress、endAddress、name、status、entities、events 描述登记对象,不是实时 BGP 状态。观察到某个 ASN 通告一个前缀,也不能据此推断它拥有该资源、已获许可,或它的通告一定合法或恶意。先辨明证据边界,再调查具体关系。

ROA 和 IRR 能解释什么,又不能证明什么

ROA 是带有数字签名的路由起源授权对象,格式见 RFC 9582。它把前缀、允许的最大前缀长度和被授权的 ASN 联系起来。它不是完整 AS 路径的安全证明,也不自动说明合同权利或整个网络的控制关系。以下示例的 maxLength 24 表示有效最大长度:省略 maxLength 时,只授权精确前缀;不建议在编码中填写与前缀长度相同的冗余 maxLength。这是概念示意,不是配置模板。

情况一:预期、授权和观测一致

登记组织:示例企业甲
预期起源:AS64500
ROA:203.0.113.0/24,maxLength 24,AS64500
BGP:203.0.113.0/24 → AS64500

这说明所示通告与这条授权匹配。登记组织和运营 AS 仍可能是不同实体,且匹配不能排除路径、转发或其他环节的问题。

情况二:起源换了,授权没有跟上

ROA:203.0.113.0/24,maxLength 24,AS64500
BGP:203.0.113.0/24 → AS64501
本例条件:验证器中没有其他能匹配该通告的授权

在本例条件下,通告会被判为 Invalid。原因可能是 ASN 迁移、服务商切换后仍保留旧 ROA,也可能是配置错误或未经许可的通告。结论是“授权与通告不匹配”,不是“已经证明恶意劫持”。

情况三:企业登记,服务商起源,授权支持这个安排

登记组织:示例企业甲
约定的运营商:示例网络乙(AS64501)
ROA:203.0.113.0/24,maxLength 24,AS64501
BGP:203.0.113.0/24 → AS64501

两处主体名称不相同,却可能有一条清楚的授权和运营关系。相比只比名字,核对前缀、起源 ASN、授权与内部安排更有意义。ROA 是重要的技术证据,但不能单独替代合同和变更审批。

读懂 Valid、Invalid 与 NotFound

  • Valid:验证器的有效授权数据中,至少有一项覆盖该路由,并同时满足起源 ASN 和前缀长度要求。
  • Invalid:存在覆盖该路由的授权数据,但没有任何一项同时满足相关要求;起源不符或前缀过长都可能造成这种结果。
  • NotFound:没有覆盖该路由的有效授权数据。它不等于“没有资源权利”,也不等于“路由一定安全”。

比较时要记录验证时点、验证器及其数据状态。验证结果与网络采取的过滤策略是两个环节;一次 Invalid 不能直接推导出全球必然断网。机制见 RFC 6811 和 RFC 8481。NRS 的 ROA 覆盖率与 ROV 采用情况进一步讨论这一区别。

IRR 记录也需要跟着运营变化更新

route: 203.0.113.0/24
origin: AS64500

一些网络依据 IRR 数据生成路由过滤器。如果 IRR 仍登记 AS64500,实际通告已变为 AS64501,应查明是不是迁移遗漏、陈旧对象或变更管理没有完成。IRR 保存的是登记信息,不保证此刻的生产状态;它与 RPKI 也不是同一种证据。相关格式和运维背景可参阅 RFC 2622 与 RFC 7454。

真正需要追查的是无法解释的差异:例如内部台账、ROA 和 IRR 都指向 AS64500,BGP 却出现了未预期的 AS64502。尽快核对运营变更、服务商配置、通告授权和历史证据,再判断属于配置故障、路由事件,还是记录没有更新。不要仅凭一个差异替事件定性。

遇到差异,按这七步查证

一、确认你比的是同一段地址

写明 CIDR 前缀及长度,分清登记范围与实际通告的关系。登记一个 /20、分成多个 /24 通告,不是同一对象的两条互相矛盾的记录。

二、记录 RDAP 结果

记录登记范围、关联组织、注册机构、状态和事件。保留查询时间与来源。不要把字段没有提供的信息自行补成结论。

三、查看 BGP

记录看到了哪些前缀、起源 ASN、AS 路径、更具体的路由和多起源情况,以及观察位置和时间。重要事件要比较多个观测点,不能把“某处没看到”直接等同于“全球不存在”。

四、核对 RPKI

对所见前缀与起源组合检查 Valid、Invalid 或 NotFound。核对覆盖授权、ASN、maxLength 和数据时间,而不只是抄下一个状态标签。

五、检查 IRR

查相关 route 或 route6 对象及 origin,留意过期、冲突或与当前变更不一致的登记。

六、对照企业自己的记录

确认预期起源、服务商、网络架构、最近迁移和临时清洗安排。公共数据未必能告诉你企业的意图,内部文件要补上这一层。

七、查明哪个环节偏离了预期

不要默认第一个不同的系统就是错误的一方。找出预期状态、谁批准过变更、哪些动作已完成,以及哪些记录或配置还需要更新。把调查结论、责任人和后续核验留下来,才能让一次排查变成可恢复的运营知识。

更具体的前缀、多起源和历史,往往能解释表面差异

登记范围与更具体前缀

较大的登记范围可以包含多个更具体前缀。它们可能因多宿主、地域安排、客户委派或流量工程而采用不同起源。比较之前,先把地址范围的包含关系画清楚。下面只演示范围计算,不代表这些路由能在全球互联网传播,也不是建议通告 /25。

示例登记范围:203.0.113.0/24
其中前半段:203.0.113.0/25
其中后半段:203.0.113.128/25
不同子范围的运营关系,必须分别核对

同一个前缀出现多个起源 ASN

观测甲:203.0.113.0/24 → AS64500
观测乙:203.0.113.0/24 → AS64501

这通常称为多起源 AS(MOAS)情况。它可能与 Anycast、迁移、DDoS 清洗或共享路由架构有关,也可能是意外通告。需要确认两个观测的时间、位置、授权和业务安排,不能仅凭“多了一个起源”判断原因。

把当前状态放回时间线

若一月看到 AS64500,十月变成 AS64501,历史数据可能显示变更恰好发生在服务商迁移、收购、机房搬迁或清洗启用之日。时间对应可以提供线索,但仍要核对变更记录,不能只因日期接近就认定因果。

企业记录能解释登记为什么落后

更名、子公司重组、收购、合并和实体整合后,登记更新可能尚未完成。这不意味着可以长期放任错误信息,而是要查清应由谁、通过什么程序更新。准确的登记有助于账户恢复、转移、尽调、安全响应和业务连续性。

分清企业直接管理与服务商指派的地址

企业正在使用的地址,不一定直接登记在企业名下。服务商指派给客户使用时,RDAP 和 BGP 都可能显示服务商。尤其在更换供应商前,应确认企业掌握的是哪种资源关系、能否继续使用,以及迁移需要哪些条件;不要从“我们一直在用”推导出可以自由带走。

登记、路由、权利和控制,必须分别留证

一家服务商可能在企业委托下运行起源 ASN;企业也可能保留资源管理关系,却没有直接操作路由设备。把“谁被登记”“谁获起源授权”“谁实际通告”“谁能改账户和配置”拆开记录,才能知道出现问题时该找谁,以及能否自行恢复。

企业内部对照台账示例。所有地址、ASN 和名称均为说明用数据;验证状态仅描述示例中给定的授权条件。
前缀登记实体预期 ASN观测 ASNRPKIIRR origin跟进状态

203.0.113.0/24

示例企业甲

AS64500

AS64500

Valid

AS64500

所列各层相符,仍需常规监测

198.51.100.0/24

示例企业甲

AS64500

AS64501

Invalid

AS64500

调查变更与授权,不直接判定恶意

第二行假设存在覆盖该前缀的 AS64500 授权,但没有能匹配 AS64501 通告的其他有效授权。实际台账还应记录观测时间、验证器、服务商安排、变更单、责任人与复核日期。没有这些背景,表格上的颜色和状态很容易制造错误的确定感。

这不是一次性查错,而是业务连续性的基础

适合重新核验的时点包括年度号码资源审计、并购、IPv4 转移、服务商迁移、ASN 变更、RPKI 部署、原因不明的可达性问题、DDoS 清洗和组织重组。日常保留基线,比事故发生后临时拼凑历史更有用。

转移完成,不等于所有技术层都已切换

地址转移可能更新登记关系,但 BGP、RPKI、IRR 和 DNS 仍可能各有待办。每一层都需要明确负责人、变更次序和核验结果。NRS 的 2026 年 IPv4 转移市场数据讨论资源在组织之间流动的背景;越是频繁流转,越不能忽略记录和运营的衔接。

并购不需要强迫所有层同一天改变

买方接管公司后,原网络继续运行几个月并不奇怪。应当追求的是:每一层都有人理解、有记录、符合实际、能够恢复,而不是为了形式一致而冒险同时改动所有配置。

准确登记与运行中的网络同样重要

知道有哪些资源、哪个实体被登记、哪个 ASN 应当起源、哪些 ROA 和 IRR 对象支持它、谁控制有关账户,有助于排障、迁移、安全响应和灾难恢复。登记准确不代表路由一定正常;网络当前能通,也不代表管理记录可以不管。

互联网中的数据包由运行中的网络转发,不由一张登记表直接转发。登记、授权、实际路由和组织知识各有功能。可靠的治理不能要求一个数据库替所有层作答,而应让不同证据能被核实、差异能被解释、变更能被追责。

最后复核:差异是否讲得通,组织是否有办法处理

登记与 BGP 对照检查清单
检查层面需要回答的问题

前缀

比较的是同一 CIDR 范围吗?

RDAP

登记资料关联的是哪个组织?

BGP

在所记录的观测点和时刻,起源 ASN 是哪个?

RPKI

有效授权是否覆盖并匹配这个前缀、长度和起源组合?

IRR

登记的 origin 是什么,是否仍适用?

更具体前缀

是否有子范围在分别通告?

多起源

是否出现多个起源,是否有合理安排?

历史

路由最近是否变化,能否找到变更背景?

服务商

是否有第三方代为运营或通告?

内部记录

当前状态是否符合企业预期?

文件证据

这项关系能否被说明和核实?

连续性

必要时,组织能否更新、纠正或恢复各层?

七种容易误导判断的做法

把不同当成错误:第三方代为通告可能完全符合安排。

把相同当成安全:ASN 在几处一致,仍不能排除其他路由问题。

把 RDAP 当作实时路由工具:登记对象并不提供当下的 BGP 全景。

把 BGP 当作产权数据库:通告行为不等于法律或合同权利。

忽略 RPKI:漏掉了起源授权这一项重要技术证据。

忽略内部记录:公共数据不一定能解释企业真正的运营意图。

变更后不再复核:服务商迁移、转移和并购都可能留下不同步的记录。

不要问“这些系统里,究竟哪一个才是真的”。更有用的问题是:“每个系统在描述什么,它们之间的关系能否解释清楚?”登记不直接路由数据包,BGP 不自行证明授权,ROA 不描绘完整网络,IRR 不保证当前配置。把这些边界讲清楚,资源才更容易被安全地运营、转移和恢复。

常见问题

为什么 RDAP 和 BGP 显示的主体不一样?

因为二者描述的不是同一件事。RDAP 返回登记关系,BGP 观测显示起源 ASN。服务商可能按约定代客户通告地址。需要核对授权和业务安排,而不是只比较名字。

BGP 的起源 ASN 就是 IP 前缀的持有人吗?

不能这样推断。起源 ASN 说明所见通告来自哪个自治系统,并不能完整确定登记关系、合同权利或法律归属。

地址登记在一家企业名下,能由另一家网络通告吗?

可以存在这样的安排,上游接入、托管、DDoS 清洗等场景都可能涉及第三方通告。是否适用于具体资源,仍需核对双方安排、起源授权和实际配置。

RDAP 能查到实时 BGP 路由吗?

RDAP 主要提供登记信息。实际路由应通过 BGP 观测核验,并记录观测点和时间;再与登记、授权及内部记录相互对照。

原文与本版说明

英文原文由 Ann Yong 于 2026 年 10 月 16 日发表。本中文稿按运营者实际查证问题的顺序重新组织,保留原文的场景、核验步骤、三张对照表、误区和四组问答。关于观测范围、RPKI 验证边界和示例资源的说明,是本版另行补充的编辑内容,不追溯归于原文发表日期。英文历史原文保留。示例中的地址、ASN 和企业名称只用于解释关系,不是真实网络观测,也不能直接当作生产配置。

从可核验的事实,走向可问责的治理

NRS 补充说明(2026年10月31日):以下关于代表授权和参与行动的说明由 NRS 后加,不属于 Ann Yong 的原文。

运营者不应因为一个系统的记录,就失去理解、解释和维护自身资源关系的能力。NRS Shield 介绍号码资源与治理风险的支持方式。需要 NRS 代表参与有关程序时,再单独审阅 POA 的授权对象、范围、期限、决策权限和撤回办法。POA 是代表授权,不是 ROA,也不赋予 NRS 路由控制权或保证业务不中断。阅读、咨询和入会本身不构成这项授权。

了解 NRS Shield · 了解 POA 与代表授权 · 查看当前行动

参与其中

注册机构的决定影响着你的网络。与 NRS 一起改变这些决定的形成方式。

每一张网络都运行在运营者从未参与制定的规则之上。NRS 的存在就是为了改变这一点。选择你与我们并肩的方式。