如何读懂一个 IP 地址的 RDAP 记录

查到了记录，只是核查的开始

RDAP 能回答注册机构记载了什么。业务要持续运行，还要知道谁在宣告地址、谁获得授权、谁能管理账户，以及出现变化时谁负责处理。下面按查找、读字段、交叉核对、资源审计的顺序展开。

代码中的地址、组织和日期是原文示例，不是实时查询结果。正文按中文读者的理解顺序重写，字段名和原始 JSON 保持不变。

RDAP 记录能帮你查清什么？

RDAP 是 Registration Data Access Protocol，即注册数据访问协议。它通过标准化的 Web 查询，以 JSON 返回 IPv4 地址范围、IPv6 前缀或自治系统号（ASN）的登记信息。对网络运营者来说，记住缩写远不如理解字段和证据边界重要。

查询一个地址，可以看到包含它的登记范围、提供信息的注册机构、资源标识、网络名称、类型、状态、相关组织和联系人、登记与更新时间、上级资源，以及备注和提示。它适用于资源审计、故障排查、IPv4 转移尽调、并购、安全调查和内部资产盘点。

先问：内部台账与外部登记是否一致？相关组织认得出来吗？技术、管理和滥用投诉联系人还有效吗？这些都是有用的线索，但 RDAP 只是资源审计中的一层证据。

RDAP 与 WHOIS：更好处理，不等于包办所有判断

两者都提供登记资料。传统 WHOIS 主要返回文本，格式往往因注册机构而异；RDAP 使用结构化 JSON、标准查询和 HTTP/HTTPS，更方便程序处理，也支持服务间重定向和国际化。RIPE NCC 与 APNIC 都提供 RDAP 查询服务。

这些优势让 RDAP 更适合自动化台账和审计。即便字段结构统一，也不能假设不同注册机构的分类和政策含义完全一致。先保留原始值，再结合该机构的定义解释。

先找到负责这个地址的查询服务

IP 查询路径通常为 /ip/{IP-address} 或 /ip/{CIDR-prefix}。例如 /ip/192.0.2.1 查询单个地址，/ip/192.0.2.0/24 查询网段。响应通常是 JSON；查到单个地址并不意味着返回的记录只覆盖这一个地址。

不必靠猜测选择 RIR。IANA 的 RDAP bootstrap 数据把地址范围与相应服务关联起来，客户端据此寻找权威登记服务；也可以使用各 RIR 的查询界面。RIPE NCC 的路径示例是 https://rdap.db.ripe.net/ip/{address}。查询时一并记下服务地址和时间，便于复核。

先看一份简化记录

下面的 JSON 把范围、名称、状态、实体和事件放在一起。192.0.2.0/24、EXAMPLE-ORG 以及时间均用于讲解，不对应当前业务的核查结论。真实响应可能包含更多字段，也可能因服务政策和访问权限省略可选字段。

{
  "objectClassName": "ip network",
  "handle": "NET-192-0-2-0-1",
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.255",
  "ipVersion": "v4",
  "name": "EXAMPLE-NET",
  "type": "DIRECT ALLOCATION",
  "country": "ZZ",
  "status": [
    "active"
  ],
  "entities": [
    {
      "handle": "EXAMPLE-ORG",
      "roles": [
        "registrant"
      ]
    },
    {
      "handle": "EXAMPLE-ABUSE",
      "roles": [
        "abuse"
      ]
    }
  ],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2020-01-01T00:00:00Z"
    },
    {
      "eventAction": "last changed",
      "eventDate": "2026-01-15T00:00:00Z"
    }
  ]
}

1. objectClassName：确认你看的是什么对象

IP 网络记录的对象类别是 ip network。其他常见类别包括自治系统号 autnum、组织或联系人 entity、域名 domain 和名称服务器 nameserver。调查一个 IP 前缀时，先确认返回的是 ip network，避免把关联联系人对象当作网段本身。

"objectClassName": "ip network"

2. startAddress 与 endAddress：把完整范围记下来

这两个字段是登记范围的起止地址。查询 192.0.2.45，可能得到 192.0.2.0 至 192.0.2.255 的网络记录。它说明该地址落在这一登记块里，不意味着查询结果只适用于单个主机。

