Is managing the host name and IP address information on your network getting to be a hassle? We explain configuring the Domain Name Service (DNS) in plain English.
Some of us are old enough to remember a day when the Internet existed only as a Department of Defense research project called the Arpanet. Back then there were few enough hosts on the Net that they could all be listed in text files stored on each Internet-connected host. The /etc/hosts file on Unix systems originally served that purpose — it contained a list of the names of all the computers on the Net, and associated those human readable names with their machine readable IP (Internet Protocol) addresses. So when a human typed in any computer’s name, that computer’s matching IP address could be instantly looked up in /etc/hosts.
Nowadays, this sort of system would be totally unmanageable due to the huge number of hosts and domains on the Internet, where it’s estimated that more than 50,000 new domain names are registered each day. The Domain Name Service (DNS, also often referred to as the Domain Name System) was created to help solve this problem. DNS is essentially a huge conga line of servers (called name servers) snaking through the Internet. For any computer connected to the Net, a given DNS server can provide you with that computer’s host name and IP address information itself, or the server knows how to find other name servers that will have that information.
So DNS does a tremendous amount to simplify domain name management on a global scale. More recently, DNS has become relevant to many more users as they gain access to high-speed network connections via cable modems and DSL. If you’re one of those users and you’re thinking about building a home network or a small office LAN to take advantage of that fast network connection, then you’ve just become an “instant system administrator”, and you’ll need to work with DNS.
Finally, even Windows administrators are finally being forced into understanding DNS because Windows 2000 relies on DNS (with some inevitable “extensions” from the boys in Redmond). See Windows Tries to Learn the DNS Dance sidebar for more information.
Whatever group you fall into, having a working understanding of DNS is crucial. Luckily, it’s also pretty straightforward. Creating the files used by DNS, starting one or more DNS servers, and configuring how, when, and if your systems use DNS is easy, especially under Linux.
In this story we give a general overview of the DNS system, how it’s implemented on Linux, and how to configure it. We describe the files that hold the configuration information and host database and where they’re located. Sample configuration files are also included to get you started with your own DNS setup.
DNS allows computers on a network to access other computers using human-readable names. In a nutshell, DNS servers translate the “names” we all know on the Internet into the IP addresses that computers actually use to communicate. All of the hosts on your network can query one or more local DNS servers for local host name and IP address information. Requests for host name and IP address information outside the administrative domain of your DNS servers are automatically passed up the DNS food chain until some DNS server can provide the requested information.
Each domain on the Internet must have at least two name servers, for redundancy. It’s best if these servers are placed on different networks so the domain can still be found even if one network is not functioning. These two servers are referred to as the “primary” and “secondary” name servers. A domain can have more than two servers if desired…the more the merrier.
These servers are called “authoritative” servers for the domain, meaning they are the source (authority) for “name” information on those networks. A “non-authoritative” DNS server is one that has cached the information for a domain. So if you ask your ISP’s name server for the address for whitehouse.gov, it can give you a non-authoritative response. But if you want to be sure you have the most up to date host information for the domain, you would need to go to the authoritative server.
At the top of this food chain are a bunch of servers that are called the Internet “root” name servers (as in the “root” of the whole system). The root name servers will send a request for name information to a primary name server first, since a primary server should contain the master name table for that domain. Primaries are configured as domain “master” servers. Any secondary servers may be configured as “slave” servers. The slaves automatically check for updates on the master server, so that administrators only need to maintain one host database.
So how does DNS work its magic? Say you want to check out the Linux Magazine Web site. Well, you fire up Netscape and enter the address http://www.linux-mag.com. In a typical configuration, your computer first checks the local /etc/hosts file to see if that server name is listed. If not, then it tries to find out the proper address by using DNS.
Your computer now looks at your network’s local DNS server list (typically provided by your ISP) and sends its request to the first server on that list. That name server checks its local database to see if it has the IP information for www.linuxmagazine. com cached. If it doesn’t, it then passes the request up the DNS chain to one of the root name servers on the Internet.
That server knows the authoritative DNS servers for every domain on the Internet, and passes the request off to the primary DNS for the linuxmagazine.com domain (ns2.via.net). That server DOES have the IP address (209. 81.9.15) and returns that information to your computer. At last, Netscape can send its request directly to linuxmagazine.com using it’s IP address.
The name server software used on the vast majority of name servers on the Internet is Berkeley Internet Name Domain (BIND). This is the software that comes preinstalled with most Linux distributions. It includes the name server (named), a library for those who wish to add DNS capabilities to software they develop, and DNS client tools such as nslookup and nsupdate.
RELATIVES OF DNS
Before diving into an explanation of what makes DNS tick, it’s worth pointing out that there are other systems that were designed to tackle the problem of associating host names with numeric addresses on a network, and many of them are still in use.
In the beginning, there were /etc/ hosts files located on each system, and that was okay. However, when an internal network grows quickly, the time required to maintain identical /etc/ hosts files on all of your systems quickly becomes a major pain, so other methods of keeping track of who’s who were invented.
Sun Microsystems invented a network-oriented file sharing solution it named Network Information Service, or NIS. NIS eventually grew up and spawned a successor, NIS+. NIS and NIS+ work by storing central versions of critical files (such as /etc/passwd, /etc/group, /etc/shadow, and /etc/ hosts) on an NIS or NIS+ server. Those files are then provided to that server’s client systems as requested. The problem with NIS and NIS+ is that they aren’t always suitable or usable because they don’t always play well together with all types of computer systems.
How to Set Up DNS Quickly
Step 1. Create the /etc/named.conf file and decide in what directory to put the other files used by DNS.
Step 2. Create that directory and the files referenced in /etc/named.conf. Get an updated named.ca from the source indicated in the article.
Step 3. Modify /etc/resolv.conf to set your default domain to your own domain and to point to the IP addresses of your and other name servers.
Step 4. Start the named by typing /etc/rc.d/init.d/named restart and resolve any typographical errors in your configuration files.
Step 5. Modify /etc/nsswitch.conf to use DNS first for host name lookups.
Step 6. Create the symbolic links to automatically start and shut down DNS as indicated in the article.
LINUX DNS FILES AND THEIR CONTENTS
The configuration information for the named name server is contained in a number of different files. These files include nsswitch.conf, resolv.conf, named.conf, named.ca, and named. local, as well as the domain-specific files vonhagen.org, and 6.168.192.in-addr.arpa. We describe what each does and give example configurations for each below.
The Name Service Switch Configuration File
As we mentioned earlier, DNS is only one possible system for mapping names to network addresses. Other methods include /etc/hosts files, NIS and NIS+. The file /etc/nsswitch.conf defines the order in which those methods should be attempted. Here’s how the entry for host information in the /etc/nsswitch.conf file looks on my system:
hosts: files dns [NOTFOUND=return] nisplus nis
So what does this entry mean? It tells any program wishing to map a name to a number to first check the /etc/hosts file (files). If that doesn’t work, then try using DNS (dns), and if a host is not found using either of these mechanisms, then give up ([NOTFOUND=return]). Any method listed after the [NOTFOUND= return] will not be used. I don’t want programs to try using nisplus or nis since I don’t run those on my systems.
The resolv.conf Configuration File
Whether or not it is running a name server, if your Linux box uses other name servers, it needs to know where to find them. This is where the /etc/ resolv.conf file comes in. It contains a listing of the name servers that the machine should use to look up addresses (usually provided by your ISP), as well as which domain names to search for hosts in if the request does not include a domain.
A typical /etc/resolv.conf file looks like this:
The lines in this file are pretty self-explanatory. The first line defines the search domain (vonhagen.org) and the next two lines define which name servers should be used to look up IP addresses.
The named Configuration File
Figure One: Sample Section of named
Name serving on Red Hat Linux systems is done by a program called named, which is part of the Berkeley Internet Name Domain package for Unix/Linux systems. The name daemon (named) uses the configuration file /etc/named.conf to identify the files that it should use to populate the local name service database. Take a look at Figure One for a sample section of this file from my system.
Let’s examine the contents of this sample more closely:
options — Identifies the directory where the files for the local DNS server are found (/var/named).
zone — Identifies each area of responsibility that the DNS server knows about and the files associated with that area. These files are located in the directory defined by the directory option. These zone files are defined in my configuration:
The file named.ca is a local cache of the highest-level DNS servers on the Internet (the so-called root name servers).
The file vonhagen.org is the master host file for the vonhagen.org domain. A name server can handle many domains, but mine is configured to host only one.
The file 6.168.192.in-addr.arpa allows the server to look up names by number, instead of looking up numbers by name. This is called “reverse lookup.”
The file named.local contains authoritative information for any hosts that you can access through the current host’s loopback network interface. It normally contains just one host entry, localhost.
DNS Name Lookup Files
Now it’s time to really getting into the guts of the named configuration files. The following defines the file formats for the zone files that control how the name server looks up information for the various domains.
A DNS name lookup file consists of three parts:
Header information in a Start Of Authority (SOA) record, identifying the domain the DNS server is providing authoritative information for, the person responsible for that domain, and a variety of parameters that are used to define when and for how long information from that DNS server can be used.
Basic information about the domain in NS and MX records, which respectively list the Name Server and Mail eXchanger for that domain.
The DNS entries (name/address pairings) themselves.
Figure Two: Sample Section of DNS File
vonhagen.org. IN SOA gateway.vonhagen.org. wvh.gethip.com. (
vonhagen.org NS gateway.vonhagen.org. ;
vonhagen.org. MX 10 gateway.vonhagen.org. ;
gateway.vonhagen.org. A 192.168.6.61 ;
gateway.vonhagen.org. HINFO “PC” “Linux” ;
corel.vonhagen.org. A 192.168.6.21 ;
corel.vonhagen.org. HINFO “PC” “Linux” ;
laptop.vonhagen.org. A 192.168.6.62 ;
laptop.vonhagen.org. HINFO “PC” “Linux” ;
twoproc.vonhagen.org. A 192.168.6.66 ;
twoproc.vonhagen.org. HINFO “PC” “Linux” ;
g4.vonhagen.org. A 192.168.6.90 ;
g4.vonhagen.org. HINFO “PPC Mac” “MacOS9u4″ ;
Figure Two shows a sample section of the DNS file for my domain, vonhagen.org.
The first line in Figure Two is the (SOA) record for my DNS server. It is qualified as being an IN (Internet) record. Other types of records exist, but they are not widely used. gateway. vonhagen.org is the name of the name server itself, and wvh.gethip. com is the e-mail address of the person responsible for this domain (you need to replace the first ‘.’ with an ‘@’ sign).
The numbers in the parentheses exist for the benefit of any secondary servers that are acting as slaves to the primary. The first number is the serial number for this version of my DNS file. This must be unique and increasing each time the file is changed. Typically, this serial number is made from the date when the file was last updated, along with a two-digit number added to the end in case you update the file more than once per day.
The remainder of the values in an SOA record are all expressed in seconds. The refresh rate is how often hosts re-query name server for information about the SOA record. The retry value is the number of seconds a remote host will wait if it can’t get authoritative information about a host in your domain. The expire time is how long a secondary name server will cache information about a host in your domain before asking for updated values. Finally, minimum is the default period of time that answers from this name server are used before new values will be asked for.
The NS record defines my domain’s name server. Its IP address must be present both in this file and in the reverse IP address mapping file.
The MX record defines the Mail eXchanger for my domain, which is the primary system that can send and receive mail for the users in my domain as well as, most importantly, the administrator responsible for the domain who was identified in the SOA record.
The MX record takes one additional parameter, a numeric value, which is the priority associated with that MX host. If you have multiple MX records, they’ll be tried in ascending numerical order until one of them accepts e-mail.
Each host entry in the DNS file consists of at most two parts — an address record (A) that provides the IP address of that host, and an optional host information (HINFO) record that provides additional information about that host.
Figure Three: DNS Entry for corel.vonhagen.org
corel.vonhagen.org. A 192.168.6.21 ;
corel.vonhagen.org. HINFO “PC” “Linux” ;
Figure Three is an extract from the file shown in Figure Two. This entry is for a host named corel.vonhagen. org at IP address 192.168.6.21, which is a PC running Corel Linux.
All of these are actually also IN records, but since that happens to be the default record type, you can leave off the IN record type designation.
Contents of a Reverse Name Lookup File
The reverse name lookup file can be a confusing beast at first, but once you understand what it does, things become much clearer. Again, the whole purpose of the name server is to convert human-readable names into the real IP addresses that computers need to be able to communicate.
There are also many situations where a program needs to look up the name associated with a particular IP address. For instance, when someone comes to your Web site, his IP address is recorded in your server logs. Reverse DNS allows you to look up the host name associated with that address, since the IP address really isn’t very useful all by itself. Security and authentication are other areas where reverse lookups can be important.
Since this is a reverse lookup file, it contains information that appears in reverse order. For instance, IP addresses are listed “backwards” from the normal format that we are used to. So corel. vonhagen.org (192.168.6.21) is listed in the reverse lookup file as 184.108.40.206.
Once you’ve created the DNS file for your domain, you also have to create an associated reverse IP mapping file that maps IP addresses back to host names. Figure Four shows a sample section of this file.
Figure Four: Sample Section of a Reverse Lookup File
6.168.192.in-addr.arpa. NS gateway.vonhagen.org. ;
220.127.116.11.in-addr.arpa. PTR corel.vonhagen.org. ;
18.104.22.168.in-addr.arpa. PTR gateway.vonhagen.org. ;
22.214.171.124.in-addr.arpa. PTR laptop.vonhagen.org. ;
126.96.36.199.in-addr.arpa. PTR twoproc.vonhagen.org. ;
188.8.131.52.in-addr.arpa. PTR g4.vonhagen.org :
Like the sample DNS lookup file shown in Figure Two, this file begins with a Start of Address (SOA) record that is an IN record. And also like the sample in Figure Two, all of the other entries in this file are IN records too, but since that is the default record type, you can again safely leave off the IN record type designation.
After the SOA record which identifies the Name Server (NS record) for your domain, subsequent records in this file are all Pointer (PTR) records that point to entries in the host name file.
Getting a named.ca File
Getting a copy of the file that defines the root name servers on the Internet is easy. The best way to get this file is to ftp to ftp.rs.internic.net, cd to the domain directory, and retrieve the file named.ca. This file is not updated very often, so this is not something you’ll need to do on a regular basis. In fact, the current named.ca was last updated on May 22nd 1999.
CREATING DNS FILES USING LINUXCONF
|Figure Five: Configuring a new DNS domain in Red Hat’s linuxconf.|
In Red Hat Linux and other Red Hat-based distributions such as Mandrake, you can most easily create DNS files using the linuxconf administration utility. Figure Five shows the DNS portion of linuxconf’s “Server tasks” screen, in linuxconf’s “Config” section.
In order to add hosts to a DNS domain, you must first create a domain and the entries in the Start of Address record. See the sections of this article on “Linux DNS Files and Their Contents” for more information. You then define the system that will be the name server for that domain and also the system that handles mail for that domain.
Once you’ve defined these “global” values, you can then begin adding hosts to the name server using screens such as linuxconf’s “Add/Edit host information” panel, shown in Figure Five.
EXPANDING DNS FILES USING A TEXT EDITOR
|Figure Six: Adding hosts to a DNS domain in Red Hat’s linuxconfig.|
As previously explained in the Creating DNS Files Using a Text Editor sidebar (pg. 72), the linuxconf administrative tool is specific to Red Hat and Red Hat-based Linux distributions. So what do you do if you are running some other Linux distribution? Most Linux distributions have their own administrative tools, but the one true lowest common denominator is to use a text editor to create the files.
|Figure Seven: Emacs displaying DNS name lookup and reverse IP address files.|
As shown in Figure Seven, you can use emacs to create a basic template for your DNS file and then augment it by cutting and pasting appropriate entries for the hosts in your domain to the host name and reverse IP address mapping files.
ADDING DNS TO YOUR STARTUP & SHUTDOWN PROCEDURES
To start DNS on Red Hat Linux systems manually, execute the following:
Remember that named is the name of the program that manages DNS on Red Hat Linux systems. The command shown shuts down any named process that is currently running and then starts a new named process using all of the current configuration files.
On Red Hat Linux systems, symbolic links to the file /etc/rc.d/init.d/ named with the name S47named should exist in the directories /etc/rc.d/rc2.d and /etc/rc.d/rc3.d. These symbolic links will start up the DNS server for run levels 2 and 3.
On Red Hat Linux systems, symbolic links to the file /etc/rc.d/init.d/ named with the name K45named should exist in the directories /etc/rc.d/rc0.d, /etc/rc.d/rc1.d, and /etc/rc.d/rc2.d. These symbolic links will shut down the DNS server when passing through run levels 0, 1, and 2.
As a single point where you can define host names and associated IP addresses, DNS provides an attractive way to store and manage that information. Once you’ve gotten DNS up and running, you’ll never want to use anything else. Other sources of host name and IP address information, such as /etc/hosts files may still be useful, but having a single, central location to store, update, and query your host information is a true win for you as an administrator and for your users.
DNS is nothing more than an application (named) using a bunch of files that work together to specify the information provided by a specific DNS server. Study the examples provided in this article carefully. Once you see how these files fit and work together, you too can be a DNS wizard. As you become more familiar with DNS, you’ll find it has additional capabilities and record types. These are not discussed in this article because its goal is to get you up and running with DNS as quickly as possible.
You will find most problems in DNS configuration files are the result of typos. But even if you encounter difficulties, online reference and guide information is only a hyperlink away. You can start with the resources found in the Web Links/For More Information sidebar (pg. 70).
Windows tries to learn the DNS dance
Microsoft Windows has always had a clumsy relationship with DNS, improving over time and culminating in the wholesale acceptance of DNS in Windows 2000 and newer versions of Windows NT.
Windows 3.11 and Windows for Workgroups were the first versions of Windows to provide integrated network support. They did so by adding “Windowized” versions of the /etc/hosts file (known as \windows\hosts) and DNS (known as WINS — the Windows Internet Naming Service). But WINS clearly shows the dark roots of its blonde hair with respect to its heritage as a Local Area Network (LAN) based networking technology.
The original Microsoft networking protocols were called NetBIOS (Network Basic Input Output System) and NetBEUI (Network BIOS Extended User Interface), and they were inherently designed for use only on LANs. Computers and resources on a network based on NetBIOS or NetBEUI did not use globally unique numbers to communicate, they just used names. This assumes that a network administrator is regulating the namespace of the network, but this approach just doesn’t work when the network namespace in question is the Internet.
When Microsoft realized that Windows machines were going to have to talk to the Internet, they came up with WINS, which is based upon NetBIOS and NetBEUI, but allows those protocols to map names to IP addresses.
The designers of DNS did not need to worry about such legacy issues. DNS evolved as part of a Wide Area Network (WAN) research project to create a manageable Internet using more powerful networking protocols such as TCP/IP, and was built from square one with global scalability in mind.
Nonetheless, integrating Unix/Linux DNS with the versions of DNS used in Win2K and newer versions of Windows NT definitely requires a certain amount of massaging. See the Web Links at the end of this article for specific information about Windows/Linux DNS integration.
Creating DNS Files Using a Text Editor
Graphical system administration tools such as Red Hat’s linuxconf are specific to Red Hat-based installations such as Red Hat and Mandrake. An easy, distribution-independent way of creating DNS files regardless of the Linux distribution you’re using is to create them in your favorite text editor. If your favorite text editor supports displaying different files in different buffers (as vim and emacs do), all the better, because you can cut and paste much of the information between your DNS name lookup file and the reverse IP address mapping file (though you’ll have to reverse it, of course). Creating DNS files in a text editor also provides an easy way to synchronize your Start of Address (SOA) information between these files.
Bill von Hagen is the President of Move2Linux.com. He is reachable at firstname.lastname@example.org.