Certification Objective 9.01: DNSBIND

---

Certification Objective 9.01: DNS/BIND

DNS is the Domain Name System, which maintains a database that can help your computer translate domain names such as www.redhat.com to IP addresses such as 216.148.218.197. As no individual DNS server is large enough to keep a database for the entire Internet, they can refer requests to other DNS servers.

DNS is based on the named daemon, which is built on the BIND (Berkeley Internet Name Domain) package developed through the Internet Software Consortium. More information is available from the BIND home page at www.isc.org/products/BIND. Red Hat Enterprise Linux 3 (and Red Hat Linux 9) includes BIND version 9.2. While this version of BIND supports the use of the /usr/sbin/rndc configuration interface, RHEL 3 still includes sample files based on the older /etc/named.conf configuration file. However, you can use the rndc command to manage DNS operation, in the same way that you used apachectl to manage the Apache server.

You can configure a DNS server by directly editing the DNS configuration files. Alternatively, you can configure a DNS server using the Red Hat Domain Name Service configuration tool. Careful use of both tools can help you learn more about DNS.

Exam Watch 

I've found the Red Hat Domain Name Service tool to be less than reliable. It sometimes aborted unpredictably on my installations of RHEL 3. In other words, the only reliable way to configure DNS on your RHEL 3 computer is by direct editing of configuration files.

You can set up four different types of DNS servers:

• A master DNS server for your domain(s), which stores authoritative records for your domain.

• A slave DNS server, which relies on a master DNS server for data.

• A caching-only DNS server, which stores recent requests like a Proxy server. It otherwise refers to other DNS servers.

• A forwarding-only DNS server, which refers all requests to other DNS servers.

  On The Job 

  redhat-config-bind is the successor to bindconf. Red Hat Enterprise Linux 3 includes a link from bindconf to redhat-config-bind.

DNS Packages

If you're just configuring your Linux computer as a DNS client, you can skip this section. The basic DNS client configuration files are automatically installed with even a minimal installation of RHEL 3.

On the other hand, if you're configuring your Linux computer as a DNS server, you'll need to install the packages associated with the DNS Name Server package group. You can do so with the Red Hat Package Management utility described in Chapter 4. However, there are only four RPM packages associated with DNS:

• bind Includes the basic name server software, including /usr/sbin/named.

• bind-utils Contains tools such as dig and host that allow you to ask a DNS server for more information about a specific Internet host. It should already be installed in any minimum installation of RHEL 3.

• caching-nameserver Allows you to set up a local cache of a remote DNS server to speed access from the computers on your network to a remote network such as the Internet.

• redhat-config-bind A GUI configuration tool useful for adding host and reverse address lookup data. It's not officially a part of the DNS Name Server package group.

Naturally, these tools are easy to install from any Red Hat network installation source that you may have created in Chapter 2. Different options and commands for installing RPMs from a remote installation source are described in Chapter 4.

The DNS Configuration Files

There are DNS configuration files required to configure your Linux computer as a client and as a server. There are two DNS client configuration files: /etc/hosts and /etc/resolv.conf. They are fairly straightforward, as described in the next section.

There are a number of additional configuration files that support the use of DNS as a server, as described in Table 9-1. You may have to create some of these files as you configure DNS.

Table 9-1: DNS Server Configuration Files

DNS Configuration File	Description
/etc/sysconfig/named	You can set up different configuration and data file directories through this file.
/etc/named.conf	The main DNS configuration file. Incorporates /etc/named.custom, and calls data files in the /var/named directory.
/etc/named.custom	If you use the Red Hat DNS configuration tool, you can include additional settings in this file.
/etc/rndc.key	The authentication key required to support requests to the DNS server.
/var/named/0.0.127.in-addr.arpa.zone	The reverse zone file for the localhost computer.
/var/named/netaddr.in-addr.arpa.zone	The reverse zone file for the LAN; on an IPv4 network, it's the first three octets, written backwards. For example, for a network address of 192.168.30.0, the reverse zone file is 30.168.192.in-addr .arpa.zone.
/var/named/domain.zone	A database for a domain such as example.com.
/var/named/localhost.zone	The zone file for the localhost computer.
/var/named/named.ca	A list of root DNS servers on the Internet.
/var/named/named.local	A reverse zone record for the localhost.
/var/named/named.stats	Statistics from your DNS server.

