Today, the Internet and almost all local networks depend upon a working
and reliable Domain Name Service (DNS), which is used
to resolve names of systems into IP addresses and vice versa.
This chapter discusses BIND, the structure of its configuration files, and
how it may be locally or remotely administered.
Introduction to DNS and BIND
Systems using IP networks must know the IP address of a remote machine
in order to connect to it. However, most users prefer to use the name of
a machine, called a hostname or a fully qualified domain name
(FQDN), when connecting to it.
Use of fully qualified domain names also have advantages for system
administrators. They allow administrators to flexibility in changing the
IP addresses for individual machines without effecting name-based
queries to the machines. Conversely, administrators can shuffle which
machines handle a name-based query in a way transparent to the user.
The service that facilitates this is caused DNS, and it is normally
implemented using centralized servers that are authoritative for some
domains and refer to other DNS servers for other domains.
DNS under Linux is made possible through the use of a
nameserver daemon that performs the IP/hostname
translation. A client application will request information from the
nameserver, usually connecting to it on the server's port 53. The
nameserver will attempt to resolve the FQDN based on its resolver
library, which may contain authoritative information about the host
requested or cached data about that name from an earlier query. If the
nameserver does not already have the answer in its resolver library, it
will turn to other nameservers, called root
nameservers, to determine which nameservers are
authoritative for the FQDN in question. Then, with that information, it
will query the authoritative nameservers for that name to determine the
IP address. If performing a reverse lookup, the same procedure is used,
except the query is made with an unknown IP address rather than a name.
Zones
On the Internet, the FQDN of a host can be broken down into different
sections, and these sections are organized in 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 a FQDN is resolved to find the IP address that
relates to a particular system, you must read the name from right to
left, with each level of the hierarchy divided by dots
(.). In this example, the
com defines the top level
domain for this FQDN. The
domain name is a sub-domain under
com, with
sales as a sub-domain under
domain. The name furthest left in a
FQDN is the hostname, identifying a particular machine.
Except for the hostname, every section is a called a
zone, which defines a particular 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 the
nameserver's configuration.
Types of Nameservers
There are four primary nameserver configuration types:
master — Stores original and
authoritative zone records for a certain namespace, answering
questions from other nameservers searching for answers concerning
that namespace.
slave — Also answers queries from
other nameservers concerning namespaces for which it is considered
an authority. However, slave nameservers get their namespace
information from master nameservers via a zone
transfer, where the slave sends the master a
NOTIFY request for a particular zone and the
master responds with the information, if the slave is authorized
to receive the transfer.
caching-only — Offers name to IP
resolution services but is not authoritative for any
zones. Answers for all resolutions are usually cached in a
database stored in memory for a fixed period of time, usually
specified by the retrieved zone record, for quicker resolution for
other DNS clients after the first resolution.
forwarding — Forwards requests to a
specific list of nameservers to be resolved. If none of the
specified nameservers can perform the resolution, the process
stops and 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 resolution.
BIND as a Nameserver
Red Hat Linux includes BIND, which is a very popular, powerful, open source
nameserver. BIND uses the named daemon to provide
name resolution services.
BIND version 9 also includes a utility called
/usr/sbin/rndc which allows the administration of the
running named daemon. More information about
rndc can be found in the Section called Using rndc.
