摘要

  • ARIN在2026年7月28日为Reg-RWS增加Authorization请求头认证。次日关闭ACSP 2022.5，同时说明URL参数中的API令牌仍会被接受。
  • 已查阅的公开资料确认了替代方式与迁移建议，但没有公布退役日期、迁移里程碑、旧式请求数量或请求头采用率。因此，建议关闭记录的是功能交付，不是旧传输方式已退场，也不是客户端迁移已经完成。

一个请求，两个生命周期

一次名录接口调用需要回答两个不同问题：请求要访问哪个资源，以及发出请求的一方是否有权访问。Reg-RWS可用于自动处理RPKI和IRR管理、地址资源再分配与重新分配，以及网段信息更新。过去，API令牌可以放在URL的查询参数里。2026年7月，ARIN新增了另一种写法：URL描述要访问的资源，密钥则单独放在Authorization请求头中。

两种写法可能得到相同的业务结果，但暴露面不同。URL经常进入浏览器历史、请求日志、代理记录和故障排查材料。ARIN在8月的说明中也把浏览器历史、服务器日志和代理日志列为URL令牌可能残留的位置。把令牌移入请求头，可以减少它意外扩散的机会，却不能让凭证凭空隐形：应用、代理、链路追踪工具或支持工单附件如果配置不当，仍可能记录Authorization值。真正的改进是收窄默认暴露面，而非免除凭证管理。

时间线让两件事的边界格外清楚。ACSP 2022.5于2022年2月11日提交，要求为REST调用中的URL令牌提供替代方式。建议解释说，记录完整URL的系统可能把有效令牌暴露给能够读取日志的人，并由此造成未经授权访问的风险。提交者没有给出具体期限。2月23日，ARIN表示HTTP请求头是较合适的方案，将这项工作列入2023年工程路线图的优先级安排，并称在实施前建议会保持开放。

2026年7月28日，ARIN宣布REST调用现可通过Authorization请求头和ApiKey认证方案传递密钥。7月29日的结案意见写明，首选替代方式已经部署，同时ARIN仍会接受URL参数中的API令牌。结案意味着请求的功能已经实现，不意味着旧方式已经关闭。8月11日的技术说明和9月的ARIN Bits再次确认：URL方式目前仍可用，日后会退役，并且建议客户现在就切换。

这其实是两只不同的时钟。第一只记录功能交付：建议被登记、评估、实现，最后关闭。第二只记录迁移：客户看到变更，修改工具，验证新的请求格式，把密钥从URL中移走，最终停止使用旧路径。公开记录对第一只时钟给出了明确终点；对第二只时钟，则没有公布日期或进度指标。

这并不是说ARIN不应关闭建议。只要增加的替代方法已经可用，一项功能请求就可以算完成，即使客户还需要时间采用。真正的治理问题出现在关闭之后：旧方式既然仍受支持，接下来就不只是代码变更，而是ARIN与使用脚本、自动化平台和第三方服务调用名录的组织之间的运维约定。

密钥放在哪里，会改变它被看见的方式

API密钥不是普通请求字段。ARIN将其描述为用于识别调用方的秘密，并指出部分REST操作要求账号关联到具备相应权限的Point of Contact。令牌放进查询参数，就会跟随资源地址一起传播。保存或复制URL的系统，可能在原始请求已经结束之后继续保存它。ARIN提及的浏览器历史以及服务器和代理日志，正是这种意外留存路径。

请求头认证改变的是凭证所在的位置，而不是所请求的资源。ARIN文档采用Authorization字段和ApiKey方案。客户端、自动化工具或资源配置服务需要可靠地发送该字段，同时保持原有端点和请求语义不变。这样，URL就不必再附带密钥。

可以参照一项技术标准，但需要说明边界。IETF RFC 6750讨论的是OAuth bearer令牌，并非ARIN的ApiKey认证方案。该规范建议把这类令牌放在Authorization请求头中，并不建议把它们放进URI参数，因为URL很容易被记录。这不表示Reg-RWS使用OAuth，也不表示该RFC直接约束ARIN。它说明的是HTTP操作中的一种普遍暴露差异：URI中的敏感值更容易进入通用日志，而专用请求字段更容易被单独管理。

请求头不是一整套安全政策。管理员可能记录所有请求头，追踪系统可能捕获它们，调试转储也可能保留它们；客户端还可能在跟随重定向前把密钥重新拼回URL。因此，切换请求头时，运营方仍需在日志中屏蔽Authorization值、妥善保存密钥、验证证书链，并准备在密钥暴露后替换它。这些是客户端侧的控制措施，并非本文声称ARIN新增了相应功能。

迁移成本也因组织而异。只维护一个客户端的团队，可能改动一个配置字段并测试数次请求。使用旧脚本、供应商软件、定时任务、外包运维和多套RPKI或IRR工具链的网络运营商，则要逐一找到生成查询参数的地方。除非ARIN进行汇总测量，否则名录看不到这项工作。这也是为什么继续兼容不能被解释为客户获知风险后仍主动选用较不安全的方法。

公开资料究竟证明了什么

