options

早期freebsd实现

	you almost certainly do not want this.

SLAVE_FORWARD (origin: [e-mail])
	if set, "slave" servers behave in an arguably more-correct way.  this
is an experimental addition to BIND 4.9 that causes slaves to time out queries
in 60/N seconds where N is the number of forwarders defined.  previously a
query would time out almost immediately, which caused a lot of unneccessary
network traffic.
	you probably want this, and you will get it by default in 4.9.1.

FORCED_RELOAD (origin: [e-mail])
	if set, then when a HUP signal is received, all secondary zones are
scheduled for serial-number comparison with the primaries.  this has the effect
that if you HUP your server, it will refresh any zones which have changed,
even if those zones refresh times have not been reached.
	you probably want this, and you will get it by default in 4.9.1.

WANT_PIDFILE (origin: berkeley, parameterized by arc@sgi)
	if set, a file called named.pid will be created in /etc or /var/run
when the name server has started.  this file can be used to send signals to
BIND, as in "kill -HUP `cat /etc/named.pid`".
	you probably want this, unless you are on an SGI (where killall(1M)
makes the pid file unnecessary)

DOTTED_SERIAL (origin: berkeley; parameterized by vixie)
	if set, allows a somewhat arcane n.m syntax in the serial number
field of an SOA.  this is officially deprecated for 4.9; you should use
straight integer values and find an encoding that does not depend on 
scaled-integer pseudodecimals.  i suggest YYYYMMDDnn where YYYY is the
four-digit year, MM is the two-digit month, DD is the two-digit day-of-month,
and nn is a daily version number in case you change your serial number more
than once in a day.  this encoding will overflow in the year 4294 gregorian.
	you almost certainly do not want this, but if you have old zone files
laying around and you don't want to think your way through converting their
serial numbers, this deprecated behaviour is available.

SENSIBLE_DOTS (origin: [e-mail]; parameterized by vixie)
	if set, changes the semantics of an "n.m" serial number from
		n*10^(3+int(0.9+log10(m))) + m
to
		n*10000+m
	if you are using DOTTED_SERIAL in spite of its deprecated status,
and you are interested in a more predictable and sensible interpretation of
dotted numbers, then you probably want this.

VALIDATE (origin: USC/ISI)
	enables a validation procedure to provide some security in an
otherwise insecure environment. Any RRs are accepted from a server only if
the server is authoritative over that domain. We consider a server
authoritative (for validation purposes) for even the sub-domains that it has
delegated to others. RRs are validated against the data we have in cache
already. Invalid records are neither cached, nor returned.
	you should try this but be careful with it as it is still experimental.
some users have reported unpredictable results.

NCACHE (origin: USC/ISI)
	enables negative caching. We cache only authoritative NXDOMAIN or
authoritative NOERROR with zero RR count. Non-authoritative NXDOMAIN answers
now contain NS records in the authority section. Non-authoritative NOERROR
responses have no authority or additional records to differentiate them from
referrals. They are cached for NTTL secs (currently 10 minutes) and are timed
out when the ttl expires.
	you should try this but be careful with it as it is still experimental.
some users have reported unpredictable results.

RESOLVSORT (origin: [e-mail])
	enable sorting of addresses returned by gethostbyname. Sorting order
is specified by address/netmask pairs. This enables a host to override the
sortlist specified in the nameserver.

STUBS (origin: [e-mail])
	enable teransfer and loading of NS records only for a zone.

SUNSECURITY (origin: [e-mail])
	enable checking of PTR records in gethostbyaddr() to detect
	spoofing. Always on on suns as rlogin etc. depend on this.

SECURE_ZONES (origin: [e-mail])
	enables support for secure zones.  This restricts access to
information in the zone according to the information found in the
secure_zone TXT RR found in the zone.  If none is found, the zone is
world readable.  For information on the format of the secure_zone TXT
RR, see the Name Server Operations Guide for BIND.

ROUND_ROBIN (origin: Marshall Rose of TPC.INT)
	if set, causes the databuf list in a namebuf to be rotated by one
slot after each access to it.  this has the effect that if multiple RR's
of a given type are present, they will be given in "round robin" order 
instead of always being given in the same order.
	you probably want this, in preference to SHUFFLE_ADDRS.

ADDAUTH (origin: [e-mail])
	if set, cause NS and glue A records to be returned with authorative
answers.  still experimental; don't use this unless you want to work on it.

RFC1535 (origin: [e-mail])
	if set, the resolver's default "search" list will be just the entire
"domain" name rather than the sliding window it had before 4.9.2.  this will
make the default search list shorter, so folks who are saying "domain a.b.c"
and relying on the implicit "search a.b.c a.b c" will miss "a.b" and "c".
	this option is on by default for compatibility with RFC 1535.  you
should NOT turn it off.

GEN_AXFR (origin: [e-mail], [e-mail], [e-mail])
	if set, allows specification of zones in classes other than "IN" in
the named.boot file. Allows an optional "/class" on the "primary" and
"secondary" directives.  Also fixes zone transfers so only data in the class
requested is transfered.

DATUMREFCNT (origin: mark andrews)
	you want this.  it will not be optional in future releases.

## ++Copyright++ 1989
## -
## Copyright (c) 1989
##    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--