Installation guide

230 Chapter 16. Berkeley Internet Name Domain (BIND)
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 au-
thoritative 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 consid-
ered authoritative for multiple zones. It all depends on the nameserver’s configuration.
16.1.2. Types of Nameservers
There are four primary nameserver configuration types:
• master — Stores original and authoritative zone records for a certain namespace, answering ques-
tions from other nameservers searching for answers concerning that namespace.
• slave — Also answers queries from other nameservers concerning namespaces for which it is con-
sidered 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. An-
swers 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.
16.1.3. 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 Section 16.3.
16.2. BIND Configuration Files
The BIND nameserver named server configuration is /etc/named.conf. All zone files are placed
in the /var/named/ directory.