现有证据支持四个彼此独立的判断：

  1. Reg-RWS已经支持请求头认证。7月的发布说明和当前REST方法文档都作了介绍。
  2. ARIN更倾向于请求头方式，并建议客户迁移。8月的技术说明和9月的月度综述都这样表述。
  3. 已查阅的公开资料仍支持URL令牌请求。7月29日的结案意见明确如此，当前REST方法页面也重复了这一点。
  4. 已查阅的资料没有公布退役日期、连续的迁移里程碑、仍使用URL参数的请求数量或请求头采用率。

第四点有意限定了范围。它只表示这些指标没有出现在本文引用的公开资料中，并不证明ARIN没有内部数据、未公开计划或客户沟通。资料同样没有描述安全事件。2022年的建议指出了一种合理的暴露机制，2026年的文件解释了ARIN为何偏好替代方式；没有一份文件报告令牌确已泄露，也没有提到发生过未经授权的名录操作。

这个区分能避免两个方向相反的误读。一种误读是把四年间隔说成失败证据；但建议本身没有规定期限，公开材料显示替代方案已经部署。另一种误读是把关闭状态当成风险已经消失；结案仍明确保留URL兼容，而9月文件所说的退役尚无日期。更安全的选项已经出现，并不代表暴露面更大的旧路径已经消失。

兼容性也是一项服务承诺

暂时保留旧方式，往往是负责任的做法。立即停用可能让无人值守但重要的资源管理任务失败。自动化调用中断，可能拖延名录变更、RPKI或IRR操作、资源再分配以及其他基于Reg-RWS构建的工作。公开资料确认了这些用途的大致范围，却没有量化某次中断会造成多大损失。名录API是运营商日常基础设施的一部分，并非可以随手丢弃的演示接口。

兼容同样有成本。每一种仍可用的请求形式，都会成为文档、支持人员、客户端维护者和使用团队必须理解的一种状态。如果一个方法被推荐，另一个却没有期限地继续工作，“首选”就可能变成没有决策日期的建议。新的集成或许继续复制旧示例，沉睡的脚本或许永远无人检查，内部安全审查也可能因为“已经可以使用请求头”而把问题勾掉。

合理做法不是要求ARIN公开可能敏感的客户级调用记录。迁移进展可以被观察，而不必披露客户身份或凭证。至少可以公开计划分几阶段、什么事件会启动退役时钟、预告期会有多长、兼容性变化如何通知客户，以及哪些情况可能让窗口延长。如果日期还没有确定，直说“尚未设定日期”会比让客户从“最终”二字猜测时间更有帮助。

本文查阅的公开材料并没有显示ARIN已经承诺上述里程碑。它们是让未来切换更可预测的建议，不是对ARIN当前计划的描述。这一界限很重要：宣布日期就意味着承担相应义务；如果ARIN尚未作出决定，分析文章不应写成它已经决定了。

退役记录不能止于一条发布说明

从技术上实现迁移，不只是给出一个可运行的请求头示例。运营商需要知道哪些端点和工具支持这种方式，客户端库是否有已知的不兼容情况，遗漏或写错请求头会返回什么错误，以及客户端是否可能同时发送请求头和URL令牌。ARIN公开指南解决了核心语法问题；在本文查阅范围内，尚未发现按客户端列出的公开兼容清单或采用率仪表板。

这类仪表板不需要揭示具体客户。汇总数据可以显示请求头调用是否正在替代URL参数调用、是否仍有长尾，以及迁移是否集中在少数几个集成上。退役通知也可以把指标和日期组合起来：发布通知、停止展示新的URL示例、进入警告期、复核兼容状态，然后再提出退役窗口。如果有些指标不适合公开，ARIN仍可以公布决策标准，并说明每个阶段是否满足。

对客户而言，等待一个统一的退役日期不是安全策略。建议已经足够明确：只要客户端支持请求头认证，就应把API密钥从URL中移走。团队可以搜索代码和配置里的查询参数拼接逻辑，先升级共用库，在日志、链路追踪和支持材料中屏蔽Authorization值，按自己的变更管理流程测试有代表性的读写操作，并替换已经暴露的密钥。这些步骤无论最后哪天退役旧方式都有价值。重要的是实际验证，而不是替换一个字符串后假设所有客户端都会照常运行。

名录也不应让最终截止日变成突然袭击。分阶段的流程给运营商时间寻找不由自己维护的客户端、联系供应商、更新操作手册、检查监控。可以先告警再拒绝请求；拒绝请求可以放在之后的阶段；文档化的例外机制可以处理真实依赖，同时避免临时通道悄悄变成永久安排。公开资料没有说ARIN已经选定这些控制办法；它们是管理跨组织兼容变更时常见的组成部分。

“关闭”究竟意味着什么

2022年的建议要求有一种更安全的REST认证方式。ARIN提供了替代方法，随后关闭记录。从这个有限意义看，状态是准确的。但工单状态不是迁移指标。它告诉读者替代功能已经实现，却没有回答仍有多少调用使用旧格式、客户能获得多长通知期，或者旧兼容方式何时结束。

对ARIN客户来说，实践结论很简单：新客户端和仍在维护的客户端都使用请求头，并把URL支持视为兼容安排，而不是同等安全的选项。对ARIN来说，剩余的治理工作是把未来退役过程讲清楚，让一条建议最终转化为有协调的迁移。现有证据不足以指称泄露或追究责任，却足以提出一个问题：什么公开信号会标记第二只时钟开始运行？

来源