我有两个运行 BIND9 的 DNS 服务器,一个是主服务器,一个是从服务器。当主服务器上的区域文件更新后,我希望从服务器立即开始提供更改的记录,但 BIND 却给我带来了一些麻烦。
DNS 区域传输已在主服务器和从服务器之间正常工作。我可以登录到从服务器并运行dig @dnsmaster myzone. AXFR
,它会打印出区域的全部内容。为了使其正常工作,DNS 主服务器配置了notify yes
和also-notify { dnsslave }
。同样,从服务器配置了allow-transfer { dnsmaster }
。
当 dnsmaster 更新时,我运行它rndc reload
,它告诉我正在发送通知。这可以通过检查 中的区域文件在从属服务器上确认/var/named/slavedata/
。它们包含最新数据,与主服务器知道的数据相匹配。
现在到了奇怪的部分。
从服务器将继续提供旧的、过时的 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 从属服务器,只是为了避免提供过时的数据。还有更好的办法吗?
答案1
从你的描述我无法告诉你到底是什么是但我可以帮你排除几个问题。
缓存大小设置和缓存 ttl 设置适用于缓存的递归查询数据,并且(正如您已经怀疑的那样)不适用于权威数据。同样,rndc flush 在这里不适用。
建议的故障排除方法:
- 验证主服务器是否按预期发送通知消息。检查主服务器和从服务器之间的日志和/或嗅探流量。
- 从日志中验证从属设备是否正在接收通知消息。
- 如果您看不到从服务器收到通知,请排除通知问题,即仔细检查主服务器上的 named.conf 中的通知选项,确保它们按预期定义、稍后不会被覆盖,并且范围适当。我建议使用“notify explicit;”和“also-notify {slave-server;};”
- 如果奴隶是看到通知后,您的问题是找出区域文件未按预期更新的原因。应该发生的事情是,在收到通知后,从属服务器应进行 SOA 查询,与其当前 SOA 进行比较,并执行 AXFR(或 IXFR,如果已启用它)以获取更新的区域副本(假设主服务器上的 SOA 更高。)您应该能够使用嗅探器观察到所有这些事情的发生,并且您还应该在两台服务器上的日志中看到它的证据。
- 如果操作没有按预期发生,请首先手动比较两台服务器上的 SOA 序列号 (dig @server $zonename SOA),以确保您没有在过去的某个时间意外地为从属服务器提供高于预期的序列号,该序列号现在高于主服务器的序列号。
如果这不起作用,请考虑发布更多信息,包括主服务器和从属服务器的 named.conf 部分以及在主服务器上加载新编辑的区域后两个服务器的日志。
答案2
我遇到过同样的情况。我的研究让我意识到了以下问题。如果您正在使用视图,那么 dig@local machine 将仅提供 localhost-view 中的内容。localhost-view 仅在重新启动命名服务器时刷新。但最新的区域文件(从主服务器传输)在从服务器上仍然可用,并将提供给来自外部源或外部视图的所有查询。因此,您需要做出安排,以便刷新 localhost-view。
答案3
在重新加载命名之前,当您在主服务器中进行更改时,请不要忘记从区域文件中增加序列 ID,否则区域文件将不会被复制到从属服务器。
答案4
区域中列出的 SOA MNAME(主名称)不会收到通知。如果 MNAME 指向从属 IP,则不会收到通知。
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-notify
我的情况是合并两组独立的 ns1/ns2 名称服务器(称为 A 和 B),同时让“ns2”成为 B 区域的主服务器。我的错误是将 ns1.A.com 和 ns1.B.com 设置为同一个 A 主 IP。由于“ns2”仍然是某些区域的主服务器,我应该将 ns1.B.com 设置为指向“ns2”IP 地址。
坏的:
ns1.A.com 1.2.3.4 ns2.A.com 1.2.3.5 ns1.B.com 1.2.3.4 ns2.B.com 1.2.3。5
好的:
ns1.A.com 1.2.3.4 ns2.A.com 1.2.3.5 ns1.B.com 1.2.3.5 ns2.B.com 1.2.3。4
我在域名注册级别和 DNS 区域级别都将其颠倒过来:因此,我必须在两个级别更新 ns1.B.com 和 ns2.B.com IP。
现在,当我更新一个区域并重新加载时,从属设备会收到通知并快速正确地进行更新。
作为参考,SOA MNAME 位于区域文件顶部附近的行中,位于到期时间之前:
@ IN SOA ns1.example.com.hostmaster.example.com.(
^ 本例中的 MNAME 是 ns1.example.com