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