DNS Server

The first order of business for Sam was to define a proper TCP/IP domain for the Intranet.

The hobbits of the company assigned IP addresses to their machines according to their whim and availability of the chosen address. The only saving grace here was that by convention, all the IP addresses had the form “192.168.1.x”. Since IP addresses were too cumbersome to use to refer to machines, each hobbit's machine had a “/etc/hosts” file populated according to his needs, and sooner than later, containing incorrect entries as the IP addresses changed for some servers. And of course, everyone had a different idea of what domain name the machines belonged to: some configured their machines to belong to the hobbiton.hobbitware.com domain, while others configured local.hobbitware.com as their domain, and so on.

Sam pretty much decreed that thenceforth all the internal machines shall belong to the “internal.hobbitware.com” domain. All the machines were configured to use the Intranet server (which was assigned the IP address 192.168.1.1) for host name lookups (DNS Server) and the “/etc/hosts” files were banished. Everyone had to get their machine name registered with Sam and get an IP address, which Sam configured into the server.

Setup

For setting up the server, Sam was helped immensely by the excellent Linux DNS-HowTo. He installed the bind server that came with his Linux distribution. (He could have also compiled it himself using the sources he could find at this place, but there really was no point to it.) Sam still swears by the DNS-HowTo and recommends that everyone read it before attempting to configure a DNS server.

First Sam had to get the list of all the “root servers” in the DNS hierarchy - the “know-all” servers that knew how to contact the next level DNS servers. He just ran the command

to get this list in the proper format. (Of course he had to use the ISP's DNS server to get to this root server in the first place.) He saved this “root.hints” file in the /var/named folder, where he planned to keep all his zone configuration. And he made a note to himself to update this file periodically (even though it didn't change much over time).

Next, Sam needed to tell the DNS server bind where to look for the domain configuration information. Now bind looks in the file “/etc/named.conf” for configuration information, so Sam went about creating this file using his favourite text editor. His configuration file looked something like this:

options {
directory "/var/named";
forward first;
forwarders {
202.54.1.30;
202.54.12.17;
};
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "zone/127.0.0";
};
zone "internal.hobbitware.com" {
notify no;
type master;
file "zone/internal.hobbitware.com";
};
zone "1.168.192.in-addr.arpa" {
notify no;
type master;
file "zone/192.168.1";
};

Sam told bind to look for all the other files relative to the “/var/named” folder. He instructed it to first forward all non-local host name lookups to his ISP's DNS servers (202.54.1.30 and 202.54.12.17), and attempt to resolve the name itself only if these servers fail. As a typical complete DNS entry lookup takes several steps, it would have been unwise to carry it out on the slower link between the company and the ISP, as opposed to the much fatter link between the ISP itself and the Internet.

The server automatically caches all name lookups, so he didn't have to specify it explicitly. This caching tremendously helps extraneous name lookups over the slow Internet link as most hobbits used to go to the same sites.

The interesting entries were those for the zones “internal.hobbitware.com” and for “1.168.192.in-addr.arpa” - for both these zones, this server was going to be the “master” server (or the authoritative source), and the zone configuration files specified contained the respective zone data. The former zone helped resolve host names to IP addresses and the latter for reverse lookups (IP addresses to host names). This in effect was all Sam needed to define his own little internal domain.

Zones Configuration

Sam now created the folder “/var/named/zone”. Here he placed three files named “127.0.0”, “internal.hobbitware.com” and “192.168.1”. The first file merely contained the following:

@   IN  SOA dns.internal.hobbitware.com. root.dns.internal.hobbitware.com. (
1   ; Serial Number
8H  ; Refresh Interval
2H  ; Retry Period
1W  ; Entry Expiry Period
1D) ; Minimum Time-to-live
;
NS  dns.internal.hobbitware.com.
;
1       PTR localhost.

This was of course as dictated by the DNS-HowTo. It was merely a fancy way of resolving “127.0.0.1” to “localhost”.

The next file (“internal.hobbitware.com”) was more interesting and contained something like this:

@   IN  SOA dns.internal.hobbitware.com. root.dns.internal.hobbitware.com. (
1421041401   ; Serial Number
8H  ; Refresh Interval
2H  ; Retry Period
1W  ; Entry Expiry Period
1D) ; Minimum Time-to-live
;
NS  dns     ; Name server for the entire domain
;
MX  10  dns.internal.hobbitware.com     ; Primary Mail Exchanger
;
localhost   A   127.0.0.1
;
www     CNAME   dns
ftp     CNAME   dns
smtp    CNAME   dns
pop     CNAME   dns
proxy   CNAME   dns
news    CNAME   dns
;
dns     A   192.168.1.1
frodo   A   192.168.1.10
merry   A   192.168.1.11
pippin  A   192.168.1.12
sam     A   192.168.1.13
;

Again, in accordance with the guidelines set in the DNS HowTo, this file defined the domain internal.hobbitware.com. It designated this server as the primary DNS as well as the mail server for this domain. It also defined several aliases (“www”, “pop”, etc.) to this server so that one could access this server as www.internal.hobbitware.com or as pop.internal.hobbitware.com, etc. After that were just name to IP address mappings for hosts. As a convention, Sam decided to keep these names in alphabetic order.

Finally the last file (“192.168.1”) contained stuff like this:

@   IN  SOA dns.internal.hobbitware.com. root.dns.internal.hobbitware.com. (
1421041402   ; Serial Number
8H  ; Refresh Interval
2H  ; Retry Period
1W  ; Entry Expiry Period
1D) ; Minimum Time-to-live
;
NS  dns.internal.hobbitware.com.
;
1   PTR dns
10  PTR frodo
11  PTR merry
12  PTR pippin
13  PTR sam
;

This file helped reverse DNS lookups and was quite similar to the previous one. Again as a convention, Sam decided to keep the entries here in numerically sorted (ascending) order.

Server Startup and Shutdown

Sam could very easily manage the DNS server using the ndc command: “ndc start” would stard the DNS server, while “ndc stop” would stop it (duh!). “ndc restart” restarted the DNS server.

Sam added an entry in the server startup scripts so that the DNS server software (bind) would automatically startup as the system booted up. Again, he found all that he needed in the DNS HowTo.

Maintenance

As new machines were added to the company, Sam had to assign a suitable name and an IP address to the machine and then update the last two files listed above in a suitable manner. He could ask the DNS server to update the zone configuration information by just issuing the command “ndc reload”.

Once in a month, Sam updated the “root.hints” file as shown above. He also used to examine the files “/var/adm/messages” and “/var/adm/debug” for diagnostic or error messages, so that he could fix them before they became serious.

Conclusion

After this setup, the company had a much saner environment with respect to machine names and addresses. There was an improvment in surfing time as most of the host names were resolved locally from the DNS cache. Finally, this setup provided the foundation on which Sam could build the other services for the Intranet.

Resources

The following were some of the resources that Sam found immensely useful during the period he set up his DNS server:

1. The Linux DNS-HowTo: A very good and useful document that told Sam everything he wanted to know about the DNS system as well as how to set up a server on his machine.
2. BIND: The DNS server that Sam installed on his machine. He could have downloaded and compiled the sources available here, but he preferred to simply install the binaries available with his distribution.