Apache Server Survival Guide asgxe.htm

• DNS: the Domain Name System
• What Is DNS?
  • Top-Level Domain Designations in the United States
  • Geographical Domain Designations
• How named Works
• Running Your Own Domain Name Server
• DNS Configuration Files
  • Reverse Lookups: IP to Hostname, the IN-ADDR.ARPA Domain
  • SOA Record
  • NS Records
  • Address and Alias Records
• The db.IP File
  • PTR Records
  • The Loopback Interface
  • The named.root File
  • The /etc/named.boot File
• Starting named
• Testing Your Name Server
• Configuring a Secondary Name Server
• Configuring Hosts in Your Network to Use the Name Server
• Summary

E

DNS and BIND Primer

The Internet is a vast collection of networks. Before a computer can talk to another, it needs an address. This address typically takes the form of a name because names are easier for people to remember. Computers, on the other hand, prefer numbers.

Without the Domain Name System (DNS), your computer would need to have a huge address book of names and addresses that included every computer on the Internet. If you wanted to send e-mail to a user at host.foo.com, the system would have to figure out that you wanted to talk to the machine at address 1.2.3.4 and do its thing.

This approach has several problems, including the following:

• Your address book would always have to be up-to-date. An old address book would not have entries that were recently added; or worse, if a host changed addresses, you would no longer be able to communicate with that host.
  
  
• Your address book would have to include every address for every system that you wanted to communicate with.
  
  
• No two hosts could share the same name.
  
  

What a mess! Believe it or not, this was the way that it was until 1984. A large host table (HOSTS.TXT) was maintained in one server at the Stanford Research Institute Network Information Center (the NIC). With more and more networks going online, it became almost impossible to keep the host list up-to-date. Before the list would be downloaded by all hosts, someone would have introduced a change that would require downloading yet another new list!

Vestiges of this address book are still used by your system to look up hosts in your local network— the /etc/hosts file.

DNS: the Domain Name System

A new system developed by Paul Mockapetris of USC's Information Sciences Institute was proposed as a replacement for HOSTS.TXT. Mockapetris's system addressed the network-load and consistency problems that the infamous HOSTS.TXT system had. Mockapetris's system boasted the following capabilities:

1. The elimination of the single repository for host information would eliminate network traffic problems caused by network administrators downloading an updated version of the HOSTS.TXT file.
   
   
2. It would also introduce a name-based domain system, where each domain would have its own internal context; thus allowing for hosts in different domains to have the same name.
   
   
3. And most importantly, it would allow for delegation of host information management. The responsibility for managing each network and each network's subdomain was handed to the local administrator for the zone in question, which made the task of keeping information up-to-date much more manageable. Local host information could be made available globally through the client/server nature of the system, insuring that each request was answered with reliable data from an authoritative source.
   
   

The original DNS system was described in the 1983 Request for Comment (RFC) documents 882 and 883. Both have been updated and superseded in 1987 by RFCs 1034 and 1035, and again in 1990 by RFCs 1101 and 1183, which implement the current specification of the DNS. In software, DNS is implemented on UNIX systems as the Berkeley Internet Name Domain (BIND) system. BIND is shipped in almost every UNIX box.

The current BIND release is composed of several programs including: named, named-xfer, named.restart, named.reload, ndc, nslookup, and the resolver libraries. The resolver libraries provide routines for programs to query DNS name servers, so you can design programs that make use of the DNS. Here's a list of the entire distribution and what each does:

dig	A domain information groper; a command line tool that can be used to gather information from a DNS server. It has zillions of options.
dnsquery	A program that uses the BIND resolver library calls to query name servers.
host	A program that does reverse DNS lookups. Instead of specifying a hostname to find its IP address, you supply the IP, and host returns the hostname.
named-xfer	A tool for doing zone transfers. Usually this program is called by other software. It can also be used to debug a zone transfer problem. But more than likely you won't use it at all.
named	The Internet domain name server daemon, and the focus of my attention in this appendix.
named.reload	A convenience program to restart the named daemon and force the server to reload and update its database files, if necessary. This program uses a hangup (SIGHUP) signal.
named.restart	A convenience program to restart the named daemon and to force the server to reload and update its database files, if necessary. This program kills the name server by using a kill (SIGKILL) signal and then starts a new server.
ndc	A cool program that allows you to send various signals to the named daemon. This command allows you to monitor the status of the server as well as to force database reloads. It has many other options.

