This step is currently under development

The initial setup of the 2 slave servers is quite simple. Basically, you're going to be installing djbdns on the 2 slaves exactly as you did on the master. Just like on the master server, you will want to have daemontools and ucspi-tcp installed on each slave servers before you install djbdns. I'm going to walk you through the setup of the first slave server. After you get the first slave set up, simply repeat this step on the second slave server. So let's get started!

Going by my example, our master server was ns1.djbdnsrocks.org. The first slave server that we are about to set up will be ns2.djbdnsrocks.org. This leaves ns3.djbdnsrocks.org for our 2nd and final slave server, which we will set up after we do this one.

Before we being, don't be a moron. Make sure you a logged into the server that you intend to use as the first slave.

First, let's download the djbdnsrocks package collection...

mkdir /downloads

cd /downloads

wget http://www.djbdnsrocks.org/downloads/djbdnsrocks.tar.gz

tar zxvf djbdnsrocks.tar.gz

cd djbdnsrocks

As I said above, you will want to make sure that daemontools and ucspi-tcp are both installed priot to installing djbdns. If you need to install them, you can find directions by following the links below:

Installing daemontools

Installing ucspi-tcp

Once you've got daemontools and ucspi-tcp installed, it's time to install djbdns...

tar zxvf djbdns-1.05.tar.gz

cd djbdns-1.05

Now compile/install it...

4. make

You will see a bunch of stuff fly by on the screen. This is normal. ;)

5. make setup check

A successful "make setup check" will produce the following output:

./install
./instcheck

OK, djbdns is now installed. Our next task is to deploy tinydns. Remember, we are going to configure this first slave server as ns2.djbdnsrocks.org, so make sure that the IP address that you are going to use for ns2 is already bound to the server and ready to use.

Deploying tinydns

The first thing you'll want to do is create the needed users on your system that will enable the slave DNS server to function correctly. Simply run the scripts to create the needed users and groups...

For Redhat and most other Linux systems:

/downloads/djbdnsrocks/scripts/slave_users_rh.script

For FreeBSD systems:

/downloads/djbdnsrocks/scripts/slave_users_freebsd.script

Next, we will create the core of the slave tinydns server. We will create a series of scripts and folders and it is here where all the zones and other configs will live. Fortunately, there are ready made scripts that do all the work for us.

So let's create the 1st slave nameserver. As I said, I'm creating the tinydns server for the IP address that will serve ns2.djbdnsrocks.org

/usr/local/bin/tinydns-conf tinydns dnslog /etc/tinydns 5.6.7.8

Viola! The /etc/tinydns folder should now exist and be full of tinydns files, just like the master server.

To start our 1st slave tinydns server, all we have to do is add it to the daemontools service directory. If you're familiar with daemontools, you know how easy this is. But if not, don't worry, because guess what? It's easy. Well, it's easy as long as you've already installed daemontools and ucspi-tcp.

So let's crank up our first slave DNS server...

ln -s /etc/tinydns /service

OK, that's it! The first slave DNS server should now be up and running. If you run a "ps -aux" (or similar) command on your server you should now see the tinydns processes running. It should look similar this:

root 12730 0.0 0.0 1376 276 ? S 12:22 0:00 supervise tinydns
tinydns 12731 0.0 0.0 1508 280 ? S 12:22 0:00 /usr/local/bin/tinydns
root 12732 0.0 0.0 1376 276 ? S 12:22 0:00 supervise log
dnslog 12733 0.0 0.0 1396 280 ? S 12:22 0:00 multilog t ./main

root 1731 0.0 0.0 1364 232 ? S Sep08 0:00 readproctitle service errors: .......................................

If the "readproctitle service errors" line is clear, as above, you are all set. If it shows errors, you will need to troubleshoot those errors. Reading the nameserver's logs at /etc/tinydns/log/main/current can help track down an error a lot of the time. Most errors with tinydns are "usually", in my experience, related to bad file permissions or ownership settings.

OK, so your first slave tinydns server is up and running. There are no zone entries present at the moment, so it's not really doing anything yet. Our next task is to configure this slave server so that it can accept syncronization commands from our master server. Doing this will allow our slave servers to exactly mirror the tinydns information on the master server, resulting in the triple redundant DNS system that we want.

The syncdns user and rsync

Earlier on the page we ran a script to add the needed users and groups to our server. One of the users that got added was a user called "syncdns". This user was also added to your master server when you ran the same script. This user has a shell and has a home directory of /etc/syndns. We are going to use this user to allow our master tinydns server to automatically sync up with each slave server. We will do this with 2 magical items: rsync and authorized keys.

