Hot Downloads

The Linux BIND Setup & Configure Secondary (Slave) DNS Server

Written by Administrator. Posted in Linux System and Network Services

3.66666666667 1 1 1 1 1 Rating 3.67 (3 Votes)
The Linux BIND Setup & Configure Secondary (Slave) DNS Server - 3.7 out of 5 based on 3 votes

Setting up a Secondary (or Slave) DNS sever is much easier than you might think. All the hard work is done when you setup the Master DNS server by creating your database zone files and configuring named.conf.

If you are wondering how is it that the Slave DNS server is easy to setup, well you need to remember that all the Slave DNS server does is update its database from the Master DNS server (zone transfer) so almost all the files we configure on the Master DNS server are copied to the Slave DNS server, which acts as a backup in case the Master DNS server fails.

 

Setting up the Slave DNS Server

Let's have a closer look at the requirements for getting our Slave DNS server up and running.

Keeping in mind that the Slave DNS server is on another machine, we are assuming that you have downloaded and successfully installed the same BIND version on it. We need to copy 3 files from the Master DNS server, make some minor modifications to one file and launch our Slave DNS server.... the rest will happen automatically :)

So which files do we copy?

The files required are the following:

  • named.conf (our configuration file)
  • named.ca or db.cache (the root hints file, contains all root servers)
  • named.local (local loopback for the specific DNS server so it can direct traffic to itself)

The rest of the files, which are our db.DOMAIN (db.firewall.cx for our example) and db.in-addr.arpa (db.192.168.0 for our example), will be transferred automatically (zone transfer) as soon as the newly brought up Slave DNS server contacts the Master DNS server to check for any zone files.

 

How do I copy the files?

There are plenty of ways to copy the files between servers. The method you will use depends on where the servers are located. If, for example, they are right next to you, you can simply use a floppy disk to copy them or use ftp to transfer them.

If you're going to try to transfer them over a network, and especially over the Internet, then you might consider something more secure than ftp. We would recommend you use SCP, which stands for Secure Copy and uses SSH (Secure SHell).

SCP can be used independently of SSH as long as there is an SSH server on the other side. SCP will allow you to transfer files over an encrypted connection and therefore is preferred for sensitive files, plus you get to learn a new command :)

The command used is as follows: scp localfile-to-copy username@remotehost:desitnation-folder. Here is the command line we used from our Gateway server (Master DNS): scp /etc/named.conf root@voyager:/etc/

Keep in mind that the files we copy are placed in the same directory as on the Master DNS server. Once we have copied all three files we need to modify the named.conf file. To make things simple, we are going to show you the original file copied from the Master DNS and the modified version which now sits on the Slave DNS server.

The Master named.conf file is a clear cut/paste from the "Common BIND Files" page, whereas the Slave named.conf has been modifed to suit our Slave DNS server. To help you identify the changes, we have marked them in red:

Master named.conf file

options {
directory "/var/named";

};


// Root Servers
zone "." IN {
type hint;
file "named.ca";
};

// Entry for Firewall.cx - name to ip mapping
zone "firewall.cx" IN {
type master;
file "db.firewall.cx";
};


// Entry for firewall.cx - ip to name mapping
zone "0.168.192.in-addr.arpa" IN {
type master;
file "db.192.168.0";
};

// Entry for Local Loopback
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
};

 

Slave named.conf file

options {
directory "/var/named";

};


// Root Servers
zone "." IN {
type hint;
file "named.ca";
};

// Entry for Firewall.cx - name to ip mapping
zone "firewall.cx" IN {
type slave;
file "bak.firewall.cx";
masters { 192.168.0.10 ; } ;
};

// Entry for firewall.cx - ip to name mapping
zone "0.168.192.in-addr.arpa" IN {
type salve;
file "bak.192.168.0";
masters { 192.168.0.10 ; } ;
};

// Entry for Local Loopback
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
};

 

As you can see, most of the slave's named.conf file is similair to the master's, except for a few fields and values, which we are going to explain right now.

The type value is now slave, and that's pretty logical since it tells the dns server if it's a master or slave.

The file "bak.firewall.cx"; entry basically tells the server what name to give the zone files once they are transfered from the master dns server. We tend to follow the bak.domain format because that's the way we see the slave server, a backup dns server. It is not imperative to use this name scheme, you can change it to whatever you wish. Once the server is up and running, you will see these files soon appear in the /var/named directory.

Lastly, the masters {192.168.0.10}; entry informs our slave server that this is the IP Address of the master DNS which it needs to contact and retrieve the zone files.

That's all there is to setup the slave DNS server ! As we mentioned, once the master is setup, the slave is a peice of cake cause it involves very few changes.

Our Final article covers the setup of  Linux BIND DNS Caching. 

Next - Linux Bind DNS Caching

or                       

Back to the Linux System and Network Services Section

Articles To Read Next:

CCENT/CCNA

Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V

Linux

  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup