369N/ACONTENT="Modular DocBook HTML Stylesheet Version 1.41"><
LINK 369N/ATITLE="BIND Resource Requirements" >Chapter 1. Introduction </
A>Organization of This Document</
A>Conventions Used in This Document</
A>Discussion of Domain Name System (<
SPAN>The Internet Domain Name System (<
SPAN>) consists of the syntax
to specify the names of entities in the Internet in a hierarchical
manner, the rules used for delegating authority over names, and the
system implementation that actually maps names to Internet
> data is maintained in a group of distributed
hierarchical databases.</
P>1.1. Scope of Document</
A>The Berkeley Internet Name Domain (<
SPAN Internet nameserver for a number of operating systems. This
document provides basic information about the installation and
care of the Internet Software Consortium (<
SPAN software package for system administrators.</
P>1.2. Organization of This Document</
A describes resource requirements for running <
SPAN environments. Information in <
I> in its presentation and is
organized functionally, to aid in the process of installing the
> 9 software. The task-oriented section is followed by
>, which contains more advanced
concepts that the system administrator may need for implementing
certain options. Section 5 describes the <
SPAN resolver. The contents of <
I organized as in a reference manual to aid in the ongoing
maintenance of the software. <
I>addresses security considerations, and
> contains troubleshooting help. The
main body of the document is followed by several
> which contain useful reference
information, such as a <
I historic information related to <
SPAN>1.3. Conventions Used in This Document</
A>In this document, we use the following general typographic
>a pathname, filename, URL, hostname,
mailing list name, or new term or concept</
P>Fixed Width Italic</
SPAN>The following conventions are used in descriptions of the
> configuration file:<
DIVinformation (within brackets when optional)</
P>Fixed Width Italic</
SPAN>Text is enclosed in square brackets</
SPAN>1.4. Discussion of Domain Name System (<
SPAN>The purpose of this document is to explain the installation
and basic upkeep of the <
SPAN> software package, and we begin by reviewing
the fundamentals of the domain naming system as they relate to <
SPAN> server runs in the background, servicing queries on a well
known network port. The standard port for the User Datagram Protocol
(UDP) and Transmission Control Protocol (TCP), usually port 53,
> is a set of routines residing
in a system library that provides the interface that programs can
use to access the domain name services.</
P>A nameserver (NS) is a program that stores information about
named resources and responds to queries from programs called <
Iact as client processes. The basic function of an NS is to provide
information about network objects by answering queries.</
P>With the nameserver, the network can be broken into a hierarchy
of domains. The name space is organized as a tree according to organizational
or administrative boundaries. Each node of the tree, called a domain,
is given a label. The name of the domain is the concatenation of
all the labels of the domains from the root to the current domain.
This is represented in written form as a string of labels listed
from right to left and separated by dots. A label need only be unique
within its domain. The whole name space is partitioned into areas
>, each starting at a domain and
extending down to the leaf domains or to domains where other zones
start. Zones usually represent administrative boundaries. For example,
a domain name for a host at the company <
I> is the top level domain to which
>The specifications for the domain nameserver are defined in
the RFC 1034, RFC 1035 and RFC 974. These documents can be found
> in 4.4BSD or are available
via File Transfer Protocol (FTP) from
(See Appendix C for complete information on finding and retrieving
RFCs.) It is also recommended that you read the related man pages:
>1.4.2. Types of Zones</
A>As we stated previously, a zone is a point of delegation in
> tree. A zone consists of those contiguous parts of the domain
tree for which a domain server has complete information and over which
it has authority. It contains all domain names from a certain point
downward in the domain tree except those which are delegated to
other zones. A delegation point has one or more NS records in the
parent zone, which should be matched by equivalent NS records at
the root of the delegated zone.</
P>To properly operate a nameserver, it is important to understand
the difference between a <
I>For instance, consider the <
SPANwhich includes names such as <
SPANzone includes only delegations for the
A zone can map exactly to a single domain, but could also include
only part of a domain, the rest of which could be delegated to other
nameservers. Every name in the <
SPANEvery subdomain is a domain and every domain except the root is
also a subdomain. The terminology is not intuitive and we suggest
that you read RFCs 1033, 1034 and 1035 to gain a complete understanding
of this difficult and subtle topic.</
P> is a Domain Nameserver, it deals primarily in
terms of zones. The master and slave declarations in the <
TTspecify zones, not domains. When you ask some other site if it is willing
to be a slave server for your <
Iactually asking for slave service for some collection of zones.</
P>Each zone will have one <
I>) server which loads the zone
contents from some local file edited by humans or perhaps generated
mechanically from some other local file which is edited by humans.
There there will be some number of <
I>servers, which load the zone
> protocol (that is, the secondary servers
will contact the primary and fetch the zone data using TCP). This
set of servers — the primary and all of its secondaries — should be
listed in the NS records in the parent zone and will constitute a <
IThis set of servers must also be listed in the zone file itself,
> name which indicates the <
IYou can list servers in the zone's top-level <
Brecords that are not in the parent's NS delegation, but you cannot
list servers in the parent's delegation that are not present in
>Any servers listed in the NS records must be configured as <
Ithe zone. A server is authoritative for a zone when it has been
configured to answer questions for that zone with authority, which
it does by setting the "authoritative answer" (AA) bit in reply
packets. A server may be authoritative for more than one zone. The
authoritative data for a zone is composed of all of the Resource
Records (RRs) — the data associated with names in a tree-structured
name space — attached to all of the nodes from the top node of the
zone down to leaf nodes or nodes above cuts around the bottom edge
>Adding a zone as a type master or type slave will tell the
server to answer questions for the zone authoritatively. If the
server is able to load the zone into memory without any errors it
will set the AA bit when it replies to queries for the zone. See
RFCs 1034 and 1035 for more information about the AA bit.</
P> server can be master for some zones and slave for others
or can be only a master, or only a slave, or can serve no zones
and just answer queries via its <
Iservers are often also called <
Islave servers are often also called <
I>All servers keep data in their cache until the data expires,
based on a Time To Live (TTL) field which is maintained for all
>1.4.3.1. Master Server</
A>primary master server</
Isource of information about a domain. The primary master is an authoritative
server configured to be the source of zone transfer for one or more
secondary servers. The primary master server obtains data for the
zone from a file on disk.</
P>1.4.3.2. Slave Server</
A>, is an authoritative server that uses zone transfers from
the primary master server to retrieve the zone data. Optionally,
the slave server obtains zone data from a cache on disk. Slave servers
in the NS RRs for the zone.</
P>1.4.3.3. Caching Only Server</
AThis means that the server caches the information that it receives
and uses it until the data expires. A caching only server is a server
that is not authoritative for any zone. This server services queries
and asks other servers, who have the authority, for the information
>1.4.3.4. Forwarding Server</
A>Instead of interacting with the nameservers for the root and
queries it cannot satisfy from its authoritative data or cache to
a fixed list of other servers. The forwarded queries are also known
>, the same type as a client would
send to a server. There may be one or more servers forwarded to,
and they are queried in turn until the list is exhausted or an answer
is found. A forwarding server is typically used when you do not
wish all the servers at a given site to interact with the rest of
the Internet servers. A typical scenario would involve a number
> servers and an Internet firewall. Servers unable
to pass packets through the firewall would forward to the server
that can do it, and that server would query the Internet <
SPANon the internal server's behalf. An added benefit of using the forwarding
feature is that the central machine develops a much more complete
cache of information that all the workstations can take advantage
>There is no prohibition against declaring a server to be a
forwarder even though it has master
and/
or slave zones as well;
the effect will still be that anything in the local server's cache
or zones will be answered, and anything else will be forwarded using
>1.4.3.5. Stealth Server</
A> is a server that answers
authoritatively for a zone, but is not listed in that zone's NS
records. Stealth servers can be used as a way to centralize distribution
of a zone, without having to edit the zone on a remote nameserver.
Where the master file for a zone resides on a stealth server in
this way, it is often referred to as a "hidden primary" configuration.
Stealth servers can also be a way to keep a local copy of a zone
for rapid access to the zone's records, even if all "official" nameservers
for the zone are inaccessible.</
P> Resource Requirements</
TD