摘要

  • DNS NOTIFY 响应表明从服务器收到了通知；RFC 1996 明确指出，响应本身不携带有用的区域信息。
  • 从 SOA 序列号比较，到 IXFR/AXFR、加载新版本，再到权威查询看到新记录，属于后续且可分别失败的阶段。
  • 运维需要一张区域发布回执，保留每次状态交接，而不是让一个通知成功计数替代整条证据链。

重试队列清空回答的是小问题

RFC 1996 让主服务器在区域变化后主动提醒从服务器，不必只等 SOA 刷新周期。主服务器收到相匹配的响应后，可以把该从服务器从本次通知的重试队列移除。这项证据很明确：通知已经抵达。

规范同时说明，NOTIFY 响应不包含有用信息。它没有报告从服务器当前持有哪个 SOA 序列号，也没有证明它已经向正确的主服务器查询、发起传送、装载数据或开始对外回答。因此，“NOTIFY 成功”是信号通道状态，不是发布完成状态。

有效的 SOA NOTIFY 会让从服务器像刷新计时器到期一样采取行动：查询已知主服务器的 SOA，比较序列号，并在远端序列号更新时发起 IXFR 或 AXFR。应答位于这条链的起点，而不是终点。

提示、传送与提供服务必须分开

NOTIFY 请求可以附带回答区，但 RFC 1996 把它限定为不安全的提示；它不能直接更新本地区域，也不能自行决定必须传送。RFC 1982 则规定了 DNS 序列号算法，其中恰好相隔半个序列空间的比较没有定义。可核验记录应保存本地值、远端值与实际比较结果，而不是只留下“较新”。

IXFR 传送增量，AXFR 可以传送完整区域。RFC 5936 把 AXFR 定义为维持权威服务器一致性的协议机制之一。即使传送会话成功，接收端仍可能没有完成 reload，某个进程仍可能运行旧版本，或者 anycast 某一站点尚未切换。

最终证明应来自针对权威服务的直接查询：检查预期 SOA 序列号和一个确实发生变化的 RRset，并覆盖每台命名服务器及有代表性的 anycast 视点。递归缓存是另一层；TTL 未到期时返回旧值不等于权威发布失败。

来源