摘要

  • ARIN 按直接分配所含的 CIDR 地址块，建立尽可能大的受支持反向委任。官方例子中，/23 对应两个 /24，/16 对应一个 /16；地址更多，不等于注册机构提供更多可分别修改的委任。
  • 下游客户的共享权限有明确限定：若重分配或重指派来自 ISP 的 /16 或更大地址块，客户不享有该项共享权限。这里看的是上游地址块，不是要求客户自己持有 /16。
  • 注册机构没有提供某个编辑权限，不代表 DNS 不能继续划分子区。ISP 或其 DNS 服务商可以在自己管理的区内安排更细的委任；这需要实际交接，并非登记客户地址便会自动完成。

地址多了，管理入口未必更多

512 个 IPv4 地址，可以对应两个分别选择名称服务器的反向委任。65,536 个地址，在另一个例子里却只对应一个。这个反差来自 ARIN 自己的反向 DNS 说明，不是一次异常测试。

前者是直接分配的 /23，分成两个 /24 委任；后者是一个 /16，管理名称服务器的边界停在这个 /16。后一位持有者控制的地址更多，只是注册机构这一层没有因此提供更多独立的编辑单位。把“控制范围更大”和“可分别操作的委任更多”当成同一回事，就会看错这套设计。

文档的关键限定是直接分配。ARIN 先看一次直接分配由哪些 CIDR 块组成，再为每个组成块建立尽可能大的受支持委任。IPv4 的这些边界是 /8、/16、/24；IPv6 则按四位一组的边界处理。本文讨论的 /16 例外属于 IPv4，不能搬到 IPv6 上。

ARIN 文档中的直接分配 注册机构这一层的反向委任 能在这一层分别处理什么
一个 /23 两个 /24 两个委任可各自指定名称服务器
一个 /16 一个 /16 指定整个 /16 委任的名称服务器

这张小表比客户地址清单多回答了一个问题：操作将落在哪个 DNS 节点上。客户清单可以把一批地址细分给很多组织，但清单中的每一行，不一定在注册机构的 DNS 管理工具里都有一个对应按钮。

这不是 ARIN 新近发布的限制。它是截至 2026 年 9 月 3 日所查官方文档描述的既有模型。文档没有给出适用客户的数量，也不能代替对某个账户的权限验证。

客户的 /24 不是问题的全部

设想一家客户从 ISP 获得一个 /24，而这个 /24 来自 ISP 向 ARIN 直接取得的 /16。这是用于解释边界的假设，不是某家客户的遭遇。

客户可能同时收到两种说法：这批地址已经登记到自己的组织；ISP 与下游组织可以共同管理反向 DNS。两句话即使分别成立，也还不足以推出“客户可以直接在 ARIN 修改自己的 /24 委任”。还要看该委任是否存在于这一层，以及共享权限的限定条件。

ARIN 的反向 DNS 页面把例外写得很具体：来自 ISP 的 /16 或更大地址块的重指派、重分配，不向接收组织提供共享权限。这里的“更大”是地址数量更多、前缀长度更短，不是 /24 比 /16 的数字大。把例外误读成“只有拿到 /16 的客户才受限制”，会漏掉上面的假设客户。

页面也说明，在符合条件的安排中，某个组织可以显示为有权管理相应反向区的组织，并且只能管理分给自己的地址。它同时提醒 ISP，在客户断开服务后及时移除相应登记，以撤去共享权限。这描述的是权限随关系进入和退出的规则，不是本次调查发现了残留权限，更不是清理仍在使用的客户记录的理由。

因此，不能只问“这个客户是否已经登记”。至少还要知道地址从哪个直接分配块而来，ARIN 在该处建立了什么反向委任，以及组织对那个具体委任有什么权限。账户角色、地址关系和 DNS 节点，各自在回答不同的问题。

改登记，不等于改 DNS

ARIN 的资源记录管理指南把详细重指派和重分配中的管理职责分开说明，也介绍了一些可共同处理的反向 DNS 和路由登记功能。阅读这种概括时，仍要保留反向 DNS 页面上的具体例外，而不能把较宽的介绍当成适用于每个地址块的授权书。