In the following sections, I'll show you how to configure the files that you need for a working DNS server. But first, you should know how to configure your computer as a DNS client. One thing to remember is that all of the files in /var/named include a dot at the end of each domain name. For example, /var/named/localhost.zone lists the local computer as:

localhost. 

In contrast, the domain names in /etc/named.conf and /etc/named.custom do not have dots at the end of their domain names.

A DNS Client

When your computer looks for another computer on a TCP/IP network such as the Internet, it typically looks in two places: /etc/hosts and any DNS servers that you've set up for your network. The order is determined by a single line in /etc/host.conf. The default is:

order hosts,bind

When your computer searches for another, this line tells your computer to search first through your /etc/hosts database. The following line in my /etc/hosts is what drives a Web browser address to my local IP address:

127.0.0.1   Enterprise3   localhost.localdomain   localhost

While you could theoretically also configure every computer on the Internet in your /etc/hosts configuration file, it's not realistic. However, if your LAN is small, you could add the IP address and hostname of each computer on your network in the /etc/hosts file. You could then duplicate this file on each computer on your LAN. Then you could use an external DNS server, provided by your ISP, for Internet access.

It's easy to configure a Linux computer as a DNS client. You may have already done so during the RHEL 3 installation process. If you have a working DHCP server, it probably provided you with the settings you need as a DNS client. Alternatively, you can configure your computer as a DNS client with the Red Hat Network Configuration utility described in Chapter 4. You can even configure your computer directly through your /etc/resolv.conf file. It's easy to do; the following version of this file lists two DNS servers on the Internet:

nameserver 207.217.120.83 nameserver 207.217.126.81

If you want to add or change the DNS servers for your computer, you can open this file directly in the text editor of your choice.

In the following section, you'll get a chance to learn about DNS nameserver configuration files from the ground up. Many of the lessons associated with a caching-only name server apply to slave and master DNS servers.

On The Job 

As with a number of Samba variables, 'name server' and 'nameserver' are both in common use with respect to servers that conform to Domain Name Service (DNS), and I use both variations throughout the book.

A Forwarding-Only Name Server

This first type of DNS server is simple. It requires a single command in the /etc/named.conf configuration file. As you can see, it's straightforward; I've set it to refer to the DNS servers that I had configured as a client:

options {      directory "/var/named";      forward only;      forwarders {           207.217.120.83;           207.217.126.81;      }; };

You can activate this configuration once you've activated this DNS server. With this configuration, any computer that looks to the local DNS server is forwarded to the IP addresses shown.

If the data can't be found in those DNS servers, it's up to those servers to ask others for the information. The alternative is to use the /var/named/named.ca file described later in this chapter.

A Caching-Only Name Server

When you request a Web page such as www.osborne.com, your network asks the configured DNS server for the associated IP address. This is usually known as a name query. If the DNS server is outside your network, this request can take time. If you have a caching-only name server, these queries are stored locally, which can save significant time while you or others on your network are browsing the same sites on the Internet.

When configuring a caching-only name server, the first step is to look at the /etc/named.conf configuration file. An abbreviated version of this file, configured for a caching name server, is shown in Figure 9-1.

Figure 9-1: /etc/named.conf, configured for a caching nameserver

The directory command tells your DNS server where to look for data files. All other files specified in named.conf are located in the /var/named directory. The /etc/named.conf file continues with the controls command, which allows you to use the rdnc command to control DNS. The next three zone commands support access to various domains:

• The first zone 'dot' refers regular requests to /var/named/named.ca, the list of root servers for the Internet.

• The second zone, for localhost, sets the forward zone for the local computer.

• The third zone is a reverse zone for the local computer.

  On The Job 

  If you have an older hardware firewall, it might expect DNS communication on TCP/IP port 53. If it does, you'll want to activate the query-source address * port 53 command.

named.ca

If your DNS servers don't have the IP address for a domain name in its database, it can refer to other databases. By default, it refers to the /var/named/named.ca file, which is a list of the root DNS servers for the Internet. An excerpt is shown in Figure 9-2. This list changes from time to time and must be maintained. I include a shell script that you can use to maintain this file later in this section.

Figure 9-2: The root DNS servers are stored in named.ca

localhost.zone

The default /var/named/localhost.zone file is shown in Figure 9-3. It incorporates a basic DNS entry for the local computer, which you can use as a template for other computers on your network.

Figure 9-3: The localhost .zone DNS data file

Reverse Lookups with named.local

