.\" ++Copyright++ 1986, 1988, 1995
.\" -
.\" Copyright (c) 1986, 1988, 1995
.\"    The Regents of the University of California.  All rights reserved.
.\" 
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\" 	This product includes software developed by the University of
.\" 	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\" 
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\" 
.\" 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, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\" 
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION 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.
.\" -
.\" --Copyright--
.\"
.\"	@(#)types.me	6.3 (Berkeley) 9/19/89
.\"
.sh 1 "Types of Zones"
.pp
A ``zone'' is a point of delegation in the DNS tree.  It contains all names
from a certain point ``downward'' except those which are delegated to other
zones.  A ``delegation point'' has one or more \fINS\fP records in the
``parent zone'', which should be matched by equivalent \fINS\fP records at
the root of the ``delegated zone'' (i.e., the ``@'' name in the zone file).
.pp
Understanding the difference between a ``zone'' and a ``domain'' is crucial
to the proper operation of a name server.  As an example, consider the
\s-1DEC.COM\s+1 \fIdomain\fP, which includes names such as
\s-1POBOX1.PA.DEC.COM\s+1 and \s-1QUABBIN.CRL.DEC.COM\s+1 even though
the \s-1DEC.COM\s+1 \fIzone\fP includes only \fIdelegations\fP for the
\s-1PA.DEC.COM\s+1 and \s-1CRL.DEC.COM\s+1 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).  Technically speaking,
every name in the DNS tree is a ``domain'', even if it is ``terminal'', that
is, has no ``subdomains''.  Technically speaking, every subdomain is a domain
and every domain except the root is also a subdomain.  The terminology is not
intuitive and you would do well to read RFC's 1033, 1034, and 1035 to gain a
complete understanding of this difficult and subtle topic.
.pp
Though \s-1BIND\s+1 is a \fIDomain\fP Name Server, it deals primarily in terms
of \fIzones\fP.  The \fIprimary\fP and \fIsecondary\fP declarations in the
\fInamed.boot\fP file specify \fIzones\fP, not \fIdomains\fP.  When you ask
someone if they are willing to be a secondary server for your ``domain'', you
are actually asking for secondary service for some collection of \fIzones\fP.
.pp
Each zone will have one ``primary'' server, which loads the zone contents
from some local file which is edited by humans or perhaps generated
mechanically from some other local file which is edited by humans.  Then
there will be some number of ``secondary'' servers, which load the zone
contents using the \s-1IP/DNS\s+1 protocol (that is, the secondary servers will
contact the primary and fetch the zone using \s-1IP/TCP\s+1).  This set of
servers (the primary and all of the secondaries) should be listed in the
\fINS\fP records in the parent zone, which will constitute a ``delegation''.
This set of servers must also be listed in the zone file itself, usually
under the ``@'' name which is a magic cookie that means the ``top level''
or ``root'' of current zone.  You can list servers in the zone's
top-level ``@'' \fINS\fP records that are not in the parent's \fINS\fP
delegation, but you cannot list servers in the parent's delegation that are
not present in the zone's ``@''.  Any servers listed in the \fINS\fP records
must be configured as authoritative (either primary or secondary) for the
zone.  If a server listed in a \fINS\fP record is not authoritative, it
will respond with a ``lame delegation'' when queried.
.sh 1 "Types of Servers"
.pp
Servers do not really have ``types''.  A server can be a primary for some
zones and a secondary for others, or it can be only a primary, or only a
secondary, or it can serve no zones and just answer queries via its ``cache''.
Previous versions of this document referred to servers as ``master'' and
``slave'' but we now feel that those distinctions \(em and the assignment of
a ``type'' to a name server \(em are not useful.
.sh 2 "Caching Only Server"
.pp
All servers are caching servers.  This means that the server caches the
information that it receives for use until the data expires.  A \fICaching
Only Server\fP 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 needed.  All servers keep data in their cache until the data
expires, based on a \fITTL\fP (``Time To Live'') field which is maintained
for all resource records.
.sh 2 "Remote Server"
.pp
A Remote Server is an option given to people who would like to use 
a name server from their workstation or on a machine that has a limited
amount of memory and CPU cycles.
With this option you can run all of the networking programs that use
the name server without the name server running on the local machine.
All of the queries are serviced by a name server that is running on another 
machine on the network.
A host which has an
\fI/etc/resolv.conf\fP file listing only remote hosts, and which does not
run a name server of its own, is sometimes called a Remote Server (because
the actual server is remote?) but more
often it is called simply a DNS Client.
This kind of host is technically not a ``server'',
since it has no cache and does not answer queries.
.sh 2 "Slave Server"
.pp
A Slave Server is a server that always forwards queries it cannot
satisfy from its cache, to a fixed list of \fIforwarding\fP servers
instead of interacting
with the name servers for the root and other domains.
The queries to the \fIforwarding servers\fP are recursive queries.
There may be one or more forwarding servers, and they are tried in turn
until the list is exhausted.
A Slave and forwarder configuration 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
workstations and a departmental timesharing machine with Internet
access.  The workstations might be
administratively prohibited from having Internet access.
To give the workstations the appearance of access to the Internet
domain system, the workstations could be Slave servers to the timesharing
machine which would forward the queries and interact with other
name servers to resolve the query before returning the answer.
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.  The use of Slave mode
and forwarding is discussed further under the description of
the \fInamed\fP bootfile commands.
.pp
There is no prohibition against declaring a server to be a \fIslave\fP
even though it has \fIprimary\fP and/or \fIsecondary\fP 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
\fIforwarders\fP list.