While the resolver configuration requires, at most, one configuration file,
several files are used to configure named. The complete set of named files is:
Sets general named
parameters and points to the sources of DNS database information
used by this server. These sources can be local disk files or
remote servers. This file is usually called
named.conf .
Points to the root zone servers. Some common names for this file are named.ca, db.cache, named.root, or root.ca.
Used to locally resolve the loopback address. The filename named.local is generally used for this file.
The zone file that maps hostnames to IP addresses. This is the file that contains the bulk of the information about the zone. To make it easier to discuss this file, this text generally refers to it as the zone file, dropping the “forward-mapping” qualifier. The zone file is generally given a descriptive name, such as wrotethebook.com.hosts, that identifies which zone’s data is contained in the file.
The zone file that maps IP addresses to hostnames. To make it easier to discuss this file, this text generally refers to it as the reverse zone file. The reverse zone file is generally given a descriptive name, such as 172.16.rev, that identifies which IP address is mapped by the 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.
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.
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.
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]
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.
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.
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.
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.
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, 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] INtype data
nameThe 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.
ttlTime-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]
INIdentifies the record as an Internet DNS resource record. There are other classes of records, but they are rarely used. Curious? See Appendix C for the other, non-Internet, classes.
typeIdentifies 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.
dataThe 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.
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.
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
The $ORIGIN directive sets the current origin, which is
the domain name used to complete any relative domain names. A
relative domain name is any name that does not end with a dot. By
default, $ORIGIN starts out as the domain name defined on the
zone statement. Use the $ORIGIN
directive to change the setting.
The $INCLUDE directive reads in an external file and includes it as part of the zone file. The external file is included in the zone file at the point where the $INCLUDE directive occurs.
The $GENERATE directive is used to create a series of resource records. The resource records created by the $GENERATE directive are almost identical, varying only by a numeric iterator. For example:
$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.
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 stopTo resume name service, use the command:
# /etc/rc.d/init.d/named startStartup 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]
Table 8-3. ndc options
Option | Function |
|---|---|
status | Displays the process status of named. |
dumpdb | Dumps the cache to named_dump.db.[a] |
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. |
[a] 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 798The 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.
[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.
[88] Appendix C (in Section C.3.1.1)
discusses how named
determines if data has been updated.
[89] See the description of the $TTL directive later in this chapter.
[90] For even more complex examples, see DNS and BIND by Albitz and Liu.
[92] See Appendix C for additional information about using CNAME records in the zone data file.
[93] At this writing, the status, trace, and restart commands are not yet implemented
for rndc.
[94] 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.