Originally Published: Tuesday, 5 December 2000 Author: Chris Campbell
Published to: enhance_articles_sysadmin/Sysadmin Page: 1/1 - [Printable]

Linux and Windows NT 4.0 Part VIII: Domain Name Servers

It slices, it dices, it's the step between having an IP address like and a cool name like Linux.com! It's called DNS, a distributed internet domain name service that resolves names to numbers. Chris Campbell, Project Manager of Linux.com's Sysadmin section, shows you how to migrate your Windows NT DNS to Linux.

   Page 1 of 1  

A Domain Name Server resolves URLs (Universal Resource Locator) to IP addresses. A request for http://www.cnn.com, for instance would be forwarded to the local DNS server that would translate the text-based URL to the IP address, and then route the http request to that location. This service is necessary in Internet communications, or users would be required to specify IP addresses all of the time.

The hosts file:

For local name resolution it is possible to use a hosts file; this is a text file with simply the machine name and IP address that matches it. This file exists in both Windows NT and Linux, and can be useful for local network resolution where Internet access is not an issue; or in a mixed NT and Linux mode where no WINS or DNS servers are used. The file in Windows NT is:

and in Linux:
The NT version of the file is relatively limited in scope. Its Linux cousin, however allows for the definition of many variables, shown in this snippet of a hosts file:
host = mail
ip =
aliases = www ftp
mx = 5 mail
ether = 02:16:7D;C3:27
os = "Mandrake 7.1"
This type of resolution is fine in a pinch, but is more or less useless with Internet connectivity. Here, a true DNS Server is needed.

The Microsoft DNS Server:

Although Microsoft included DNS server with Windows NT 4.0, it wasn't emphasized for name resolutions. Specifically, Microsoft pushed using its own WINS (Windows Internet Naming Service) for this task and at a time before dynamic DNS, WINS may have seemed less of an administrative hassle. Modern DNS and BIND (available at this point for both Windows NT and Linux) allows for dynamic updating.

Windows 2000's much hyped ADS is based on DNS and updates DNS records dynamically also, but it does not play friendly with others. It prefers to be the primary DNS, and requires specific conditions placed upon a primary if it is not. This can be a negative factor with existing installations where unix-like operating systems are used for Internet related functions including DNS.

On Windows NT, to add DNS Services:

Click the "SERVICES" tab. Click "Add". Select "Microsoft DNS Server" from the generated list.

After copying files, the installation will continue and reboot. After the reboot, go to:

Next, go to "DNS" and then "New Server". A window will open asking for the IP address. Put the TCP/IP address of the local machine in here, or if you're just following, you may put in the local loopback address ( Once the new server has been created in the DNS manager, go to the local server, then cache. Here you will "arpa" and "NET". Right click on "Cache" and then go to "New Domain".

Enter the name of your domain. Be sure to put just the domain name, such as foo.com. After the new domain has been created, hosts and records can be created by right clicking on the new domain and clicking "New Host" or "New Record".


A host is an domain name to IP translation for a single IP address. For instance, let's say that our domain is foo.com. We have three different machines in my domain:
Each server is for a different section of our company, foo.com, and they serve all sorts of different things on them. is sales, is development and is management. So we want to give them each a hostname within the domain. We right click on the newly created foo.com domain and we click "New Host".

A box opens and we type Sales where it asks for "Host Name" and then where it asks for "Host IP Address." We then Click "Done" and the DNS manager creates an "A" record under our domain for the host. We repeat the motions with for development and with for management.

Now, if we are using this DNS server for our resolution, we can type, for example:

and the DNS server will look up the name and return the IP address that we registered:

Records are used to indicate more specialized functions within the domain. These records are of numerous types. Most commonly you will see things such as MX records for mail exchange and NS records for Name Servers. {Note that Primary Name Servers for your local domain will require to have a SOA (Start of Authority) record made for them to indicate their role.}

Returning to the previous example, let's say that our name server and mail server is on another machine, After adding in the host name (mail.foo.com), as in the previous example, we need the DNS to be able to tell incoming mail where to go, so we want to add the records for our box. We right click on the foo.com domain and we click "New Record".

A box opens and we select the "NS Record" Record Type. Now, type mail where it asks for "DNS Name". We then click "Done" and the DNS manager creates an NS record under our domain for the host.

Next, right click on the foo.com domain and we click "New Record". A box opens and we select the Record Type of "MX Record". Here we are asked for "Host Name" (Optional) and "DNS Name". We would specify Mail for both. There is also a field for preference. We will type "1" here; this specifies the mail server priority in case there are multiple mail servers in the domain.

Records can do varied other functions too. Let's say that we want the management server ( known also as:

