摘要

  • RFC 9526 让住宅侧的 Homenet Naming Authority 生成并以 DNSSEC 签署公共区域，私钥不交给外包方；Distribution Manager 与公共权威服务器负责让该区域在互联网可见。
  • 双向 TLS 只能证明控制或同步通道上的对端身份，不能证明域名权属、父区 DS 已更新、所有公共节点都加载了最新序列号，也不能证明外部验证器成功建立信任链。
  • “公共区域已经上线”必须由一组相互衔接的凭据支撑：权属、签名版本、区域传输、公共分发、父区委派、外部验证，以及撤销后的消失。

更换路由器后，旧的权威仍可能活着

想象家庭把旧路由器换成新设备。新设备生成了新的 DNSSEC 密钥，建立了双向认证的 TLS 通道，向 Distribution Manager 传输了序列号更高的区域。控制台显示同步成功。可是旧服务商仍在某个公共权威节点上回答旧区域，父区中的 DS 仍指向旧密钥。

每个局部记录都可能是真的。新 HNA 确实完成了签名；DM 确实接收了传输；旧公共节点也可能仍在提供一个签名尚未过期的版本。问题不是某一方说谎，而是组织把分散的事实压成了一个“DNS 已发布”的状态。

RFC 9526 的价值正在这里。它把住宅公共命名拆成多种能力：谁选择名称，谁写成区域，谁持有签名私钥，谁接收区域，谁把它送到公共权威服务器，谁修改父区 DS，以及外部递归解析器最终看见什么。自动化可以连接这些能力，却不能假定一次成功响应已经替所有下游环节作证。

公共区域不是 home.arpa 的镜像

RFC 9526 处理的是注册域名之下的 Public Homenet Zone。住宅内部使用的 home.arpa 属于 Homenet Zone，不是这个公开流程的发布对象。两者的边界决定了隐私与控制面：内部发现到的名称，不应因为技术上可复制就自动进入公共 DNS。

HNA 可以从 DHCP、mDNS、UPnP、PCP 或人工配置中取得候选名称与地址，但它仍要执行发布策略。链路本地地址不应进入公共区域。私有地址或唯一本地地址在 VPN 场景中可能有意义，却不代表任何互联网用户都能访问对应服务。

因此，第一个需要保存的证据不是 AXFR，而是选择。应记录哪些名称被纳入、哪些被排除、使用哪一版策略、谁批准这次公开，以及地址为什么适合被发布。只保留最终区域，会让团队在发生暴露时无法判断一个设备名究竟是主动公开、自动发现误入，还是设备退役后未被清理。

HNA 是作者，但不是公共柜台

规范要求 HNA 创建公共区域的全部内容，并以 DNSSEC 签署它。DNSSEC 操作和私有密钥材料由 HNA 掌握，架构没有把这些私钥交给 Distribution Manager 的安排。外包方拿到的是已经签名的陈述，而不是替住宅网络创作另一份陈述的能力。

与此同时，HNA 作为隐藏主服务器存在。除非采取额外保护，它的地址不应出现在公共 NS 记录里；它也不应直接处理互联网公众的普通查询。外界真正访问的是 DNS Outsourcing Infrastructure 提供的公共权威服务器。

这形成一个容易被忽略的权力分割。住宅侧掌握“写什么”和“以哪个密钥签名”；外包侧掌握“哪个版本被取走”“哪些公共节点收到它”和“查询流量落到哪里”。私钥没有外流，不能推出公共发布权仍完全留在家中。反过来，外包方能够延迟或保留旧版本，也不等于它能伪造新的有效签名。

监控界面应把两类状态分开。“已签名”必须指向具体区域序列号、内容哈希、DNSKEY 与签名有效期；“已公开”必须说明哪些权威实例在什么时间回答了该版本。一个状态不能凭推断升级为另一个。

控制通道与同步通道不是同一项承诺

HNA 和 DOI 之间由 Distribution Manager 对接，但 RFC 9526 明确区分两条通道。控制通道用于交换建立委派、构造 DNSSEC 信任链和定位同步服务所需的信息。HNA 发起连接，双方以 TLS 相互认证。

同步通道的连接角色反过来：DM 是 TLS 客户端，HNA 是服务器和隐藏主服务器。区域通过 AXFR 或 IXFR 传输。DNS NOTIFY 可以催促 DM 立即检查更新，SOA 的计时参数则让次服务器即使没有收到通知，也能按计划发现新版本。

同一对 IP 地址甚至可以同时用于两条通道，但它们证明的事情不同。控制通道成功，说明某个 HNA 与某个 DM 在一套信任配置下完成了受保护的交换。同步成功，说明某次区域传输发生。若没有把传输绑定到序列号、内容哈希和读回结果，就不能断言 DM 收到的正是运营者期待的版本。

更不能从双向 TLS 推出域名权属。证书可以识别一个设备或服务，而注册域名的处分权来自注册商、账户或其他外部安排。把认证、授权、执行和外部结果混为一个绿色标识，正是自动化越权的起点。

