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

Question

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?

Answer 1

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.

Answer 2

I faced the same situation. My researched led me to the following realization. If you are using views, then dig@local machine will only serve what is in the localhost-view. the localhost-view get refreshed only during restart of the named. But latest zone file (transferred from the master) is still available on the slave and will be served to all queries coming from the external sources or external views. So, you need to make arrangements so that your localhost-view is refreshed.

Answer 3

Please do not forget to increment serial id from the zones files when you make changes in Master Server before reload named, otherwise the zones files will not be replicated to Slave Server.

Answer 4

The SOA MNAME (master name) listed in the zone is not notified. If the MNAME points to the slave's IP then it will NOT get notified.

https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-notify

My situation was merging two separate sets of ns1/ns2 nameservers (call them A and B) while keeping "ns2" the master for the B zones. My mistake was setting ns1.A.com and ns1.B.com to the same A master IP. Since "ns2" was still the master for some zones, I should have set ns1.B.com to point to the "ns2" IP address.

Bad:

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

Good:

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

I had it backwards at both the domain registry level and the DNS zone level: So, I have to update ns1.B.com and ns2.B.com IPs at both levels.

Now when I update a zone and reload the slave gets the notify and updates quickly and correctly.

For reference, the SOA MNAME is in the line near the top of zone files that precedes the expiry times:

@ IN SOA ns1.example.com. hostmaster.example.com. (

^ The MNAME in this example is ns1.example.com