The Linux Page

BIND errors between masters and slaves

Using BIND as a Master and a Slave simultaneously

I got BIND on two servers (the named service). Each server is at the same time a master and a slave depending on the domain name. For instance, I host on my server and on my company's server.

Up to here, easy.

The slaves are expected to update themselves whenever the master emits a change in a zone.

Somehow, one of my domain names would not work at all on the slave (company's server). I searched and searched and I just couldn't find out why it was not working. Finally, I tried to search the named.conf.local of the slave using the master domain name (i.e. copy & paste). That's how I discovered that I misspelled the name in the slave!!!

Errors using the wrong spelling
Mar 18 17:21:40 web named[21982]: zone refresh: unexpected rcode (REFUSED) from master (source
Mar 18 17:21:40 web named[21982]: zone Transfer started
Mar 18 17:21:40 web named[21982]: transfer of '' from connected using
Mar 18 17:21:40 web named[21982]: transfer of '' from failed while receiving responses: NOTAUTH
Mar 18 17:21:40 web named[21982]: transfer of '' from end of transfer

As you can see this error was not clear. The problem was that lorusso is one R and two S's...

Now that was not all. I was getting another kind of error too:

Errors using BIND 9.3, notification refused
Mar 18 21:34:14 web named[16331]: zone sending notifies (serial 46)
Mar 18 21:34:14 web named[16331]: client received notify for zone ''
Mar 18 21:34:14 web named[16331]: zone refused notify from non-master:

As we can see the BIND tool wants to update the domain name by sending a notification. But that notification is being refused. This happens since BIND 9.3 apparently. The concept is simple but quite a gotcha! The server is actually sending a notification to itself and chances are if you are reading this you have the same problem:

You need to allow the server to notify itself!

I had a hard time to see that with that error because of the other error I had before. I found a site where someone else ran in that problem and had a simple solution:

Add a notify-allow { <myself>; } where <myself> is your slave server IP address. If you are like me, you want to add that to both your servers.

More info about BIND (but really no solution to any of your everyday problems...):

Determining whether BIND is running as Master or Slave

By default, BIND will be a master.

It is possible to always run BIND as a master and simply duplicate your zones by hand (with a mechanism of your own such as an rsync) on all your servers.

However, the named service offers a way to copy zones between servers. In that case, one server is called the master and the others are slaves. The number of servers is not limited, although you probably want to keep it small to keep it manageable.

Slave servers are good if you have several offices or just your own domain names and need two servers.

To transform a master named server into a slave, you use the allow-update option. When this option is used in the global space of named.conf, then the BIND service runs 100% as a slave.

If, like me, you want to run as a Master for some domains and as a Slave for others, then you want to be very careful on how you use the allow-update option.

I suggest that you use the option only in the zones marked as slave (i.e. type slave;). Yet, if you have just one or two masters, you can as well write one global allow-update and then cancel that declaration in your master entries as in:

   zone "" {
        type master;
        file "/etc/bind/alexis/";
        allow-update { none; };

An example of allow-update with an IP address appears below. allow-update can include several IP addresses separated by semi-colons.

Errors about permissions denied
22-Aug-2010 15:40:27.246 general: error: dumping master file: /etc/bind/alexis/tmp-I2lHgTnElm: open: permission denied
22-Aug-2010 15:40:27.247 xfer-in: error: transfer of '' from failed while receiving responses: permission denied

Today I noticed that the bind server was working in only one direction. Wondering, I looked at the logs (after I turned on the feature) and noticed that the tool was telling me that it did not have permissions to write to the alexis folder (often called slave although in our case we have several people and used several folders to segregate the names). I verified all the folders and files, made sure they were owned by bind, just like on the other server, and it still did not work.

So I search on the Internet and found a post on Ubuntu that gave up the answer:

Although all the permissions look correct as per the old days,
they are not correct for the new days of apparmor.
Yes! apparmor will prevent the write whether you want it or not.

Look at the settings of apparmor and see that the /etc/bind folder is a read-only folder now (which is a GREAT thing, since that's how it should always have been!)

Instead, BIND is expected to write dynamic files in /var/cache/bind/*

However, if you are like me, you probably have something like this in your configuration file:

   zone "" {
        type slave;
        file "/etc/bind/alexis/";
        masters {; };
        allow-update {; };

When such a zone configuration on your server, the zone is considered a slave. Here we also tell that slave that the master is at a specific IP address. That IP address is the only trusted source. Good.

Then, in between, we notice the file specification. This is a path and file name of the zone used to save the slave server version of the zone...

In your apparmor /etc/apparmor.d/usr.sbin.named configuration file you will see this:

   /etc/bind/** r,
   /var/lib/bind/** rw,
   /var/lib/bind/ rw,
   /var/cache/bind/** rw,
   /var/cache/bind/ rw,

As you can see, anything under /etc/bind will be write protected from bind (DO NOT CHANGE IT!). Whether or not bind wants it that way does not matter here.

On the other hand, we have two read-write folders: /var/lib/bind and /var/cache/bind. The second one is where dynamic slave files are saved once you fix you configuration. The file "..." specification needs not include a path at all and the system automatically puts the files under the right folder.

   zone "" {
        type slave;
        file "";
        masters {; };
        allow-update {; };

As you can see, that is nearly the same as the previous configuration, we just removed the path in the file specification.

Now everything works! Don't forget, if you want immediate update of slave name servers you've got to restart your name servers AND bump up the serial number of zone files that you modify. This is how they know that it was bumped up.

Other errors?

Got another error and don't know how to fix it? Post a comment below with the inf or contact me directly.