审计时记录整个范围，再与内部前缀清单、子分配和实际宣告比较。遗漏范围边界，会让后续核对从一开始就选错对象。

"startAddress": "192.0.2.0",
"endAddress": "192.0.2.255"

3. ipVersion：区分 IPv4 与 IPv6

v4 表示 IPv4，v6 表示 IPv6。这个字段看似简单，却能避免批量处理时混用地址格式、前缀规则或查询结果。

"ipVersion": "v4"

4. handle：记录的编号，不是权利凭证

handle 是注册机构系统内用于识别该对象的唯一标识。它不是 IP 地址本身，可以用于交叉引用、对象追踪、审计记录、查找相关链接和比较历史资料。

一个编号能告诉你正在讨论哪条登记记录，不能单凭它认定法律所有权。

"handle": "NET-192-0-2-0-1"

5. name：网络名称未必是公司现在的名称

name 是与网络登记关联、方便人识别的名称。企业可能改名、被收购，技术系统中的旧标签却继续存在。因此不能把 EXAMPLE-NET 一类值直接当作当前法人名称。

尽调应把它与 entities、组织资料、公司文件和其他登记信息核对，查明名称之间的关系。

"name": "EXAMPLE-NET"

6. type：按具体注册机构的定义理解

type 表示该 RIR 登记模型中的网络分类。示例中的 DIRECT ALLOCATION 不能被当作所有 RIR 通用的取值和解释。

先记录值及其来源，再查相应机构的术语和政策。分类信息有帮助，但不会自动替你完成权利或合规判断。

"type": "DIRECT ALLOCATION"

7. country：登记国家不是实时地理位置

登记信息中的国家代码不能证明每台服务器或每个用户都位于该国。一个范围可以与某国组织关联，却在另一国路由、跨国提供服务、从多个地点宣告，或用于云基础设施。商业 GeoIP 数据库也可能给出不同结果。

安全调查、尽调或位置核查需要独立证据。示例的 ZZ 是占位值，不能把它当成某个实际国家的查询结果。

"country": "ZZ"

8. status：active 不等于网络已经畅通

status 描述登记对象的状态。IANA 对网络和 ASN 的 active 状态解释为已分配或指派供运营网络使用；这是登记状态，不是实时可达性测试。

它不直接证明前缀正在 BGP 中宣告、路由可达、某个 ASN 获准起源、存在有效 ROA、反向 DNS 正常，或地址正在承载生产流量。登记、路由、RPKI、IRR 和 DNS 应分别核验。

"status": [
  "active"
]

9. parentHandle：沿上级关系追溯

parentHandle 指向上级网络登记。资源具有层级关系，较小范围可能处于更大分配或登记之下。

查看父级记录，有助于理解下游分配、客户网络、资源历史和组织关系。第一条查询记录没有交代清楚的背景，可能需要沿这一关系继续查。

"parentHandle": "PARENT-NET"

10. entities：先识别主体，再看它扮演的角色

entities 数组可以列出组织、个人、角色或其他登记联系人对象。实体可能包含自己的 handle、联系资料、roles、关联实体、事件、备注和链接。

不要看到一个组织名就默认它承担全部责任。还要看角色：它是登记主体、技术联系人，还是处理滥用投诉的联系人？

"entities": [
  {
    "handle": "EXAMPLE-ORG",
    "roles": [
      "registrant"
    ]
  }
]

11. roles：找到真正能处理问题的人

常见角色有 registrant、administrative、technical、abuse、noc 和 billing。示例中的 abuse 指向滥用投诉联系角色，technical 指向技术联系角色；一个实体也可能承担多个角色。

核对组织是否可识别，管理联系人是否仍有授权，技术联系人能否联系，滥用投诉渠道是否可用。关键资源的联系人过期，会在故障、转移、安全事件和账户恢复时变成实际阻碍。

"roles": [
  "abuse"
]

"roles": [
  "technical"
]

12. vcardArray：联系信息可能只公开一部分

实体的 vcardArray 使用结构化方式记录组织或联系人名称、地址、电子邮件、电话等资料。不要假定每次查询都会展示所有字段。

公开程度取决于服务实现、隐私政策、访问权限、遮盖处理、资源类型和适用规则。信息缺失时，先读 remarks 与 notices；查不到公开内容，不等于注册机构没有该信息。

