Organization of This Document
In this document, Chapter 1 introduces
the basic DNS and BIND concepts. Chapter 2
describes resource requirements for running BIND in various
environments. Information in Chapter 3 is
task-oriented in its presentation and is
organized functionally, to aid in the process of installing the
BIND 9 software. The task-oriented
section is followed by
Chapter 4, which contains more advanced
concepts that the system administrator may need for implementing
certain options. Chapter 5
describes the BIND 9 lightweight
resolver. The contents of Chapter 6 are
organized as in a reference manual to aid in the ongoing
maintenance of the software. Chapter 7 addresses
security considerations, and
Chapter 8 contains troubleshooting help. The
main body of the document is followed by several
appendices which contain useful reference
information, such as a bibliography and
historic information related to BIND
and the Domain Name
System.
The Domain Name System (DNS)
This document explains the installation
and upkeep of the BIND (Berkeley Internet
Name Domain) software package. We
begin by reviewing the fundamentals of the Domain Name System
(DNS) as they relate to BIND.
The Domain Name System (DNS) is a hierarchical, distributed
database. It stores information for mapping Internet host names to
IP
addresses and vice versa, mail routing information, and other data
used by Internet applications.
Clients look up information in the DNS by calling a
resolver library, which sends queries to one or
more name servers and interprets the responses.
The BIND 9 software distribution
contains a name server, named, and a
resolver library, liblwres.
The data stored in the DNS is identified by domain names that are organized as a tree according to
organizational or administrative boundaries. Each node of the tree,
called a domain, is given a label. The domain
name of the
node is the concatenation of all the labels on the path from the
node to the root node. 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 parent
domain.
For example, a domain name for a host at the
company Example, Inc. could be
ourhost.example.com,
where com is the
top level domain to which
ourhost.example.com belongs,
example is
a subdomain of com, and
ourhost is the
name of the host.
For administrative purposes, the name space is partitioned into
areas called zones, each starting at a node and
extending down to the "leaf" nodes or to nodes where other zones
start.
The data for each zone is stored in a name server, which answers queries about the zone using the
DNS protocol.
The data associated with each domain name is stored in the
form of resource records (RRs).
Some of the supported resource record types are described in
the section called “Types of Resource Records and When to Use Them”.
For more detailed information about the design of the DNS and
the DNS protocol, please refer to the standards documents listed in
the section called “Requests for Comments (RFCs)”.
To properly operate a name server, it is important to understand
the difference between a zone
and a domain.
As stated previously, a zone is a point of delegation in
the DNS tree. A zone consists of
those contiguous parts of the domain
tree for which a name 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 is marked by one or more
NS records in the
parent zone, which should be matched by equivalent NS records at
the root of the delegated zone.
For instance, consider the example.com
domain which includes names
such as host.aaa.example.com and
host.bbb.example.com even though
the example.com zone includes
only delegations for the aaa.example.com and
bbb.example.com zones. 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
name servers. Every name in the DNS
tree is a
domain, even if it is
terminal, that is, has no
subdomains. Every subdomain is a domain and
every domain except the root is also a subdomain. The terminology is
not intuitive and we suggest reading RFCs 1033, 1034, and 1035
to
gain a complete understanding of this difficult and subtle
topic.
Though BIND is called a "domain name
server",
it deals primarily in terms of zones. The "primary" and "secondary"
declarations in the named.conf file
specify
zones, not domains. When BIND asks some other site if it is willing to
be a secondary server for a domain, it is
actually asking for secondary service for some collection of zones.
Authoritative Name Servers
Each zone is served by at least
one authoritative name server,
which contains the complete data for the zone.
To make the DNS tolerant of server and network failures,
most zones have two or more authoritative servers, on
different networks.
Responses from authoritative servers have the "authoritative
answer" (AA) bit set in the response packets. This makes them
easy to identify when debugging DNS configurations using tools like
dig (the section called “Diagnostic Tools”).
The authoritative server where the main copy of the zone
data is maintained is called the
primary (or
master) server, or simply the
primary. Typically it 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. This file is called the
zone file or
master file.
In some cases, however, the zone file may not be edited
by humans at all, but may instead be the result of
dynamic update operations.
The other authoritative servers, called the
secondary
(or slave) servers, load the zone
contents from another server using a replication
process known as a zone transfer.
Typically the data is transferred directly from the primary
master, but it is also possible to transfer it from another
secondary. In other words, a secondary server may itself act as a
primary to a subordinate secondary server.
Periodically, the secondary server must send a refresh query to
determine whether the zone contents have been updated. This
is done by sending a query for the zone's Start of Authority (SOA) record and
checking whether the SERIAL field has been updated; if so,
a new transfer request is initiated. The timing of these
refresh queries is controlled by the SOA REFRESH and RETRY
fields, but can be overridden with the
max-refresh-time,
min-refresh-time,
max-retry-time, and
min-retry-time options.
If the zone data cannot be updated within the time specified
by the SOA EXPIRE option (up to a hard-coded maximum of
24 weeks), the secondary zone expires and no longer
responds to queries.
Usually, all of the zone's authoritative servers are listed in
NS records in the parent zone. These NS records constitute
a delegation of the zone from the parent.
The authoritative servers are also listed in the zone file itself,
at the top level or apex
of the zone. Servers that are not in the parent's NS delegation can be listed in the zone's top-level NS
records, but servers that are not present at
the zone's top level cannot be listed in the parent's delegation.
A stealth server is a server that is
authoritative for a zone but is not listed in that zone's NS
records. Stealth servers can be used for keeping a local copy of
a
zone, to speed up access to the zone's records, or to make sure that
the
zone is available even if all the "official" servers for the zone
are
inaccessible.
A configuration where the primary server itself is a
stealth server is often referred to as a "hidden primary"
configuration. One use for this configuration is when the primary
is behind a firewall and is therefore unable to communicate directly
with the outside world.
The resolver libraries provided by most operating systems are
stub resolvers, meaning that they are not
capable of
performing the full DNS resolution process by themselves by talking
directly to the authoritative servers. Instead, they rely on a
local
name server to perform the resolution on their behalf. Such a
server
is called a recursive name server; it performs
recursive lookups for local clients.
To improve performance, recursive servers cache the results of
the lookups they perform. Since the processes of recursion and
caching are intimately connected, the terms
recursive server and
caching server are often used synonymously.
The length of time for which a record may be retained in
the cache of a caching name server is controlled by the
Time-To-Live (TTL) field associated with each resource record.
Even a caching name server does not necessarily perform
the complete recursive lookup itself. Instead, it can
forward some or all of the queries
that it cannot satisfy from its cache to another caching name
server,
commonly referred to as a forwarder.
Forwarders are typically used when an administrator does not
wish for all the servers at a given site to interact
directly with the rest of the Internet. For example, a
common scenario is when multiple internal DNS servers are
behind an Internet firewall. Servers behind the firewall
forward their requests to the server with external access,
which queries Internet DNS servers on the internal servers'
behalf.
Another scenario (largely now superseded by Response Policy
Zones) is to send queries first to a custom server for RBL
processing before forwarding them to the wider Internet.
There may be one or more forwarders in a given setup. The
order in which the forwarders are listed in
named.conf does not determine the
sequence in which they are queried; rather,
named uses the response times from
previous queries to select the server that is likely to
respond the most quickly. A server that has not yet been
queried is given an initial small random response time to
ensure that it is tried at least once. Dynamic adjustment of
the recorded response times ensures that all forwarders are
queried, even those with slower response times. This
permits changes in behavior based on server responsiveness.
Name Servers in Multiple Roles
The BIND name server can
simultaneously act as
a primary for some zones, a secondary for other zones, and a caching
(recursive) server for a set of local clients.
However, since the functions of authoritative name service
and caching/recursive name service are logically separate, it is
often advantageous to run them on separate server machines.
A server that only provides authoritative name service
(an authoritative-only server) can run with
recursion disabled, improving reliability and security.
A server that is not authoritative for any zones and only provides
recursive service to local
clients (a caching-only server)
does not need to be reachable from the Internet at large and can
be placed inside a firewall.