By writing the IP-Address reversed like this, we are essentially creating a new domain. The root domain, is still dot (.). However, this time there is just the single top-level domain in-addr.arpa. This notation is often referred to as the reverse domain. Because we are defining a new domain in the siemau.rev file, we need a new Start of Authority record. We could copy the SOA record from the siemau.forward file, however the domain is wrong. The domain is now 147.144.199.in-addr.arpa. So, all we need to do is replace the old domain name with the new one and the entry would be identical. The first line would then look like this:

We can now duplicate the remainder of the SOA record from the siemau.rev file. One thing I do to help keep things straight is to think of the NS record as part of the SOA record. In “reality”, they separate records. However, if you think of them together, you won’t forget and leave off the NS record. Since we are defining a new domain, we also need the NS record for this new domain. It’s NS record would look like this:

However, I don’t like the idea of two SOA records. There is the chance that I update the database files, but forget to update one of the SOA record with the new serial number. To eliminate that problem, there is a directive that you can give the name server to include another file while it’s reading the information. This is the $INCLUDE directive. To include a single SOA record, we create a file, perhaps siemau.soa and use the $INCLUDE directive in both the siemau.forward and siemau.rev files. The line would look like this:

Since we already defined the directory in the named.boot file, there is no need for a path here. However, we have a problem. The SOA record in siemau.forward is for a different domain (siemau.dom) than in siemau.rev 147.144.199.in-addr.arpa). We can take advantage of a magic character: @. This will be read as the domain name, provided the domain name is same as the origin (The origin is the machine that this data is on).

Let’s create a single SOA file (i.e. siemau.soa) and make it identical to other others with the exception of the domain name. Instead we replace it with the “@.” Next we remove the SOA records from the siemau.forward and siemau.rev file and replace it with the $INCLUDE directive above. When the name server reads the siemau.forward file, it gets to the $INCLUDE directive sees that it needs to include the siemau.soa file. When it gets to the “@”, the system translates it as linux-tutorial.info. Next, when the system reads the siemau.rev file, it sees the same directive, includes the same file, however, this time the “@” is interpreted as “147.144.199.in-addr.arpa.

There are still two lines in the named.boot file that we haven’t covered. The first sets up this servers as primary for the “local” domain. This is a special domain that refers to this host only. Remember from our discussion of IP address that the IP address for the local host is 127.0.0.1. The “network” that this host is on is 127.0.0. We always need to be the primary name server for this domain, there we have the line in our named.boot:

The named.local file could contain just two lines:

Note that here, too, we are including the named.soa file. When the system reads named.local, it includes named.soa and the “@” is translated to 0.0.127.in-addr.arpa as it should.

The last line tells us to read the cache file:

The root.cache file is the list of the root domain name serves. You can obtained the most current list root name servers using anonymous ftp from the machine ftp.rs.internic.net. The file is domain/named.root.

Let’s assume we want vesta to be the secondary name server for this domain. We would then create a named.boot file on vesta, that might look like this:

If we look carefully, we see that the only difference is the that for the forward and reverse files, we change “primary” to secondary. Note that that vesta is still the primary for the domain 0.0.127.in-addr.arpa (the local domain). The contents of the files are theoretically the same. This is where the concept of the serial number comes in. When the secondary loads it’s file it compares the serial number to what it reads from the primary. Note also that the IP address, 192.168.42.1, the address of the primary server. In our case this is the machine siemau.

If we want a caching only server, the named.boot file is a little simpler:

We still specify the directory and the root.cache file. However, we are now the primary for just a single machine, ourselves.

In any of the example named.boot files we could have include a line that simply said:

That would be a name server, regardless of what of type, that forwards all requests that it cannot satisfy to a list of predetermined forwarders. If this sever does not have the answer, it will not interact with any other server, except for those listed as forwarders. Therefore, any time you have a slave server, you must also have a list of forwarders. The entry for the forwarders might look like this:

The last kind of server I called a client. It’s configuration is the simplest. You need to create a file called /etc/resolv.conf and include a line defining the domain and then a list of the name servers or resolvers as they resolve your queries. If we had siemau as the primary for this domain and vest the secondary, our file might look like this:

Note that if this file doesn’t exits, your system will expect to get it’s information from the /etc/hosts file. Therefore, you can say that on the client side that if /etc/resolv.conf doesn’t exist, you are not using DNS.

If you have a larger network with many different departments, you might have already decided to have multiple name servers. As I mentioned, it is a good idea to have your name servers also be the gateway as they are “well connected.” This also applies to the gateway you have to the Internet. To make life simpler for both you trying to reach the outside world and the people trying to get in, it is a good idea to have the Internet gateway also the primary name server for your entire domain.

If your organization is large, then having the Internet gateway a name server for your entire organization would be difficult to manage. Since you already decided to break your network down by department, then each department should have its own name server. One thing you could do is set up the domain name server as a secondary for the sub-domains. This is easy to set up (as we described above) and saves you from having to maintain a list of every machine within your organization.