Update Zone Files

Update Zone Files

Now that we have the zone files entered into the slave DNS server successfully, the zone files need to be populated with current information from the master DNS server. There are a number of ways to do that; AXFR (or IXFR), rsync, scp, etc. Setting up any of those methods is an involved process, and they all work (some better than others), but I’ve found rsync to be the most satisfactory solution for updating zone files.

Before starting, confirm that both the master DNS server and the slave DNS server machines have the latest rsync installed.

# yum install rsync

On the master DNS server machine, create a user that has a password and login access. Using webmin you can click the System icon at the top and then click the Users and Groups icon. Click the “Create a new user” link. Fill it out like this.

Also, farther down the page next to “Primary group” select “Existing group” and enter named, like this.

Click the Create button at the bottom.

Determine where your zone files are located in your master DNS server. Those are usually in one of these two locations.

/var/named/
/var/named/chroot/var/named/

If you are in the correct directory you will see individual files for each zone you maintain. The file naming convention is simply the domain name that the zone services.

On the slave DNS server machine, test rsync by logging into SHH as root and issuing the following command. This step is more than just a test, since you must login to rsync manually at least once to add your remote server to the “allow” list before a non-human login is allowed.

# rsync -avz -e ssh dnsdenver@example.com:/var/named /var/named/slaves/

Where “dnsdenver” is the user you created in the master DNS machine and example.com is the domain name (or IP address) of your master DNS server. The first /var/named entry is the location in your master DNS server where the zone files are located, and /var/named/slaves/ is the location in the slave DNS server where you want the zone files to be replicated.

Note that if you are using a non-standard SSH port (555 in this example) that you will need to enter the command like this:

# rsync -avz -e "shh -p 555" dnsdenver@entomy.com:/var/named/ /var/named/slaves/dallas/

The test run will still ask for the password of the user, which you will need to provide, but we’ll take care of automating the process later. Right now you just want to get your source and target directories doing exactly what you want them to do. That is, to make sure that rsync is finding the zone files in the master DNS server machine, and then updating the zone files in the slave DNS server machine where you want them to go. Test run rsync as many times as you need to in order to get it working right.

Note that rsync might be moving some sub directories to the slave DNS server machine that you don’t need. Don’t worry about that now, we’ll exclude those later.
Once you are satisfied that rsync is doing exactly what you want it to do, we’ll move-on make rsync run without user interaction by installing a key. On the slave DNS server machine, login to SSH as root and issue the following commands.

IMPORTANT: Don’t enter your password when prompted. If you enter your password rsync will still require user interaction. Just press Enter when prompted for a password.

# mkdir /root/rsync # ssh-keygen -t dsa -b 1024 -f /root/rsync/mirror-rsync-key
Now copy the key you just created to the master DNS server machine.
# scp /root/rsync/mirror-rsync-key.pub dnsdenver@example.com:/home/dnsdenver/

If you are using an alternate ssh port, such as 522 suggested earlier in this paper, then you would need to enter that command this way:

# scp –P 522 /root/rsync/mirror-rsync-key.pub dnsdenver@example.com:/home/dnsdenver/
If you have difficulty with the above command for some reason (perhaps a firewall issue from a non-standard SSH port) don’t fret over it too much. Use whatever method you wish to transfer the file, just make sure that it’s in the home directory for the user you created in the master DNS server machine.

On the master DNS server machine, login to SSH as the user you created (dnsdenver in my example) but NOT AS ROOT. You MUST login as the user you created. Enter the following commands.

# mkdir ~/.ssh # chmod 700 ~/.ssh # mv ~/mirror-rsync-key.pub ~/.ssh/ # cd ~/.ssh # touch authorized_keys # chmod 600 authorized_keys # cat mirror-rsync-key.pub >> authorized_keys
Your key should be installed in the master DNS machine and is now ready for testing.
On the slave DNS server machine, login to SSH as root and issue this more detailed rsync command (it is all one command, but wrapping to a new line).

rsync -avz --delete --exclude=**/data --exclude=**/slaves -e "ssh -p 555 -i /root/rsync/mirror-rsync-key" dnsupdate@entomy.com:/var/named /var/named/slaves/dallas

Note that we’ve added a few things since we tested rsync earlier. The “--delete” entry tells rsync to remove any files that it finds on the slave DNS server that are no longer on the master DNS server. The “--exclude=” entries tell rsync to ignore the /data and /slaves directories, so they won’t be transferred any longer. The “ssh” commands between the double-quotes tells SSH to use the non-standard SSH port 555, and to authenticate using the specified key. If you are using the standard SSH port of 22 then you can enter the “ssh” entry like this.

"ssh -i /root/mirror-rsync-key"

The rest of the entries should be entered exactly as what worked well for you during the testing phase. If the command does what you want it to do, and runs without asking for a password, then you are ready to automate the process. To do that you will run the rsync to update zone file contents each time the zone file list is updated. We can do that by entering the final rsync command in the script that we wrote for the slave DNS server. In the example we called it getdallas and placed it in the following directory.

/var/named/chroot/var/named/slaves/

Edit the script with a text editor, adding the rsync command on a new line before the named restart command, so it looks like this.

Test run the script using SSH as root on the slave DNS machine, just to be sure everything works as it should. You don’t need to do anything else, since the cron job for that script was created in a previous step. You can run the scripts in the two machines as often as you wish, but bear in mind that the DNS server in the slave machine will be unavailable for the time it takes to restart named. Running it once or twice per hour should be more than adequate.