We can add a record for the host with the type of CNAME (Canonical Name). This will prompt us for an alias name and we tell it to use "administration". In the field that asks for the DNS name, we specify "Management". Now both:
will both resolve to:
Other types of records include SOA (as noted above) for indicating authority for the zone data, PTR (Pointer Records, the optional checkbox when we created the records) this simply does Address to name mapping, in addition to the name to address mapping as we had set up. For proper understanding of DNS and BIND, it is necessary to understand the hierarchical layout of the Internet domain system. Unfortunately that is much more in depth than this article intends to go. I strongly suggest that anyone intending to continually support a production DNS server on Linux obtain a copy of "DNS and BIND" by Paul Albitz & Cricket Liu (O'Reilly books). It's a fantastic book, an excellent read, especially for a technical book. Incidentally, if this article fails to sway current NT administrators to using Linux for DNS, there is still a wonderful NT resource for DNS: "DNS for WIndows NT", also written by Albitz and Liu. (O'Reilly)

DNS & BIND in Linux:

Most likely DNS services in the form of BIND (Berkeley Internet Name Daemon) has been included with your Linux distribution. If for some reason though, it is not, it is easily enough downloaded from:

There are several key files needed for BIND, starting with /etc/named.conf (Note that for this article we are using BIND Version 8, earlier version of BIND, such as BIND Version 4, refer to /etc/named.boot). Here is an example of our named.conf file for our hypothetical company, foo.com:
options {
directory "/var/named";
// query-source address * port 53;
// named(8) boot file for foo.com
// directory where cache files are stored
// type domain source (ip/file) backup file
zone "." {
type hint;
file "root.cache";
// domains for which we are the primary DNS server
zone "foo.com" {
type master;
file "db.foo.com";
zone "bar.com" {
type master;
file "db.bar.com";
Here, you can see that we have declared this server the Primary DNS for the foo.com domain and the bar.com domain. Additional domains can be added to the bottom, keeping consistent syntax as the first two. (Declaring separate zone files.) Note also that the root DNS information is declared here also in root.cache; This file contains the routing information for the higher level domains; this information file can also be called named.root or db.cache; This file must be retrieved from the internic:
The file will be named.root and will be located under the 'domain' directory. After downloading this file, either change the root.cache entry in named.conf or rename the named.root file to root.cache. (a quick cat of this file will show all of the Internet root name servers.)

Now we move on to the zone files that we declared in named.conf. First, we will start with the file db.foo.com:

; Domains defined in this file:
; foo.com.
$ORIGIN foo.com.
@ IN SOA mail.foo.com (
199907303 ; serial
28800 ; refresh
7200 ; retry
604800 ; expire
86400 ; minimum
IN NS mail.foo.com
IN MX mail.foo.com
localhost IN A
mail IN A
sales IN A
development IN A
management IN A
administration IN CNAME management
www IN CNAME mail
ftp IN CNAME mail
staff IN CNAME mail
www2 IN CNAME mail
In the above zone file, we have set up the same rules as defined in the Windows NT example. Here we have entered the DNS information manually; there are other options to doing this, including GUI based packages and scripts that create these configuration files dynamically.


There are several tools than can be used for configuration file creation. One such is Hosts to Name Server (H2N) from the aforementioned "DNS & BIND" O'Reilly tome. There is another close relative of H2N that is available here:

This script takes manually entered information from the hosts file in Linux and creates the needed configuration files for the name server daemon. (Additional options will need to be defined. Be sure to read the DNSTool information before attempting use.) This method of importing is probably reassuringly familiar to administrators of HP/UX and other unices where this is a standard way of inputting the DNS data.

Regardless of using DNStool, H2N, or just creating the configuration files manually, the final step of the process is to restart the Named daemon. This can be done by simply executing:

(As covered multiple times before in the series, you can tell named to reread the configuration file (named.conf) by sending it a SIGHUP signal with "kill -HUP " also. )

This would also need to be set as a service to start at boot time. The process is covered in depth in previous articles involving other Internet services such as www and alike. In all probability though, the BIND services would be installed with the installation of the OS. It would strongly be advised that a new DNS server be a fresh installation in any case.

Additional DNSTool Information:

In both the Windows NT environment and Linux, it is possible to test the functionality of the local DNS server with the use of the NSLookup utility. (Note that both NT and Linux servers will have to be set to look to this new DNS as the primary DNS Server.)

At command line, in either environment, type

nslookup {machinename.domainname}
If the DNS server is functional, then the IP and domain information will be returned in response; if not, then the response will be that it can not find the machine name or that it is a nonexistent domain. (In Linux, if you create the file /etc/resolv.conf, and add:
domain {domainname}
then nslookup will use the local domain name if only the machine name is specified.)

One final thing to watch out for; in Linux, even if you have indicated the local machine as the DNS server for the network, it is also important that you set the machine to look to the DNS for name resolution. This setting is located in /etc/nsswitch.conf

If you are running DNS now, you may consider setting DNS first for other settings. For just testing the DNS server, confirm the following line in /etc/nsswitch.conf:

hosts: dns files nis
Resolution will be attempted on order from left to right. If files were the first on the left, then the local machine would attempt name resolution via /etc/hosts. By placing DNS first, we set the machine to check our designated server first. This is also very useful to remember in environments with DHCP; it is a common mistake to assume that just because all of the information is being pushed down, that no additional adjustment needs to be done. Often this configuration file has been overlooked, which results in confusion and frustration for the person attempting to configure the machine.

Chris Campbell is a .conf-file editing, registry-cleanin' machine. He can be E-mailed at soup@linux.com.

   Page 1 of 1