What Is DNS?

DNS is a distributed database. By distributed I mean that no single repository contains complete information regarding other domains. A program called name server is responsible for implementing the server portion of the equation. When a machine is configured to use DNS, client programs making calls to the gethostbyname() and gethostbyaddr() library routines use the resolver library. This library allows them to query a name server across a network instead of looking up information in the /etc/host file.

The structure of the Internet domain system is similar to that of the UNIX file system. There's a root domain and a series of directories called top-level domains. In turn, top-level domains are composed of other subdirectories or subdomains. Each domain or subdomain is separated by a dot (.). Each second-level domain can have up to 26 characters. Subdomain labels can have up to 63 characters in length. The root domain is null, meaning there's no label, and is usually represented by empty quotes (""). Unlike a file path, domain names are written and read from the bottom up:

host.subdomain.domain.topleveldomain

The host label is the name of the machine.

The subdomain label is a subdivision of a domain. Typically subdomains are used to create logical groupings of machines to match some internal organization criteria. Don't be surprised if you ever see more than one subdomain. As a matter of fact, subdomains are common under geographical domain designations.

The domain is the domain name of the organization, usually matching the organization's name, such as IBM, APPLE, and NEXT.

The topleveldomain is a classification of the domain.

Top-Level Domain Designations in the United States

Fig. E.1. The U.S. Top-Level Domains. Domains are shown in ovals. A machine is shown as a box

This statement is actually not the full truth. The original classifications originated before the Internet became an international entity. Given its incredible and unexpected success everywhere, additional classifications emerged—geographical designations.

Geographical Domain Designations

Geographical designations follow the ISO 3166 standard, which establishes a two-letter abbreviation for country names. The only inconsistency is Great Britain, which goes by UK instead of GB. The United States also has a geographical designation, US, which is not yet as widely used as the others. The U.S. geographical domain is supposed to accommodate U.S. state and local government agencies, schools, libraries, museums, and individuals.

Geographical domains are at the same hierarchical level as the standard U.S. domains and are properly registered with the NIC. However, administration of those domains is handled by different organizations in various countries.

The subdomains for the U.S. domain follow postal abbreviation's conventions for the states and territories. Each state can then further subdomain according to an individual city name, locale, plus the hostname.

In addition to the state subdomains, there are two other categories: FED for agencies of the federal government and DNI for Distributed National Institutes or organizations that span state, regional, and other organization boundaries that are national in scope.

Within each state's subdomain there are locality names. These can be cities, counties, or local names. The locality can be a CI for city or CO for county:

hostname.CI.locality.state.US -> pear.CI.CEDARBURG.WI.US

hostname.CO.locality.state.US -> apple.CO.MILWAUKEE.WI.US

A state subdomain, groups the following subdomains:

K12	For public schools. Private schools add the PVT name, schoolname.PVT.K12.state.US.
CC	For community colleges: collegename.CC.state.US.
TEC	For technical colleges: collegename.TEC.state.US.
LIB	For libraries: library.LIB.state.US.
STATE	For state government agencies: agency.STATE.state.US.
GEN	For General Independent Entity. For anything that doesn't fit in the other categories.

Fig. E.2. The U.S domain. Notice that other countries and standard U.S top level domains share the same level.

Table E.1 lists all the top-level domains known at the time of this writing. However, this may be outdated by now. This table is a reflection on the dynamics of our world: New countries are formed, and new countries join the Internet community.

How named Works

named (pronounced name-d) is the BIND name server daemon. This software answers queries about hostnames and IP addresses. When named doesn't know the answer to a query, it asks other servers (typically in the top-level domains) that provide information on how to contact other name servers responsible for the domain in question. named caches this information in case there's a need to find another host near that domain. This allows it to ask a closer name server for the answer in future queries. This effectively skips the top-level name servers from the process and reduces the overall effort required to obtain the new address.

