Certification Objective 11.02-The Berkeley Internet Name Domain (BIND)

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.

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 

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

The DNS Configuration Files

DNS configuration files are required to configure your Linux computer as a client and as a server. The client configuration was described earlier in this section. There are a number of additional configuration files that support the use of DNS as a server, as described in Table 11-1. You may have to create some of these files as you configure DNS. If you've installed the bind-chroot package, you'll find the real copy of these files in the /var/named/chroot/var/named directory, linked to /var/named.

Table 11-1: DNS Server Configuration Files

DNS Configuration File	Description
/etc/sysconfig/named	Set up different configuration and data file directories through this file.
/etc/named.conf	The main DNS configuration file. Incorporates data from other files with the include directive.
/etc/named-caching-nameserver.conf	A template DNS configuration file for a caching DNS server.
/etc/named.rfc1912.zones	Adds appropriate zones for localhost names and addresses.
/var/named/chroot/etc/rndc.key	The authentication key required to support requests to the DNS server.
/var/named/my.internal.zone.db	The zone file for the local network.
/var/named/slaves/my.slave.internal.zone.db	The zone file for a slave DNS server.
/var/named/slaves/my.ddns.internal.zone.db	The zone file for a dynamic DNS server.
/var/named/localdomain.zone	The zone file for the localhost's domain.
/var/named/localhost.zone	The zone file for the localhost computer.
/var/named/named.broadcast	A broadcast record for the localhost.
/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.ip6.local	An IPv6 version of named.local.
/var/named/named.zero	Defaults to the broadcast record for the localhost.
/var/named/data/named.stats.txt	Statistics from your DNS server, only available after DNS is active.

As noted in the default copy of /etc/sysconfig/named, the ROOTDIR directive points to /var/named/chroot/ as the root directory for all other DNS server configuration files. We assume that you've installed bind-chroot, in which case, all files in Table 11-1 are in that directory unless otherwise noted. Some may be linked to that directory. For example, once created, /etc/named.conf is actually a soft link to /var/ named/chroot/etc/named.conf.

In many cases, you do not have to use the file names listed in Table 11-1. All you need to do is make sure the file is properly cited in the main named.conf configuration file. Remember that if you've installed the bind-chroot RPM, these files will be linked to files in the /var/named/chroot/ directory.

Many of these files include templates in the DNS documentation directory, /usr/share/doc/bind-versionnum/sample.

In the following sections, you'll see 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/named.local lists the local computer as:

 localhost. 

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

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 .caching-nameserver.conf configuration file. The directives in the default version of this file are shown in Figure 11-1.

Figure 11-1: /etc/named .caching-nameserver.conf

Exam Watch

The current version of the Red Hat Exam Prep guide suggests that you need to know how to configure a caching-only DNS server for the RHCE exam.

• The options directive encompasses several basic DNS directives, including the following:

  • The listen-on port (and listen-on-v6 port) directives-as well as the query-source port (and query-source-v6 port) directives-specify the TCP/IP port number (for IPv4 and IPv6).

    If you're extending this to your local network, you'll need to include the IP address of the local network card. For example, if it's 192.168.0.15, the directive would be (don't forget the semicolon after each IP address)

     listen-on port 53 { 127.0.0.1; 192.168.0.15; } 

  • The directory directive tells your DNS server where to look for data files. Remember that if you've installed the bind-chroot RPM, these files will be linked to /var/named/chroot/ subdirectories.

  • The dump-file specifies the cache for the current DNS database and the output from the rndc dumpdb command.

  • The statistics-file specifies the cache for the current DNS database and the output from the rndc stats command.

  • The memstatistics-file specifies the location for memory usage statistics.

  • The allow-query lists the IP addresses allowed to get information from this server. If you want to extend this to the 192.168.0.0 network, you could change this directive to this:

     allow-query { 127.0.0.1; 192.168.0.0/24; } 