The /var/named/named.local file provides a reverse-lookup record for your computer, as localhost. As shown in Figure 9-4, the PTR record (on the last line in the file) is 1, which associates the loopback address, 127.0.0.1, with your computer.

Figure 9-4: The named.local reverse DNS file

Configuring a Simple Domain

Return to the /etc/named.conf configuration file. With what we know about DNS configuration files, we can create a Master DNS server. Assume that you've defined a simple domain for the computers on your network; call it example.com.

On The Job 

The example.com domain is a generic domain that can't be assigned on the Internet. You can therefore use this domain name on your private network (assuming that you don't have a domain of your own).

Look at the zone '0.0.127.in-addr.arpa' IN line near the bottom of the sample file. This says that the zone 0.0.127.in-addr.arpa will be defined, that the localhost is the master server (type master) for that zone, associated data is stored in a file called named.local, and no other DNS server is allowed to 'update' or change the IP address associated with the localhost (allow-update { none; }).

On The Job 

Not all characters are allowed in hostnames. DNS can read only regular letters, numbers, and the hyphen (-) character. Unlike Linux, DNS does not distinguish between upper- and lowercase characters; for example, Mail.Example.Com is equivalent to mail.example.com.

Now you can add your network to your DNS server. Start by inserting a new zone section in the /etc/named.conf file, before the include '/etc/rndc.key'; command. (If you're also going to use Red Hat's GUI Domain Name Service tool, you should instead add this information to /etc/named.custom.)

zone "example.com" IN {     type master;     file "example.com.zone"; };

Note again that we do not use a period at the end of any address in /etc/named.conf. If you want to create a slave server, the information that you'd enter is similar:

zone "example.com" IN {     type slave;     file "slave.example.com.zone";     masters {            192.168.30.5              }; };

The task for a slave server is easier; it periodically checks with the master DNS server, in this case the computer with an IP address of 192.168.30.5. When it does, it automatically reads the master DNS server data and creates the slave.example.com.zone file in the /var/named directory.

Creating a Zone File

If you're creating a master DNS server, you'll need to create a zone file. Based on the configuration so far, this will be an example.com.zone file in the /var/named directory. I've created one for my own network, as shown in Figure 9-5.

Figure 9-5: An example .com.zone file

Now let's decipher some of the language in this file:

$TTL 3D means that the default Time To Live (TTL) for data on this DNS server is three days. It's also common to have a TTL of 86400, which corresponds to the number of seconds in a day. You can specify individual TTLs for each entry in this file.

The SOA (Start Of Authority) record is the preamble to all zone files. It describes the zone where it comes from (a computer called enterprise3.example.com), the administrator e-mail for this DNS server ([e-mail]). The SOA record command line also specifies a number of other parameters:

• Serial number is based on the date and version number. Based on the one shown in Figure 9-5, this database file is the first one created for this server on February 12, 2004.

• The refresh frequency determines how long the local DNS slave server waits before checking for updates from any master DNS servers.

• The retry frequency specifies how often the local DNS slave server retries contacting the master server.

• If there is no response from a DNS master server before the end of the expiration period, the local server stops accepting requests for the given domain.

• The Time To Live is the minimum amount of time other DNS servers should keep the local zone information in their remote cache.

The NS is the Name Server resource record, which refers to the name of the DNS server computer, which in this case is enterprise3.example.com.

The MX is the Mail Exchange record, which directs e-mail information to a particular computer, in this case, mail.example.com. Some number such as what's shown is required with any MX record.

In my example.com.zone file shown in Figure 9-5, I also have entries for three computers in this DNS zone. Each is associated with an A (address) record, its IP address. The final three entries specify canonical names (CNAME) for specific computers. For this zone file, www.example.com is also known as enterprise3.example.com.

CNAME allows you to assign several names to each computer. In this case, mail, ftp, and www are all aliases for the enterprise3 computer. A CNAME is not a legal hostname for an e-mail address. For example, [e-mail] won't work based on the example.com.zone file shown. However, it is something you can use on your network as an outgoing mail server.

If you have more than one mail server, you can add a number before the name of each MX computer. For example, based on the following commands:

     IN     MX     10      mail.example.com.           IN     MX     20      mail2.example.com.

any e-mail directed to this domain is first sent to mail.example.com.

Save this file and restart named with the service named restart command. Examine the results with the host -l example.com command. I've shown the result from my zone file in Figure 9-6.

Figure 9-6: Listing a working DNS zone

The Reverse Zone

