files.me

早期freebsd实现

.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\"    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--
.\"
.\"	@(#)files.me	6.8 (Berkeley) 9/19/89
.\"
.sh 1 "Files
.pp
The name server uses several files to load its data base.
This section covers the files and their formats needed for \fInamed\fP.
.sh 2 "Boot File"
.pp
This is the file that is first read when \fInamed\fP starts up.
This tells the server what type of server it is,
which
zones it has authority over and where to get its initial data.
The default location for this file is \fI/\|etc\|/\|named\|.\|boot\fP\|.
However this can be changed
by setting the \fIBOOTFILE\fP variable when you compile \fInamed\fP 
or by specifying
the location on the command line when \fInamed\fP is started up.
.sh 3 "Domain"
.pp
A default domain may be specified for the nameserver
using a line such as
.(b l
.ta 0.5i +\w`secondary   `u +\w`berkeley.edu   `u +.5i +.5i
\fIdomain 	Berkeley\fP\fB\|.\|\fP\fIEdu\fP
.)b
.re
Older name servers use this information when they receive a query for a name
without a ``\fB.\fP'' that is not known.  Newer designs assume that the
resolver library will append its own idea of a ``default domain'' to any
unqualified names.  Though the name server can still be compiled with
support for the \fIdomain\fP directive in the boot file, the default is to
leave it out and we strenuously recommend against its use.  If you use this
feature, clients outside your local domain which send you requests about
unqualified names will have the implicit qualification of your domain rather
than theirs.  The proper place for this function is on the client, in their
\fB/etc/resolv.conf\fP (or equivalent) file.  Use of the \fIdomain\fP
directive in your boot file is strongly discouraged.
.sh 3 "Directory"
.pp
The \fIdirectory\fP directive specifies the directory in which the nameserver
should run, allowing the other file names in the boot file to use relative path
names.  There can be only one \fIdirectory\fP directive and it should be given
before any other directives that specify file names.
.(b l
.ta 0.5i +\w`secondary   `u +\w`berkeley.edu   `u +.5i +.5i
\fIdirectory  	/var/named\fP
.)b
.re
If you have more than a couple of named files to be maintained, you may wish
to place the named files in a directory such as /var/named and adjust the
directory command properly.  The main purposes of this command are to make
sure named is in the proper directory when trying to include files by
relative path names with $Include and to allow named to run in a location
that is reasonable to dump core if it feels the urge.
.sh 3 "Primary Service"
.pp
The line in the boot file that designates the server as a primary server 
for a zone looks as follows:
.(b l
.ta 0.5i +\w`secondary   `u +\w`berkeley.edu   `u +.5i +.5i
\fIprimary  	Berkeley\fP\fB\|.\|\fP\fIEdu	ucbhosts\fP
.)b
.re
The first field specifies that the server is a primary one for the zone 
stated in the second field.
The third field is the name of the file from which the data is read.
.pp
The above assumes that the zone you are specifying is a class \fIIN\fP
zone.  If you wish to designate a different class you can append
\fI/class\fP to the first field, where \fIclass\fP is either the
integer value or the standard mnemonic for the class.  For example the line 
for a primary server for a hesiod class zone looks as follows:
.(b l
.ta 0.5i +\w`secondary   `u +\w`berkeley.edu   `u +.5i +.5i
\fIprimary/HS         Berkeley\fP\fB\|.\|\fP\fIEdu    hesiod.data\fP
.)b
.re
Note that this support for specifying other than class \fIIN\fP zones is a
compile-time option which your vendor may not have enabled when they built
your operating system.
.sh 3 "Secondary Service"
.pp
The line for a secondary server is similar to the primary except
that it lists addresses of other servers (usually primary servers)
from which the zone data will be obtained.
.(b l
.ta 0.5i +\w`secondary   `u +\w`berkeley.edu   `u +\w`128.32.0.10  `u +\w`128.32.0.10  `u +.5i +.5i
\fIsecondary	Berkeley\fP\fB\|.\|\fP\fIEdu	128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10	\fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP \fIucbhosts.bak\fP
.)b
.re
The first field specifies that the server is a secondary master server for
the zone stated in the second field.
The two network addresses specify the name servers which have data for the 
zone.  Note that at least one of these will be a \fIprimary\fP, and, unless
you are using some protocol other than \s-1IP/DNS\s+1 for your zone transfer
mechanism, the others will all be other \fIsecondary\fP servers.  Having your
secondary server pull data from other secondary servers is usually unwise,
since you can add delay to the propagation of zone updates if your network's
connectivity varies in pathological but common ways.  The intended use for
multiple addresses on a \fIsecondary\fP declaration is when the \fIprimary\fP
server has multiple network interfaces and therefore multiple host addresses.
The secondary server gets its data across the network from one of the listed
servers.  The server addresses are tried in the order listed.
If a filename is present after the list of primary servers, data for the zone
will be dumped into that file as a backup.
When the server is first started, the data is loaded from the backup file
if possible, and a primary server is then consulted to check that the zone
is still up-to-date.  Note that listing your server as a \fIsecondary\fP
server does not neccessarily make it one \(em the parent zone must
\fIdelegate\fP authority to your server as well as the primary and the
other secondaries, or you will be transferring a zone over for no reason;
no other server will have a reason to query you for that zone unless the
parent zone lists you as a server for the zone.
.pp
As with primary you may specify a secondary server for a class other than
\fIIN\fP by appending \fI/class\fP to the \fIsecondary\fP keyword, e.g.,
\fIsecondary/HS\fP.
.sh 3 "Stub Service"
.pp
The line for a stub server is similar to a secondary.
.(b l
.ta 0.5i +\w`stub   `u +\w`berkeley.edu   `u +\w`128.32.0.10  `u +\w`128.32.0.10  `u +.5i +.5i
\fIstub	Berkeley\fP\fB\|.\|\fP\fIEdu	128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10	\fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP \fIucbhosts.bak\fP
.)b
.re
The first field specifies that the server is a stub server for the zone stated
in the second field.
.pp
Stub zones are intened to ensure that a primary for a zone always has the
correct nameserver records for children of that zone. If the primary is not
a secondary for a child zone it should be configured with stub zones for
all its children. Stub zones provide a mechanism to allow nameserver records
for a zone to be specified in only one place.
.(b l
.ta 0.5i +\w`primay   `u +\w`dms.csiro.au   `u +\w`130.155.98.1  `u +.5i +.5i
\fIprimary	CSIRO\fP\fB\|.\|\fP\fIAU	\fIcsiro.dat\fP
\fIstub	dms.CSIRO\fP\fB\|.\|\fP\fIAU	130\fP\fB.\fP\fI155\fP\fB.\fP\fI16\fP\fB.\fP\fI1	\fIdms.stub\fP
\fIstub	dap.CSIRO\fP\fB\|.\|\fP\fIAU	130\fP\fB.\fP\fI155\fP\fB.\fP\fI98\fP\fB.\fP\fI1	\fIdap.stub\fP
.)b
.re
.sh 3 "Caching Server"
.pp
You do not need a special line to designate that a server is a caching
server.  What denotes a ``caching only'' server is the absence of authority
lines, such as \fIsecondary\fP or \fIprimary\fP in the boot file.
.pp
All servers, including ``caching only'' servers, should have a line as
follows in the boot file to prime the name servers cache:
.(b l
\fIcache		\fP\fB.\fP\fI	root\fP\fB.\fP\fIcache\fP
.)b
All cache files listed will be read in at named boot time and any values
still valid will be reinstated in the cache and the root nameserver
information in the cache files will be used until a root query is 
actually answered by one of the name servers in your cache file, at
which time that answer will be used until it times out and your cache
file will be ignored.
.pp
As with \fIprimary\fP and \fIsecondary\fP, you may specify a secondary
server for a class other than \fIIN\fP by appending \fI/class\fP to the
\fIcache\fP keyword, e.g., \fIclass/HS\fP.
.pp
Do not put anything into your \fIcache\fP files other than root server
information.
.sh 3 "Forwarders"
.pp
Any server can make use of \fIforwarders\fP.  A \fIforwarder\fP is another
server capable of processing recursive queries that is willing to try
resolving queries on behalf of other systems.  The \fIforwarders\fP
command specifies forwarders by internet address as follows:
.(b l
\fIforwarders		\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10	\fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP
.)b
.re
There are two main reasons
for wanting to do so.  First, some systems may not have full network
access and may be prevented from sending any IP packets into the rest of
the Internet and therefore must rely on a forwarder which does have
access to the full net.  The second reason is that the forwarder sees
a union of all queries as they pass through his server and therefore it
builds up a very rich cache of data compared to the cache in a typical
workstation nameserver.  In effect, the \fIforwarder\fP becomes a meta-cache
that all hosts can benefit from, thereby reducing the total number of queries
from that site to the rest of the net.
.pp
The effect of ``forwarders'' is to prepend some fixed addresses to the list
of name servers to be tried for every query.  Normally that list is made up
only of higher-authority servers discovered via \fINS\fP record lookups for
the relevant domain.  If the forwarders do not answer, then unless the
\fIslave\fP directive was given, the appropriate servers for the domains
will be queried directly.
.sh 3 "Slave Servers"
.pp
Slave mode is used if the use of forwarders is the only possible way
to resolve queries due to lack of full net access or if you wish to prevent
the nameserver from using other than the listed forwarders.
Slave mode is activated by placing the simple command
.(b l
\fIslave\fP
.)b
in the bootfile.  If \fIslave\fP is used, then you must specify forwarders.
When in slave mode, the server will forward each query to each of the the
forwarders until an answer is found or the list of forwarders is exhausted.
The server will not try to contact any remote name server other than those
named in the \fIforwarders\fP list.
.pp
So while \fIforwarders\fP adds to the end of the ``server list'' for each
query, \fIslave\fP causes the ``server list'' to contain \fIonly\fP those
addresses listed in the \fIforwarders\fP declarations.  Careless use of
the \fIslave\fP directive can cause really horrible forwarding loops, since
you could end up forwarding queries only to some set of hosts which are also
slaves, and one or several of them could be forwarding queries back to you.
.pp
Use of the \fIslave\fP directive should be considered very carefully.
.sh 3 "Zone Transfer Restrictions"
.pp
It may be the case that your organization does not wish to give complete
lists of your hosts to anyone on the Internet who can reach your name servers.
While it is still possible for people to ``iterate'' through your address
range, looking for \fIPTR\fP records, and build a list of your hosts the
``slow'' way, it is still considered reasonable to restrict your export of
zones via the zone transfer protocol.  To limit the list of neighbors who
can transfer zones from your server, use the
.(b l
\fIxfrnets\fP
.)b
directive.  This directive has the same syntax as \fIforwarders\fP except
that you can list network numbers in addition to host addresses.  For example,
you could add the directive \fIxfrnets 16.0.0.0\fP if you wanted to permit
only hosts on Class A network number 16 to transfer zones from your server.
This is not nearly granular enough, and a future version of \s-1BIND\s+1 will
permit such access-control to be specified on a per-zone basis rather than
the current ``global'' basis.
.pp
The \fIxfrnets\fP directive may also be given as \fItcplist\fP for
compatibility with interim releases of \s-1BIND\s+1 4.9.
.pp
Note that \fIxfrnets\fP support is a compile-time option which your vendor
may not have enabled when they built your operating system.
.sh 3 "Sorting Addresses"
.pp
If there are multiple addresses available for a name server which \s-1BIND\s+1
wants to contact, \s-1BIND\s+1 will try the ones it believes are ``closest''
first.  ``Closeness'' is defined in terms of similarity-of-address; that is,
if one address is on the same \fIsubnet\fP as some interface of the local host,
then that address will be tried first.  Failing that, an address which is on
the same \fInetwork\fP will be tried first.  Failing that, they will be tried