13. events：日期是调查线索

events 用 eventAction 说明事件类型，用 eventDate 记录时间。可能出现 registration、last changed、expiration、deletion 等动作；盘点通常先关注登记和最后修改时间。

最近更新可能只是改了联系人、公司信息、维护数据、完成转移或纠正记录，不自动代表异常。很旧的日期也不能证明资源被弃用。把时间放回业务和登记变更背景中解释。

"events": [
  {
    "eventAction": "registration",
    "eventDate": "2020-01-01T00:00:00Z"
  },
  {
    "eventAction": "last changed",
    "eventDate": "2026-01-15T00:00:00Z"
  }
]

14. remarks：别跳过记录的补充说明

remarks 针对对象补充信息，可能涉及特殊情况、限制、遮盖原因、历史背景或注册机构特有的说明。

尽调时不要因为它靠近 JSON 尾部就忽略。这些文字可能改变你对前面字段的理解。

"remarks": [
  {
    "description": [
      "Additional registration information."
    ]
  }
]

15. notices：理解整份响应的条件

notices 通常位于响应顶层，说明与整体响应有关的使用条款、隐私、版权、数据遮盖、查询限制等。它与针对具体对象的 remarks 作用不同。

自动化系统也应保留并处理提示：它可能解释某些数据为何缺失、返回结果应如何使用。

16. links：顺着关系查，而不是只看第一屏

links 可以指向当前对象、父对象、关联实体、其他表示方式或相关登记资源。rel 中的 self、up 等关系说明链接用途，href 给出目标。

原文下方只是 links 的示意片段，并非完整的协议实现范本：符合 RFC 9083 的链接对象还需要 value。编写客户端时应遵循完整标准，不能直接把省略字段的讲解示例当作生产响应模板。

"links": [
  {
    "rel": "self",
    "href": "https://example.net/rdap/ip/192.0.2.0/24"
  }
]

按这个顺序做第一轮检查

先确认范围和 IP 版本，再看 handle、名称、分类和状态；随后检查实体、角色、时间，最后读备注、提示并追溯父级与关联链接。下表把每一步的用途列出来。

这只是初筛。查到一份结构完整的登记记录，并不意味着资源的路由、授权、信誉和业务依赖也已经核对完毕。

RDAP 单独回答不了的六件事

是否正在路由：有登记记录的范围也可能没有出现在全球 BGP 中。另查当前宣告、起源 ASN、稳定性和前缀长度。

是否获准宣告：登记主体不等于起源 ASN 的授权结论。把 RPKI／ROA、IRR 路由对象、适用 LOA 和实际 BGP 放在一起比较；它们各自的可信度和用途并不相同。

法律或合同权利：登记信息可以成为证据，但完整判断还涉及协议、转移文件、公司记录、政策、资源历史、适用法律及相关裁判。

物理位置：country 不能代替地理位置调查。IP 信誉：垃圾邮件、黑名单、恶意软件、历史滥用和商业信誉需要另查。

反向 DNS：登记存在不代表反向解析已正确配置。邮件、托管、企业服务和安全运维尤其需要单独核验这一层。

把不同证据连起来，别让一个数据库包办一切

登记层看资料是否准确；路由层看前缀是否按预期宣告；授权层看起源 ASN 与 ROA、IRR 及相关文件是否一致；DNS 层看命名和反向委派。

还要检查安全对象和账户权限、地址信誉、资源取得与管理文件，以及人员、供应商、基础设施或组织变动后的持续管理能力。

内部权威台账应把这些层次关联起来，并记录来源、时间和差异。任何一个字段都不应承担描述资源全部运行状态的任务。

把 RDAP 放进可重复的七步资源审计

1. 建清单。列出重要 IPv4、IPv6 前缀和 ASN，包括预留、暂未使用、已委派、旧系统以及连续性用途的资源，不要只抄路由器或防火墙配置。

2. 查登记。逐项保存范围、注册机构、handle、名称、type、status、关联组织、管理／技术／滥用联系人、登记日期和最后修改时间，并记录查询来源与时间。

3. 对内部资料。确认组织关系、联系人任职及授权、范围和历史记录是否一致，相关注册账户是否仍能正常访问。差异应解释，不能一概认定某一边正确。

