什么是 RDAP（以及为什么它比以往任何时候都更重要）

围绕替代 WHOIS（这一用于获取域名注册人信息的主要协议）的讨论已经持续了数十年。如今，WHOIS 正在被逐步淘汰，取而代之的是“注册数据访问协议”（Registration Data Access Protocol，简称 RDAP）。

为什么会发生这种变化？

WHOIS 缺乏标准化的数据格式，并存在诸多设计缺陷，例如缺乏身份验证机制，无法安全地传输数据。很明显，WHOIS 需要进化——或者被取代。互联网工程任务组（IETF）中的多个工作组一直致力于此。

早在 2003 年，IETF 的一个小组开始开发“互联网注册信息服务”（Internet Registry Information Service，简称 IRIS）——这一协议旨在通过使用 XML 来解决 WHOIS 缺乏标准化数据格式的问题。该标准于 2008 年最终定稿，虽然在技术上可行，但并未得到广泛采用。

IETF 意识到 IRIS 可能过于复杂，因此成立了另一个工作组——“Web 可扩展互联网注册数据服务”（Web Extensible Internet Registration Data Services，简称 WEIRDS），开启了新一轮 WHOIS 现代化工作。这些努力最终促成了定义 RDAP 的多份 RFC（互联网标准工作文档），并于 2015 年正式标准化。

时间快进到今天，RDAP 已成为 WHOIS 的明确继任者。2025 年 1 月 28 日，ICANN 发表了一个明确的信号：WHOIS 时代正式结束——他们已弃用 WHOIS 的 43 端口。

这一转变重新激起了人们对 RDAP 的兴趣。本文将探讨这一协议的工作原理及其相较于 WHOIS 的优势。

什么是 RDAP？

RDAP 是一种用于访问当前域名注册数据的协议。它本质上是对 WHOIS 的替代，并针对这一拥有 43 年历史的旧协议存在的不足进行了改进，提供了以下功能：

• 使用 JSON 格式的结构化数据
• 通过 HTTPS 提供更高的安全性
• 支持用户认证与基于角色的访问控制
• 更好地支持 国际化（多语言与字符集）

---

RDAP 如何工作？

RDAP 是一个基于 REST 的协议——它通过 HTTP 运行，允许客户端发送请求并以结构化的 JSON 格式获取注册数据。
在深入了解查询与响应的过程之前，我们需要先理解一个对 RDAP 至关重要的概念——引导（Bootstrapping） 与 引导发现（Bootstrap Discovery）。

---

RDAP 的引导与引导发现

域名数据由不同的组织（如域名注册局）管理。

例如，当你想获取 example[.]com 的注册详情时，请求会被路由到 Verisign（负责 .com 顶级域的公司）；
如果是 example[.]info（注意：该域名不存在），请求会发送给 Afilias；
而 InterNIC 则负责 example[.]top 的注册数据（该域名同样不存在；所有 “example.” 开头的二级域名都被保留用于文档说明，不可注册）。

由于域名注册实际发生在注册商（Registrar）层面，注册商也会维护相应的域名注册数据。
因此，虽然注册局是注册数据的权威来源，但它可能会将查询指向负责该域名的注册商。

随着数以千计的注册局分别管理不同的顶级域（TLD），将请求正确路由到相应组织是一项挑战。而作为 RDAP 的终端用户，你又该如何知道该查询哪个服务器呢？这时，IANA 的引导注册表（Bootstrap Registries） 发挥了作用。

IANA 维护着引导文件，用于确定由哪个 RDAP 服务器（通常由注册局或注册商运营）负责处理特定的注册数据。

当终端用户通过 RDAP 客户端（如命令行工具、查询工具或网页接口）发起域名注册信息查询时，
客户端会先从 https://data.iana.org/rdap/ 获取正确的 RDAP 服务器，然后将请求发送给它。
这一过程被称为 引导发现（Bootstrap Discovery）。

这与 WHOIS 的工作方式有显著区别——WHOIS 客户端必须预先配置好每个顶级域对应的服务器。

RDAP 查询（RDAP Query）

当客户端知道应将请求发送至哪个 RDAP 服务器后，它会使用 HTTP 构建一个 RDAP 查询。
需要注意的是，RDAP 强制要求加密通信，所有交互必须通过 HTTPS 进行，以确保客户端与服务器之间的数据在传输过程中不会被窃听。

查询的 URL 结构通常包括以下几部分：

• 来自 IANA 引导注册表的基础 URL；
• 资源类型标识符（例如：域名、IP 地址或 ASN）；
• 以及具体的资源内容。

以下是几个 RDAP 查询的示例：

https://rdap.verisign.com/com/v1/domain/example.com

https://rdap.publicinterestregistry.org/rdap/domain/example.org

http://rdap.apnic.net/ip/2001:dc0:2001:11::194

然而，如你所见，要形成查询，你需要知道每个顶级域对应的 RDAP 服务器地址，而这在不同 TLD 之间都不同。
与 WHOIS 不同的是，RDAP 服务器名称并没有统一标准，因此无法通过猜测得出。

这也意味着使用引导机制的查询工具（lookup tool）可以自动帮你完成这一部分。