Rsync is the program that will allow our master server to sync up it's data with the slave servers. Rsync will do this via the syncdns user and will work through good old ssh. Normally, a user would need a password to log in to a remote server via ssh. However, with the use of authorized keys we can configure our system so that the syncdns user will have authorization to log into the slave servers without the use of a password. The first step in setting this up is to log into our MASTER server and generate a public key for the syncdns user. So let's get to it...

First, log into your master DNS server and get into a root shell

Next, you will need to "su" to the syncdns user...

su - syncdns

The above command should drop you into a shell as the syncdns user. Just to be sure we're in the right place, let's get into the user's home directory, which is /etc/syncdns..

cd ~

Next, we'll create a directory called ".ssh"...

mkdir .ssh

Now let's cd into that directory..

cd .ssh

Now we're going to generate a public encryption key for the syndns user. In the command below, I've used /usr/bin/ssh-keygen. However, your system may have the ssh-keygen utility in a different location such as /usr/local/bin/ssh-keygen or something like that. Anyway, let's generate our key...

/usr/bin/ssh-keygen -tdsa

When you run the above command, it's going to ask you a few questions. Simple hit ENTER for each question without changing the default settings and DO NOT enter a passphrase when asked. Simply hit ENTER. It should look something like this:

/usr/bin/ssh-keygen -tdsa

Generating public/private dsa key pair.
Enter file in which to save the key (/etc/syncdns/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/syncdns/.ssh/id_dsa.
Your public key has been saved in /etc/syncdns/.ssh/id_dsa.pub.
The key fingerprint is:
f7:a4:6d:22:77:aa:2f:b8:3d:06:56:4c:12:dd:6d:55 syncdns@yourhost.com

Running a list of the directory should now show 2 new files...

ls -al

drwxr-xr-x 2 syncdns syncdns 512 Nov 16 20:17 .
drwxr-xr-x 3 syncdns syncdns 512 Nov 16 20:17 ..
-rw------- 1 syncdns syncdns 1192 Nov 16 20:17 id_dsa
-rw-r--r-- 1 syncdns syncdns 1132 Nov 16 20:17 id_dsa.pub

The "id_dsa.pub" key file is the one we're interested in. This file contains the encryption key that will allow the slave servers to let the syncdns user to login with the burden of a password. In order for this to happen, however, we need to rename the file and then get it over to the .ssh folder of the syndns user on the slave server.

First, rename the file..

mv id_dsa.pub authorized_keys2

Now, let's move this file over to the slave server. I like to use "scp", but you can use whatever means you like. I'm going to move it using a user called "eric" that I've got setup on all of my servers, but you can move it with whatever user you like.

scp authorized_keys2 myuser@ns2.djbdnsrocks.org:/home/myuser

If you're able to log into your 2nd slave server, go ahead and move the file over there as well...

scp authorized_keys2 myuser@ns3.djbdnsrocks.org:/home/myuser

Now, log into your first slave server, get into a root shell and place the authorized_keys2 file in the proper place...

cd /etc/syncdns

mkdir .ssh

cd .ssh

cp /home/myuser/authorized_keys2 /etc/syncdns/.ssh

chown syncdns:syncdns authorized_keys2

chmod 644 authorized_keys2

Next, we will set the proper permissions so that the syncdns user has the ability to change the tinydns data files during sync...

chown -R root:syncdns /etc/tinydns/root

chmod -R 775 /etc/tinydns/root

OK, everything should be ready to go. Assuming you have installed rsync on both the master and slave servers (as instructed in the pre-installation requirements), we should be ready to give the system a test drive!

Testing the rsync connection and tinydns synchronization

With the syncdns user configured and the authorized key on the slave server, we should now be able to make a successful connection and syncronization from the master server.

To facilitate this test, I would reccomend opening up 2 connections on your screen. The first should be to the master DNS server (as root) and the 2nd to the 1st slave server (as root). In this way, when we run the test on the master you can jump over to the slave and verify that the data has been syncronized.

In the "test drive" section of this installation guide, you should have created a test zone entry for your master DNS server using Vegadns. That being the case, the /etc/tinydns/root/data and /etc/tinydns/root/data.cdb files should contain data pertaining to the entries you made. The 1st slave server, on the other hand, should have no such data present. We're going to run the syncronization commands now and when it's done you should be able to see the data from the master server present on the slave server, and with the same time stamp as the master server files.

So, from our master server, let's run the sync commands. In the commands below, I have used the IP address of my 1st slave server, which for this example is 5.6.7.8. Use common sense and stick your 1st slave server's IP address in there instead...

setuidgid syncdns rsync -tav -e ssh /etc/tinydns/root/data.cdb syncdns@5.6.7.8:/etc/tinydns/root/data.cdb

setuidgid syncdns rsync -tav -e ssh /etc/tinydns/root/data syncdns@5.6..7.8:/etc/tinydns/root/data

WARNING: This step is not finished yet.

Proceed to step 9