BIND slave doesn’t sync up with master until it is restarted

binddomain-name-systemmaster-slave

I have two DNS servers running BIND9, one master and one slave. When the zone file is updated on the master, I want the slave server to immediately start serving the changed record(s), but BIND is giving me some guff.

DNS zone transfer is already working correctly between the master and the slave. I can log into the slave server and run dig @dnsmaster myzone. AXFR and it prints out the entire contents of the zone. To make that work, the DNS master is configured with notify yes and also-notify { dnsslave }. Likewise, the slave is configured with allow-transfer { dnsmaster }.

When dnsmaster is updated, I run rndc reload and it tells me that notifications are being sent. This is confirmed on the slave by inspecting the zonefiles in /var/named/slavedata/. They contain the most recent data, matching what the master knows.

Now comes the weird part.

The slave server will continue to serve up old, stale DNS records, completely ignoring the fact that new data is available on disk after being notified by the master. I'm using dig to check the results with this command: dig @slaveserver record.zone.tld.

I thought BIND might be keeping an in-memory cache of its authoritative zones, so I set max-cache-size and max-cache-ttl to 0, but that had no effect.

I tried other ways of flushing this alleged cache, by running commands like rndc flush and rndc reload on the slave server, but it still returns the old stale records.

Finally, I noticed that MINTTL on the zone was set to 86400 (24 hours), so I temporarily changed the MINTTL to 15 seconds, and restarted the slave server. No effect – the slave would only provide updated DNS results after the service is restarted.

What's going on here? What is the expected behaviour of BIND9 when receiving notification that a zone is updated? Does it always respect TTL and MINTTL? I would assume that it would always use the most recent data available.

At my wit's end, I am considering setting up a crontab to restart the BIND slaves on an hourly basis, just to avoid serving up stale data. Is there anything better?

Best Answer

From your description I can't tell you exactly what is the problem but I can help you rule out several things.

The cache size settings and cache ttl settings are for cached recursive query data and (as you already suspected) don't apply to authoritative data. Similarly rndc flush is inapplicable here.

Suggested troubleshooting method:

  1. Verify that the notify messages are being sent by the master as expected. Check the logs and/or sniff traffic between the master and slave.
  2. Verify from the logs that the notify message is being received by the slave.
  3. If you cannot see the slave receiving the notify, troubleshoot as a notify issue, i.e. double-check your notify options in named.conf on the master, making sure they are defined as you expect, are not overridden later, and are scoped appropriately. I recommend using "notify explicit;" with "also-notify {slave-server;};"
  4. If the slave is seeing the notify, your issue is figuring out why the zone file is not being updated as you expect. What should happen is after the notify is received, the slave should make an SOA query, compare to its current SOA, and do an AXFR (or IXFR if you have enabled it) to get the updated zone copy (assuming the SOA on the master is higher.) You should be able to observe all of this happening with a sniffer and you should also be seeing evidence of it in the logs on both servers.
  5. If operations do not occur as you expect, start by manually comparing the SOA serial numbers on the two servers (dig @server $zonename SOA) to make sure you didn't accidentally give the slave a higher-than-expected serial number some time in the past which is now higher than the master's serial number.

If that doesn't work, consider posting more information, including named.conf sections from both the master and slave and logs from both servers of what is occurring after you load a freshly edited zone on the master.

Related Topic