Now programs can convert the names in your-domain.com to real IP addresses. You're ready for the next step: a reverse zone file, which allows a DNS server to convert backwards, from an IP address to a hostname. Reverse zone lookups are used by many servers of different kinds (FTP, IRC, WWW, and others) to decide if they even want to talk to a computer asking for information. It's a common way for a mail server to check if an e-mail has come from a valid domain. Therefore, for full access to all Internet services, you need a reverse zone. Start by adding another zone to the /etc/named.conf configuration file:

zone "30.168.192.in-addr.arpa" IN {           type master;           file "example.com.rr.zone";           allow-update { none; }; };

This is similar to the 0.0.127.in-addr.arpa zone as described in /etc/named.conf. I've created an example.com.rr.zone file in the /var/named directory for the computers on my network, as shown in Figure 9-7.

Figure 9-7: A reverse DNS zone file

Once again, restart named and examine the output of host -l your-domain.com. If the results do not look similar to the actual zone file, look for error messages in /var/log/messages.

On The Job 

Reverse zones can be used by several different services, such as sendmail and Apache. The reverse zone DNS database allows a server to verify if the name of a requesting computer matches its IP address, which can keep crackers from trying to 'spoof' your system.

Starting named

Make sure your computer is connected to a network. Now you can start your DNS server through the named daemon with the service named start command. View the syslog message file (usually called /var/log/messages) with the tail -f /var/log/messages command. If there are problems, you'll see error messages here.

If there are any error messages, the named daemon will display the file with the error. Stop the service with the service named stop command and check the applicable configuration files.

Now test the setup. Use the dig command to examine your work. For example, if you use dig to look up the address of www.redhat.com, you'll see something like the output shown in Figure 9-8.

Figure 9-8: DNS query using dig

The dig command asks your DNS server to look for the www.redhat.com server. It then contacts one of the name server computers listed in /etc/resolv.conf. If that doesn't work, it goes to one of the name servers listed in the named.ca file and makes its requests from there. The request may be passed on to other DNS servers. Therefore, it can take some time before you see an answer.

Once you're satisfied with your configuration, you'll want to make sure that DNS starts the next time you reboot Linux. Naturally, that may be the only way that you would get full credit for your work on the RHCE exam. The following command makes sure that the named daemon starts the next time you boot Linux in the standard login runlevels:

# chkconfig --level 35 named on 

Common DNS Pitfalls

DNS is an Internet-wide database of domain names and IP addresses. If you want your DNS server to participate, make sure the information that goes into the database is up to date and properly formatted. Many network outages can be traced to poorly administered DNS servers. A few examples of common DNS errors are described in the following sections.

Timing

Sometimes, all you need to do is wait a while. Whenever a change is made in a DNS database, it takes some time before the change is noted (a.k.a. propagated) to other DNS servers on the Internet. Therefore, whenever you change something such as the IP address associated with a Web server, it's advisable to keep the old IP address available for that Web server until the new IP address has time to propagate.

The Serial Number Wasn't Incremented

The single most common DNS error occurs when an administrator makes updates to a zone file, restarts DNS, and notices that no one else on the Internet knows about the updates. If another DNS server doesn't detect a new serial number on a zone file, it assumes the file is the same, and sticks with its cache. No data is taken from the update, and other DNS servers don't get the revised information.

When you update a zone file, update the serial number. It's best done with the current date in the format shown in the examples (four-digit year, two-digit month, and two-digit date, followed by a one-digit increment number). If you've updated the DNS more than once today, increment the last number as well.

The Reverse Zone Isn't Delegated

Not all network administrators have control over their DNS servers. Some administrators contract with an ISP for this service.

Now assume you're that ISP administrator. You'll need to assign this customer a range of IP addresses for their domain name. Then you'll need to assign the domain name and IP addresses to a specific DNS 'zone of authority.'

Next, you'll also need to set up the reverse zone. For example, if you assign the 192.168.1. network (192.168.1. is short for the IPv4 network address of 192.168.1.0), you'll need to add NS records in the forward zone, and PTR records in the reverse zone.

On The Job 

From an end-user perspective, DNS might be considered the glue that holds the Internet together. Pay special attention to the nuances of the configuration files, so that network-wide problems are avoided.

The Red Hat DNS Configuration Tool

Red Hat has created a number of excellent GUI configuration tools. They are 'front-ends' which can help many administrators create the configuration files that they need. Unfortunately, I do not believe that the Red Hat Domain Name Service tool should be included in this category. As of this writing, Red Hat has incorporated changes into a different RPM package optimized for Fedora Linux; this updated RPM package, system-config-bind, is not supported by Red Hat through an enterprise subscription.

