Knowledge Base ISC Main Website Ask a Question/Contact ISC
What does named log message "deleted from unreachable cache" mean?
Author: Cathy Almond Reference Number: AA-00765 Views: 5112 Created: 2012-08-02 10:49 Last Updated: 2014-11-01 10:06 0 Rating/ Voters


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.

Remove entry from unreachable masters cache upon receiving notification

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)


Bug RT #30501 may cause spurious "deleted from unreachable cache" log messages

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-2016 Internet Systems Consortium

Please help us to improve the content of our knowledge base by letting us know below how we can improve this article.

If you have a technical question or problem on which you'd like help, please don't submit it here as article feedback.

For 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.

Custom Fields
  • Bug tracking system reference: RT #25960
  • CHANGES reference: 3204
Feedback
  • There is no feedback for this article
Info Submit Feedback on this Article
Nickname: Your Email: Subject: Comment:
Enter the code below:
Quick Jump Menu