摘要

  • ARIN在2026年7月28日上线了通过Authorization请求头传递Reg-RWS API密钥的方式，并将其列为首选；当前快速入门指南仍把URL查询参数方式标为Supported，现有资料也没有给出退役日期。
  • URL往往会被浏览器、服务器、代理、诊断工具和支持流程整体复制，因此URL中的密钥具有更宽的日常传播面。请求头能显著减少这种意外暴露，却不能保证任何客户端、代理或日志系统都无法记录密钥。
  • Reg-RWS能够读取和修改注册信息、处理重新分配、提交ROA并编辑IRR对象，所以凭证处理具有实际运营后果；但现有来源没有证明发生过泄露、盗用或未经授权的操作。
  • ARIN可用一份不识别客户的迁移回执证明进度：列明各认证通道状态、旧通道的汇总使用比例、脱敏边界、通知节点、关闭条件、拒绝行为和密钥轮换指引。

ARIN的公开文档现在同时展示两种请求形态。推荐方式把经过遮蔽的凭证放进Authorization: ApiKey […]；旧方式则把?apikey=[…]附在URL之后。两种请求都能向Reg-RWS证明调用者身份，但它们不会在网络工具链中留下相同的轨迹。

URL经常被当成一个不可拆分的整体。浏览器会保存它，命令行可能留下它，服务器和反向代理通常记录它，监控系统、错误报告、截图与支持工单也会复制它。当密钥成为URL的一部分时，一次看似普通的“复制地址”，就可能同时复制了操作权限。ARIN在8月11日发布的迁移说明明确提到，URL中的密钥可能进入浏览器历史、服务器日志和代理日志。

请求头的价值在于把“访问哪个资源”与“凭什么访问”分开。HTTP库、网关和安全工具更有可能把Authorization识别为敏感字段，继而进行遮蔽或禁止记录。这不是自动生效的秘密保险箱，但它移除了一个结构性问题：地址每被复制一次，凭证就跟着复制一次。

因此，ARIN的这次改进值得肯定。7月28日的发布公告称，RESTful调用已经可以用请求头提交API令牌，并把这种方式列为首选替代方案；公告同时确认发布完成、系统运行正常，并关闭了Suggestion 2022.5。更新客户端的运营者不再需要仅仅因为接口沿用旧设计，就把可重复使用的密钥嵌入资源地址。

不过，“完成”需要一个明确宾语。完成的是功能交付，不是所有客户端迁移，也不是旧通道关闭。当前快速入门指南在GET、POST和PUT示例中，把请求头方式标为Recommended，把URL方式标为Supported。8月11日的说明称URL支持最终会被移除，但被冻结的五份来源没有提供具体日期。

这其实是三个不同的状态变化。第一，更安全的能力已经可用。第二，调用方需要迁移。第三，服务端最终需要拒绝旧格式。如果把三者压缩成一个“已完成”，那么一项产品建议的关闭，就容易被误读为一项运营风险已经关闭。

保留一段兼容期本身并不荒谬。Reg-RWS调用可能嵌在多年未改的脚本、IP地址管理平台、自动化编排流程和第三方产品之中。突然拒绝URL凭证，可能中断注册记录维护或路由安全操作。双通道并存给运营者留下升级、测试错误处理以及轮换旧密钥的时间。

兼容的代价同样清楚：只要旧通道仍能工作，新功能试图减少的传播面就仍然存在。安全结果最终取决于采用率和退役，而不只是功能是否上线。关闭Suggestion 2022.5证明ARIN交付了所请求的能力，却不能证明调用方已转移、历史记录中不再存在旧URL，或服务端已经具备安全拒绝查询参数的条件。

快速入门指南还有一句需要收窄。该页面称，请求头端点的设计不会允许密钥在流程中的任何时点被捕获。ARIN自己的8月11日文章使用了更准确的表述：请求头能“显著降低”意外暴露的概率。后者才与公开技术证据一致。

Authorization仍是HTTP请求的一部分。客户端库可能在调试模式下展示它；反向代理或应用服务器可能因配置不当而记录请求头；追踪和可观测性系统可能过度采集元数据；进程内存、崩溃转储和支持包也可能包含凭证。终端设备一旦受控，密钥放在哪个字段都不能解决问题。TLS保护密钥在可信端点之间传输，却不会让合法处理密钥的系统忘记它。

IETF的RFC 6819同样采用风险下降而非绝对安全的语言。文档指出，URI查询参数中的令牌可能泄漏到日志文件和引用信息中，因此建议使用授权请求头。它说这种做法降低泄漏或无意存储的可能性，同时另行要求正确配置日志并限制日志访问。标准并没有把请求头名称描述为一种“绝对无法记录”的技术属性。

这并不意味着ARIN现在正在记录授权请求头，也不意味着某位客户已经泄露密钥。被冻结的来源没有提供任何真实密钥被窃取、重放或滥用的证据。这里需要纠正的是公开描述的精度：一个更安全的通道应当被表述为减少已知传播路径，而不是凭字段位置消灭所有捕获可能。

这种精度之所以重要，是因为Reg-RWS承载的不是无关紧要的查询。ARIN的接口文档列出了对委派、网络、组织、联系人和客户信息的读取与修改，也包括提交路由起源授权、编辑互联网路由注册对象以及请求报告。每项操作的实际权限仍取决于账户、联系人关联和可管理记录。把密钥移到请求头不会扩大或缩小这些权限，只会减少凭证离开预期请求环境的一种常见方式。

所以，最小公共控制不应是一句“端点已经安全”，而应是一份凭证通道迁移回执。它可以只包含汇总信息，不公开任何客户身份。回执首先应列出发布版本、文档版本、适用的Reg-RWS操作族，以及每种认证通道究竟处于recommended、supported、deprecated还是rejected状态。

回执还应给出一个明确观察窗口内，旧URL通道所占调用比例，并确认URL、请求头、应用、代理、诊断与支持日志的遮蔽范围。迁移时间线需要包括通知日期、支持阶段、退役门槛、正式拒绝日期和回滚规则。旧格式被关闭之后，错误响应不得回显密钥，也不能通过重定向或新的诊断日志把凭证重新传播出去。

这些数据不要求ARIN公布任何密钥或客户名单。认证通道使用比例、变化趋势以及仍出现URL凭证的操作族数量，已经足以说明进度。样本过小时，还可以延迟或合并披露，避免汇总数据反向识别客户。迁移回执的目的不是公开点名尚未升级的人，而是证明旧入口可以关闭，同时不让运营遥测本身变成新的泄露面。

当前公开记录已经提供了状态链的起点：请求头方式于7月28日上线，它被列为推荐方式；URL查询参数仍受支持；未来退役已经被原则性宣布，但没有日期。缺少的是这些状态之间可核查的连接：采用率如何计算，哪些日志边界已得到验证，什么条件代表迁移完成，以及服务将在何时不再接受最容易随地址四处传播的凭证形式。

来源