On most modern networks, including the Internet, users locate other
computers by name. This frees users from the daunting task of remembering
the numerical network address of network resources. The most effective way
to configure a network to allow such name-based connections is to set up a
Domain Name Service (DNS) or a
nameserver, which resolves hostnames on the network
to numerical addresses and vice versa.
This chapter reviews the nameserver included in Red Hat Enterprise Linux, the
Berkeley Internet Name Domain
(BIND) DNS server, with an emphasis on the
structure of its configuration files and how it may be administered both
locally and remotely.
When hosts on a network connect to one another via a hostname, also
called a fully qualified domain name (FQDN),
DNS is used to associate the names of machines to the IP address for the
host.
Use of DNS and FQDNs also has advantages for system
administrators, allowing the flexibility to change the IP address for a
host without effecting name-based queries to the machine. Conversely,
administrators can shuffle which machines handle a name-based query.
DNS is normally implemented using centralized servers that are
authoritative for some domains and refer to other DNS servers for other
domains.
When a client host requests information from a nameserver, it usually
connects to port 53. The nameserver then attempts to resolve the FQDN
based on its resolver library, which may contain authoritative
information about the host requested or cached data from an earlier
query. If the nameserver does not already have the answer in its
resolver library, it queries other nameservers, called root
nameservers, to determine which nameservers are
authoritative for the FQDN in question. Then, with that information, it
queries the authoritative nameservers to determine the IP address of the
requested host. If performing a reverse lookup, the same procedure is
used, except the query is made with an unknown IP address rather than a
name.
On the Internet, the FQDN of a host can be broken down into different
sections. These sections are organized into a hierarchy (much like a
tree), with a main trunk, primary branches, secondary branches, and so
forth. Consider the following FQDN:
When looking at how an FQDN is resolved to find the IP address that
relates to a particular system, read the name from right to left, with
each level of the hierarchy divided by periods
(.). In this example,
com defines the top level
domain for this FQDN. The name
example is a sub-domain under
com, while
sales is a sub-domain under
example. The name furthest to the
left, bob, identifies a specific
machine hostname.
Except for the hostname, each section is a called a
zone, which defines a specific
namespace. A namespace controls the naming of
the sub-domains to its left. While this example only contains two
sub-domains, a FQDN must contain at least one sub-domain but may
include many more, depending upon how the namespace is organized.
Zones are defined on authoritative nameservers through the use of
zone files, which describe the namespace of
that zone, the mail servers to be used for a particular domain or
sub-domain, and more. Zone files are stored on primary
nameservers (also called master
nameservers), which are truly authoritative and where
changes are made to the files, and secondary
nameservers (also called slave
nameservers), which receive their zone files from the
primary nameservers. Any nameserver can be a primary and secondary
nameserver for different zones at the same time, and they may also be
considered authoritative for multiple zones. It all depends on how the
nameserver is configured.
There are four primary nameserver configuration types:
master — Stores original and
authoritative zone records for a namespace, and answers queries
about the namespace from other nameservers.
slave — Answers queries from other
nameservers concerning namespaces for which it is considered an
authority. However, slave nameservers get their namespace
information from master nameservers.
caching-only — Offers name to IP
resolution services but is not authoritative for any
zones. Answers for all resolutions are cached in memory for a
fixed period of time, which is specified by the retrieved zone
record.
forwarding — Forwards requests to a
specific list of nameservers for name resolution. If none of the
specified nameservers can perform the resolution, the resolution
fails.
A nameserver may be one or more of these types. For example, a
nameserver can be a master for some zones, a slave for others, and
only offer forwarding resolutions for others.
BIND performs name resolution services through the
/usr/sbin/named daemon. BIND also includes an
administration utility called /usr/sbin/rndc. More
information about rndc can be found in Section 12.4 Using rndc.
BIND stores its configuration files in the following locations:
/etc/named.conf — The configuration
file for the named daemon.
/var/named/ directory — The named
working directory which stores zone, statistic, and cache files.
The next few sections review the BIND configuration files in more
detail.