---

RDAP 响应（RDAP Response）

当 RDAP 服务器收到查询请求后，它会检索相应的注册数据，并以 JSON 对象 的形式返回结果。

RDAP 响应（JSON 格式）
（机器可读但不太便于人类阅读）

为了提升可读性，客户端通常会解析响应内容，并以更易理解的格式展示。
如果是用于自动化处理，也可以保留 JSON 原样或转换为其他格式。
例如，WhoisXML API 的查询工具 可以将域名注册数据以 JSON 或 XML 格式展示。

RDAP 客户端通常还会缓存 IANA 的引导注册表，从而避免每次查询都重复请求 IANA 服务器。
这种机制显著加快了查询速度，也减轻了 IANA 的服务器负载。

为什么引导机制让 RDAP 更加稳健

作为一种相对较新的机制（至少在域名注册数据领域），引导（Bootstrapping） 具有以下优势：

• 去中心化（Decentralization）：
  虽然 IANA 维护着引导注册表，但实际的注册数据分布在众多 RDAP 服务器中，由不同组织分别运营。
  如果某一台服务器出现故障，并不会导致整个系统瘫痪。
• 可扩展性与自动化（Scalability & Automation）：
  引导注册体系可以轻松应对互联网的增长。
  只需为新增的域名、IP 地址块或自治系统号（ASN）添加新的条目即可。
  由于这些注册表是机器可读的，整个发现过程可以完全自动化。
• 安全性（Security）：
  通过 HTTPS 下载引导注册文件，防止篡改并确保客户端获取到准确的信息。
• 易维护性（Ease of Maintenance）：
  如果某个 RDAP 服务器的信息发生变更，只需在 IANA 的引导文件中更新，
  所有客户端都会自动获取到最新数据。
  这比手动重新配置每个客户端（WHOIS 的方式）高效得多。

WHOIS 或已走向终结，RDAP 正当其时

向 RDAP 的过渡已经进行了好几年。自 2019 年起，ICANN 要求 gTLD 注册局与注册商必须实现 RDAP 服务。
但直到 2025 年 1 月 28 日，ICANN 才正式废止 gTLD 注册局和注册商必须维护 WHOIS 服务的要求。

尽管 ccTLD 注册局拥有更大的灵活性（因为它们遵循的地区政策与全球 gTLD 要求不同），
但 gTLD 上 WHOIS 端口 43 的废弃仍意味着 RDAP 已成为 gTLD 注册数据的权威来源。
因此，通过端口 43 访问 WHOIS 的服务也预计将被关闭。

然而，根据我们的内部测试，端口 43 在许多情况下仍可用于查询 gTLD 数据。我们预计该端口的全面关闭将是一个渐进过程。

RDAP 与 WHOIS 有哪些不同？

乍一看，RDAP 可能只是另一种查询域名注册信息的方式，就像我们熟悉的 WHOIS 协议一样。
虽然在某种程度上确实如此，但 RDAP 在架构设计和数据处理方式上进行了显著改进，不只是简单替换协议而已。

那么，RDAP 与 WHOIS 有哪些区别呢？下面快速概览一下。

特性	WHOIS	RDAP
数据格式	纯文本，非结构化	JSON 格式，结构化且可被机器解析
访问控制	无身份验证，所有用户均可访问	支持基于身份验证和权限的访问控制
国际化支持	限制较多	支持多语言和国际字符集
分页功能	不支持	支持分页与过滤查询
重定向机制	不标准	标准化的重定向机制，可跨注册局查询
安全机制	明文传输	使用 HTTPS，传输加密
扩展能力	靠各注册局自行定义	采用标准化扩展框架，兼容性更高

这些改进使 RDAP 能在满足监管与隐私要求的同时，提供更加统一、安全、可靠的注册数据访问方式。

让我们更详细地看看这些差异。

协议（Protocol）

WHOIS 使用一种基于文本的专有协议，传统上通过 TCP 的 43 端口 访问。它需要专门的客户端软件，并且与标准的 Web 技术集成度较低。

而 RDAP 采用 RESTful 架构，这意味着它使用与网页浏览器相同的 HTTP/HTTPS 协议。
这种 RESTful 方式让开发者更容易与 RDAP 交互——他们只需通过简单的 GET 请求 即可获取数据，而不必像 WHOIS 那样手动建立 43 端口连接并解析纯文本响应。

响应格式（Response Format）

WHOIS 返回的是 纯文本（plain text），而 RDAP 则使用 JSON 格式，这是一种标准化、可被机器解析的数据结构。

在我们的内部测试中，我们还发现两者在查询结果上存在差异。
下图展示了通过 RDAP 获取的 swantonartscouncil[.]com 域名注册详情的截图。

这与通过 WHOIS 获取的相同域名注册数据有所不同。

请注意对比其中的 注册人姓名（registrant name） 和 电子邮件地址（email address） 字段（出于隐私原因，具体信息已做模糊处理）。

正如你所看到的，WHOIS 的响应中包含了一些在 RDAP 响应中未显示的注册人信息。

---

标准化的查询与响应（Standardized Queries and Responses）

