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.