Chapter 29 Administering DNS

This chapter describes how to administer the Domain Name System (DNS). For more detailed information, see DNS and Bind by Cricket Liu and Paul Albitz, (O'Reilly, 1992) and "Name Server Operations Guide for BIND", University of California, Berkeley.

• "Trailing Dots in Domain Names"

• "Modifying DNS Data Files"

• "Adding and Deleting Machines"

• "Adding Additional DNS Servers"

• "Creating DNS Subdomains"

• "DNS Error Messages and Problem Solving"

Trailing Dots in Domain Names

When working with DNS-related files, follow these rules regarding the trailing dot in domain names:

• Use a trailing dot in domain names in hosts, hosts.rev, named.ca, and named.local data files. For example, sales.doc.com. is correct.

• Do not use a trailing dot in domain names in named.boot or resolv.conf files. For example, sales.doc.com is correct.

Modifying DNS Data Files

Whenever you add or delete a host or make some other change in one of the DNS data files in the master DNS server or otherwise modify DNS data files, you must also:

• Change the serial number in the SOA resource record so the secondary servers modify their data accordingly (see "Changing the SOA Serial Number").

• Inform in.named on the master server that it should reread the data files and update its internal database (see "Forcing in.named to Reload DNS Data").

Changing the SOA Serial Number

Every DNS database file begins with a Start of Authority (SOA) resource record. Whenever you alter any data in a DNS database file, you must increment the SOA serial number by one integer.

For example, if the current SOA Serial Number in a data file is 101, and you make a change to the file's data, you must change 101 to 102. If you fail to change the SOA serial number, the domain's secondary servers will not update their copy of the database files with the new information and the primary and secondary servers will become out of synch.

A typical SOA record of a sample hosts file looks like this:

; sample  hosts  file
@	IN       SOA 	nismaster.doc.com. root.nismaster.doc.com. (
			109 ; Serial
			10800 ; Refresh
 	                1800 ; Retry
			3600000 ; Expire
			86400 ) ; Minimum

Thus, if you made a change to this hosts file, you would change 109 to 110. The next time you change the file, you would change 110 to 111.

Forcing in.named to Reload DNS Data

When in.named successfully starts, the daemon writes its process ID to the file /etc/named.pid. To have in.named reread named.boot and reload the database, enter:

# kill -HUP `cat /etc/named.pid`

This will eliminate all previously cache, and the caching process will start over again.

Do not attempt to run in.named from inetd. This will continuously restart the name server and defeat the purpose of having a cache.

Adding and Deleting Machines

When you add or delete a machine, always make your changes in the data files stored on your primary DNS server. Do not make changes or edit the files on your secondary servers because those will be automatically updated from the primary server based on your changing the SOA serial number.

Adding a Machine

To add a machine to a DNS domain, you set the new machine up as a DNS client and then add records for the new machine to the appropriate hosts and hosts.rev files.

For example, to add the host rigel to the doc.com domain:

1. Create a /etc/resolv.conf file on rigel.

2. Add dns to the hosts line of rigel's /etc/nsswitch.conf file

   (See "DNS and Internet Access".)

3. Add an address (A) record for rigel to the primary server's hosts file.

   For example:

   rigel IN A 123.45.6.112

4. Add any additional optional records for rigel to the primary server's hosts file.

   Optional records could include:

   • Alias (CNAME)

   • Mail exchange (MX)

   • Well known services (WKS)

   • Host information (HINFO)

5. Add a PTR record for rigel to the hosts.rev file.

6. Increment the SOA serial number in the primary server's hosts and hosts.rev files.

7. Reload the server's data.

   Either reboot the server or enter:

   # kill -HUP `cat /etc/named.pid`

   These steps are explained in more detail in Solaris Naming Setup and Configuration Guide.

Removing a Machine

To remove a machine from a DNS domain:

1. Remove dns from the hosts line of the machine's nsswitch.conf file.

2. Remove the machine's /etc/resolv.conf file.

3. Delete the records for that machine from the primary server's hosts and hosts.rev files.

4. If the machine has CNAME records pointing to it, those CNAME records must also be deleted from the hosts file.

5. Set up replacements for services supported by the removed machine.

   If the machine is a primary server, mail host, or host for any other necessary process or service, you must take whatever steps are necessary to set up some other machine to perform those services.

Adding Additional DNS Servers

You can add primary and secondary servers to your network. To add a DNS server:

1. Set the server up as a DNS client.

   See "Adding a Machine".

2. Set up the server's boot file.

3. Set up the server's named.ca file.

4. Set up the server's hosts file.

5. Set up the server's hosts.rev file.

6. Set up the server's named.local file.

7. Initialize the server.

8. Test the server.

   These steps are explained in more detail in Solaris Naming Setup and Configuration Guide.

Creating DNS Subdomains

As your network grows you may find it convenient to divide it into one or more DNS subdomains. (See "Introducing the DNS Namespace" for a discussion of DNS domain hierarchy and structure.)

When you divide your network into a parent domain and one or more subdomains, you reduce the load on individual DNS servers by distributing responsibility across multiple domains. In this way you can improve network performance. For example, suppose there are 900 machines on your network and all of them are in one domain. In this case, one set of DNS servers composed of a primary and additional secondary and caching-only servers have to support 900 machines. If you divide this network into a parent domain and two subdomain, each with 300 machines, then you have three sets of primary and secondary servers each responsible for only 300 machines.

By dividing your network into domains that match either your geographic or organizational structure (or both), the DNS domain names indicate where a given machine or email address fits into your structure. For example, rigel@alameda.doc.com implies that the machine rigel is located at your Alameda site, and the email address barnum@sales.doc.com implies that the user barnum is part of your Sales organization.

Dividing your network into multiple domains requires more set up work than keeping everything in one domain, and you have to maintain the delegation data that ties your domains together. On the other hand, when you have multiple domains, you can distribute domain maintenance tasks among different administrators or teams, one for each domain.

Planning Your Subdomains

Here are some points to consider before dividing your network into a parent and one or more subdomains:

• How many subdomains? The more subdomains your create, the more initial set up work you have to do and the more ongoing coordination work for the administrators in the parent domain. The more subdomains, the more delegation work for the servers in the parent domain. On the other hand, fewer domains mean larger domains, and the larger a domain is the more server speed and memory is required to support it.

• How to divide your network? You can divide your network into multiple domains any way you want. The three most common methods are by organizational structure where you have separate subdomains for each department or division (sales, research, manufacturing, etc.); by geography where you have separate subdomains for each site; or by network structure where you have separate subdomains for each major network component. The most important rule to remember is that administration and use will be easier if your domain structure follows a consistent, logical, and self-evident pattern.

• Consider the future. The most confusing domain structures are those that grow over time with subdomains added haphazardly as new sites and departments are created. To the degree possible, try to take future growth into account when designing your domain hierarchy. Also take into account stability. It is best to base your subdomains on what is most stable. For example, if your geographic sites are relatively stable but your departments and divisions are frequently reorganized, it is probably better to base your subdomains on geography rather than organizational function. On the other hand, if your structure is relatively stable but you frequently add or change sites, it is probably better to base your subdomains on your organizational hierarchy.

• Wide area network links. When a network spans multiple sites connected via modems or leased lines, performance will be better and reliability greater if your domains do not span such Wide Area Network (WAN) links. In most cases, WAN links are slower than contiguous network connections and more prone to failure. When servers have to support machines that can only be reached over a WAN link, you increase the network traffic funneling through the slower link, and if there is a power failure or other problem at one site, it could affect the machines at the other sites. (The same performance and reliability considerations apply to DNS zones. As a general rule of thumb, it is best if zones do not span WAN links.)

• NIS+ name service. If your enterprise-level name service is NIS+, administration will be easier if your DNS and NIS+ domain and subdomain structures match.

• Subdomain names. To the degree possible, it is best to establish and follow a consistent policy for naming your subdomains. When domain names are consistent, it is much easier for users to remember and correctly specify them. Keep in mind that domain names are an important element in all of your DNS data files and that changing a subdomain name requires editing every file in which the old name appears. Thus, it is best to choose subdomain names that are stable and unlikely to need changing. You can use either full words, such as manufacturing, or abbreviations, such as manf, as subdomain names, but it will confuse users if some subdomains are named with abbreviations and others with full names. If you decide to use abbreviations, use enough letters to clearly identify the name because short cryptic names are hard to use and remember. Do not use reserved top-level Internet domain names as subdomain names. This means that names like org, net, com, gov, edu, and any of the two-letter country codes such as jp, uk, ca, and it should never be used as a subdomain name.

Setting Up a Subdomain

In most cases, new subdomains are usually created from the start with a new network and machines, or split off from an existing domain. The process is essentially similar in both cases.

Once you have planned your new subdomain, follow these steps to set it up:

1. Make sure all of the machines in the new subdomain are properly set up as DNS clients.

   If you are carving a new subdomain out of an existing domain, most of the machines are probably already set up of DNS clients. If you are building a new subdomain from scratch (or adding new machines to an existing network) you must install properly configured resolv.conf and nsswitch.conf files on each machine as described in Solaris Naming Setup and Configuration Guide.

2. Install properly configured boot and DNS data files on the subdomain's primary master server.

   Install the following files on each server (see Solaris Naming Setup and Configuration Guide for details):

   • /etc/named.boot.

   • /var/named/named.ca.

   • /var/named/hosts.

   • /var/named/hosts.rev.

   • /var/named/named.local.

   Note that the server host files must have an Address (A) record, any necessary CNAME records for each machine in the subdomain and the server hosts.rev files must have a pointer (PTR) record for each machine in the subdomain. Optional HINFO and WKS records can also be added.

3. If you are splitting an existing domain, remove the records for the machines in the new subdomain from the parent domain's master server hosts and hosts.rev files.

   This requires deleting the A records for the machines that are now in the new subdomain from the hosts files of the old domain's servers, and also deleting the PTR records for those machines from the old domain's hosts.rev files. Any optional HINFO and WKS records for the moved machines should also be deleted.

4. If you are splitting an existing domain, add the new subdomain name to CNAME records in the parent domain's master server hosts and file.

   For example, suppose you are using the machine aldebaran as a fax server and it had the following CNAME record in the hosts file of the parent domain's servers:

   faxserver IN CNAME aldebaran

   In addition to creating a new faxserver CNAME record for aldebaran in the hosts file of the new subdomain's master server, you would also have to change this CNAME record in the parent domain's hosts file to include aldebaran's subdomain as shown below:

   faxserver IN CNAME aldebaran.manf.doc.com

5. Add NS records for the new subdomain's servers to the parent domain's hosts file.

   For example, suppose that your parent domain is doc.com and you are creating a new manf.doc.com subdomain with the machine rigel as manf's primary master server and aldebaran as the secondary master server. You would add the following records to the hosts file of doc.com's primary master server:

   manf.doc.com 99999 IN NS rigel.manf.doc.com 99999 IN NS aldebaran.manf.doc.com

6. Add A records for the new subdomain's servers to the parent domain's hosts file.

   Continuing with the above example, you would add the following records to the hosts file of doc.com's primary master server:

   rigel.manf.doc.com 99999 IN A 1.22.333.121 aldebaran.manf.doc.com 99999 IN A 1.22.333.136

7. Start up named on the subdomain's servers.

   # /usr/sbin/in.named

   Instead of running in.named from the command line, you can reboot. See Solaris Naming Setup and Configuration Guide for details.

DNS Error Messages and Problem Solving

See Appendix A, Problems and Solutions, and Appenix B, Error Messages, for DNS problem solving and error message information.