There are three types of name servers:

• Primary
  
  
• Secondary
  
  
• Caching-only
  
  

Name servers are distinguished by the source of their information and if the server providing the information is authoritative for the domain. Authoritative name servers provide information that is "guaranteed" to be correct. While nonauthoritative answers are usually correct, primary and secondary servers for a domain are the only servers authoritative for the information. Caching-only name servers are never authoritative, although they help speed up the process a great deal.

I should qualify the guaranteed qualifier I used in the last paragraph. It is possible for information provided by a secondary name server to be stale. Unless the System Administrator manually updates the secondary servers, it is possible for secondary servers to distribute stale information until their refresh period expires. A refresh period forces secondary name servers to check for changes on the domain database file after the period of time specified by the Administrator managing the domain is complete. Typically this period is no longer than six hours.

If you were wondering about the reliability of cached information, it will satisfy your curiosity to learn that DNS information is usually cached for a little while. Cached information only exists until the Time To Live (TTL) delay expires. The TTL for DNS-cached records is usually set to one day. You should also be aware that the top-level and sometimes second-level domain name servers never cache information. Otherwise, top-level information could be vulnerable to tainted information. Also, because of the amount of information they handle, their caches would quickly grow and bloat, which increases the computational load required to find an answer.

Running Your Own Domain Name Server

Before you proceed, you will need to register your domain name with the InterNIC if your domain falls into any of the ORG, NET, EDU, GOV, and COM domains. If you want to register a U.S. domain, go to http://www.isi.edu/in-notes/usdnr.

Registering your domain involves a few steps:

1. Figure out where in the domain hierarchy your organization falls.
   
   
2. Find a domain name that is not in use by another site in that domain hierarchy.
   
   
3. If you are not on the Internet yet, find someone that will host a temporary name server for you.
   
   
4. Fill out an application.
   
   
5. Wait for the application to be approved.
   
   

Registering your own domain can be a great thing. It establishes your identity in the Internet, and it makes you available to the world. To search for names that have not been taken, you can visit http://rs.internic.net for searches involving ORG, NET, EDU, GOV, and COM domains. To search in the U.S. subdomain, visit http://www.isi.edu/in-notes/usdnr).

Choose the registration services link. Once on that page, choose the Whois registration tool. This page gives you a Web interface to the whois program. The whois program allows you to research domain name information among other things. If you find a match, your name is in use. Some things to keep in mind: domain names cannot be longer than 26 characters and can only contain letters, digits, and dashes.

Once you find a name that is not in use, you can go ahead and complete the World Wide Web application form. You will need to have the address for two name servers that supply information about your domain. The machines you list in the application will be queried for information about your domain, so you need to make sure that they are reachable or if your network is not up, that someone runs DNS for you temporarily. Usually your service provider can help with this. If the name servers are not found during the verification process, your application will be delayed.

Once you complete the online form, a copy of the application will be mailed to you. Please note that the application you filled online is not processed. To process the request you need to e-mail the form back to domreg@internic.net.

A small charge is associated with registering a domain name. New registrations cost $100, and the registration is good for two years. Subsequent renewals are $50/year. If you don't pay your registration fee, the top-level domain servers will forget about your domain, and no one will be able to reach you. That's power!

Once your domain is approved, you are ready to set up your own domain name server. Approvals can take anywhere from one day to three weeks depending on load and other things.

To run a domain name server, you will need to install BIND. The source for BIND can be found at http://www.isc.org/isc or from ftp://ftp.vix.com/pub/bind/release/bind.tar.gz. For your convenience, a copy has been included on the CD-ROM that accompanies this book.

Once you obtain the source, you should follow the compilation instructions in the package. The official release at the time I grabbed my copy was 4.9.3. As usual, running outdated software creates a source of security problems. If your system comes with an older version of the software, you really should upgrade. The installation steps are as follows:

