摘要

  • ISC 在 APNIC 62 把区域列表、区域查看器和序列号差异检测列为 Stork 当时已有的 DNS 功能。资料没有说明 APNIC 已在生产环境部署 Stork，也没有报告真实的区域陈旧事故。
  • 差异只证明 Stork 已发现并成功抓取的服务器、视图与区域配置之间存在不同。若缺少失败项、不受支持的视图、明确排除项和缓存年龄，“没有差异”就不能扩展为整个权威 DNS 体系的一致结论。
  • 每次比较都应留下覆盖回执：Stork 与 DNS 软件版本、预期和实际观察范围、抓取状态、原始 SOA 序列号、观察时间、时效上限，以及每个不可见项的处置。

没有进入列表的那一行，不会显示不一致

监控界面最容易让人放心的数字是零。零个告警，零个差异，零个待处理项。问题不在零是否准确，而在它有没有分母。

在 APNIC 62 的 Stork 演示稿中，Marcin Siodelski 把区域列表与筛选、BIND 9 配置查看、区域查看器和“Serial Mismatch Detection”放在当天已有的功能一侧。APNIC 随后发布的技术场次报道也提到跨服务器的序列号差异检测。这是一个实用信号：同一 DNS 区域在不同服务器上出现不同 SOA 序列号时，运营人员不必逐台查找。

但 Stork 比较的不是一个抽象的“全部 DNS”。它比较代理能够发现的守护进程、能够读取的配置和接口，以及服务器要求代理抓取后进入自身数据库的区域信息。任何没有跨过这条链的服务器、视图或区域配置，都不会显示为红色；它也不会显示为绿色。

Stork 2.4.1 的 DNS 文档把这一边界写得很具体。对于 BIND 9，代理先从正在运行的 named 进程寻找实际配置文件。如果找不到配置，该 BIND 9 守护进程不会进入已发现列表。区域查看器还依赖 BIND 的 statistics channel 来取得配置的视图和区域。PowerDNS 则通过自己的配置文件、Web API 和 API key 接入。

这里的“不可见”并不等于故障。某台服务器可能被有意排除，配置权限可能遵循最小授权，某个接口也可能按政策关闭。证据边界只要求一句准确的话：结果描述的是成功进入观察集合的对象，而不是机构所拥有的每一台权威服务器。

第二个边界是时间。Stork 的区域列表最初为空，操作员点击 Fetch Zones 后，服务器才把各代理收集到的列表写入缓存。文档明确说明，这个列表不会自动刷新；想看到新状态，就要再次抓取。抓取中的错误可以在 Fetch Status 中查看。于是，一个界面可能完全正确地展示上午十点的列表，却不能自动证明下午四点新增的视图也已经进入比较。

界面同时给出两个不同的数量。Zone Configs Count 统计区域配置；同一名称如果存在于多个视图，会被计算多次。Distinct Zones 统计不同名称，只计算一次。只保存后者，会丢掉视图维度；只保存前者，又无法看出增长来自新名称还是同一名称下的新视图。两者都是比较分母的一部分。

视图也揭示了身份选择的问题。若 BIND 9 的同名区域位于非默认视图，Stork 在请求详细内容的 AXFR 时需要用 TSIG 让 BIND 判断目标视图。match-clients 与 allow-transfer 中的配置参与这个选择。另一方面，Stork 2.4.1 明确不支持 PowerDNS 5.0 引入的 DNS 视图。一个未受支持的 PowerDNS 视图不是“序列号一致”，也不是“序列号错误”；它只是没有进入这次观察。

区域列表和区域内容还走不同的数据路径。列表及其序列号来自 DNS 服务器集成，并在 Fetch Zones 后缓存。操作员点击 Show Zone 时，Stork 才通过 AXFR 获取区域记录；如果已有缓存，界面可能先显示旧副本，直到点击 Refresh from DNS。因此，AXFR 失败可能妨碍查看记录，却不一定抹去列表里已有的序列号。反过来，看见一个序列号也不等于完整区域记录已经被成功传输。

区域传送监控又是第三条路径。APNIC 62 演示稿把 XFR Monitoring 标为开发版 2.5.1 的新功能。2.5.1 代理手册说明，这项 BIND 专用的日志跟踪默认关闭，需要显式启用，而且无法跟踪只写入 syslog 的传送事件。ISC 的 Stork 页面把 2.4.1 列为当前稳定版，把 2.5.1 列为开发版。报告若不携带版本，就很容易把相邻版本的能力借给当前证据。

SOA 序列号本身也不是普通递增整数。RFC 1912解释了次级服务器如何用它判断是否需要获取更新。RFC 1982则定义了 32 位环形空间中的比较规则：数值会回绕，普通整数大小不能直接代替序列号先后；恰好相差半个空间时，顺序没有定义。

现有资料能够支持“Stork 检测差异”，却没有为每一种数值组合说明它如何标注谁新谁旧。因此回执应保存两个原始值；如果产品给出先后判断，还要保存比较规则和结果。“不同”来自不相等。“某台服务器落后”还需要角色、时间和 RFC 1982 语义。

相同序列号也不能证明全部记录逐字一致、DNSSEC 验证成功或终端用户得到预期答案。这些边界值得另外验证，却不是本文要重复的主题。本次 APNIC 新闻的更早一步是：在讨论“相同”意味着什么之前，先证明所有本应比较的行确实出现了。

一份覆盖回执无需泄露密钥或内部拓扑。它可以记录 Stork server 与 agent 版本、DNS 实现与守护进程版本；机器、守护进程、区域、类别和视图的稳定标识；由谁维护的预期清单；抓取起止时间与逐守护进程状态；两个区域计数；明确排除与不受支持的视图；原始 SOA 值；观察或缓存时间与允许的最大年龄；最后是差异、相同、不可用等状态、告警处置和纠正链。

这样，界面就不必只给一个绿色结论。它可以说：对声明范围完整；因缺失行而部分完整；因超过时效而陈旧；或因成员集合变化而不可直接比较。部分覆盖中的一个差异依然是真实证据。部分覆盖中的“零差异”则不能被提升为全网事实。

这不是在削弱 Stork。恰恰相反，中央视图的价值在于把分散证据连接起来。软件负责生成实际观察集合；运营者负责声明预期集合。两者一起保存，差异提示才从一个有用的屏幕状态变成可以复核的决定记录。

来源