最影响公众的分发通道，反而由服务商自行实现

DM 从 HNA 取得区域后，还要把它送到一个或多个公共权威服务器。RFC 9526 把这一段称为 Distribution Channel，但没有规定唯一实现。服务商可以使用 AXFR、数据库复制、REST 或其他成熟方式。

这种留白给现有平台留出空间，也把证据责任交给了服务商。HNA 到 DM 的传输成功，并不是每个公共节点的部署回执。多区域、任播和异构软件环境都可能出现部分节点滞后、拒绝或加载不完整的情况。

运营者至少应保存 DM 接受的序列号和哈希，再从预定的每个公共权威实例读取 SOA、DNSKEY 与代表性记录。若只能验证一个明示的法定数量，也应公开这个范围。单个任播地址可能掩盖多个后端；从若干网络重复查询只是抽样观察，不能冒充完整节点清单。

规范未定义内部复制，不意味着可以用“供应商内部”终止追问。恰当的说法是：DM 在某时接收了第 42 代；这些公共节点在指定窗口回答第 42 代；这些节点尚未回答或仍停留在第 41 代。

NOERROR 是承诺，不是父区读回

DNSSEC 把父区权力单独暴露出来。HNA 通过 DS RRset 提供 Key Signing Key 的摘要。若 DOI 同时拥有注册商关系或有权联系父区，它可以安排把这个 DS 写入父区。DM 接受更新时，以 NOERROR 表示承诺执行父区更新。

“承诺”不能被改写成“已经完成”。它证明 DM 接受了责任，却不证明注册局已经处理请求，不证明父区此刻返回预期 DS，也不证明递归验证器已经抛弃缓存中的旧值。账户权属错误、流程失败、旧 DS 意外共存，都可能发生在成功响应之后。

安全委派只有在三个条件接上时成立：子区使用预期密钥签名，父区存在对应 DS，验证器能够建立完整链。RFC 9526 甚至要求 HNA 在无法安排安全委派时仍对区域签名。由此可见，“签名有效”与“链路安全”从来不是同一句话。

应把提交的 DS、DM 响应、父区读回和独立验证结果分别保存。否则，密钥轮换失败时，团队只会看到笼统的“DNSSEC 开启”，却不知道断点是在作者、传递者、父区还是缓存观察面。

规范要求确认域名所有权，却不替你完成确认

RFC 9526 要求 DOI 只有在确信 HNA 拥有 Registered Homenet Domain 时才提供服务，同时把所有权证明留在范围之外。这不是缺失的几个字段，而是另一个治理系统的入口。

若 DOI 就是注册商，客户账户、合同和设备入网流程可以组成权属依据。若权威 DNS 由独立服务商提供，则需要额外证明。无论哪种模式，域名账户、控制通道证书和 DNSSEC 私钥都可能有不同的持有人、到期日与恢复流程。

迁移计划必须回答：谁能修改父区，哪个 HNA 凭据能命令 DM，哪把密钥签署当前区域，旧服务商何时停止回答。如果路由器恢复出厂就同时丢失控制凭据和撤销路径，那么协议连接再安全，也无法给组织提供持续的控制权。

删除比创建更能检验控制力

创建成功容易让控制台显得强大，删除才会暴露权限是否真正可收回。RFC 9526 要求 HNA 能够向特定 DM 请求删除委派。DM 收到指令后必须停止提供该公共区域，并可用 NOERROR 表示已经删除。

这个响应仍只覆盖 DM 的边界。公共权威节点需要退出，父区 NS 或 DS 可能需要变更，递归缓存要等待 TTL 到期。服务商迁移时，新旧体系可能在一段时间内同时回答。若旧区的签名仍有效，观察者甚至会看到两套各自“密码学正确”的现实。

可靠的删除回执应逐一检查旧 DM、所有权威端点、父区记录、签名有效期与缓存时限，并区分永久退役和服务迁移。它要证明旧权力已经消失，而不只是新权力已经出现。

此外，非活跃 HNA 何时被服务商删除，由商业协议决定。技术上的主动撤销权与合同上的清理权不是同一项权利。管理者必须知道两者由谁触发、等待多久、发生争议时如何恢复。

重编号让“当前版本”分裂成多个时钟

住宅前缀变化时，HNA 更新 AAAA 记录，通知 DM 自己的新同步地址，并触发新的区域传输。在先建后拆的情形中，新旧前缀会短暂共存；在突发重编号中，旧地址可能先失效，新地址稍后才出现。

规范建议 HNA 每次启动都更新同步位置，因为它不知道离线了多久，也不知道签名区域是否已经过期。这个建议揭示了真正的运行对象：预期地址、HNA 序列号、DM 已取回版本、公共节点已服务版本、父区状态和递归缓存都在不同时间线上变化。

所以不能只问“DNS 是否正常”。应问每个边界当前认可哪一代、这个判断的观察时间是什么、旧值何时必须消失。旧地址可能仍被合法缓存，却已经无法到达；新地址可能已经公开，却没有匹配的防火墙或 VPN 策略。

来源

来源