摘要

  • DNSOP 对 draft-jabley-dnsop-zone-cut-to-nowhere-01 的采纳征询截至 2026 年 9 月 14 日。Datatracker 所示的是仍在进行的采纳征询，而不是已采纳的工作组文件或 RFC。
  • 草案允许父域使用一条目标为空的 NS 记录，标示子域存在于另一 DNS 命名空间。它不公布可达的权威服务器，不证明外部解析成功，也不替子域运营者决定访问政策。

一个空目标记录可以表达边界，却不能替任何人打开边界后的门。

草案处理的是分割 DNS 中很实际的移动性问题。某机构可能在公共 DNS 中维护 EXAMPLE.COM，同时只在内部网络中维护 CORP.EXAMPLE.COM。设备离开办公室时，从互联网可达的递归解析器得到否定答复；回到内部网络后，又从内部解析器得到肯定答复。缓存使两个答复相遇，DNSSEC 感知的解析器还可能把先前已验证的外部否定答复视为与后来的内部答复冲突。问题不在于内部子域不该存在，而在于公共父域若只说“不存在”，它就说得太多。

所谓 “zone cut to nowhere”，是父域对自己能力范围内事实的较窄表述：子域存在，但不能通过父域所在的 DNS 命名空间使用。草案规定，父域以单一、目标为空的 NS 资源记录表达这种情况，也就是 NS .。这不是一个被隐藏的服务器名称，也不是等候客户端补全的地址。它刻意不提供通往子域的公共路线。

草案对相邻配置同样谨慎。如果一个 NS RRSet 除了空目标外还包含普通的服务器名称，它就不是 “delegation to nowhere”。其他可达目标的存在有其不同含义，草案不替它下定义。这一限定看似细小，实则保住了技术记录的可解释性：不能因为一条空记录就把真实的委派说成无路可走，也不能因为想表达边界就把包含真实服务器的记录伪装成边界。

RFC 1034 所描述的通常转介，能把请求者指向掌握所需信息的名称服务器。空目标信号不具备这个功能。它不发布子域的权威服务器，也不把公共父域变成私有网络的入口目录。正因为不包含一条可达路径，外部使用者不应从中推断服务可用、网络准入、账户权限或故障责任。

DNSSEC 也没有取消这一限制。草案允许在父域管理员已知子域签名密钥时设置安全的 “delegation to nowhere”。这样，解析器在随后从真正包含子域的命名空间收到签名答复时，可以使用相应的信任锚。但若不同命名空间中的子域使用不同签名，或其中一个未签名，草案建议不要这样做。信任锚是带条件的密码学事实；它不是一项对所有解析器、应用或依赖方都适用的服务授权。

DNSOP 的章程把工作范围放在 DNS 部署、运行考虑、协议维护、更新和扩展上。它是讨论缓存、验证和分割命名空间的合适场所。其公开讨论的价值在于收集运行经验、暴露互操作风险、检验语言是否足够精确。它却不能成为承担内部网络损失的一方。参与者可以提出证据、警告或反对；仅凭参与，并不能取得某企业子域、解析器或客户服务的决定权。

因此，程序状态也必须与技术内容分开。Datatracker 目前将该文本列为 DNSOP 候选的个人 Internet-Draft，工作组状态为 Call For Adoption By WG Issued，IESG 状态为 I-D Exists。运行时征询的截止日期和任何单封支持邮件，都不能提前变成工作组共识、文件采纳、标准发布或已部署行为。每一个后续状态都需要自己的决定主体、日期和公开记录。

这份草案最值得保留的不是“把私有 DNS 公之于众”，而是让公共 DNS 不再越界替私有 DNS 发言。父域可以指出子域位于别处；子域的运营者仍保留服务器、内部解析器、密钥、访问规则和恢复安排。外部用户得到的是对边界更准确的说明，而不是一张不存在的服务承诺书。

采用该模式的组织应有一份本地的命名空间边界记录：父域版本、受影响子域的类别、批准公共信号的人、受影响的解析器群体、是否使用安全委派及其密钥前提、验证日期、回退权限和测试结果。记录不必披露内部主机或地址。它要避免的是几年后有人把 NS . 误认成配置事故、公共委派遗漏，或者从未获授权的内部服务入口。

现有来源没有证明任何已命名网络采用了草案，没有证明所有公共解析器会以相同方式处理它，也没有给出采纳征询的结果。来源所证明的是更克制的一点：DNSOP 正在研究如何让父域承认另一命名空间中的子域，同时不声称可以发布、管理或到达该子域。

来源

  1. DNSOP 采纳征询
  2. draft-jabley-dnsop-zone-cut-to-nowhere-01
  3. DNSOP 章程
  4. IETF Internet-Draft 流程状态
  5. RFC 1034：域名系统概念与设施