DNS区域传输已在主站和从站之间正常工作.我可以登录到从服务器并运行dig @dnsmaster myzone. AXFR并打印出区域的全部内容.为了实现这一目的,DNS主服务器配置了notify yes和also-notify {dnsslave}.同样,从站配置了allow-transfer {dnsmaster}.
当更新dnsmaster时,我运行rndc reload并告诉我正在发送通知.通过检查/ var / named / slavedata /中的zonefiles在slave上确认这一点.它们包含最新的数据,与主人知道的相匹配.
现在是奇怪的部分.
从服务器将继续提供旧的陈旧DNS记录,完全忽略了在主机通知后磁盘上有新数据这一事实.我正在使用dig来检查这个命令的结果：dig @slaveserver record.zone.tld.
我认为BIND可能会保留其权威区域的内存缓存,因此我将max-cache-size和max-cache-ttl设置为0,但这没有任何效果.
我尝试通过在从服务器上运行rndc flush和rndc reload之类的命令来刷新这个所谓的缓存的其他方法,但它仍然返回旧的陈旧记录.
最后,我注意到区域中的MINTTL设置为86400(24小时),因此我暂时将MINTTL更改为15秒,然后重新启动从属服务器.没有效果 – 从服务器只会在重新启动服务后提供更新的DNS结果.
这里发生了什么？接收区域更新通知时BIND9的预期行为是什么？它总是尊重TTL和MINTTL吗？我认为它总会使用最新的数据.
在我的智慧结束时,我正在考虑设置一个crontab来每小时重启BIND从属服务器,以避免提供过时的数据.有更好的吗？
解决方法
缓存大小设置和缓存ttl设置用于缓存的递归查询数据,并且(如您所怀疑的)不适用于权威数据.类似地,rndc flush在这里不适用.
建议的故障排除方法：
>验证主服务器是否按预期发送了通知消息.检查日志和/或嗅探主站和从站之间的流量.
>从日志中验证从站正在接收通知消息.
>如果您看不到从服务器收到通知,请作为通知问题进行故障排除,即仔细检查主服务器上named.conf中的通知选项,确保它们按预期定义,以后不会被覆盖,并且适当地确定范围.我建议使用“notify explicit;”使用“also-notify {slave-server;};”
>如果从服务器正在查看通知,则您的问题是找出区域文件未按预期更新的原因.应该发生的事情是收到通知后,奴隶应该进行SOA查询,与其当前的SOA进行比较,并执行AXFR(如果已启用它,则执行IXFR)以获取更新的区域副本(假设主服务器上的SOA)更高.)您应该能够使用嗅探器观察所有这些情况,并且您还应该在两台服务器的日志中看到它的证据.
>如果操作没有按预期发生,请首先手动比较两个服务器上的SOA序列号(挖掘@server $zonename SOA),以确保您不会意外地为从站提供高于预期的序列号过去的时间现在高于主人的序列号.
如果这不起作用,请考虑发布更多信息,包括主服务器和从服务器的named.conf部分以及两个服务器上的日志,这些服务器在主服务器上加载新编辑的区域后发生的情况.
