PCQ Labs' hands-on guide shows that it's easier than it's reputed to be, if you do your homework

Setting up a Unix system as DNS (a Domain NameServer) is reputed to be the most difficult thing around. However, in our experience at PCQ Labs, it was nowhere as hard as it was claimed to be. Of course, a lot of background reading helped. The recommended way of setting up DNS on any machine is to get someone else's running DNS files and change the IP addresses and names to fit yours. This is what the gurus recommend, and this is what most consultants do. If you still want to go ahead and do it yourselves, then read on.

Configuring Linux to run as a DNS server requires you to create five files and configure three others.
To start with you must create a file with the name of named.boot in your /etc directory. Contents of the file we created for our setup are shown below:

directory /var/named
;type domain source file or host
cache . root.cache
primary 0.0.127.in-addr.arpa labzone/127.0.0
primary 1.168.192.in-addr.arpa labzone/192.168.1
primary pcqlabs.com labzone/pcqlabs

Here the first line gives the directory path where all other files are located. This directory is considered as the root, and all further directories and files created will be in context to this.

The next line is a remark; it tells you the various fields that exist in the file. All lines that begin with a semicolon are remarks put in for information and clarity.

The third line contains the name of the cache file, which in this case is root.cache. This file contains the IP addresses of the nine root nameservers (explained later) on the planet. If your network is connected to the Internet, then it will pick up the names and the IP addresses of these main Internet nameservers from this file. If, however, you are running it as an isolated network not connected to the Internet, you can afford to remove this line.

The next two lines are meant to provide reverse mapping, that is, if you type an IP address, then the machine should search for and find the host name. The fourth line gives the system the correct information for loopback, so that if you ask for localhost or 127.0.0.1 it will respond correctly. The last field labzone/127.0.0 means that a file called 127.0.0 is present in subdirectory labzone within the directory /var/named/. Similarly, the line after that indicates that all requests for 192.168.1.x should pick up the information from /var/named/labzone/192.168.1.

The fifth line indicates that this is the primary DNS server for the domain pcqlabs.com. The file /var/named/labzone/pcqlabs contains the host name to IP address information for this domain.

Each line beginning with primary ends up specifying a file to be created for further information. These files, created to service entries in the named.boot file are called the DNS database files or, less commonly, the zone files. It is necessary to have one zone file for each "primary" entry.

After this, we come to the root.cache file (if you are running an isolated intranet, you need not create this file at all). This file contains the IP addresses of the root nameservers on the Internet. There is a set of nine servers which maintain the IP addresses of all the top level domains in the world. Each time any application needs to find out an IP address of a particular host, it needs to look up the address on these servers. To access these servers, of course, it must have their IP addresses--and these are stored in the root.cache file. The latest version of this file is available via anonymous FTP from InterNIC (rs.internic.net) as /domain/named.root. You should periodically download the latest version and replace your existing one.

Once we had done all this, the next file to be created was /var/named/labzone/127.0.0. The contents are as shown below:

The periods at the end of the names (pcqlabs.com.) are important. Don't leave them out!

Here IN is Internet, SOA is Start of Authority, which means that this server will be regarded as the authoritative nameserver for the domain. The entry root.pcqlabs.com specifies the e-mail address to which any DNS related information is to be mailed. Note we have to say root.pcqlabs.com and not [email protected]. While any valid e-mail address can be used, it has to specified in the format shown above, not in the usual [email protected] manner. The e-mail address [email protected] should exist. The entries in parenthesis (serial, refresh, etc) are a part of the first record, and indicate actions to be taken in case a secondary name server exists.

Each time you modify this file you must increment the serial number. That's because if you are going to use secondary nameservers, they'll check if they have to update their own records by checking the serial number. If you modify the file and do not increment the serial number, the secondary nameservers will not update their records. Of course, if you are using only one nameserver for your system, you needn't bother about the serial number at all. The refresh field contains the number of seconds between secondary server data accuracy checks. After this comes the Retry field which contains the number of seconds after which a secondary server should retry accessing the primary nameserver if it failed to connect the first time. The Expire time is the time after which a secondary server should expire the data received from the primary, if the data could not be refreshed. The TTL (Time To Live) is the time for which the data provided by this server should be allowed to remain in other server caches, before it is declared obsolete.

