How to verify that a BIND slave name server is actually synchronizing properly with master (and fix it afterwards)?

Posted on

How to verify that a BIND slave name server is actually synchronizing properly with master (and fix it afterwards)? – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.

But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about linux, domain-name-system, bind, nameserver, .

I’ve set up two name servers, a master and a slave according to this link. The setup is functioning evidenced by the fact that sites featured on the master server gets served as expected.

Recently though, I’ve begun suspecting that the slave server doesn’t synchronize correctly with the master. During an error inspection I tried reloading a random zone file:

rndc reload domain.tld

(“domain.tld” being a placeholder)

only to be greeted by this:

zone refresh queued

Above is the message that is returned, regardless of domain tested.

I’ve tried searching the whole slave server for any zone files (find / -name *.zone), with no result (but since I’m not fully aware of how the BIND setup works, I’m not even sure that the slave server is supposed to contain the zone files like the master, making the search potentially redundant).

Then I checked the log, it’s filled with the likes of following entries:

dumping master file: tmp-CWKpRfrNi0: open: permission denied

Looks like a permission problem to me, but I’m honestly not entirely sure. BTW, I have also tried reloading zone files after incrementing the serial, with no luck.

  1. Is there a way to verify that the slave server is functioning as intended?
  2. Assuming above information is enough to conclude that en error is in fact the culprit and the server is faulty, how do I fix it?

Solution :

My bind-9.8.2-0.37 from CentOS 6 says after a slave is restarted (for each of the zones, even if they are already cached):

08-Apr-2016 12:15:07.571 zone loaded serial 2016040103

The named.conf contains, among other stuff::

logging {
  channel general_file      { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; };
  category general      { general_file; };

No need to search for zone files, you should have them manually defined in named.conf, so their location should be easily determinable. Maybe you have chroot misconfigured, that is named runs thinking the root of the filesystem is somewhere like /var/named/chroot and it has no proper permissions set there.

Leave a Reply

Your email address will not be published. Required fields are marked *