由于 WHOIS 使用纯文本格式且缺乏严格的标准化，不同服务提供商输出的结构和内容可能差异很大。

而 RDAP 要求客户端使用统一的查询结构，并且注册局与注册商必须以标准化的 JSON 格式和统一字段进行响应。
这让数据处理更加容易，因为使用 RDAP 时，返回数据的结构始终一致。

用户身份验证（User Authentication）

RDAP 支持分级访问控制（tiered access control） 的机制，虽然这不是强制要求。各 RDAP 服务器运营方可以根据自身需求，设置访问权限，以决定不同客户端可查看的数据范围。
相比之下，WHOIS 不具备此功能——所有相关域名信息对所有人公开显示。

国际化支持（International Support）

WHOIS 在多语言和字符集方面存在局限，因为它最初仅为 ASCII 字符 设计。这意味着包含其他语言字符（如西里尔字母、阿拉伯语或中文）的域名或注册信息，往往无法被准确显示。

而 RDAP 自设计之初就全面支持 Unicode——这是一种几乎涵盖所有文字系统的国际编码标准。
因此，全球用户可以更方便地用本国语言访问和管理域名注册数据。

内置安全机制（Built-In Security）

WHOIS 缺乏内置加密机制，所有数据都以明文形式传输，容易被截取或篡改。

而 RDAP 强制使用 HTTPS 协议，确保客户端与服务器之间的通信经过加密，防止未经授权的第三方拦截或修改域名数据。

RDAP 推广现状（RDAP Rollout）

虽然 RDAP 无疑是未来的注册数据访问标准，但截至 2025 年 2 月 20 日，实际部署情况仍存在差异。
目前，仅约 74.8% 的顶级域（TLDs） 已启用 RDAP 服务。

来源：https://deployment.rdap.org/

如果聚焦到 国家及地区顶级域（ccTLDs），这一比例会更低——目前只有 29.4% 的 ccTLDs 部署了 RDAP。

这与 ICANN（互联网名称与数字地址分配机构） 的权限范围有关。
ICANN 的政策要求（包括向 RDAP 的过渡）仅适用于通用顶级域（gTLDs），而 ccTLDs 则由各国或地区自行管理与运营，因此其采用 RDAP 的进度相对较慢。

来源：https://deployment.rdap.org/

如何使用 RDAP（How to Use RDAP）

由于 RDAP 是一种 RESTful 协议，它自然可以用于 API 调用与查询。事实上，我们的 WHOIS API 已经全面兼容 RDAP。
该接口允许你通过 RDAP 或 WHOIS 获取注册数据。我们新增了一个名为 “rdap” 的参数，用于选择查询方式：

• 0 —— 自动模式（Auto protocol）
• 1 —— 使用 RDAP 协议查询
• 2 —— 使用 WHOIS 协议查询

此外，我们还实现了两项自动机制：

• 当 WHOIS 数据无法获取时，系统会自动回退（fallback）到 RDAP；
• “自动模式（Auto protocol）” 会基于技术检测与跨 TLD 的服务器监控，自动选择 RDAP 或 WHOIS 中可用性最高的数据源。

更多技术细节可在 WHOIS API 文档 中查看。

如果你想自己试试，可以先注册账号以获取免费 API 积分与 API Key，然后在终端运行以下命令（将 API_KEY 替换为你的实际密钥）：

curl --location 'https://www.whoisxmlapi.com/whoisserver/WhoisService' \

    --header 'Content-Type: application/json' \

    --data '{

        "domainName": "example.com",

        "apiKey": "API_KEY",

        "outputFormat": "JSON",

        "rdap": 1

    }'

值得注意的是，与 WHOIS 一样，RDAP 仅提供当前的注册数据。
两者都不是历史档案系统，如果你想查询域名的历史注册记录，需要使用 WHOIS 历史查询 API（WHOIS History API）。

作为 WHOIS/RDAP 客户端的维护方，我们会持续为用户保存和更新域名的历史信息，并确保所有历史数据库中的数据也会同步包含来自 RDAP 的更新内容。

向 RDAP 过渡对用户意味着什么

我们前面已经介绍了 RDAP 的运作方式及其与 WHOIS 的区别，那么问题来了：
这场转变究竟会对组织或个人产生什么影响？

在过渡初期，受到影响最大的群体是 域名注册商（registrars）与注册局（registries）。
他们必须投入资源建立新的系统与流程以支持 RDAP 服务。

对于普通的域名注册者而言，日常体验变化并不明显——
你仍会通过注册商注册域名，甚至可能察觉不到底层协议的变化。

然而，对 网络安全专家 和 域名数据使用者 来说，这一转变会带来一些明显变化：

• 域名所有权数据将变得更标准化、更可靠；
• 但由于 RDAP 的分级访问机制（tiered access），某些信息的公开可见性可能降低。

具体的隐私保护程度取决于各注册商的访问控制实现方式，以及当地的隐私法规要求。

对于非公开域名注册信息的访问，用户可能需要通过 注册数据请求服务（Registration Data Request Service, RDRS） 进行申请，并提供访问数据的合理理由与用途说明。