1. FTP the source.
   
   
2. Unpack the source.
   
   
3. Change your directory to the BIND distribution directory.
   
   
4. Create a build directory by issuing a make DST=build links.
   
   
5. Cd to the build directory you just created.
   
   
6. Set the appropriate options, if any, in conf/options.h.
   
   
7. Configure the makefile for settings appropriate for your machine/os. This is easily done by removing the # from all the lines under the section that describes your operating system. If you have special locations where you want the binaries installed, set the DEST (for destination) variable to a path more palatable to you.
   
   

---

To avoid confusion, keep the default paths and rename your distribution copies of named and nslookup that came with your system to named.dist and nslookup.dist, respectively. This way you can keep your original binaries in case you run into trouble and you need to revert to something known to work.

---

1. Type make to build everything.
   
   

If compilation fails, you may want to add ./bin to your path. You can do this simply enough on a csh by issuing the following:

set path = (./bin $path)

After make builds everything, you will want to verify which files are going to be installed. Issue a make -n install to see where make wants to install everything. This will list all the commands that are going to be executed by the install target without actually running them. You should then backup or rename any remaining files that are going to be replaced with an .orig extension.

If you are running SunOS 4.1.x, NetBSD-1 or Solaris 2.x, you can integrate the new client-side resolver library into your system shared libraries. This will upgrade all dynamically linked programs to use the new libraries instead of the old ones. For more information, read the information included in the shres directory of the BIND release.

If the installation proceeded properly, BIND should now be installed in your system. Congratulations!

DNS Configuration Files

The first step in setting up your DNS database is to convert your existing /etc/hosts file into its equivalent DNS format. To configure DNS you'll need to create a few databases and startup files. I placed everything in /usr/local/named with the exception of /etc/named.boot. named looks by default for its boot file in /etc/named.boot. To get things running, you'll need to create a few files (replace DOMAIN with your domain name, and IP with your network IP address):

• /etc/named.boot
  
  
• /usr/local/named/db.DOMAIN
  
  
• /usr/local/named/db.IP
  
  
• /usr/local/named/db.127.0.0
  
  

The db files: db.DOMAIN and db.IP, contain hostname-to-IP and IP-to-hostname translation tables, respectively. The basic components for these files are

• SOA Record
  
  
• NS Records
  
  
• Address and Alias Records
  
  
• PTR Records
  
  

While the structure of the db files is similar, there's one significant difference. I mentioned that the db.DOMAIN maps hosts to IP addresses. Data in DNS is indexed by name, including addresses. Mapping from an IP address to a hostname (the reverse) actually turns out to be a little more difficult. Given the current design, searching for a name would require searching the entire database until a match was found. Obviously, this would not be very efficient. To solve the problem, the designers of DNS created a special domain that uses IP addresses as names. This domain is called the IN-ADDR.ARPA domain.

Reverse Lookups: IP to Hostname, the IN-ADDR.ARPA Domain

The IN-ADDR.ARPA domain has four levels of subdomains. Each level represents one of the octets in a 32-bit IP address. Each level has 256 (from 0 to 255) subdomains, each named after each possible octet value.

The IN-ADDR.ARPA domain has enough room for every host on the Internet given the current 32-bit (four-octet) IP representation.

Remember the domain names are read from the bottom up, like host.domain.dom. Because of this, IN-ADDR.ARPA domains are represented with their IP addresses in reverse.

If your host IP address is 1.2.3.4, your host number is 4, and the IN-ADDR.ARPA name would be written as 4.3.2.1.IN-ADDR.ARPA.

This way the name server can group, organize, and retrieve IP-to-hostname queries as efficiently as the regular name-based queries.

Before you proceed, you may want to create your db.DOMAIN and db.IP files. I created mine in /usr/local/named and renamed DOMAIN and IP to the name of my domain and network IP, respectively (db.ACCESSLINK.COM and db.204.95.222).

SOA Record

A start of authority (SOA) resource record is the first entry in a db file. This record indicates that the name server is authoritative. An authoritative name server provides the most accurate and reliable information about a domain. A single SOA record is required at the beginning of each db.DOMAIN and db.IP file.

