Configuring named (TCP/IP Network Administration, 3rd Edition)

8.3. Configuring named

While the resolver configuration requires, at most, one configuration file, several files are used to configure named. The complete set of named files is:

The configuration file

All of these files can have any names you wish. However, you should use descriptive names for your zone files, the filenames named.conf and named.local for the boot file and the loopback address file, and one of the well-known names for the root hints file to make it easier for others to maintain your system. In the following sections, we'll look at how each of these files is used, starting with named.conf.

8.3.1. The named.conf File

The named.conf file points named to sources of DNS information. Some of these sources are local files; others are remote servers. You need to create only the files referenced in the master and cache statements. We'll look at an example of each type of file you may need to create.

The structure of the configuration commands in named.conf is similar to the structure of the C programming language. A statement ends with a semicolon (;), literals are enclosed in quotes (""), and related items are grouped together inside curly braces ({}). A comment can be enclosed between /* and */, like a C language comment; it can begin with //, like a C++ comment, or with #, like a shell comment. These examples use C++ style comments, but, of course, you can use any of the three valid styles you like.

Table 8-1 summarizes the basic named.conf configuration statements. It provides just enough information to help you understand the examples. Not all of the named.conf configuration commands are used in the examples, and you probably won't use all of the commands in your configuration. The commands are designed to cover the full spectrum of configurations, even the configurations of root servers. If you want more details about the named.conf configuration statements, Appendix C, "A named Reference" contains a full explanation of each command.

Table 8-1. named.conf configuration commands

Command	Function
acl	Defines an access control list of IP addresses
include	Includes another file into the configuration file
key	Defines security keys for authentication
logging	Defines what will be logged and where it will be stored
options	Defines global configuration options and defaults
server	Defines a remote server's characteristics
zone	Defines a zone

The way you configure the named.conf file controls whether the name server acts as a zone's master server, a zone's slave server, or a caching-only server. The best way to understand these different configurations is to look at sample named.conf files. The next sections show examples of each type of configuration.

8.3.1.1. A caching-only server configuration

A caching-only server configuration is simple. A named.conf file and a named.ca file are all that you need, though the named.local file is usually also used. A possible named.conf file for a caching-only server is:

$ cat /etc/named.conf
options {
        directory "/var/named";
};

//
// a caching only name server config
//
zone "." {
        type hint;
        file "named.ca";
};

zone "0.0.127.in-addr.arpa" {   
        type master;
        file "named.local";
};

The options statement defines the default directory for named. In the sample file, this is /var/named. All subsequent file references in the named.conf file are relative to this directory.

The two zone statements in this caching-only configuration are found in all server configurations. The first zone statement defines the hints file that is used to help the name server locate the root servers during startup. The second zone statement makes the server the master for its own loopback address, and says that the information for the loopback domain is stored in the file named.local. The loopback domain is an in-addr.arpa domain [86] that maps the address 127.0.0.1 to the name localhost. The idea of resolving your own loopback address makes sense to most people, and named.conf files should contain this entry. The hints file and the local host file, along with the named.conf file, are used for every server configuration.[87]

[86]See Chapter 4, "Getting Started" for a description of in-addr.arpa domains.

[87]BIND 8 requires the root hints file, but BIND 9 has hints compiled in that are used if no root hints file is provided.

These zone and options statements are the only statements used in most caching-only server configurations, but the options statement used can be more complex. A forwarders option and a forward only option are sometimes used. The forwarders option causes the caching-only server to send all of the queries that it cannot resolve from its own cache to specific servers. For example:

options {
        directory "/var/named";
        forwarders { 172.16.12.1; 172.16.1.2; };
};

This forwarders option forwards every query that cannot be answered from the local cache to 172.16.12.1 and 172.16.1.2. The forwarders option builds a rich DNS cache on selected servers located on the local network. This reduces the number of times that queries must be sent out on the wide area network, which is particularly useful if you have limited bandwidth to the wide area network or if you are charged for usage.

When network access to the outside world is severely limited, use the forward only option to force the local server to always use the forwarder:

options {
        directory "/var/named";
        forwarders { 172.16.12.1; 172.16.1.2; };
        forward only;
};

With this option in the configuration file, the local server will not attempt to resolve a query itself even if it cannot get an answer to that query from the forwarders.

Adding options to the options statements does not change this from being a caching-only server configuration. Only the addition of master and slave zone commands will do that.

8.3.1.2. Master and slave server configurations

The imaginary wrotethebook.com domain is the basis for our sample master and slave server configurations. Here is the named.conf file to define crab as the master server for the wrotethebook.com domain:

options {
        directory "/var/named";
};

// a master name server configuration
//
zone "." {
        type hint;
        file "named.ca";
};

zone "0.0.127.in-addr.arpa" {   
        type master;
        file "named.local";
};

zone "wrotethebook.com" {   
        type master;
        file "wrotethebook.com.hosts";
};

zone "16.172.in-addr.arpa" {   
        type master;
        file "172.16.rev";
};

The directory option saves keystrokes on the subsequent filenames. It tells named that all relative filenames (i.e., filenames that don't begin with a /), no matter where they occur in the named configuration, are relative to the directory /var/named. This option also tells named where to write various files, such as the dump file.

The first two zone statements in the sample configuration are the zone statements for the loopback address and the hints file. These statements were discussed earlier in reference to caching-only configurations. They always have the same function and are found in almost every configuration.

The first new zone statement declares that this is the master server for the wrotethebook.com domain and that the data for that domain is loaded from the file wrotethebook.com.hosts.

The second new zone statement points to the file that maps IP addresses from 172.16.0.0 to hostnames. This statement says that the local server is the master server for the reverse domain 16.172.in-addr.arpa and that the data for that domain is loaded from the file 172.16.rev.

A slave server's configuration differs from a master's only in the structure of the zone statements. Slave server zone statements point to remote servers as the source of the domain information instead of local disk files, and they define the zone as type slave. Unlike the file clause in a master zone statement, the file clause in a slave zone statement contains the name of a local file where information received from the remote server will be stored -- not a file from which the domain is loaded. The following named.conf file configures ora as a slave server for the wrotethebook.com domain:

options {
        directory "/var/named";
};

// a slave server configuration
//
zone "." {
        type hint;
        file "named.ca";
};

zone "0.0.127.in-addr.arpa" {   
        type master;
        file "named.local";
};

zone "wrotethebook.com" {   
        type slave;
        file "wrotethebook.hosts";
        masters { 172.16.12.1; };
};

zone "16.172.in-addr.arpa" {   
        type slave;
        file "172.16.rev";
        masters { 172.16.12.1; };
};

The first zone statement with its type set to slave makes this a slave server for the wrotethebook.com domain. The statement tells named to download the data for the wrotethebook.com domain from the server at IP address 172.16.12.1 and to store that data in the file /var/named/wrotethebook.hosts. If the wrotethebook.hosts file does not exist, named creates it, gets the zone data from the remote server, and writes the data in the newly created file. If the file does exist, named checks with the remote server to see if the remote server's data is newer than the data in the file. If the data has changed, named downloads the updated data and overwrites the file's contents with the new data. If the data has not changed, named loads the contents of the disk file and doesn't bother with a zone transfer.[88] Keeping a copy of the database on a local disk file makes it unnecessary to transfer the zone file every time the local host is rebooted. It's necessary to transfer the zone only when the data changes.

[88]Appendix C, "A named Reference" (in Section C.3.1.1, "Start of Authority record") discusses how named determines if data has been updated.

The last zone statement in this configuration says that the local server is also a slave server for the reverse domain 16.172.in-addr.arpa, and that the data for that domain should also be downloaded from 172.16.12.1. The reverse domain data is stored locally in a file named 172.16.rev, following the same rules discussed previously for creating and overwriting wrotethebook.hosts.

8.3.2. Standard Resource Records

The configuration commands discussed above and listed in Table 8-1 are used only in the named.conf file. All other files used to configure named (the zone file, the reverse zone file, named.local, and named.ca) store DNS database information. These files all have the same basic format and use the same type of database records. They use standard resource records, called RRs. These are defined in RFC 1033, the Domain Administrators Operations Guide, and in other RFCs. Table 8-2 summarizes all of the standard resource records used in this chapter. These records are covered in detail in Appendix C, "A named Reference".

Table 8-2. Standard resource records

Resource record text name	Record type	Function
Start of Authority	SOA	Marks the beginning of a zone's data and defines parameters that affect the entire zone.
Nameserver	NS	Identifies a domain's name server.
Address	A	Converts a hostname to an address.
Pointer	PTR	Converts an address to a hostname.
Mail Exchange	MX	Identifies where to deliver mail for a given domain name.
Canonical Name	CNAME	Defines an alias hostname.
Text	TXT	Stores arbitrary text strings.

The resource record syntax is described in Appendix C, "A named Reference", but a little understanding of the structure of these records is necessary to read the sample configuration files used in this chapter.

The format of DNS resource records is:

 [name] [ttl] IN type data

name: The name of the domain object that the resource record references. It can be an individual host or an entire domain. The string entered for the name field is relative to the current domain unless it ends with a dot. If the name field is blank, i.e., contains only whitespace, the record applies to the domain object that was named last. For example, if the A record for rodent is followed by an MX record with a blank name field, both the A record and the MX record apply to rodent.
ttl: Time-to-live defines the length of time, in seconds, that the information in this resource record should be kept in a remote system's cache. Usually this field is left blank and the default ttl, set for the entire zone by the $TTL directive, is used.[89]

[89]See the description of the $TTL directive later in this chapter.
IN: Identifies the record as an Internet DNS resource record. There are other classes of records, but they are rarely used. Curious? See Appendix C, "A named Reference" for the other, non-Internet, classes.
type: Identifies the kind of resource record. Table 8-2 lists the record types under the heading Record type. Specify one of these values in the type field.
data: The information specific to this type of resource record. For example, in an A record, this is the field that contains the actual IP address.

Later in this chapter we look at each of the remaining configuration files. As you look at the files, remember that all of the standard resource records in these files follow the format described above.

The bulk of a zone file is composed of standard resource records. In addition, BIND provides some zone file directives that are used to build a DNS database.

8.3.3. Zone File Directives

BIND provides four directives that simplify the construction of a zone file or define a value used by the resource records in the file. The four directives are evenly divided into two commands that simplify the construction of a zone file, $INCLUDE and $GENERATE, and two that define values used by the resource records, $ORIGIN and $TTL.

8.3.3.1. The $TTL directive

The $TTL directive defines the default TTL for resource records that do not specify an explicit time to live. The time value can be specified as a number of seconds or as a combination of numbers and letters. Defining one week as the default TTL using the numeric format is:

$TTL 604800

One week is equal to 604800 seconds. Using the alphanumeric format, one week can be defined simply as:

$TTL 1w

The possible values that can be used with the alphanumeric format are:

w for week
d for day
h for hour
m for minute
s for second

$ORIGIN 20.16.172.in-addr.arpa.
$GENERATE 1-4 $ CNAME $.1to4

The $GENERATE keyword is followed by the range of records to be created. In the example the range is 1 through 4. The range is followed by the template of the resource records to be generated. In this case, the template is $ CNAME $.1to4. A $ sign in the template is replaced by the current iterator value. In the example, the value iterates from 1 to 4. This $GENERATE directive produces the following resource records:

1 CNAME 1.1to4
2 CNAME 2.1to4
3 CNAME 3.1to4
4 CNAME 4.1to4

Given that 20.16.172.in-addr.arpa. is the value defined for the current origin, these resource records are the same as:

1.20.16.172.in-addr.arpa. CNAME 1.1to4.20.16.172.in-addr.arpa.
2.20.16.172.in-addr.arpa. CNAME 2.1to4.20.16.172.in-addr.arpa.
3.20.16.172.in-addr.arpa. CNAME 3.1to4.20.16.172.in-addr.arpa.
4.20.16.172.in-addr.arpa. CNAME 4.1to4.20.16.172.in-addr.arpa.

These odd-looking records are helpful for delegating reverse subdomains. Delegating domains is described later in this chapter.

Except for named.conf, all of the BIND configuration files are composed of standard records and directives. All four of the remaining configuration files are database files. Two of these files, named.ca and named.local, are used on all servers, regardless of server type.

8.3.4. The Cache Initialization File

The zone statement in named.conf that has its type set to hints points to the cache initialization file. Each server that maintains a cache has such a file. It contains the information needed to begin building a cache of domain data when the name server starts. The root domain is indicated on the zone statement by a single dot in the domain name field because the cache initialization file contains the names and addresses of the root servers.

The named.ca file is called a "hints" file because it contains hints that named uses to initialize the cache. The hints it contains are the names and addresses of the root servers. The hints file is used to help the local server locate a root server during startup. Once a root server is found, an authoritative list of root servers is downloaded from that server. The hints are not referred to again until the local server is forced to restart. The information in the named.ca file is not referred to often, but it is critical for booting a named server.

The basic named.ca file contains NS records that name the root servers and A records that provide the addresses of the root servers. A sample named.ca file is shown here:

; 
.                     3600000  IN  NS   A.ROOT-SERVERS.NET. 
A.ROOT-SERVERS.NET.   3600000  IN  A    198.41.0.4 
; 
.                     3600000      NS   B.ROOT-SERVERS.NET. 
B.ROOT-SERVERS.NET.   3600000  IN  A    128.9.0.107 
; 
.                     3600000      NS   C.ROOT-SERVERS.NET. 
C.ROOT-SERVERS.NET.   3600000  IN  A    192.33.4.12 
; 
.                     3600000      NS   D.ROOT-SERVERS.NET. 
D.ROOT-SERVERS.NET.   3600000  IN  A    128.8.10.90 
; 
.                     3600000      NS   E.ROOT-SERVERS.NET. 
E.ROOT-SERVERS.NET.   3600000  IN  A    192.203.230.10 
; 
.                     3600000      NS   F.ROOT-SERVERS.NET. 
F.ROOT-SERVERS.NET.   3600000  IN  A    192.5.5.241 
; 
.                     3600000      NS   G.ROOT-SERVERS.NET. 
G.ROOT-SERVERS.NET.   3600000  IN  A    192.112.36.4 
; 
.                     3600000      NS   H.ROOT-SERVERS.NET. 
H.ROOT-SERVERS.NET.   3600000  IN  A    128.63.2.53 
; 
.                     3600000      NS   I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.   3600000  IN  A    192.36.148.17
;
.                    3600000       NS  J.ROOT-SERVERS.NET. 
J.ROOT-SERVERS.NET.  3600000   IN  A   198.41.0.10
;
.                    3600000       NS  K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.  3600000   IN  A   193.0.14.129
;
.                    3600000       NS  L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.  3600000   IN  A   198.32.64.12
;
.                    3600000       NS  M.ROOT-SERVERS.NET.
.ROOT-SERVERS.NET.  3600000   IN  A   202.12.27.33

This file contains only name server and address records. Each NS record identifies a name server for the root (.) domain. The associated A record gives the address of each root server. The TTL value for all of these records is 3600000 -- a very large value that is approximately 42 days.

Create the named.ca file by downloading the file domain/named.root from ftp.rs.internic.net via anonymous ftp. The file stored there is in the correct format for a Unix system. The following example shows the superuser downloading the named.root file directly into the local system's named.ca file. The file doesn't even need to be edited; it is ready to run.

# ftp ftp.rs.internic.net
Connected to rs.internic.net.
220-*****Welcome to the InterNIC Registration Host  *****
    *****Login with username "anonymous"
    *****You may change directories to the following:
      policy            - Registration Policies
      templates         - Registration Templates
      netinfo           - NIC Information Files
      domain            - Root Domain Zone Files
220 And more!
Name (ftp.rs.internic.net:craig): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password: craig@wrotethebook.com
230 Guest login ok, access restrictions apply.
Remote system type is Unix.
Using binary mode to transfer files. 
ftp> get /domain/named.root /var/named/named.ca
local: /var/named/named.ca remote: /domain/named.root
200 PORT command successful.
150 Opening BINARY mode data connection for /domain/named.root (2769 bytes).
226 Transfer complete.
2769 bytes received in 0.998 secs (2.7 Kbytes/sec)
ftp> quit
221 Goodbye.

Download the named.root file every few months to keep accurate root server information in your cache. A bogus root server entry could cause problems with your local server. The data given above is correct as of publication, but could change at any time.

If your system is not connected to the Internet, it won't be able to communicate with the root servers. Initializing your hints file with the servers listed above would be useless. In this case, initialize your hints with entries that point to the major name servers on your local network. Those servers must also be configured to answer queries for the "root" domain. However, this root domain contains only NS records pointing to the domain servers on your local network. For example, assume that wrotethebook.com is not connected to the Internet and that crab and horseshoe are going to act as root servers for this isolated domain. crab is declared the master server for the root domain in its named.conf file. horseshoe is configured as the slave server for the root domain. They load the root from a zone file that starts with an SOA record identifying crab as the server and providing an in-house point of contact. Following the SOA record, the file contains NS records and A records, stating that crab and horseshoe are authoritative for the root and delegating the wrotethebook.com and 16.172.in-addr.arpa domains to the local name servers that service those domains. (How domains are delegated is covered later in the chapter.) Details of this type of configuration are provided in DNS and BIND by Liu and Albitz (O'Reilly & Associates).

