What’s the expected behavior with BIND slave that’s been offline for some time? – A server stack is the collection of software that forms the operational infrastructure on a given machine. In a computing context, a stack is an ordered pile. A server stack is one type of solution stack — an ordered selection of software that makes it possible to complete a particular task. Like in this post about What’s the expected behavior with BIND slave that’s been offline for some time? was one problem in server stack that need for a solution. Below are some tips in manage your linux server when you find problem about linux, domain-name-system, bind, , .
We have a situation where a BIND slave server was not able to write any zone data to the file system. When this server was rebooted and BIND restarted it started with an older version of the zone files than what was currently on the master.
During this time it was able to receive IXFR transfers from the master, it just couldn’t persist these changes to the HDD.
This got me wondering about what is the expected behavior with a BIND server? It seems like a bit of a design flaw that it wouldn’t do some checking with its master, prior to entering service.
For reference this is the version of bind on the slave side:
$ rpm -q bind
bind-9.8.2-0.47.rc1.el6_8.2.x86_64
I did find this reference:
Which states the following:
Zone notifies and refreshes
Apart from when a server is restarted, or when rndc commands are used to force a zone transfer, there are two
mechanisms that cause slave servers to check whether or not their copy
of a zone is current. The process of checking and updating is called
a zone refresh :
I interpret this as BIND not doing anything special when in its start up phase.
Hmm, didn’t read all the docs completely. There’s a paragraph that states the following on the same page:
When a server is restarted, it sends out notifications for the zones
that it has loaded (in case they have been updated while it was not
running). Similarly, when loading zones that are slaved, a
newly-restarted named will initiate a refresh for each zone (using
jittered time intervals so that all refreshes are not initiated
concurrently).
So from this it sounds like the BIND slaves will send out a notification to the master and then coordinate IXFRs to catch up and begin serving updated zone information.
