What does named log message "deleted from unreachable cache" mean?
- 01 Jul 2021
- 2 Minutes to read
-
Contributors
-
Print
-
DarkLight
-
PDF
What does named log message "deleted from unreachable cache" mean?
- Updated on 01 Jul 2021
- 2 Minutes to read
-
Contributors
-
Print
-
DarkLight
-
PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
An example of the message being logged is:
02-Aug-2012 07:58:20.601 general: info: primary 192.0.2.4#53 (source 192.0.2.8#0) deleted from unreachable cache
BIND maintains a cache of unreachable primaries to which it refers when handling a zone refresh. If a zone refresh fails with a specific primary (either during the query for the SOA or after querying and while attempting a subsequent zone transfer), then this primary 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 primary 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 primary to secondary) doesn't guarantee that the primary will be reachable from the secondary, but it does ensure quicker recovery in the situation where a primary was temporarily unavailable, for example for a reboot.
Remove entry from unreachable primaries cache upon receiving notification
Primary 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 secondary 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 primary 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 primary 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 primary 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 https://www.isc.org/downloads/.