• The logging directive specifies several more parameters; the channel directive specifies output methods, in this case to default_debug, activated in the data/ named.run subdirectory, logging only dynamic issues.

• The view localhost_resolver directive identifies this caching nameserver as the client and destination for the localhost computer, with the settings described in /etc/named.rfc1912.zones.

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.

Now, to create a caching DNS server, all you need to do is copy the /var/named/chroot/ etc/named.caching-nameserver.conf file to /var/named/chroot/etc/named.conf, and make the changes suggested in this section. As described in the comments to this file, changes are overwritten if you use the Red Hat BIND configuration tool, but if the changes you need to make are so simple, why bother?

Exam Watch

If you need an iptables firewall and have enabled the query-source address * port 53; directive, enable UDP communication through port 53.

A Slave Name Server

Note that there is no 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.org" IN {     type slave;     file "slaves/example.com.org";     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/chroot/var/named/slaves directory.

A Forwarding-Only Name Server

This type of DNS server is simple. It requires a single command in the /etc/named .conf configuration file (remember that it's linked to /var/named/chroot/etc/named .conf). 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;      }; }; 

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 used the /var/named/named.ca file described later in this chapter.

named.ca

If your DNS servers don't have the IP address for a domain name in the database, that server can refer to other databases. By default, the DNS server refers to the /var/named/named.ca file, which is a list of the root DNS servers for the Internet. (This file is normally linked to /var/named/chroot/var/named/named.ca.) An excerpt is shown in Figure 11-2.

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

localhost.zone

The default /var/named/localhost.zone file is shown in Figure 11-3. (Remember, it's linked to /var/named/chroot/var/named/localhost.zone.) It incorporates a basic DNS entry for the local computer, which you can use as a template for other computers on your network.

Figure 11-3: The localhost.zone DNS datafile

Reverse Lookups with named.local

The /var/named/named.local file provides a reverse-lookup record for your computer, as localhost. (Remember, it's linked to /var/named/chroot/var/named/localhost.zone.) As shown in Figure 11-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 11-4: The named.local reverse DNS file

Configuring a Simple Domain

Review the /etc/named.rfc1912.zones configuration template file. With what we know about DNS configuration files, we can use it to create a master DNS server. Assume that you've defined a simple domain for the computers on your network; call it example.org.

On the Job 

The example.com, example.net, and example.org domains are generic domain names that can't be assigned on the Internet. You can therefore use any of these domain names on your private network.

Exam Watch

The current version of the Red Hat Exam Prep guide suggests that you need to know how to configure only a slave and caching DNS name server for the RHCE exam. However, understanding how to create a master DNS name server is an important skill for Linux system administrators.

Before you continue, activate the named_write_master_zones SELinux setting. You can do so from the SELinux Management Tool, or by running the following command:

 # setsebool -P named_write_master_zones 1 

Now return to the named.conf file. Look at the zone "0.0.127.in-addr.arpa" IN line near the middle of this 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 localhost (allow-update { none; }).

On the Job 

Not all characters are allowed in host names. 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.

Copy the named.rfc1912.zones file to /etc/named.conf. But wait-remember that it's based on links to the /var/named/chroot/etc/ directory. So to preserve the links, make the change with commands such as these:

 # cd /var/named/chroot/etc # cp named.rfc1912.zones named.conf 

But that's not enough. You need to tell DNS where to look, and more. The simplest solution is to open the file in a text editor and then add the options stanza described earlier for the caching nameserver:

 options {         listen-on port 53 { 127.0.0.1; 192.168.0.15; };         listen-on-v6 port 53 { ::1; };         directory       "/var/named";         dump-file       "/var/named/data/cache_dump.db";         statistics-file "/var/named/data/named_stats.txt";         memstatistics-file "/var/named/data/named_mem_stats.txt";         query-source    port 53;         query-source-v6 port 53;         allow-query    { localhost; 192.168.0.0/24; }; }; 

This isn't the default options directive from /etc/named.caching-nameserver.conf. Notice how I added the IP address for my network card to the listen-on port 53 directive (192.168.0.15) and the network address to the allow-query directive.

Now you can add your network to your DNS server. Start by inserting new forward and reverse zone sections in the /etc/named.conf file, followed by the include "/etc/rndc.key"; directive. (I assume that you're not going to overwrite these changes with the Red Hat GUI Domain Name Service tool.) The following is based on my example.org domain, on the 192.168.0.0/24 network:

 zone "example.org" IN {     type master;     file "example.org.zone"; }; zone "0.168.192.in-addr.arpa" IN {     type master;     file "example.org.rr.zone"; }; include "/etc/rndc.key"; 

For further guidance, see the named.conf file in the /usr/share/doc/bind-9.3.3/ sample/etc/ directory.

Creating an RNDC Key

Now you need to create an RNDC (Remote Name Daemon Control) key and configuration file in the /etc/ directory, linked to actual locations in the /var/named/ chroot/etc directory. The simplest method is with the rndc-confgen command, which sets up entries for the aforementioned files:

 # rndc-confgen # Start of rndc.conf key "rndckey" {         algorithm hmac-md5;         secret "jRqhTi7E4pjZcvjJ/GdT0g=="; }; options {         default-key "rndckey";         default-server 127.0.0.1;         default-port 953; }; # End of rndc.conf # Use with the following in named.conf, adjusting the allow list as needed: # key "rndckey" { #       algorithm hmac-md5; #       secret "jRqhTi7E4pjZcvjJ/GdT0g=="; # }; # # controls { #       inet 127.0.0.1 port 953 #               allow { 127.0.0.1; } keys { "rndckey"; }; # }; # End of named.conf 

While you could substitute entries as noted, that would override expected directives in RHEL's /etc/rndc.key. Fortunately, there's an easier way, which automatically includes a key in /etc/rndc.key (which is linked to /var/named/chroot/etc/rndc.key). The -b 512 switch includes a 512 bit encryption key:

 # rndc-confgen -a -b 512 

And the following entry in /etc/named.conf refers to the rndc.key file:

 include "/etc/rndc.key"; 

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.org.zone file in the /var/named directory (linked to /var/named/chroot/var/named/example.org.zone). I've created one for my own network, as shown in Figure 11-5.

Figure 11-5: An example.org .zone file

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

$TTL 86400 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 3D, which corresponds to three days. 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 enterprise5vm.example.org), 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 11-5, this database file is the first one created for this server on February 27, 2007.

• 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 TTL 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-in this case, enterprise5vm.example.org.

The MX is the Mail Exchange record, which directs e-mail information to a particular computer-in this case it's also enterprise5vm.example.org. Some number such as what's shown (10) is required with any MX record. If you have multiple mail servers, the number specifies the priority (lower numbers are served first).

In my example.org.zone file shown in Figure 11-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, www1.example.org is also known as enterprise5a .example.org.

CNAME allows you to assign several names to each computer. In this case, www1 is an alias for the enterprise5a computer. You can use additional CNAME directives to specify the same address for an FTP or even an rsync server. However, a CNAME is not a legal host name for an e-mail address. For example, [e-mail] won't work based on the example.org.zone file shown in the figure.

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

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

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

Save this file, and reread the configuration files with the rndc reload command.

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 backward, from an IP address to a host name. 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 whether 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 "0.168.192.in-addr.arpa" IN {           type master;           file "example.com.rr.zone"; }; 

This is similar to the 0.0.127.in-addr.arpa zone 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 11-6.

Figure 11-6: 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 rndc 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 rndc stop command and check the applicable configuration files.

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 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. When I change web hosts, I'm told to wait up to 48 hours until propagation is complete. 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, the server 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, don't forget to 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 a 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, to avoid network-wide problems.