BIND从站不会与主站同步，直到重新启动

我有两台运行BIND9的DNS服务器，一台主机和一台从机。当区域文件在主服务器上更新时，我想让从服务器立即开始服务更改的logging，但是BIND给了我一些guff。

主区域和从区域之间的DNS区域传输已经正常工作。我可以login到从服务器并运行dig @dnsmaster myzone. AXFR dig @dnsmaster myzone. AXFR并打印出该区域的全部内容。为了做到这一点，DNS主服务器configuration了notify yes和also-notify { dnsslave } 。同样，从站configuration了allow-transfer { dnsmaster } 。

当dnsmaster更新时，我运行rndc reload ，它告诉我通知正在发送。这在slave上通过检查/var/named/slavedata/ 。他们包含最新的数据，匹配主人所知道的。

现在来了怪异的一部分。

从属服务器将继续提供旧的，陈旧的DNSlogging，完全忽略在主服务器收到通知后磁盘上有新数据的事实。我正在用dig命令检查结果： dig @slaveserver record.zone.tld 。

我以为BIND可能会保留其权威区域的内存caching，所以我设置max-cache-size和max-cache-ttl为0，但是没有效果。

我尝试了其他方法来刷新这个所谓的caching，通过在从服务器上运行诸如rndc flush和rndc reload类的命令，但它仍然返回旧的陈旧logging。

最后，我注意到该区域的MINTTL被设置为86400（24小时），所以我暂时将MINTTL改为15秒，然后重新启动从属服务器。没有效果 – 从属服务重新启动后，只会提供更新的DNS结果。

这里发生了什么？当接收到区域更新的通知时，BIND9的预期行为是什么？它是否始终尊重TTL和MINTTL ？我会假设它总是使用最新的可用数据。

在我的机智的结尾，我正在考虑设置一个crontab来重新启动BIND奴隶小时，只是为了避免提供陈旧的数据。有更好的吗？

从你的描述我不能告诉你究竟是什么问题，但我可以帮你排除几件事情。

caching大小设置和cachingttl设置用于caching的recursion查询数据，并且（如您已经猜到的）不适用于权威数据。同样，rndc flush也不适用于此。

build议的排除方法：

validation通知消息正如主人所发送的。检查日志和/或嗅探主从站之间的stream量。
从日志中确认通知消息正在被从设备接收。
如果您看不到接收通知的从服务器，则将其作为通知问题排除故障，即在主服务器上的named.conf中仔细检查通知选项，确保按照您的预期定义通知选项，稍后不会覆盖，并且范围适当。我build议使用“明确通知” 用“also-notify {slave-server;};”
如果从服务器看到通知，你的问题是搞清楚为什么区域文件没有像你期望的那样被更新。接收到通知后，从机应该进行SOA查询，与当前的SOA进行比较，然后执行AXFR（或IXFR，如果启用了该function）以获取更新的区域副本（假设主节点上的SOA ）你应该能够观察到嗅探器发生的所有事情，你也应该在两台服务器的日志中看到它的证据。
如果操作不像您期望的那样发生，那么首先手动比较两台服务器上的SOA序列号（dig @server $ zonename SOA），以确保您在一定时间内不会意外地给予从站高于预期的序列号在过去，现在比主号的序列号要高。

如果这不起作用，请考虑发布更多信息，包括主服务器和从服务器上的named.conf部分，以及在主服务器上加载新编辑的区域之后发生的事情。

在重新加载命名之前，当您在主服务器中进行更改时，请不要忘记增加区域文件中的序列号，否则区域文件将不会复制到从服务器。

我面临同样的情况。我的研究让我有以下的认识。如果您正在使用视图，那么dig @ local机器将仅服务于localhost-view中的内容。 localhost-view仅在重新启动命名时刷新。但是最新的区域文件（从主机传送）在从机上仍然可用，并将用于来自外部源或外部视图的所有查询。所以，你需要做一些安排，让你的localhost-view被刷新。