A SOA record looks like this:

domain.dom IN SOA hostname.domain.dom. root.domain.dom. {

1 ; Serial ID

10800 ; Record Refresh in seconds (3 hours)

3600 ; Retry after one hour (in seconds)

604800 ; Expire after one week (in seconds)

86400 ) ; Minimum TTL (Time to live) of one day

On your db.DOMAIN file, replace domain.dom with the name of your domain (for example, acme.com).

IN stands for Internet. There are other possible values, but for this example, and more likely for your needs, this will fit the bill.

Replace hostname.domain.dom. with the fully qualified domain name of the host where you are creating this data. Note that the trailing period needs to be there.

Replace root.domain.dom. with a valid e-mail address for the person managing your DNS. Replace the @ sign on the e-mail address with a period. Again, note that there's a trailing period after the address.

The serial id of the record is very important. Any time you update any of the database files, you must increment this number. If for some reason you forget to increment the serial id, the secondary name servers won't realize that you have modified the database and won't update their information. Secondary name servers use this number to determine if their copy of the db file is up-to-date. A good strategy is to put the current date in a format such as YYYYMMDDR where

YYYY is the year: 1996.

MM is the month: 06.

DD is the day: 30.

R is the number of the revision (in case you modify the file more than once on the same day): 1.

The refresh interval tells the secondary server how often to check for updates on this file.

The retry interval tells the secondary server how long to wait before trying to reach the primary server, if the initial attempt failed.

If the secondary server repeatedly fails to contact the primary after the expire interval, data on the database is going to be considered stale, and the secondary server will stop responding to requests for the domain.

The TTL value specifies how long resource records served from this file will remain in a caching server's cache. After the TTL expires, the server will have to requery your server for information about your domain.

NS Records

Next, you need to specify the names of domain name servers in your domain. You do this by using name server (NS) resource records. They look like this:

"domain.dom IN NS hostname.domain.dom."

