An example of the messages being logged is:
02-Aug-2012 07:58:20.601 general: info: master 192.0.2.4#53 (source
192.0.2.8#0) deleted from unreachable cache
BIND maintains a cache of unreachable masters to which it refers when handling a zone refresh. If a zone refresh fails with a specific master (either during the query for the SOA or after querying and while attempting a subsequent zone transfer), then this master is cached as 'unreachable' for 10 minutes.
As of versions 9.6-ESV-R6, 9.7.5, 9.8.2 and 9.9.0 onwards, the change below implements an earlier removal of a master server from the unreachable cache if a notify is received from it. Note that receipt of a notify (which is a UDP packet travelling from master to slave) doesn't guarantee that the master will be reachable from the slave, but it does ensure quicker recovery in the situation where a master was temporarily unavailable, for example for a reboot.
Master servers that had previously been marked as unreachable because of failed zone transfer attempts will now be removed from the "unreachable" list (i.e. considered reachable again)if the slave receives a NOTIFY message from them. [RT #25960]
In the CHANGES file, it is described thus:
3204. [bug] When a master server that has been marked as
unreachable sends a NOTIFY, mark it reachable
again. [RT #25960]
To further investigate (if for example, the message is being logged persistently, which suggests that notifies are being received, but that many zone transfers are failing), you need to examine what is being logged under category xfer-in. For events that would lead to the master being added to unreachable cache, search for messages containing "failed to connect" or "could not refresh". For example:
xfer-in: error: transfer of 'testzone.example.com/IN' from 192.0.2.4#53: failed to connect: timed out
You may also see other logged messages that indicate that a transfer has not happened because this master is currently listed in unreachable cache. There are several different messages that can be logged (from different circumstances), but they all contain the text "unreachable (cached)". For example:
general: info: zone testzone.example.com/IN: refresh: skipping zone transfer as master 192.0.2.4#53 (source 192.0.2.8#0) is unreachable (cached)
In some versions of BIND named may also mistakenly find and report on older cache entries that
are already "deleted". This problem has been addressed in BIND 9.6-ESV-R9, 9.8.5, 9.9.3 and 9.10.0 (and all newer versions released since those listed). If you are running an affected version but have no evidence of ongoing problems (from
further inspection of logging category xfer-in) then you can safely
ignore these messages. They indicate that there has been a connectivity
issue at some point in the past, but which is now cleared. However, we would encourage you to upgrade to the latest revision of a currently-supported version of BIND; details as well as downloads can be found on our main website at http://www.isc.org/downloads/.
© 2001-2017 Internet Systems ConsortiumFor assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.