Bv9ARM.1.html revision 40f53fa8d9c6a4fc38c0014495e7a42b08f52481
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
<!--
- Copyright (C) 2000 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
- copyright notice and this permission notice appear in all copies.
-
- THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM
- DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
- INTERNET SOFTWARE CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT,
- INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
- FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
- NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
- WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: Bv9ARM.1.html,v 1.10 2000/08/01 01:17:48 tale Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
<HTML>
<HEAD>
<TITLE> Section 1. Introduction </TITLE></HEAD>
<BODY BGCOLOR="#ffffff">
<OL>
<H1 CLASS="1Level">
<A NAME="pgfId=1007883">
</A>
Section 1. Introduction </H1>
</OL>
<P CLASS="1LevelContinued">
<A NAME="pgfId=1007884">
</A>
The Internet Domain Name System (DNS) 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 addresses. DNS data is maintained in a group of distributed hierarchical databases.</P>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997352">
</A>
1.1 Scope of Document</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997353">
</A>
The Berkeley Internet Name Domain (BIND) implements an Internet nameserver for a number of operating systems. This document provides basic information about the installation and care of the Internet Software Consortium (ISC) BIND version 9 software package for system administrators.</P>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997354">
</A>
1.2 Organization of This Document</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1155516">
</A>
In this document, <EM CLASS="Emphasis">
Section 1</EM>
introduces the basic DNS and BIND concepts. <EM CLASS="Emphasis">
Section 2</EM>
describes resource requirements for running BIND in various environments. Information in <EM CLASS="Emphasis">
Section 3</EM>
is <EM CLASS="Emphasis">
task-oriented</EM>
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 <EM CLASS="Emphasis">
Section 4</EM>
, which contains more advanced concepts that the system administrator may need for implementing certain options. Section 5 describes the BIND 9 lightweight resolver. The contents of <EM CLASS="Emphasis">
Section 6</EM>
are organized as in a reference manual to aid in the ongoing maintenance of the software. <EM CLASS="Emphasis">
Section 7 </EM>
addresses security considerations, and <EM CLASS="Emphasis">
Section 8</EM>
contains troubleshooting help. The main body of the document is followed by several <EM CLASS="Emphasis">
Appendices</EM>
which contain useful reference information, such as a <EM CLASS="Emphasis">
Bibliography</EM>
and historic information related to BIND and the Domain Name System.</P>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997356">
</A>
1.3 Conventions Used in This Document</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997382">
</A>
In this document, we use the following general typographic conventions:</P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody3">
<A NAME="pgfId=997359">
</A>
<EM CLASS="Emphasis">
To describe:</EM>
</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody3">
<A NAME="pgfId=997361">
</A>
<EM CLASS="Emphasis">
We use the style:</EM>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997363">
</A>
a pathname, filename, URL, hostname,<BR>
mailing list name, or new term or concept</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody5">
<A NAME="pgfId=997365">
</A>
<EM CLASS="pathname">
Italic</EM>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997371">
</A>
literal user input</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody4">
<A NAME="pgfId=997373">
</A>
<KBD CLASS="Literal-user-input">
Fixed Width Bold</KBD>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997375">
</A>
variable user input</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody5">
<A NAME="pgfId=1034911">
</A>
<EM CLASS="Optional-meta-syntax">
Fixed Width Italic</EM>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997379">
</A>
program output</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody4">
<A NAME="pgfId=997381">
</A>
<CODE CLASS="Program-Process">
Fixed Width</CODE>
</P>
</TD>
</TR>
</TABLE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997412">
</A>
The following conventions are used in descriptions of the BIND configuration file:</P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody3">
<A NAME="pgfId=997385">
</A>
<EM CLASS="Emphasis">
To describe:</EM>
</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody3">
<A NAME="pgfId=997387">
</A>
<EM CLASS="Emphasis">
We use the style:</EM>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997389">
</A>
keywords</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody6">
<A NAME="pgfId=997391">
</A>
<EM CLASS="production_target">
Sans Serif Bold</EM>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997393">
</A>
variables</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<H6 CLASS="CellBody7">
<A NAME="pgfId=997395">
</A>
<EM CLASS="variable">
Sans Serif Italic</EM>
</H6>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997397">
</A>
"meta-syntactic" information (within brackets when optional)</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody5">
<A NAME="pgfId=997399">
</A>
<EM CLASS="Optional-meta-syntax">
Fixed Width Italic</EM>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997401">
</A>
Command line input</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody4">
<A NAME="pgfId=997403">
</A>
<KBD CLASS="Literal-user-input">
Fixed Width Bold</KBD>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997405">
</A>
Program output</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody4">
<A NAME="pgfId=997407">
</A>
<CODE CLASS="Program-Process">
Fixed Width</CODE>
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997409">
</A>
Optional input</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1" valign="top">
<P CLASS="CellBody">
<A NAME="pgfId=997411">
</A>
Text is enclosed in square brackets</P>
</TD>
</TR>
</TABLE>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997413">
</A>
1.4 Discussion of Domain Name System (DNS) Basics and BIND</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997414">
</A>
The purpose of this document is to explain the installation and basic upkeep of the BIND software package, and we begin by reviewing the fundamentals of the domain naming system as they relate to BIND. BIND consists of a <EM CLASS="Emphasis">
nameserver</EM>
(or "daemon") called <CODE CLASS="Program-Process">
named</CODE>
and a <CODE CLASS="Program-Process">
resolver</CODE>
library. The BIND 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 specified in<CODE CLASS="Program-Process">
</CODE>
<EM CLASS="pathname">
. The <EM CLASS="Emphasis">
resolver</EM>
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>
<DIV>
<OL>
<H4 CLASS="3Level">
<A NAME="pgfId=997415">
</A>
1.4.1 Nameservers</H4>
</OL>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997416">
</A>
A nameserver (NS) is a program that stores information about named resources and responds to queries from programs called <EM CLASS="Emphasis">
resolvers</EM>
which act as client processes. The basic function of an NS is to provide information about network objects by answering queries.</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997417">
</A>
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 called <EM CLASS="Emphasis">
zones</EM>
, 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 <EM CLASS="Emphasis">
Example, Inc.</EM>
would be:</P>
<P CLASS="3LevelContinued1">
<A NAME="pgfId=997418">
</A>
<EM CLASS="URL">
ourhost.example.com</EM>
</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997419">
</A>
where <EM CLASS="URL">
com</EM>
is the top level domain to which <EM CLASS="URL">
ourhost.example.com</EM>
belongs, <EM CLASS="URL">
example</EM>
is a subdomain of <EM CLASS="URL">
com</EM>
, and <EM CLASS="URL">
ourhost</EM>
is the name of the host.</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997420">
</A>
The specifications for the domain nameserver are defined in the RFC 1034, RFC 1035 and RFC 974. These documents can be found in<BR>
<EM CLASS="pathname">
in 4.4BSD or are available via File Transfer Protocol (FTP) from<BR>
<EM CLASS="URL">
or via the Web at <EM CLASS="URL">
. (See Appendix C for complete information on finding and retrieving RFCs.) It is also recommended that you read the related man pages: <CODE CLASS="Program-Process">
named</CODE>
and <CODE CLASS="Program-Process">
resolver</CODE>
.</P>
</DIV>
<DIV>
<OL>
<H4 CLASS="3Level">
<A NAME="pgfId=997421">
</A>
1.4.2 Types of Zones</H4>
</OL>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997422">
</A>
As we 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 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>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997423">
</A>
To properly operate a nameserver, it is important to understand the difference between a <EM CLASS="Emphasis">
zone</EM>
and a <EM CLASS="Emphasis">
domain</EM>
.</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997424">
</A>
For instance, consider the <EM CLASS="URL">
example.com</EM>
domain which includes names such as <EM CLASS="URL">
host.aaa.example.com </EM>
and <EM CLASS="URL">
host.bbb.example.com</EM>
even though the <EM CLASS="URL">
example.com</EM>
zone includes only delegations for the <EM CLASS="URL">
aaa.example.com</EM>
and <EM CLASS="URL">
bbb.example.com</EM>
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 nameservers. Every name in the DNS tree is a <EM CLASS="Emphasis">
domain</EM>
, even if it is <EM CLASS="Emphasis">
terminal</EM>
, that is, has no <EM CLASS="Emphasis">
subdomains</EM>
. Every 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>
<P CLASS="3LevelContinued">
<A NAME="pgfId=1007878">
</A>
Though BIND is a Domain Nameserver, it deals primarily in terms of zones. The master and slave declarations in the <EM CLASS="pathname">
named.conf</EM>
file specify zones, not domains. When you ask some other site if it is willing to be a slave server for your <EM CLASS="Emphasis">
domain</EM>
, you are actually asking for slave service for some collection of zones.</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997426">
</A>
Each zone will have one <EM CLASS="Emphasis">
primary master</EM>
(also called <EM CLASS="Emphasis">
primary</EM>
) 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 <EM CLASS="Emphasis">
slave</EM>
(also called <EM CLASS="Emphasis">
secondary) </EM>
servers, which load the zone contents using the DNS 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 <EM CLASS="Emphasis">
delegation</EM>
. This set of servers must also be listed in the zone file itself, usually under the <CODE CLASS="Program-Process">
@</CODE>
name which indicates the <EM CLASS="Emphasis">
top level</EM>
or <EM CLASS="Emphasis">
root</EM>
of the current zone. You can list servers in the zone's top-level <CODE CLASS="Program-Process">
@</CODE>
NS records that are not in the parent's NS delegation, but you cannot list servers in the parent's delegation that are not present in the zone's <CODE CLASS="Program-Process">
@</CODE>
.</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997428">
</A>
Any servers listed in the NS records must be configured as <EM CLASS="Emphasis">
authoritative</EM>
for the 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 of the zone.</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997430">
</A>
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>
</DIV>
<DIV>
<OL>
<H4 CLASS="3Level">
<A NAME="pgfId=997431">
</A>
1.4.3 Servers</H4>
</OL>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997432">
</A>
A DNS 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 <EM CLASS="Emphasis">
cache</EM>
. Master servers are often also called <EM CLASS="Emphasis">
primaries</EM>
and slave servers are often also called <EM CLASS="Emphasis">
secondaries</EM>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997433">
</A>
All servers keep data in their cache until the data expires, based on a Time To Live (TTL) field which is maintained for all resource records.</P>
<DIV>
<OL>
<H5 CLASS="4Level">
<A NAME="pgfId=997434">
</A>
1.4.3.1 Master Server</H5>
</OL>
<P CLASS="4LevelContinued">
<A NAME="pgfId=997435">
</A>
The <EM CLASS="Emphasis">
primary master server</EM>
is the ultimate source 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>
</DIV>
<DIV>
<OL>
<H5 CLASS="4Level">
<A NAME="pgfId=997436">
</A>
1.4.3.2 Slave Server </H5>
</OL>
<P CLASS="4LevelContinued">
<A NAME="pgfId=997437">
</A>
A <EM CLASS="Emphasis">
slave server</EM>
, also called a <EM CLASS="Emphasis">
secondary server</EM>
, 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 provide necessary redundancy. All secondary/slave servers are named in the NS RRs for the zone.</P>
</DIV>
<DIV>
<OL>
<H5 CLASS="4Level">
<A NAME="pgfId=997438">
</A>
1.4.3.3 Caching Only Server</H5>
</OL>
<P CLASS="4LevelContinued">
<A NAME="pgfId=997439">
</A>
Some servers are <EM CLASS="Emphasis">
caching only servers</EM>
. This 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 it needs.</P>
</DIV>
<DIV>
<OL>
<H5 CLASS="4Level">
<A NAME="pgfId=997440">
</A>
1.4.3.4 Forwarding Server</H5>
</OL>
<P CLASS="4LevelContinued">
<A NAME="pgfId=997441">
</A>
Instead of interacting with the nameservers for the root and other domains, a <EM CLASS="Emphasis">
forwarding server</EM>
always forwards queries it cannot satisfy from its authoritative data or cache to a fixed list of other servers. The forwarded queries are also known as <EM CLASS="Emphasis">
recursive queries</EM>
, 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 of internal DNS 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 DNS servers on 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 of.</P>
<P CLASS="4LevelContinued">
<A NAME="pgfId=997442">
</A>
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 the forwarders list.</P>
</DIV>
<DIV>
<OL>
<H5 CLASS="4Level">
<A NAME="pgfId=997443">
</A>
1.4.3.5 Stealth Server</H5>
</OL>
<P CLASS="4LevelContinued">
<A NAME="pgfId=1014846">
</A>
A <EM CLASS="Emphasis">
stealth server</EM>
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>
</DIV>
</DIV>
</DIV>
<HR ALIGN="center">
</BODY>
</HTML>