更直接的区别在于操作本身。指南明确说，网络修改请求可以改网络名称、联系人和公开备注，但不能用它修改反向 DNS 委任。把客户名字改对，是让登记更准确；它不会自动在父区中产生一条指向客户名称服务器的委任。

Reg-RWS 方法文档进一步说明了对象边界：委任随相关网络出现和消失，不能独立创建或删除；它使用委任名称识别，而不是 NET 句柄。接口可以列出某个 NET 关联的委任，也要求修改前先取得当前委任信息。

这使“我有这个 NET”与“我要修改哪个反向区”之间多了一步必要识别。文档里的接口不是本次测试结果：我们没有使用 ARIN 账户或密钥重放任何修改，也没有证明某位用户会收到允许或拒绝。它能支持的结论更有限，也更实用——登记对象和 DNS 编辑对象不是可以随意互换的单位。

下一层仍然可以交出去

如果分析停在“客户没有共享权限”，就容易把一个注册服务的边界写成整个 DNS 的能力边界。

RFC 1034 对区域和委任的说明提供了另一条路径。一个组织管理自己的 DNS 区后，可以在其下继续建立子区委任。父区需要有相应的名称服务器记录，必要时还需要地址粘合记录；父子两边的配置必须彼此对应。

回到那个假设的 /24。若 ISP 的 /16 反向区由 ISP 或它选定的 DNS 服务商管理，双方可以安排将相应 /24 子区交给客户的名称服务器。这个动作发生在 ISP 所管理的 DNS 层，不等于把 ARIN 的整个 /16 委任控制权交给客户，也不要求客户获得 ISP 的注册账户。

“可以安排”是技术上的可能性，不是某家 ISP 已承诺提供的服务。谁负责建立父区记录、谁维护客户区、谁在供应商变更后保留这些配置，都需要实际落实。DNS 提供了划分责任的办法，却不会替双方完成服务约定。

更小的地址块还有另一种处理方式。RFC 2317讨论少于 256 个 IPv4 地址的情况，通过额外的委任名称和 CNAME 引用，在不改变基本查询机制的前提下，让更小范围的反向映射可以分开管理。它没有让父区消失；查询仍然依赖父区中正确的引用。

这也不能倒推成 ARIN 支持任意 /25 委任对象。注册机构支持到哪一层，提供商如何在下一层组织 DNS，是两个问题。普通的 /24 从 /16 下继续委任，并不需要把它包装成 RFC 2317 的小块方案。分清这点，才能同时避免两种误解：一是认为没有注册机构按钮就无法自主维护；二是认为有了 DNS 技术就无需上游配合。

改动要落在实际选中的区上

ARIN 的 DNS 管理操作说明要求用户查看自己有权修改的反向区、名称服务器、DS 密钥标签和共享权限组织。修改名称服务器时，变更会应用到所有选中的委任，并替换原有名称服务器。

因此，输入内容正确，仍不等于修改范围正确。客户想换自己 /24 的 DNS 服务，操作人员若面对的是整个 /16 的父侧委任，首先要解决的是该改哪一层，而不是把客户的服务器名字直接填进去。正确的解决办法取决于现有区结构，不能从这篇文档分析替某个网络下指令。

说明还区分了数据库更新与 DNS 可见性：记录在数据库中立即反映，DNS 可能需要最多 24 小时；未指定 TTL 时默认是 86,400 秒。这是文档中的处理预期，不是我们测到的传播时间，更不意味着全世界缓存会在同一瞬间清空。

本次材料没有显示客户故障、委任拒绝、邮件损失或错误归因。反向映射本来也不是路由、所有权或完整身份的证明。它揭示的是一个更日常的交付问题：给客户一批地址、给客户一项注册服务权限、让客户能够维护自己的 DNS，是三件需要分别确认的事。把它们合成一个“已分配”，才容易让责任在最需要时变得含糊。