TCP/IP Network Administration

TCP/IP Network AdministrationSearch this book
Previous: 8.2 Configuring the Resolver Chapter 8
Configuring DNS Name Service
Next: 8.4 Using nslookup

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 configuration files are:


Sets general named parameters and points to the sources of domain database information used by this server. These sources can be local disk files or remote servers.

Points to the root domain servers


Used to locally resolve the loopback address


The zone file that maps hostnames to IP addresses


The zone file for the reverse domain that maps IP addresses to hostnames

The filenames shown here are generic names. We use them to make it easier to discuss the files in this text. The files can have any names you wish. Use the filenames named.boot and named.local for the boot file and the loopback address file. Use the name or one of the well-known alternatives, named.root and, for the file that lists the root servers. However, don't use the names named.hosts and named.rev for your zone files. Use descriptive names. In the following sections, we'll look at how each of these files is used, starting with named.boot.

8.3.1 The named.boot File

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

Table 8.1 summarizes the named.boot configuration statements used in this chapter. It provides just enough information to help you understand the examples. Not all of the named.boot 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 all of the named.boot configuration statements, Appendix C contains a full explanation of each command.

Table 8.1: named.boot Configuration Commands
directoryDefines a directory for all subsequent file references
primaryDeclares this server as primary for the specified zone
secondaryDeclares this server as secondary for the specified zone
cachePoints to the cache file
forwardersLists servers to which queries are forwarded
optionsEnables optional BIND processing
xfrnetsLimits zone transfers to specific addresses

The way in which you configure the named.boot file controls whether the nameserver acts as a primary server, a secondary server, or a caching-only server. The best way to understand these different configurations is to look at sample named.boot files. The next sections show examples of each type of configuration. Configuring a caching-only nameserver

A caching-only server configuration is simple. A named.boot file and a file are all that you need, though the named.local file is usually also used. The most common named.boot file for a caching-only server is:

;  a caching-only server configuration
primary         0.0.127.IN-ADDR.ARPA    /etc/named.local
cache           .                       /etc/

The only line in this sample file required for a caching-only configuration is the cache statement. It tells named to maintain a cache of nameserver responses, and to initialize the cache with the list of root servers found in the file The name of the file containing the root server list can be any name you wish, but root.cache, named.root, and are often used. The presence of a cache statement does not make this a caching-only configuration; a cache statement is used in every server configuration. It is the absence of primary and secondary statements that makes this a caching-only configuration.

However, there is one primary statement that is an exception to this rule. You'll see it in our sample named.boot file, and in almost every caching-only configuration. It defines the local server as the primary server for its own loopback domain, and it says that the information for the loopback domain is stored in the file named.local. The loopback domain is an domain [5] that maps the address to the name localhost. The idea of resolving your own loopback address makes sense to most people, so most named.boot files contain this entry.

[5] See Chapter 4, Getting Started , for a description of domains.

These primary and cache statements are the only statements used in most caching-only server configurations, but other statements can be added. A forwarders statement, and even an options statement are sometimes used. The forwarders statement causes the caching-only server to send all of the queries that it cannot resolve from its own cache to specific servers. For example:


This statement forwards every query that cannot be answered from the local cache to and The forwarders command 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 following statement to force the local server to always use the forwarder.

options forward-only

With this statement 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 forwarders or options statements does not change this from being a caching-only server configuration. Only the addition of primary and secondary commands will do that. Primary and secondary server configurations

The imaginary domain is the basis for our sample primary and secondary server configurations. Here is the named.boot file to define almond as the primary server for the domain:

; primary nameserver boot file.
directory                              /etc
primary                     named.hosts
primary   16.172.IN-ADDR.ARPA          named.rev
primary   0.0.127.IN-ADDR.ARPA         named.local
cache     .                  

The directory statement 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 /etc.

