Typical Bind slave failure scenario - What happens and when?

[Russell Jones]

Bind 9.7 on CentOS 6.2


Hi all,

I am attempting to recreate a failure scenario of a slave server that 
cannot contact its master for a zone. I am having a difficult time 
following the log entries of what is occurring due to Bind not seemingly 
following the SOA definitions for the zone. I have the following set on 
this test zone:

example.com             IN SOA  dns1.example.com. root.dns1.example.com. (
                                 2012071914 ; serial
                                 60         ; refresh (1 minute)
                                 30         ; retry (30 seconds)
                                 120        ; expire (2 minutes)
                                 86400      ; minimum (1 day)
                                 )



I am running into the following issues:

  * The refresh time seems to be ignored. Even though it is set at 60
    seconds, it seemed to poll the master server somewhere between 3 and
    5 minutes. I had to define max and min refresh time in
    /etc/named.conf to get it to respect this time. Is there some
    internal limit to how low of a setting  Bind will allow in some of
    the SOA definitions? I was unable to find a minimum limit for this
    when Googling :-)

  * I am seeing the following messages when it fails to contact the
    master (as expected). Only problem is after it sends this message I
    am not seeing an attempt to contact the master every 30 seconds as I
    am interpreting the "retry" limit to mean:
      o zone example.com/IN: refresh: retry limit for master
        10.32.69.1#53 exceeded (source 0.0.0.0#0)


Am I misunderstanding what Bind will log and attempt to do with the 
"retry" limit?

Is there any documentation outlining what will actually occur, and when, 
with a slave server when it cannot contact a zone's master for updates?


Thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120827/5d5116fd/attachment.html>