In any case, it is best if you learn how to configure Linux services, including DNS, directly from the configuration files. As a Linux systems administrator, you may not always have access to the GUI. You may need to administer servers remotely, which makes GUI configuration difficult at best.

If you want to try the Red Hat Domain Name Service configuration tool shown in Figure 9-9, back up your DNS configuration files first: /etc/named.conf, /etc/named.custom, and the files in the /var/named directory. In RHEL 3, this is based on the redhat-config-bind RPM.

Figure 9-9: The Red Hat Domain Name Service configuration tool

Keep It Working

Assuming you're running your own DNS, you also need to keep the /var/named/named.ca file up to date. The easiest way to do this is by using dig, which is also known as the DNS Information Groper. If your DNS is working properly and is connected to the Internet, you can run commands such as dig www.osborne.com.

Let us analyze the dig command further. First, run dig with no arguments. You will get information from the local named.ca file. Then use this command to query one of the listed root servers with a command such as dig a.ROOT-SERVERS.NET. The output should resemble a named.ca file. Save it to a file with a command such as dig @a.root-servers.net.ns > named.ca.new and replace the old named.ca file. Remember to reload the named daemon after replacing the named.ca file.

Alternatively, the following script can be run automatically to update named.ca. The text of the base script is also available in the DNS-HOWTO available from the Linux Documentation Project at www.tldp.org. At the time of this writing, the base script in the HOWTO is still written for BIND 8. If you're using this file, change all of the 'root.hints' filenames to 'named.ca', and then replace the mail-alias 'hostmaster' with a working e-mail address.

Once you're satisfied with the configuration, you can set up a crontab entry to run this script on a monthly basis in the /etc/cron.montly directory.

#!/bin/sh   #   # Update the nameserver cache information file once per month.   # This is run automatically by a cron entry.   #   # Original by Al Longyear   # Updated for bind 8 by Nicolai Langfeldt   # Miscellaneous error-conditions reported by David A. Ranch   # Ping test suggested by Martin Foster   #   (    echo "To: hostmaster <hostmaster>"    echo "From: system <root>"    echo "Subject: Automatic update of the named.ca file"    echo    PATH=/sbin:/usr/sbin:/bin:/usr/bin:    export PATH    cd /var/named    # Are we online?  Ping a server on the Internet    case 'ping -qnc 1 www.redhat.com' in      *'100% packet loss'*)           echo "The network is DOWN. named.ca NOT updated"           echo           exit 0           ;;    esac    dig @A.ROOT-SERVERS.NET . ns > named.ca.new 2>>&1    case 'cat named.ca.new' in      *Got answer*)           # It worked           :;;      *)           echo "The named.ca file update has FAILED."           echo "This is the dig output reported:"           echo           cat named.ca.new           exit 0           ;;    esac echo "The named.ca file has been updated to contain the following     information:"    echo    cat named.ca.new    chown root.root named.ca.new    chmod 444 named.ca.new    rm -f named.ca.old    mv named.ca named.ca.old    mv named.ca.new named.ca.hints    /etc/rc.d/init.d/named restart    echo echo "The nameserver has been restarted to ensure that the update     is complete."    echo "The previous named.ca file is now called   /var/named/named.ca.old."   ) 2>>&1 | /usr/lib/sendmail -t   exit 0 

Exercise 9-1: Set Up Your Own DNS Server

Following the example files shown previously, set up your own DNS server. Set it up to serve the domain called rhce.test. As long as your domain is private, it doesn't matter that rhce.test does not match the standard domain name types such as .com or .net.

1. Edit the /etc/named.conf file to reflect the configuration files that you plan to use. Name the zone file rhce.test.zone and set it to be a master domain.

2. Edit the file /var/named/rhce.test.zone and place the proper zone information in it. Start by adding in the header with the serial number and expiration information.

3. Add the SOA resource record (RR) with a proper administrative e-mail address contact.

4. Add NS and MX RRs for the domain. Use the 192.168.*.* address range. If you're configuring an actual TCP/IP network with static IP addresses, feel free to use the assigned IP addresses on your network.

5. Add several hosts to the zone file. Use WWW, FTP, and mail for a few.

6. Save the zone file and then restart named with the service named restart command.

7. Use the dig command to check the rhce.test domain. If it works, you have a working DNS server.

---