The first primary statement declares that this is the primary server for the domain, and that the data for that domain is loaded from the file named.hosts. In our examples, we'll use the filename named.hosts as the zone filename, but you should choose a more descriptive filename. For example, a better name for the zone file is

The second primary statement points to the file that maps IP addresses from to hostnames. This statement says that the local server is the primary server for the reverse domain, and that the data for that domain is loaded from the file named.rev. Again, the filename named.rev is just an example; use descriptive names in your actual configuration.

The format of a primary statement is the keyword primary, the domain name, and the name of the zone file from which the domain information is read. All primary statements have this simple format.

The final two statements in the sample configuration are the primary statement for the loopback domain and the cache statement. These statements are discussed earlier in the section about caching-only configurations. They have the same function in every configuration and are found in almost every configuration.

A secondary server's configuration differs from a primary's by using secondary instead of primary statements. Secondary statements point to remote servers as the source of the domain information instead of local disk files. Secondary statements begin with the keyword secondary, followed by the name of the domain, the address of one or more authoritative servers for that domain, and finally the name of a local file where information received from the remote server will be stored. The following named.boot file configures filbert as a secondary server for the domain:

; secondary nameserver boot file.
directory                                       /etc
secondary   16.172.IN-ADDR.ARPA   172.16.rev
primary     0.0.127.IN-ADDR.ARPA                named.local
cache       .                         

The first secondary statement makes this a secondary server for the domain. The statement tells named to download the data for the domain from the server at IP address, and to store that data in the file /etc/ If the 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 different from the data in the file. If the data has changed, named downloads the updated data and overwrites the file 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. [6] 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 only necessary to transfer the zone when the data changes.

[6] Appendix C (in the SOA record section) discusses how named determines if data has been updated.

The next line in this configuration says that the local server is also a secondary server for the reverse domain, and that the data for that domain should also be downloaded from The reverse domain data is stored locally in a file named 172.16.rev, following the same rules discussed previously for creating and overwriting

8.3.2 Standard Resource Records