All domain name servers that you list here will be designated authoritative for the domain. Replace domain.dom and hostname.domain.dom. with the name of your domain (don't forget the period) and the fully qualified domain name of the domain name server. An example of this is as follows:

ACCESSLINK.COM IN NS ns1.ACCESSLINK.COM.

ACCESSLINK.COM IN NS ns2.ACCESSLINK.COM.

Address and Alias Records

Now you'll create name-to-address mappings. Resource records for address and Alias records look like this:

; Host Addresses

localhost IN A 127.0.0.1

router IN A 204.95.222.100

www IN A 204.95.222.200

hydrogen IN A 204.95.222.1

lithium IN A 204.95.222.3

; Aliases

mailhost IN CNAME hydrogen.ACCESSLINK.COM.

ns1 IN CNAME hydrogen.ACCESSLINK.COM.

ns2 IN CNAME lithium.ACCESSLINK.COM.

ftp IN CNAME hydrogen.ACCESSLINK.COM.

The db.IP File

The db.IP file stores an IP-to-name lookup table. The main difference between the two is that instead of listing regular IP addresses, it uses the funny IN-ADDR.ARPA notation.

Like the db.DOMAIN file, the db.IP file has a SOA Record. The only difference is that the name of the domain is specified as IN-ADDR.ARPA domain notation:

222.95.204.IN-ADDR.ARPA IN SOA hostname.domain.dom. root.domain.dom. {

1 ; Serial ID

10800 ; Record Refresh in seconds (3 hours)

3600 ; Retry after one hour (in seconds)

604800 ; Expire after one week (in seconds)

86400 ) ; Minimum TTL (Time to live) of one day

The db.IP file also lists NS resource records. These are also specified in IN-ADDR.ARPA domain notation:

1.222.95.204.IN-ADDR.ARPA. IN NS ns1.ACCESSLINK.COM.

3.222.95.204.IN-ADDR.ARPA. IN NS ns2.ACCESSLINK.COM.

In addition, the db.IP file also lists its reverse version of the Address Records (IN A entries, in your db.DOMAIN file). These are called PTR Records.

PTR Records

The DNS resource records used for IP-to-name mappings are called Pointer (PTR) Records. There's one record for each IP address on your network. All IP addresses are specified using the IN-ADDR.ARPA domain notation:

1.222.95.204 IN PTR hydrogen.ACCESSLINK.COM.

3.222.95.204 IN PTR lithium.ACCESSLINK.COM.

100.222.95.204 IN PTR router.ACCESSLINK.COM.

200.222.95.204 IN PTR www.ACCESSLINK.COM.

The Loopback Interface

In addition to the db.DOMAIN and db.IP files, the server will need a db.IP file for the loopback interface. This is a special IP address that hosts use to route traffic to themselves. The address of the loopback network is (almost always) 127.0.0.0, and the host number for the localhost is 127.0.0.1.

The file is pretty standard. If you copy your other db.IP file, you'll only need to delete all PTR records and insert a new PTR record pointing to the localhost, the last line in the following listing:

222.95.204.IN-ADDR.ARPA IN SOA hostname.domain.dom. root.ACCESSLINK.COM. {

1 ; Serial ID

10800 ; Record Refresh in seconds (3 hours)

3600 ; Retry after one hour (in seconds)

604800 ; Expire after one week (in seconds)

86400 ) ; Minimum TTL (Time to live) of one day

; Name Servers

;

1.222.95.204.IN-ADDR.ARPA. IN NS ns1.ACCESSLINK.COM.


3.222.95.204.IN-ADDR.ARPA. IN NS ns2.ACCESSLINK.COM.

;

; localhost

1.0.0.127.IN-ADDR.ARPA. IN PTR localhost.

The named.root File

In addition to knowing all the gory details about your network, DNS needs to know how to contact the name servers for the root domain. Your BIND release should have included a copy of this file. If not, you can find a copy at

ftp://ftp.rs.internic.net/domain/named.root

This file is only used at startup. After named is able to contact the top-level name servers, it updates its internal information.

The /etc/named.boot File

If you are following at the terminal, you have now developed and downloaded all the files you need to get named going. However, you need to create a configuration file that can tell named where to find all its files. If you have followed my example and created your files in /usr/local/named, your boot file will look like this:

directory /usr/local/named

primary domain.dom db.DOMAIN

primary xxx.xxx.xxx.IN-ADDR.ARPA db.IP

primary 0.0.127.IN-ADDR.ARPA db.127.0.0

cache . named.root

Here's how my boot file looks after I replace the placeholders with the naming convention described earlier:

directory /usr/local/named

primary ACCESSLINK.COM db.ACCESSLINK

primary 222.95.204.IN-ADDR.ARPA db.204.95.222

primary 0.0.127.IN-ADDR.ARPA db.127.0.0

cache . named.root

Starting named

To start the name server as root on a terminal, type:

/etc/named.

If you located your boot file somewhere other than in the default /etc/named.boot, you can tell named where to look for it by using the -b flag, /etc/named -b pathtobootfile.

If there were any errors in your configuration files, named will log an error using syslog, and if the error is bad enough, it will quit. To see where named will log any errors, type in the following:

grep daemon /etc/syslog.conf

This will print the name of the file where named will log errors to. In my case, the result of this command is /usr/adm/messages, yours may be /usr/var/messages or something like that. Please note that by default named logs a restart message whenever it starts. It is very likely that if you made a typo or forgot to enter a field, named will complain by saying ...Unknown type:... or ...unknown field 'foo'.... Look for the offending line and compare it to the examples.

Testing Your Name Server

If named started correctly, then you can use nslookup to see if it is serving information correctly. If your machine was not on the Internet before, chances are that you have not set the domainname for it. On some systems this is done with the hostname command. Other systems use domainname. To check if your system has been set up, type hostname (or domainname) on a terminal.

If the domainname has not been set up, the superuser can set it up by giving the command an argument:

domainname domain.dom

Replace domain.dom with the name of your domain. You may want this to happen automatically at the system startup time. Just include the line domainname domain.dom on your /etc/rc.local or equivalent system startup file.

To see if it is all working correctly, type the following:

% nslookup lithium

Server: ns1.ACCESSLINK.COM

Address: 204.95.222.1

Name: lithium.ACCESSLINK.COM

Address: 204.95.222.3

You may want to also see if you can use nslookup to find a machine out of your network::

% nslookup www.next.com

Server: ns1.ACCESSLINK.COM

Address: 204.95.222.1

Non-authoritative answer:

Name: ftp.next.com

Address: 129.18.1.3

Aliases: www.next.com

A final test involves querying a remote name server to see if it can obtain your address. You can do this easily with nslookup by specifying the address of the remote name server after the host you are looking for:

% nslookup lithium.accesslink.com beta.inc.net

Server: ns1.inc.net

Address: 204.95.160.2

Name: lithium.ACCESSLINK.COM

Address: 204.95.222.3

If it works, then you'll probably want named to be started up when you reboot the computer. You can accomplish this easily enough by putting an entry such as the following in your /etc/rc.local file:

if -f [/etc/named.boot]; then

 echo "starting named …"

 /usr/etc/named

fi

The preceding script will check to see if your /etc/named.boot file exists in the /etc directory. If it does, then name server is started.

---

If when you Telnet or FTP to other machines, you find that there's a long lag (10 seconds or so) between connecting and receiving a login prompt, more than likely your reverse DNS lookups are not working properly. It is possible that your ISP, to whom your IP addresses are registered, is not providing the proper information. Have them check their DNS information.

---

Congratulations, your primary name server is now running.

Configuring a Secondary Name Server

Configuring a secondary name server is a lot less work. You should strongly consider running a secondary name server on your site or have someone else run one for you. It is even better have someone else run DNS for you at another site, and remember to add the address of that name server to your domain registration form. This will ensure that if your name servers go down, your network doesn't grid to a halt.

To build a secondary name server, follow these steps:

1. Install the software as you did for your primary name server.
   
   
2. Copy /etc/named.boot to the other computer's /etc directory.
   
   
3. Copy /usr/local/named/named.root and db.127.0.0 to /usr/local/named/ on the other computer.
   
   
4. Edit the file /etc/named.boot on your secondary server. Change all instances of primary to secondary, with the exception of the line referring to db.127.0.0. This name server is also primary for the loopback address; it is its own loopback address.
   
   

And that's it. To finish, copy the startup commands you put in your primary server's rc.local file.

On starting the secondary server, it will transfer a copy of all the databases to the /usr/local/named directory.

Configuring Hosts in Your Network to Use the Name Server

Before any client in your network can use your name server, you'll need to create the /etc/resolv.conf file. This file contains a list of all the name servers in your network and the order they are queried in. The basic format is as follows:

search domainname...

nameserver ipaddress

Ours looks like this:

seach accesslink.com

nameserver 204.95.222.1

nameserver 204.95.222.2

Summary

Because the intention of this appendix was to provide you with a basic reference and to help you quickly set up DNS, the information is by no means complete. DNS is not particularly complicated. However, complex networks require complex DNS setups, and as should be expected, powerful software cannot be mastered in an appendix; DNS keeps the Internet running. This appendix gets your DNS running; it is not an absolute reference on the subject. For more information, I would suggest that you read the documentation included with your release of DNS. If you FTPed the package, it contains excellent documentation as well as a frequently asked questions (FAQ) list. As for printed information, the following might be helpful.

DNS and BIND, by Paul Albitz & Cricket Liu, is published by O'Reilly and Associates, Inc. ISBN 1-56592-010-4. It's a great book. However, some of the information is a little out-of-date.

For an excellent UNIX system administration book, the best this author has ever seen, check out UNIX System Administration Handbook, now in its second edition. While it is impossible to cover UNIX in one volume, it does an excellent job of explaining the art of UNIX system administration. It has more than enough detail to get you going. This book was written by Evi Nemeth, Garth Snyder, Scott Seebass, and Trent R. Hein. It is published by Prentice Hall, ISBN 0-13-151051-7.