After this comes the nameserver record. This is primarily a pointer to the fully qualified domain name of the system. In our case it was called pcqlabs.com. The last and final record is the PTR record (pointer) that contains the IP address to DNS host name mappings. The 1 at the beginning gets translated to 1.0.0.127.in-addr.arpa which is the reverse of the localhost address 127.0.0.1. Once we are through with the 127.0.0 file, we move on to the 192.168.1 file. We used this name as it is our network address. You can give any name as long as you maintain consistency across all the files and the records that call them. The file looks like this:

This file also contains material similar to the other database files and if you have understood the contents of the file 127.0.0 then this file should not be too much of a problem. The file contains the same three types of resource records (RRs): the SOA, the NS, and the PTR. Note that the 131 in the PTR record is the final quad of the IP address of the nameserver which in our case had an IP address of 192.168.1.131.

After this we started work on the pcqlabs file. Its contents are as shown below:

Again this file looks somewhat similar to other database files, apart from the fact that we have three new types of RRs here: CNAME, A, and MX. Each A RR contains a DNS host name and an IP address. Here we define the various hosts on the network and map their IP addresses to the names that we want to assign them. In the file above, we created three hosts: localhost, linux, and ntserver. Note that since we have not given their fully qualified domain names, by default, the domain becomes pcqlabs.com--so ntserver is ntserver.pcqlabs.com and so on. The localhost defines the machine on which you are setting up the DNS. The same machine is assigned the name linux in the pcqlabs file. Both assignments are necessary. CNAME allows a machine to be addressed by more than one name. For example, in the last two records, what we are actually saying is that kill.pcqlabs.com is the same as ntserver.pcqlabs.com, the one that has an IP address of 192.168.1.130.

One important resource record is the MX (Mail eXchanger). This decides the machine that will handle mail for the domain. In the above file, the primary mail server for the domain pcqlabs.com has been defined as ntserver.pcqlabs.com. In case the primary mail server does not work, linux.pcqlabs.com takes charge since it has been defined as the secondary mail server. Which server acts as primary and which is secondary depends on the preference value given in the record (10 for ntserver and 20 for linux). The machine with the lower number is the primary.

In the above file, while the ntserver MX RR has the hostname written as ntserver.pcqlabs.com., the linux MX RR does not have a fully qualified domain name. Either way works, but if you are going to write the fully qualified domain name, then don't forget the trailing dot. Also the MX record must not use a canonical name, that is, we cannot use kill.pcqlabs.com in place of ntserver.pcqlabs.com.

This finishes off the main part of the DNS configuration.

Now comes the modification of files. First is the file /etc/resolv.conf. The following two lines should be the only contents of the file. All others should be deleted.

domain pcqlabs.com
nameserver 127.0.0.1

After we had finished work on resolv.conf we have to configure the system bootup scripts, that is, the rc.inet1 and rc.inet2 files in the /etc/rc.d directory. First we open up rc.inet1 file and at the very top insert the following lines

Save this file and open rc.inet2. Insert the lines in bold at the location shown below
...
#Start the Inet Superserver
if [ -f ${NET}/inetd ]; then
${NET}/inetd
else
echo "NO INET found... INET cancelled!!!"
exec false
fi

# Insert following lines; if they exist, knock off the hash signs
# Start the named server
if [ -f ${NET}/named ]; then
echo -n "named"
${NET}/named
fi
# End of Insert

# Start the various INET servers.
for server in ${IN_SERV} ; do
if [ -f ${NET}/${server} ]; then
echo -n " ${server}"
${NET}/${server}
fi
done
...
Note that you need to make the changes in the system bootup scripts only if you wish to start the nameserver at boot time itself. If that is not the case, then you can start the name daemon by simply typing ndc start at the root prompt. If at any time you want to stop the server from running, you can simply type ndc stop, to restart type ndc restart and to make it reread the files the command to use is ndc reload. It is recommended that you set up your machine to start the nameserver at bootup.
Of all the daemons we have used, named was the toughest; but it was nowhere as hard as we had expected it to be. The Internet is teeming with horror stories about the woes of the poor administrators who tangled with this one. If you do your home work right, then you should not face any problem.

The contents of the root.cache file are given below.