The configuration commands discussed above and listed in Table 8.1 are used only in the named.boot file. All other files used to configure named (named.hosts, named.rev, named.local, and store domain 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 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 RecordRecordFunction
Text NameType
Start of AuthoritySOA

Marks the beginning of a zone's data, and defines parameters that affect the entire zone.

NameserverNSIdentifies a domain's nameserver.
AddressAConverts a hostname to an address.
PointerPTRConverts an address to a hostname.
Mail ExchangeMXIdentifies where to deliver mail for a given domain name.
Canonical NameCNAMEDefines an alias hostname.
Host InformationHINFODescribes a host's hardware and OS.
Well-Known ServiceWKSAdvertises network services.
TextTXTStores 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


This is the name of the domain object 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, the record applies to the domain object that was named last. For example, if the A record for peanut is followed by an MX record with a blank name field, both the A record and the MX record apply to peanut.


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 in the SOA record, is used. [7]

[7] See the section on SOA records in Appendix C.


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.


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.


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.

In the following sections we look at each of the remaining configuration files. As you look at the files, remember that all of the records in these files are standard resource records that follow the format described above.

8.3.3 The Cache Initialization File

The cache statement in named.boot points to a 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 nameserver starts. The root domain is indicated on the cache statement by a single dot, and the file contains the names and addresses of the root servers.

The file is sometimes called a "hints" file, because it contains hints named uses to initialize the cache. The hints it contains are the names and addresses of the root servers. It 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 file is not referred to often, but it is critical for booting a named server.

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

.                     3600000  IN  NS   A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.   3600000  IN  A
.                     3600000      NS   B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.   3600000  IN  A
.                     3600000      NS   C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.   3600000  IN  A
.                     3600000      NS   D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.   3600000  IN  A
.                     3600000      NS   E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.   3600000  IN  A
.                     3600000      NS   F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.   3600000  IN  A
.                     3600000      NS   G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.   3600000  IN  A
.                     3600000      NS   H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.   3600000  IN  A
.                     3600000      NS   I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.   3600000  IN  A

This file contains only nameserver and address records. Each NS record identifies a nameserver 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 file by downloading the file domain/named.root from ( via anonymous ftp. The file stored at the InterNIC is in the correct format for a UNIX system. The example below shows the superuser downloading the named.root file directly into the local system's file. The file doesn't even need to be edited: it is ready to run.

# ftp
Connected to
Name ( anonymous
331 Guest login ok, send your email address as password.
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get domain/named.root
200 PORT command successful.
150 Opening data connection for domain/named.root (2119 bytes).
226 Transfer complete.
2119 bytes received in 0.137 secs (15 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 cache file with the servers listed above would be useless. In this case, initialize your cache with entries that point to the major nameservers 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 is not connected to the Internet and that almond and pecan are going to act as root servers for this isolated domain. Both servers declare they are primary for the root domain in their named.boot files. They load the root from a zone file that contains NS records and A records, stating that they are authoritative for the root and delegating the and domains to the local nameservers 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.4 The named.local File

The named.local file is used to convert the address (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 as the "loopback" address, this file is virtually identical on every server. Here's a sample named.local file:

@          IN  SOA (
                        1               ; serial

                        360000          ; refresh every 100 hours
                        3600            ; retry after 1 hour
                        3600000         ; expire after 1000 hours
                        360000          ; default ttl is 100 hours
           IN  NS
0          IN  PTR      loopback.
1          IN  PTR      localhost.

Neither the NS record nor the first PTR record is required. The first PTR record maps the network to the name loopback, which is an alternative to mapping the network name in the /etc/networks file. Only the SOA record and the second PTR record are needed. The required PTR record is the same on every host: host address 1 on network 127.0.0 is mapped 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 as the server originating this zone, and the email address 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: jan is the user and is the host.) Many systems do not include the NS record; but when it is used, it 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.boot,, and named.local, are the only files required to configure caching-only servers and secondary 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, sample configuration files are available in the conf/master directory [8] of the bind.tar.gz file. This compressed tar file can be obtained via anonymous ftp from the isc/bind/src directory on The named.local file shown above was derived from the named.local sample that comes with BIND.

[8] The sample file in this directory is called root.cache.

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

8.3.5 The Reverse Domain File

The named.rev 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 named.rev file in our example is the zone file for the domain. The domain administrator creates this file on almond, and every other host that needs this information gets it from there.

;        Address to hostname mappings.
@       IN      SOA (
                                10099   ;   Serial
                                43200   ;   Refresh
                                3600    ;   Retry
                                3600000 ;   Expire
                                2592000 ) ; Minimum
                IN      NS
                IN      NS
                IN      NS
1.12            IN      PTR
2.12            IN      PTR
3.12            IN      PTR
4.12            IN      PTR
2.1             IN      PTR
6               IN      NS
                IN      NS

Like all zone files, the named.rev file begins with an SOA record. The @ in the name field of the SOA record references the current domain. In this case it is the domain defined by the primary statement in our sample named.boot file:

primary   16.172.IN-ADDR.ARPA              named.rev

The @ in the SOA record allows the primary 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.boot. Change the hostname ( and the manager's mail address (, and use this SOA record in any of your zone files.

The NS records that follow the SOA record define the nameservers for the domain. Generally the nameservers are listed immediately after the SOA, before any other record has the chance to modify the domain name. Recall that a blank name field means that the last domain name is still in force. The SOA's domain reference is still in force because the following NS records have blank name fields.

PTR records dominate the named.rev 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 The host name in the data field of the PTR record is fully qualified to prevent it from being relative to the current domain name. Using the information in this PTR, named will translate into

The last two lines of this file are additional NS records. As with any domain, subdomains can be created in an domain. This is what the last two NS records do. These NS records point to pecan and salt as nameservers for the subdomain Any query for information in the 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.

Subdomains in the domain are not as common or as useful as subdomains in the host namespace. 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 domain name, the four bytes of the address are treated as four distinct pieces. In reality, the IP address is 32 contiguous bits. Subnets divide up the IP address space and subnet masks are bit-oriented, which does not limit them to byte boundaries. subdomains divide up the domain name space and can only occur at a full byte boundary because each byte of the address is treated as a distinct "name."

8.3.6 The named.hosts File

The named.hosts 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 named.hosts file, like the named.rev file, is only created on the primary server. All others servers get this information from the primary server.

;       Addresses and other host information.
@       IN      SOA (
                                10118      ; Serial
                                43200      ; Refresh
                                3600       ; Retry
                                3600000    ; Expire
                                2592000 )  ; Minimum
;	Define the nameservers and the mail servers
                IN      NS
                IN      NS
                IN      NS
                IN      MX      10
                IN      MX      20
;       Define localhost
localhost       IN      A
;       Define the hosts in this zone
almond          IN      A
                IN      MX      5
loghost         IN      CNAME
peanut          IN      A
                IN      MX      5
goober          IN      CNAME
pecan           IN      A
walnut          IN      A
filbert         IN      A
;       host table has BOTH host and gateway entries for
mil-gw          IN      A
;    Glue records for servers within this domain
pack.plant      IN      A
acorn.sales     IN      A
;       Define sub-domains
plant           IN      NS
                IN      NS
sales           IN      NS
                IN      NS

Like the named.rev file, the named.hosts file begins with an SOA record and a few NS records that define the domain and its servers, but the named.hosts file contains a wider variety of resource records than a named.rev file does. We'll look at each of these records in the order in which they occur in the sample file, so that 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 almond is the mail server for with a preference of 10. Mail addressed to is redirected to almond for delivery. Of course for almond to successfully deliver the mail, it must be properly configured as a mail server. The MX record is only part of the story. We look at configuring sendmail in Chapter 10, sendmail .

The second MX record identifies pecan as a mail server for 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 domain to almond first; if almond is unavailable, try sending the mail to pecan." 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, but mail addressed to will still be sent directly to - not to almond or pecan. This configuration allows simplified mail addressing in the form 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 domain to enter the name localhost and have it resolved to the address by the local nameserver.

The next A record defines the IP address for almond. (Note that the records that relate to a single host are grouped together, which is the most common structure used in zone files.) The A record is followed by an MX record and a CNAME record that both relate to almond. The almond MX record points back to the host itself, and the CNAME record defines an alias for the host name.

This host-specific MX record is provided as a courtesy to remote mailers. Some mailer implementations look for an MX record first, and then query for the host's address. Providing an MX record saves these mailers one additional nameserver query.

peanut's A record is also followed by an MX record and a CNAME record. However, peanut's MX record serves a different purpose. It directs all mail addressed to to almond. This MX record is required because the MX records at the beginning of the zone file redirect mail only if it is addressed to If you also want to redirect mail addressed to peanut, you need a "peanut-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, almond can be referred to by the name loghost, and peanut can be referred to as goober. The loghost alias is a generic hostname used to direct syslogd output to almond. [9] Hostname aliases should not be used in other resource records. [10] 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.

[9] See Chapter 3 for a further discussion of generic hostnames.

[10] See Appendix C for additional information about using CNAME records in the named.hosts file.

Your named.hosts file will 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. Starting named

After you construct the named.boot file and the required zone files, start named. named is usually started at boot time from a startup script, but it can be started at the command prompt:

# named

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

[11] This file if found at /usr/adm/messages on both our Linux and Solaris sample systems but it might be located somewhere else on your system. Check your system's documentation.

Previous: 8.2 Configuring the Resolver TCP/IP Network AdministrationNext: 8.4 Using nslookup
8.2 Configuring the Resolver Book Index8.4 Using nslookup