Section 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
-
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.
- The root hints file
-
Points to the root zone servers. Some common names for this file are named.ca, db.cache, named.root, or root.ca.
- The localhost file
-
Used to locally resolve the loopback address. The filename named.local is generally used for this file.
- The forward-mapping zone 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 reverse-mapping zone 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.
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 contains a full explanation of each command.
|
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[5] 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.[6]
[5] See Chapter 4 for a description of in-addr.arpa domains.
[6] 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 storednot 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.[7] 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.
[7] Appendix C (in Section C.3.1.1) 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.
|
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] 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.[8]
[8] 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 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
8.3.3.2 The $ORIGIN directive
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.
8.3.3.3 The $INCLUDE directive
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.
8.3.3.4 The $GENERATE directive
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.
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. 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 3600000a 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.[9] In most cases, however, reverse zone files are simpler than the forward-mapping zone file.
[9] 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.
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.comnot 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.[10] Hostname aliases should not be used in other resource records.[11] 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.
[10] See Chapter 3 for a further discussion of generic hostnames.
[11] See Appendix C 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.[12]
[12] At this writing, the status, trace, and restart commands are not yet implemented for rndc.
|
Option |
Function |
|---|---|
|
status |
Displays the process status of named. |
|
dumpdb |
Dumps the cache to named_dump.db.[13] |
|
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. |
[13] 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.[14] Once named is running to your satisfaction, use nslookup to query the name server to make sure it is providing the correct information.
[14] 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.
