Howto- Configuring BIND master and slave DNS servers

• Tweet

• Tweet

DNS (Domain name system) servers are one of the most crucial parts of hosting servers on the internet. DNS servers give us the ability to connect to websites and other types of servers by using words and number instead of IP addresses. Without DNS servers users visiting a website would have to connect using its IP address (say for example http://88.192.77.211 instead of http://www.unixmen.org). It can be somewhat hard for people to remember IPv4 addresses this becomes even more apparent with many web servers switching to IPv6. I don’t know many people that could easily remember a 32 digit address of each website they visit.

BIND (Berkeley internet name domain) is one of the most widely used DNS servers; it comes standard in most Unix like operating systems. Installation at first can be somewhat overwhelming; however once you understand some of the basics you can begin to get a clearer picture of how BIND and DNS servers in general work. In this article I will cover some of the basics of BIND and give a brief description of how it works. Please also note that this tutorial is for red hat distributions only (RHEL, Fedora, CentOS, etc).

 Before you begin it’s recommended that you have atleast two servers (ns1.example.com and ns2.example.com), one to act as the primary or master name server and the second to act as a slave. The primary server can handle recursive or iterative queries and it is where all of the zone files are located. These zone files contain DNS records and are transferred to the slave servers using iterative queries (also know as a zone transfer). These DNS records are then stored on the slave servers for a period of time and when a client requests information about a domain name, a recursive query is used to communicate with the slave servers and then respond back with the details. Think of a recursive query as something that is used to resolve a domain name and an iterative query as a one way query used to update the slave.

 Of course you can also have many more than just one slave which can be useful for hosting companies with a high level of traffic, as by increasing the amount of slave servers that you are using you are also increasing level of availability to clients. You are also increasing the level of fault tolerance by not limiting your DNS servers to a single point of failure. In essence if slave server one goes down temporarily for whatever reason (upgrading, power failure) slave server two will still be able to handle the traffic and take over the duties of name server one.

 To check whether you have BIND installed you can start out by using rpm

 rpm –qa bind

 It’s also a good idea to install bind utilities which contains tools such as dig which is used for issuing DNS queries and troubleshooting problems with your DNS servers.

 yum –y install bind-utils

 Next you will need to start the BIND service

 service named start

 You can also check to see if the service is running using netstat

netstat –tap

 Next you will need to open the /etc/resolv.conf file and place the IP address of your master and slave DNS servers at the top. In this example 10.0.0.1 will be the IP address of the master and 10.0.0.2 will be the IP address of the slave.

nameserver 10.0.0.1

nameserver 10.0.0.2

 You will then need to open up the /etc/named.conf file. This file is used for configuring how BIND will run, such as the port number used, the level of security and where the zones are located.

 Inside the options {} section place the following line to allow the master server to transfer all the zones to the slave server.

{codecitation}options {

allow-transfer { 10.0.0.2; };

}{/codecitation}

Next you will need to generate a RNDC key with a tool called rndc-confgen. This key is used for encryption when communicating with an external name server.

 rndc-confgen –a –c /etc/rndc.key

 This creates a key file in the /etc folder which can be included into the /etc/named.conf file with the following lines. You will also need to make sure that the name inside controls matches the name inside the key file “rndc-key”.

 {codecitation}controls {

inet 127.0.0.1 allow { localhost; };

keys { rndc-key; };

};

 include “/etc/rndc.key”;{/codecitation}

 Depending on your version you will either have several zones inside your named.conf file or they will be included in a file called named.zones or named.rfc1912.zones. These zones are used for specifying the root, master and slave locations.

 Root zone

 {codecitation}zone “.” IN {

type hint;

file “named.ca”;

};{/codecitation}

The root or “.” zone is a file which lists all of the root DNS servers. If you are familiar with the hierarchy of DNS servers the root servers are at the top of the list and have the greatest authority. By default the root server details are listed in the named.ca file.

 localhost zone

 {codecitation}zone “localhost” IN {

type master;

file “named.localhost”;

allow-update { none; };

};{/codecitation}

 The localhost zone is created by default in /var/named/named.localhost. It is used for replying to queries with the IP 127.0.0.1 for any domain name queries as localhost. This can be useful for certain applications running on the same server that need to access localhost.

 Reverse mapping zones

 zone "1.0.0.127.in-addr.arpa" IN {

type master;

file "named.loopback";

allow-update { none; };

};

Reverse mapping zones are used for translating an IP address to a hostname using the in-addr.arpa domain. In this case when the loopback IP 127.0.0.1 is queried it will return the host name localhost.

 Creating a zone

 By now you should have almost everything setup necessary for running a master server, except for the zone and zone files. These zones are much like the default ones already created, except in this case we will add some information to them to make them usable from the slave server. In this case we will be using the domain name unixmen.com and 10.0.0.3 will refer to the web server where the website is located.

 {codecitation}zone “unixmen.org” in{

type slave;

file “slaves/unixmen.org”;

masters {10.0.0.1};

};

zone “3.0.0.10.in-addr.arpa” in{

type slave;

file “slaves/10.0.0.1.rev”;

masters {10.0.0.1};

}; {/codecitation}

Adding these two zones similar to before will create forward and reverse zones. You will also need to create the proper zone files inside the /var/named/slave directory with the appropriate DNS records as seen below.

 /var/named/slave/unixmen.org

 $TTL 1D

@ IN SOA ns1.unixmen.org. ns2.unixmen.org. unixmen.org. (

2010082500 ; serial

5M ; refresh

2M ; retry

1W ; expire

5M ) ; minimum

IN NS ns1.unixmen.org.

IN NS ns2.unixmen.org.

; Master name server

NS1 IN A 10.0.0.1

; Slave name server

NS2 IN A 10.0.0.2

WWW IN A 10.0.0.3

Most parts should be self explanatory if you have ever setup a website domain name before, but incase your not familiar with some of the terms I will list them below.

TTL = Time to live

SOA = Start of authority record

NS = Name server record

A = Address record (For IPv6 this is AAA)

It is also worth mentioning that the serial is simply the current date. It’s also a good idea to create a reverse mapping zone for the forward mapping zones you just created, although it isn’t required.

 Finally make sure that you save everything and restart named.

 service named restart

If you are switching name servers it may take a day or two for your records from your previous DNS server to expire so that your server can start to use it. In the mean time there are a few ways you can test to see if your installation is working such as using dig.

 dig unixmen.org

 or alternatively to check what name servers the website is using.

 nslookup unixmen.org

 To setup the slave server you will need to configure bind similarly on the second sever except for a few slight differences. Firstly you will need to setup the options to include these lines.

{codecitation}options {

allow-transfer {“none”;};

recursion yes;

}{/codecitation}

As the slave server does not need to transfer zones you will need to turn transfers (or iterative queries) off. As I also explained earlier recursive queries allow the client to connect and by default recursion is turned on, but you can also force it on using the recursion yes; line.

You will also need to place in all of the zones inside the appropriate zone files or the named.conf file, except you will not need to create the files containing the SOA and DNS records because the master will automatically transfer these over and store them inside the selected files for you.

 {codecitation}zone “.” IN {

type hint;

file “named.ca”;

};

 zone “localhost.localdomain” IN {

type master;

file “named.localhost”;

allow-update { none; };

};

zone “localhost” IN {

type master;

file “named.localhost”;

allow-update { none; };

};

zone “1.0.0.127.in-addr.arpa” IN {

type master;

file “named.loopback”;

allow-update { none; };

};

zone “unixmen.com” in{

type slave;

file “slaves/unixmen.com”;

masters {10.0.0.1};

};

zone “3.0.0.10.in-addr.arpa” in{

type slave;

file “slaves/10.0.0.1.rev”;

masters {10.0.0.1};

};{/codecitation}

 Once you have finished configuring both servers you will also need to configure both bind installations to run on boot up.

chckconfig named on

{module user9-footer}

Related posts:

1. Howto install puppet Master and client in ubuntu
2. Install and confgure DNS For RHEL/Centos/Fedora
3. Configuring Sendmail SMTP server on CentOS & Scientific Linux
4. Now Home servers are a click away with BeedBox Project
5. Ubuntu Enterprise cloud delivered on Dell servers