摘要

  • RDAP 的错误对象不是含糊的空响应，而是 501，并将 Whois 列为替代入口。
  • RIPE NCC 的数据库团队 2025 年承诺支持 e164.arpa；2026 年 11 月的生产响应仍显示该支持未实现。

这份响应不只说“未实现”，还把客户端送回旧门：whois.ripe.net，端口 43。2026 年 11 月 1 日，我分别查询 e164.arpa 和 6.4.e164.arpa，两条 RDAP 路径都返回 HTTP 501。字段 port43 保留了服务运营方的现实判断：这个对象目前要通过 Whois 查。

这不是对电话路由的测试。e164.arpa 是 DNS 命名空间，IANA 将它描述为把 E.164 号码映射到互联网 URI。ENUM 查询走 DNS；RDAP 查询的是注册数据。一个数据库接口的状态不能当成 DNS 树的状态报告。RIPE NCC 的 RDAP 文档列出 domain 类型，并以反向 DNS 名称举例；当前响应则明确指出该类型在 ENUM 区域上的边界。IANA .ARPA 列表 · RIPE Database RDAP 文档

这个边界在 2025 年被写进了邮件。7 月底，一位参与者报告 ENUM 子域请求返回 500，根域返回 400。RIPE NCC 数据库团队解释，RFC 9082 对 RIR 的 domain 查询没有列出 e164.arpa；如果要支持，就得处理服务发现和其他 RIR 的重定向。团队同时说，Whois 日志每天有数百次相关查询。8 月 5 日，RIPE NCC 承诺推进实现并写一份 RFC，目标是与 Whois 功能相当。Database 工作组原始邮件

那组“数百次”来自 Whois 日志，计数对象是旧协议请求。它没有给出用户、呼叫或 RDAP 客户端数量，也不能说明迁移速度。RIPE NCC 没有在这条讨论中公布可与之对照的 RDAP 查询计数。替代协议的交付还要回答服务发现和跨 RIR 请求是否转向的问题。

到 2026 年 10 月，RIPE NCC 在 RIPE 93 说支持工作已有进展，却再次询问社区是否应继续。团队称如获支持即可实施。会议记录没有版本号、RFC 草案编号或计划日期。11 月 1 日，实时接口仍回答 501。2025 年的 400 和 500 变成了更明确的 501，支持本身仍未出现。RIPE 93 Database 会议记录

对工具开发者来说，port43 是个有用、也有些尴尬的回执：服务给出了可走的路，却同时证明现代接口没有覆盖这个对象。只要 RDAP 代码遇到 ENUM 就转去 Whois，客户端就得长期维护两个查询栈；若每家 RIR 自己设计发现与重定向，例外还可能各不相同。

更好的交付记录应把标准草案、负责的 RDAP 服务、发现方式和生产版本串在一起。这样，客户端可以知道何时删除 Whois 例外，数据库团队也能给出可核对的上线证据。一个发布版本号或公开草案能改变当前判断；按协议公布的查询量则能衡量迁移需求。眼下，最具体的事实仍是两条 501，以及响应里的端口 43。

来源：RIPE NCC Database 工作组邮件、RIPE 93 Database 会议记录、RIPE Database RDAP 文档、根域 RDAP 响应、分支 RDAP 响应、IANA .ARPA 列表。