8.3.5. The named.local File

The named.local file is used to convert the address 127.0.0.1 (the "loopback address") into the name localhost. It's the zone file for the reverse domain 0.0.127.IN-ADDR.ARPA. Because all systems use 127.0.0.1 as the "loopback" address, this file is virtually identical on every server. Here's a sample named.local file:

$TTL    86400
@       IN  SOA     crab.wrotethebook.com. alana.crab.wrotethebook.com. ( 
                    1               ; serial  
                    360000          ; refresh every 100 hours 
                    3600            ; retry after 1 hour 
                    3600000         ; expire after 1000 hours 
                    3600            ; negative cache is 1 hour 
                    ) 
        IN  NS      crab.wrotethebook.com. 
0       IN  PTR     loopback.
1       IN  PTR     localhost.

Most zone files start as this one does, with a $TTL directive. This directive sets the default TTL for all resource records in this zone. It can be overridden on any individual record by defining a specific TTL on that record.

The SOA record and the NS record identify the zone and the name server for the zone. The first PTR record maps the network 127.0.0.0 to the name loopback, which is an alternative to mapping the network name in the /etc/networks file. The second PTR record is the heart of this file. It maps host address 1 on network 127.0.0 to the name localhost.

The SOA record's data fields and the NS record that contains the computer's hostname vary from system to system. The sample SOA record identifies crab.wrotethebook.com. as the server originating this zone, and the email address alana.crab.wrotethebook.com. as the point of contact for any questions about the zone. (Note that in an SOA record, the email address is written with a dot separating the recipient's name from the hostname: alana is the user and crab.wrotethebook.com is the host. The domain names end in a dot, indicating that they are fully qualified and no default domain name should be appended.) The NS record also contains the computer's hostname. Change these three data fields and you can use this identical file on any host.

The files discussed so far, named.conf, named.ca, and named.local, are the only files required to configure caching-only servers and slave servers. Most of your servers will use only these files, and the files used will contain almost identical information on every server. The simplest way to create these three files is to copy a sample file and modify it for your system. Most systems come with sample files. If your system doesn't, get sample configuration files from a running server.

The remaining named configuration files are more complex, but the relative number of systems that require these files is small. Only the master server needs all of the configuration files, and there should be only one master server per zone.

8.3.6. The Reverse Zone File

The reverse zone file is very similar in structure to the named.local file. Both of these files translate IP addresses into hostnames, so both files contain PTR records.

The 172.16.rev file in our example is the reverse zone file for the 16.172.in-addr.arpa domain. The domain administrator creates this file on crab, and every other host that needs this information gets it from there.

$TTL 86400
; 
;        Address to hostname mappings. 
; 
@       IN      SOA     crab.wrotethebook.com. jan.crab.wrotethebook.com. ( 
                                2001061401   ;   Serial 
                                21600        ;   Refresh 
                                1800         ;   Retry 
                                604800       ;   Expire 
                                900 )        ;   Negative cache TTL 
                IN      NS      crab.wrotethebook.com. 
                IN      NS      ora.wrotethebook.com. 
                IN      NS      bigserver.isp.com. 
1.12            IN      PTR     crab.wrotethebook.com. 
2.12            IN      PTR     rodent.wrotethebook.com. 
3.12            IN      PTR     horseshoe.wrotethebook.com. 
4.12            IN      PTR     jerboas.wrotethebook.com. 
2.1             IN      PTR     ora.wrotethebook.com. 
6               IN      NS      linuxuser.articles.wrotethebook.com.
                IN      NS      horseshoe.wrotethebook.com.

Like all zone files, the first resource record in the reverse zone file is an SOA record. The @ in the name field of the SOA record references the current origin. Because this zone file does not contain an $ORIGIN directive to explicitly define the origin, the current origin is the domain 16.172.in-addr.arpa defined by the zone statement for this file in our sample named.conf file:

 zone "16.172.in-addr.arpa" {   
        type master;
        file "172.16.rev";
};

The @ in the SOA record allows the zone statement to define the zone file domain. This same SOA record is used on every zone; it always references the correct domain name because it references the domain defined for that particular zone file in named.conf. Change the hostname (crab.wrotethebook.com.) and the manager's mail address (jan.crab.wrotethebook.com.), and use this SOA record in any of your zone files.

The NS records that follow the SOA record define the name servers for the domain. Generally the name servers are listed immediately after the SOA and have a blank name field. Recall that a blank name field means that the last domain name is still in force. This means that the NS records apply to the same domain as the SOA's.

PTR records dominate the reverse zone file because they are used to translate addresses to hostnames. The PTR records in our example provide address-to-name conversions for hosts 12.1, 12.2, 12.3, 12.4, and 2.1 on network 172.16. Because they don't end in dots, the values in the name fields of these PTR records are relative to the current domain. For example, the value 3.12 is interpreted as 3.12.16.172.in-addr.arpa. The hostname in the data field of the PTR record is fully qualified to prevent it from being relative to the current domain name (and therefore it ends with a dot). Using the information in this PTR, named will translate 3.12.16.172.in-addr.arpa into horseshoe.wrotethebook.com.

The last two lines of this file are additional NS records. As with any domain, subdomains can be created in an in-addr.arpa domain. This is what the last two NS records do. These NS records point to horseshoe and linuxuser as name servers for the subdomain 6.16.172.in-addr.arpa. Any query for information in the 6.16.172.in-addr.arpa subdomain is referred to them. NS records that point to the servers for a subdomain must be placed in the higher-level domain before you can use that subdomain.

Domain names and IP addresses are not the same thing and do not have the same structure. When an IP address is turned into an in-addr.arpa domain name, the four bytes of the address are treated as four distinct pieces of a name. In reality, the IP address is 32 contiguous bits, not four distinct bytes. Subnets divide up the IP address space and subnet masks are bit-oriented, which does not limit them to byte boundaries. Limiting subdomains to byte boundaries makes them less flexible than the subnets they must support. Our example in-addr.arpa domain delegates the subdomain at a full byte boundary, which treats each byte of the address as a distinct "name." This is the simplest reverse subdomain delegation, but it might not be flexible enough for your situation.

The $GENERATE example shown earlier in this chapter helps create more flexible reverse domain delegations. The $GENERATE directive created CNAME records to map a range of addresses in an in-addr.arpa domain to a different domain that has more flexible domain name rules. Real in-addr.arpa domain names must be four numeric fields, corresponding to the four bytes of the IP address, followed by the string in-addr.arpa. In the $GENERATE example, we mapped these names to longer names that give us more flexibility. Here is a larger example of the $GENERATE command:

$ORIGIN 30.168.192.in-addr.arpa.
$GENERATE 0-63    $ CNAME $.1ST64
$GENERATE 63-127  $ CNAME $.2ND64
$GENERATE 128-191 $ CNAME $.3RD64
$GENERATE 192-255 $ CNAME $.4TH64

These four $GENERATE commands map the 256 numeric names in the 30.168.192.in-addr.arpa domain into four other domains, each composed of 64 numeric names. When a remote server seeks the PTR record for 52.30.168.192.in-addr.arpa, it is told that the canonical name for that host is 52.1st64.30.168.192.in-addr.arpa and that the server must seek the pointer record for that host from the server for the 1st64.30.168.192.in-addr.arpa domain. In effect, the $GENERATE directive lets us divide the single 30.168.192.in-addr.arpa domain into multiple domains. Once it is divided, each piece can be delegated to a different server.

Subdomain delegation can make reverse domains complex.[90] In most cases, however, reverse zone files are simpler than the forward-mapping zone file.

[90]For even more complex examples, see DNS and BIND by Albitz and Liu.

8.3.7. The Forward-Mapping Zone File

The forward-mapping zone file contains most of the domain information. This file converts hostnames to IP addresses, so A records predominate, but it also contains MX, CNAME, and other records. The zone file, like the reverse zone file, is created only on the master server; all other servers get this information from the master server.

$TTL 86400
; 
;       Addresses and other host information. 
; 
@      IN      SOA     crab.wrotethebook.com. jan.crab.wrotethebook.com. ( 
                                2001061401   ;   Serial 
                                21600        ;   Refresh 
                                1800         ;   Retry 
                                604800       ;   Expire 
                                900 )        ;   Negative cache TTL 
;       Define the name servers and the mail servers 
                IN      NS      crab.wrotethebook.com. 
                IN      NS      ora.wrotethebook.com. 
                IN      NS      bigserver.isp.com. 
                IN      MX      10 crab.wrotethebook.com. 
                IN      MX      20 horseshoe.wrotethebook.com. 
; 
;       Define localhost 
; 
localhost       IN      A       127.0.0.1 
; 
;       Define the hosts in this zone 
; 
crab            IN      A       172.16.12.1 
loghost         IN      CNAME   crab.wrotethebook.com. 
rodent          IN      A       172.16.12.2 
                IN      MX      5 crab.wrotethebook.com. 
mouse           IN      CNAME   rodent.wrotethebook.com. 
horseshoe       IN      A       172.16.12.3 
jerboas         IN      A       172.16.12.4 
ora             IN      A       172.16.1.2 
;       host table has BOTH host and gateway entries for 10.104.0.19 
wtb-gw          IN      A       10.104.0.19 
; 
;    Glue records for servers within this domain 
; 
linuxmag.articles  IN      A       172.16.18.15 
24seven.events     IN      A       172.16.6.1 
; 
;       Define sub-domains 
; 
articles           IN      NS      linuxmag.articles.wrotethebook.com. 
                   IN      NS      horseshoe.wrotethebook.com. 
events             IN      NS      24seven.events.wrotethebook.com.
                   IN      NS      linuxmag.articles.wrotethebook.com.

Like the reverse zone file, the zone file begins with an SOA record and a few NS records that define the domain and its servers, but the zone file contains a wider variety of resource records than a reverse zone file does. We'll look at each of these records in the order they occur in the sample file, so you can follow along using the sample file as your reference.

The first MX record identifies a mail server for the entire domain. This record says that crab is the mail server for wrotethebook.com with a preference of 10. Mail addressed to user@wrotethebook.com is redirected to crab for delivery. Of course, for crab to successfully deliver the mail, it must be properly configured as a mail server. The MX record is only part of the story. We look at configuring sendmail in Chapter 10, "sendmail ".

The second MX record identifies horseshoe as a mail server for wrotethebook.com with a preference of 20. Preference numbers let you define alternate mail servers. The lower the preference number, the more desirable the server. Therefore, our two sample MX records say "send mail for the wrotethebook.com domain to crab first; if crab is unavailable, try sending the mail to horseshoe." Rather than relying on a single mail server, preference numbers allow you to create backup servers. If the main mail server is unreachable, the domain's mail is sent to one of the backups instead.

These sample MX records redirect mail addressed to wrotethebook.com, but mail addressed to user@jerboas.wrotethebook.com will still be sent directly to jerboas.wrotethebook.com -- not to crab or horseshoe. This configuration allows simplified mail addressing in the form user@wrotethebook.com for those who want to take advantage of it, but it continues to allow direct mail delivery to individual hosts for those who wish to take advantage of that.

The first A record in this example defines the address for localhost. This is the opposite of the PTR entry in the named.local file. It allows users within the wrotethebook.com domain to enter the name localhost and have it resolved to the address 127.0.0.1 by the local name server.

The next A record defines the IP address for crab, which is the master server for this domain. This A record is followed by a CNAME record that defines loghost as an alias for crab.

rodent's A record is followed by an MX record and a CNAME record. (Note that the records that relate to a single host are grouped together, which is the most common structure used in zone file.) rodent's MX record directs all mail addressed to user@rodent.wrotethebook.com to crab. This MX record is required because the MX records at the beginning of the zone file redirect mail only if it is addressed to user@wrotethebook.com. If you also want to redirect mail addressed to rodent, you need a "rodent-specific" MX record.

The name field of the CNAME record contains an alias for the official hostname. The official name, called the canonical name, is provided in the data field of the record. Because of these records, crab can be referred to by the name loghost, and rodent can be referred to as mouse. The loghost alias is a generic hostname used to direct syslogd output to crab.[91] Hostname aliases should not be used in other resource records.[92] For example, don't use an alias as the name of a mail server in an MX record. Use only the canonical (official) name that's defined in an A record.

[91]See Chapter 3, "Network Services" for a further discussion of generic hostnames.

[92]See Appendix C, "A named Reference" for additional information about using CNAME records in the zone data file.

Your zone file could be much larger than the sample file we've discussed, but it will contain essentially the same records. If you know the names and addresses of the hosts in your domain, you have most of the information necessary to create the named configuration.

8.3.8. Controlling the named Process

After you construct the named.conf file and the required zone files, start named. named is usually started at boot time from a startup script. On a Solaris 8 system, named is started by the /etc/init.d/inetsvc script. On a Red Hat Linux system, the script that starts named is /etc/rc.d/init.d/named. The Red Hat script can be run from the command prompt with optional arguments. For example, on a Red Hat system, the following command can be used to stop the name server:

# /etc/rc.d/init.d/named stop

To resume name service, use the command:

# /etc/rc.d/init.d/named start

Startup scripts work, but the named control (ndc) program is a more effective tool for managing the named process. It comes with BIND 8 and provides a variety of functions designed to help you manage named. BIND 9 has a similar tool named rndc. Table 8-3 lists the ndc options and the purpose of each.[93]

[93]At this writing, the status, trace, and restart commands are not yet implemented for rndc.

Table 8-3. ndc options

Option	Function
status	Displays the process status of named.
dumpdb	Dumps the cache to named_dump.db.[94]
reload	Reloads the name server.
stats	Dumps statistics to named.stats.
trace	Turns on tracing to named.run.
notrace	Turns off tracing and closes named.run.
querylog	Toggles query logging, which logs each incoming query to syslogd.
start	Starts named.
stop	Stops named.
restart	Stops the current named process and starts a new one.

[94]This file is stored in the directory defined by the directory option in the named.conf file.

ndc options are simple to understand and easy to use. The following commands would stop, then restart the named process:

# ndc stop
# ndc start
new pid is 795

This command sequence assumes that there is some length of time between stopping the old named process and starting a new one. If you really want to quickly kill and restart the named process, use the restart option:

# ndc restart
new pid is 798

The first time you run named, watch for error messages. named logs errors to the messages file.[95] Once named is running to your satisfaction, use nslookup to query the name server to make sure it is providing the correct information.

[95]This file is found in /usr/adm/messages on our Solaris system and in /var/log/messages on our Red Hat system. It might be located somewhere else on your system; check your documentation.