I manage my slave servers with a couple scripts which keep the content on my slave servers the same as that on my master. What I mean is that every one of my slaves hosts all the zones that my master hosts, whether the zone is actually delegated to the slave or not.

This eliminates variance between the zones loaded on my slaves, while still allowing me to keep different directives in the "options" and other blocks of the BIND config file. I know which zones are loaded on each slave - the answer is "all of the zones". I can setup a zone once on my master server, run a single script, and have the zone added to my slaves. This saves a huge amount of time in the long run, if you add zones regularly.

The idea here is that the input to this script isn't any "options", "controls", "logging" or any other statements. What this script is written to work with is the "zone" blocks.

I have a named.conf like this (contents of blocks deleted for brevity):

 options {
         version "surely you must be joking";
 };
 
 controls        {
 };
 
 logging {
 };
 
 zone "localhost" {
 };
 
 zone "0.0.127.in-addr.arpa" {
 };
 
 zone "." {
 };
 
 include "subdir1/named.zones";
 include "subdir2/named.zones";
 include "subdir3/named.zones";
		

This way "subdir1/named.zones", "subdir2/named.zones", and "subdir3/named.zones" only contain "zone" blocks. This makes the job of the filter much easier. Now you can setup your slaves the exact same way, using the "include" directive to include a single named.zones file containing all the zones that you wish to slave.

Use this script to generate the named.zones file for the slaves. The script puts the backup zone files in a sub directory named "secondary" and changes the filename to match the domain name exactly (unless it contains a slash, in which case the slash is replaced with an underscore). This is a *very* basic script, but it shows you how powerful a simple script can be - saving lots of time and effort.

Also, the wrapper script has no real error checking - it just reloads BIND after syncing the file. I have an extensive logging infrastructure that pages me right away if there's any errors in the logs, so I kept it out of the script. I'd recommend building in some error checking somewhere if you don't have any way of determining if the new config file loaded properly (HINT: named-checkconf from the BIND 9 distro).

Use a shell wrapper like this to use SSH public-key authentication and rsync to push the file out. Wrapping it this way requires you to enter your public-key passphrase only once, which is the best part of the script.

I don't have the time and the patience to explain SSH public-key authentication, so please don't ask me to. Buy the O'Reilly book on it, it was one of the best investments I've ever made. The wrapper script will probably need modifications for your system.

If you have a higher serial number on your slaves then on your master server, one way to fix it is to increment your master's serial number by the largest amount possible, then set it to the desired number. Instead of remembering the formula to do this, I've written a script to do the work for me.

Use this form to calculate the the serial that you need to load into the zone on your master. Once the slaves sync to the new serial, set the serial on the master to the lower number you wanted to set it to initially.

Admission of guilt: I haven't actually tested this yet, but I copied the formula from Cricket's book, so it should work.