摘要

  • Richard Laager 在 ARIN 建议 2026.4 中描述：把母网的一个 NET 详细重新分配给另一 Org 后，母网 API key 不能按子 NET 的 handle 读取，却可以删除它、用 mostSpecificNet 按地址范围取得它；接收方 Org 的 key 则能按 handle 读取。
  • ARIN 在 2026 年 3 月 30 日答复，认为其他现有查询工具及未来开发规划足以支持当前做法，暂不更改 API 权限，并在提交者同意下结案。

能删，不能按编号读。这个顺序听着像权限表写反了，却是 Richard Laager 在 ARIN 建议 2026.4里给出的可复现步骤：先从自己控制的母 NET 向另一组织做详细重新分配，再拿母网侧 API key，以新子 NET 的 handle 调用 GET。返回的是权限不足。Laager 说，用同一方的权限可以 DELETE 那条子记录；给出首尾 IP 地址，用 mostSpecificNet 也能拿到它；不用登录，公众在 Whois 里同样看得见这些资料。

详细重新分配本来就让两方同时留在记录旁。ARIN 的资源管理说明写明，接收方要有自己的 Org ID，能够在 ARIN Online 管理分配给它的地址。直接登记持有人仍可收回这笔重新分配。IRR 对象和反向 DNS 的管理由双方共享。母网与接收方因此都与子 NET 有关系，但哪一种关系能通过哪一个 API 动作，仍由 ARIN 的入口规则决定。

Laager 把四扇门都试过了。接收方 Org 的 key 能按 handle GET。母网 key 在同一入口被拒。母网 key 改用起止地址搜索，能从 mostSpecificNet 取得子 NET。公众则能按 handle 或 IP 地址通过 Whois 查看同类公开内容。对象没有消失，资料也并非保密。拒绝发生在“母网身份＋按 handle 查询”这一组条件上。

Reg-RWS 方法说明把这些入口分别列出。GET /rest/net/NETHANDLE 返回 NET 载荷；GET /rest/net/mostSpecificNet/STARTIP/ENDIP 查某地址范围内最具体的 NET；DELETE /rest/net/NETHANDLE 发起删除重新分配或重新分配记录的工单式请求，直接分配的 NET 不在这个删除方法的适用范围；PUT /rest/net/NETHANDLE 则带着载荷修改记录。方法、路径、结果都不同。一次按地址范围查得成功，无法替按 handle 的失败响应自动补票。

这会把小小的权限差变成一套客户侧流程。自动化系统完成重新分配后，通常保存 ARIN 返回的子 NET handle。下一次核对时，它按这个编号读回对象，比较预期与登记状态。若 GET 被拦下，就得同时保存地址首尾，走另一条查询路径，再核对子 NET handle、母网、地址范围和接收 Org，确认拿到的真是同一笔记录。Whois 可帮人排查，却有不同的接口和采集证据。更不能因为 DELETE 通道仍可用，就把删除再创建当成读取的替代；客户登记记录不是调试用的临时文件。

Laager 提了两项改法。他认为 NET 的 GET 应普遍允许；又认为既然母网一方能删了重建直接子网，也该能用 PUT 修改。NET 修改说明列出的可改字段包括网络名、联系人 handle 和公开评论。读一份 Whois 已可见的资料，与改写影响后续使用的登记字段，权限赌注不同。这两项都是提交人的建议，ARIN 没有采纳。

3 月 30 日，ARIN 答复说它讨论了其他现有检索方式和未来开发计划，认为此时没有必要调整 API 权限检查。Laager 同意关闭建议。ARIN 的回复没有宣布按 handle GET 已修复，而是选择让用户使用已有的替代路径。这个决策省下服务端权限改动，却把对象身份核对和双路径读取留给了每一个依赖母网 key 的集成程序。

公开证据还缺一项：拿双方当前 API key 对这几条正式端点跑一份生产调用记录，才能确认三月答复后拒绝是否仍在。已经确定的是建议报告的路径差异，以及 ARIN 决定不改当前权限。运营者因此必须把“这条路径拒绝读取”和“NET 根本不存在”分成两种状态。混为一谈，清单对账和后续变更都会走错。

同一条子 NET，在一个入口能按范围找到，在另一个入口能删，在按编号读取的入口却对母网关门。机构选择了维持这张门禁图。客户软件只好把它背下来，并在每次对账时确认自己走的是哪一扇门。

建议 2026.4 与 ARIN 回复 · Reg-RWS 方法 · 资源管理说明 · NET 修改说明