BIND configurations are described by the type of service the software is configured to provide. The four levels of service that can be defined in a BIND configuration are resolver-only systems, caching-only servers, master servers, and slave servers.

The resolver is the code that asks name servers for domain information. On Unix systems, it is implemented as a library rather than as a separate client program. Some systems, called resolver-only systems, use only the resolver; they don’t run a name server. Resolver-only systems are very easy to configure: you just need to set up the /etc/resolv.conf file.

The three other BIND configurations all require that the local system run the named server software. They are:

A name server may use any one of these configurations or, as is often the case, it may combine elements of more than one type of configuration. However, all systems run the resolver, so let’s begin by examining the configuration of the client side of the DNS software.

The configuration file clearly documents the resolver configuration. It allows you to identify up to three name servers, two of which provide backup if the first server doesn’t respond. It defines the default domain and various other processing options. The resolv.conf file is a critical part of configuring name service.

resolv.conf is a simple, human-readable file. There are system-specific variations in the commands used in the file, but the entries supported by most systems are:

The most common resolv.conf configuration defines the local domain name as the search list, the local host as the first name server, and one or two backup name servers. An example of this configuration is:

# Domain name resolver configuration file 
# 
search wrotethebook.com 
# try yourself first 
nameserver 172.16.12.2 
# try crab next 
nameserver 172.16.12.1 
# finally try ora
nameserver 172.16.1.2

The example is based on our imaginary network, so the default domain name is wrotethebook.com. The configuration is for rodent, and it specifies itself as the first name server. The backup servers are crab and ora. The configuration does not contain a sort list or any options, as these are infrequently used. This is an example of an average resolver configuration.

# Domain name resolver configuration file 
# 
search wrotethebook.com 
# try crab 
nameserver 172.16.12.1 
# next try ora
nameserver 172.16.1.2

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 contains a full explanation of each command.

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.

$ 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";
};

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

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

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";
};

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 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.

The resource record syntax is described in Appendix C, 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

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.

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.

$TTL 604800

$TTL 1w

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

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

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.

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.
M.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).

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.

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.

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.

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.

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.

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]

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.^[94] Once named is running to your satisfaction, use nslookup to query the name server to make sure it is providing the correct information.