4. 独立查 BGP。确认起源 ASN、宣告前缀、路由可见性、预期上游关系和异常宣告。查询 RDAP 成功不是网络健康证明。

5. 查授权。核对 ROA、起源 ASN、前缀、最大长度、RPKI 验证状态和相关 IRR 信息。路由迁移或 ASN 变更后尤其要重查。

6. 查业务依赖。检查反向 DNS、API、客户白名单、VPN、防火墙、SaaS 集成、支付平台、邮件系统及合规文件对地址的依赖。

7. 记录例外。写清差异是什么、原因、负责人、是否需要修正以及连续性风险，让下一位接手的人能够复核。

IPv4 转移尽调：登记只是其中一层

交易前要查清由哪个 RIR 管理、实际登记范围、关联实体、父级关系、更新时间、备注提示，以及这些内容与交易文件是否相符。

完整尽调还要覆盖适用 RIR 流程、转移文件、公司资料、路由历史、RPKI、IRR、反向 DNS、地址信誉和部署计划。原文引用的登记信息过期案例保留在延伸资料中，供读者进一步核对。

登记准确性怎样变成业务连续性问题

设想技术联系人三年前已离职，公司改了名，却没人知道谁掌握注册账户；同一地址又写进数百个客户白名单，而一次重大迁移即将开始。此时，登记资料已不只是文档问题。

关键资源应有当前记录、受控的账户访问、明确的内部管理责任、可追溯的历史、路由与 RPKI 可见性，以及恢复流程。目标是让登记层成为可靠的业务基础，不能拿它代替对整个网络的理解。

读完之后，要能把记录与正在运行的网络对上

RDAP 展示注册机构当前记载，BGP 展示观测到的路由，RPKI 帮助验证起源是否符合已发布授权，DNS 展示命名和反向委派；公司与交易文件补充组织和资源历史。把它们连接起来，才更接近真实情况。

不要把登记当路由，把国家字段当地理位置，把实体记录当完整法律结论，或把 active 当作生产使用的证明。对依赖 IPv4、IPv6 与 ASN 的组织，定期复查整套资源记录是否准确、可理解、与实际业务一致，比仅确认数据库里有这个地址更有价值。

六个常见问题

什么是 RDAP 记录？

通过 RDAP 返回的结构化登记资料。IP 网络记录可以包含范围、标识、状态、关联实体、联系人、事件和其他登记信息。

RDAP 的全称是什么？

Registration Data Access Protocol，中文可称注册数据访问协议。

能用 RDAP 查询 IPv4 吗？

可以。它支持单个 IPv4、IPv6 地址、CIDR 网段，以及采用相应查询路径的 ASN。返回的网络范围可能大于你输入的单个地址。

RDAP 比 WHOIS 好在哪里？

标准查询、JSON、HTTPS 和权威服务间重定向更便于自动化处理。WHOIS 仍为许多运营者熟悉，具体记录仍需结合机构语境解释。

handle 表示什么？

注册机构内用于唯一识别该对象的编号，可用于交叉引用和追踪记录；它不是所有权证书。

status 为 active 就表示可用吗？

它说明登记对象的状态，不直接证明前缀正在路由、可达或通过 RPKI 起源验证。运行情况需要独立检查。

原文与编注

原文由 Ann Yong 于 2026 年 8 月 26 日发表并于同日更新。此版保留全部实质内容、16 个原始 JSON 示例、两张表和六个 FAQ；原站重复的五条 FAQ 合并到对应问题。字段 active 的定义和 links 示例缺少 value 的说明为本次编注。原文日期不改写为本次发布日。

标准与延伸阅读

• 互联网号码资源审计
• 网络权威台账
• 注册层风险
• BGP 起源核查
• RFC 9082
• RFC 9083
• RFC 9224
• IANA：RDAP 字段值
• IANA：IPv4 服务引导
• IPv4 转移中的过期登记信息

核查之后，选择你真正需要的下一步

技术核查发现风险后，可向 NRS Shield 寻求成员支持。POA 是另外一项明确的代表授权决定，应先了解范围、期限、决策权和撤回方式。阅读文章或寻求帮助不会自动授予代表权。

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