两个站点，一个私有 DNS 区域：记录归谁所有？

你在绿色站点添加一台主机，它对绿色用户可解析，而黄色办公室仍然收到 NXDOMAIN。这既不是 VPN 故障，也不是解析器损坏；这是私有区域内的归属空白。两份各自编辑的记录列表不会仅仅因为站点之间可达就变成一个区域。解决之道是发布计划，而不是又一条防火墙规则。

症状点出了缺失的归属方

每个站点大概都有一条本地覆盖、一条 Pi-hole 条目或一行 dnsmasq，是当初需要某个名字时有人加上的。绿色记录只存在于绿色解析器上，因此黄色站点的客户端去问自己的解析器，得到诚实的“没有这个名称”。过期答案看起来不一样：主机搬走了，一个站点更新了自己的副本，另一个仍然返回旧地址。

这两种情形都不能靠清缓存长久解决。转发解析器的缓存只是它曾经收到过的答案的副本，并不是发布新名称的权威，所以今天能用的缓存对明天的主机毫无说明。BIND 文档正是因为这个原因，才把主、辅、递归和转发角色分开描述。

因此设计问题很窄，也可以回答：谁可以创建记录，以及该记录如何到达每一个必须为它作答的解析器？

选项 A：一个权威区域加辅助服务器

为 internal.example.com 运行主服务器，并让受支持的辅助服务器在各站点获取该区域。每个站点的递归解析器询问本地辅助服务器，因此答案来自权威来源而非缓存，改动一次即被传送，而不是重新敲一遍。

这种安排需要明确决策，而这些决策容易拖延、跳过代价却很高。谁可以编辑该区域？允许哪些服务器传送它，经由哪些地址？站点之间的隧道中断时，客户端应当看到什么？辅助服务器会继续用最后一份副本作答，这通常是想要的行为，但它必须是一个被声明的选择，而不是故障时的意外。

按地址把区域传送限制在已知的辅助服务器，并在实现支持时使用事务签名。开放传送等于把你的内部命名空间抄给任何能连到端口的人。

代价是协调：一条编辑路径、一次变更评审，以及关于记录出错时谁值班的共同理解。

选项 B：每个站点一个子域

把 green.internal.example.com 委派给绿色站点，把 yellow.internal.example.com 委派给黄色站点。每个站点成为自己名称的权威，父区域只承载委派记录。围绕一个文件的争执消失了，本地团队不必等集中变更就能添加主机。

委派必须存在于父区域中，并带有指向站点权威服务器的 NS 记录。完整委派不现实时，对该子域做条件转发是可行的替代，但那是解析器设置、不是已发布的事实，所以每个解析器都需要同一条规则。

代价只是转移而非消失：父区域仍需要归属方，而新建站点现在是两处改动而不是一处。

让每个解析器遵循这个选择

通过受支持的配置把已批准的解析器和搜索域交给客户端，并确保 解析器到任何它必须查询的远程 DNS 服务器都有被允许的 VPN 路由。应用还需要通往这些答案所返回私有地址的路由，因为名称正确却没有路径，仍然是断开的连接。

如果由 Pi-hole 提供本地解析，请写明它拥有哪些记录、转发哪些查询。两份各自编辑的 Pi-hole 列表依然不会复制。在 Pi-hole v6 中，自定义 dnsmasq 行要通过 TOML、CLI 或环境变量等宿主侧选项设置，不会通过 API 暴露；加载 /etc/dnsmasq.d/ 中的文件是默认关闭的独立选项。

然后用一个到处都应当可见的名称，从两侧分别测试：

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

SOA 响应会告诉你，黄色解析器认为自己是权威、在询问辅助服务器，还是仅仅在转发。这些是故障方式不同的不同设计，而响应通常能指出你实际部署的是哪一种。

用三个验收场景收尾：每个站点各一个名称、一小时内改动的一条记录，以及站点间链路不可用。只通过第一项的设计，只有纸面上的发布计划，生产环境里仍是本地覆盖。