BIND slave doesn't sync up with master until it is restarted
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:
- 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.
- Verify from the logs that the notify message is being received by the slave.
- 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;};"
- 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.
- 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.
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.