files in doc/html were not maintained, removed them
This commit is contained in:
Andreas Gustafsson
@@ -1,80 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND acl Statement</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide--<CODE>acl</CODE> Statement</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
acl <VAR>name</VAR> {
|
||||
<VAR><A HREF="address_list.html">address_match_list</A></VAR>
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Usage"><H3>Definition and Usage</H3></A>
|
||||
|
||||
<P>The <CODE>acl</CODE> statement creates a named address match list.
|
||||
It gets its name from a primary use of address match lists: Access
|
||||
Control Lists (ACLs).</P>
|
||||
|
||||
<P>Note that an address match list's name must be defined with
|
||||
<CODE>acl</CODE> before it can be used elsewhere; no forward
|
||||
references are allowed.</P>
|
||||
|
||||
The following ACLs are built-in:
|
||||
|
||||
<DL>
|
||||
<DT><CODE>any</CODE>
|
||||
<DD>
|
||||
Allows all hosts.
|
||||
|
||||
<DT><CODE>none</CODE>
|
||||
<DD>
|
||||
Denies all hosts.
|
||||
|
||||
<DT><CODE>localhost</CODE>
|
||||
<DD>
|
||||
Allows the IP addresses of all interfaces on the system.
|
||||
|
||||
<DT><CODE>localnets</CODE>
|
||||
<DD>
|
||||
Allows any host on a network for which the system has an interface.
|
||||
</DL>
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: acl.html,v 1.3 2000/07/27 09:42:08 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,117 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND Address Match Lists</TITLE>
|
||||
</HEAD>
|
||||
<BODY>
|
||||
|
||||
<H2>BIND Configuration File Guide--Address Match Lists</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
<VAR>address_match_list</VAR> = 1*<VAR>address_match_element</VAR>
|
||||
|
||||
<VAR>address_match_element</VAR> = [ "!" ] (<VAR><A HREF="docdef.html">address_match_list</A></VAR> / <VAR><A HREF="docdef.html">ip_address</A></VAR> / <VAR><A HREF="docdef.html">ip_prefix</A></VAR> / <VAR><A HREF="acl.html">acl_name</A></VAR> / <VAR><A HREF="docdef.html">"key" key_id</A></VAR>) ";"
|
||||
</PRE>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Usage"><H3>Definition and Usage</H3></A>
|
||||
|
||||
<P>Address match lists are primarily used to determine access control for
|
||||
various server operations. They are also used to define priorities
|
||||
for querying other nameservers and to set the addresses on which
|
||||
<CODE>named</CODE> will listen for queries.
|
||||
The elements which constitute an address match list can be any
|
||||
of the following:</P>
|
||||
|
||||
<UL>
|
||||
<LI>an IP address (in dotted-decimal notation),</LI>
|
||||
|
||||
<LI>an IP prefix (in the '/'-notation),</LI>
|
||||
|
||||
<LI>a key ID, as defined by the
|
||||
<A HREF="key.html"><CODE>key</CODE></A> statement, or
|
||||
|
||||
<LI>the name of an address match list previously defined with
|
||||
the <A HREF="acl.html"><CODE>acl</CODE></A> statment, or</LI>
|
||||
|
||||
<LI>another <VAR>address_match_list</VAR></LI>
|
||||
</UL>
|
||||
|
||||
<P>Elements can be negated with a leading exclamation mark ("!"), and
|
||||
the match list names "any", "none", "localhost" and "localnets" are
|
||||
predefined. More information on those names can be found in the
|
||||
description of the <A HREF="acl.html"><CODE>acl</CODE></A> statement.
|
||||
|
||||
<P>The addition of the <CODE>key</CODE>
|
||||
clause made the name of this syntactic element something of a
|
||||
misnomer, since security keys can be used to validate access without
|
||||
regard to a host or network address. Nonetheless, the term "address
|
||||
match list" is still used throughout the documentation.</P>
|
||||
|
||||
<P>When a given IP address or prefix is compared to an address match
|
||||
list, the list is traversed in order until an element matches. The
|
||||
interpretation of a match depends on whether the list is being used
|
||||
for access control, defining <CODE>listen-on</CODE> ports, or as a
|
||||
topology, and whether the element was negated.</P>
|
||||
|
||||
<P>When used as an access control list, a non-negated match allows
|
||||
access and a negated match denies access. If there is no match,
|
||||
access is denied. The clauses <CODE>allow-query</CODE>,
|
||||
<CODE>allow-transfer</CODE>, <CODE>allow-update</CODE> and
|
||||
<CODE>blackhole</CODE> all use address match lists like this.
|
||||
Similarly, the <CODE>listen-on</CODE>
|
||||
option will cause the server to not accept queries on any of the
|
||||
machine's addresses which do not match the list.
|
||||
|
||||
<P>When used with the <CODE>topology</CODE> clause, a non-negated
|
||||
match returns a distance based on its position on the list (the closer
|
||||
the match is to the start of the list, the shorter the distance is
|
||||
between it and the server). A negated match will be assigned the
|
||||
maximum distance from the server. If there is no match, the address
|
||||
will get a distance which is further than any non-negated list
|
||||
element, and closer than any negated element.</P>
|
||||
|
||||
<P>Because of the first-match aspect of the algorithm, an element that
|
||||
defines a subset of another element in the list should come before the
|
||||
broader element, regardless of whether either is negated. For
|
||||
example, in <CODE>1.2.3/24; ! 1.2.3.13;</CODE> the 1.2.3.13
|
||||
element is completely useless, because the algorithm will match
|
||||
any lookup for 1.2.3.13 to the 1.2.3/24 element. Using
|
||||
<CODE>! 1.2.3.13; 1.2.3/24</CODE> fixes that problem by
|
||||
having 1.2.3.13 blocked by the negation but all other 1.2.3.* hosts
|
||||
fall through.
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: address_list.html,v 1.3 2000/07/27 09:42:10 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,101 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND Comment Syntax</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide--Comment Syntax</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
/* This is a BIND comment as in C */
|
||||
|
||||
// This is a BIND comment as in C++
|
||||
|
||||
# This is a BIND comment as in common Unix shells and perl
|
||||
</PRE>
|
||||
|
||||
<A NAME="Usage"><H3>Definition and Usage</H3></A>
|
||||
|
||||
<P>Comments may appear anywhere that whitespace may appear in a BIND
|
||||
configuration file.</P>
|
||||
|
||||
<P>C-style comments start with the two characters <CODE>/*</CODE>
|
||||
(slash, star) and end with <CODE>*/</CODE> (star, slash). Because
|
||||
they are completely delimited with these characters, they can be used
|
||||
to comment only a portion of a line or to span multiple lines.</P>
|
||||
|
||||
<P>C-style comments cannot be nested. For example, the following is
|
||||
not valid because the entire comment ends with the first
|
||||
<CODE>*/</CODE>:
|
||||
|
||||
<PRE>
|
||||
/* This is the start of a comment.
|
||||
This is still part of the comment.
|
||||
/* This is an incorrect attempt at nesting a comment. */
|
||||
This is no longer in any comment. */
|
||||
</PRE>
|
||||
|
||||
|
||||
<P>C++-style comments start with the two characters <CODE>//</CODE>
|
||||
(slash, slash) and continue to the end of the physical line. They
|
||||
cannot be continued across multiple physical lines; to have one
|
||||
logical comment span multiple lines, each line must use the
|
||||
<CODE>//</CODE> pair. For example:
|
||||
|
||||
<PRE>
|
||||
// This is the start of a comment. The next line
|
||||
// is a new comment, even though it is logically
|
||||
// part of the previous comment.
|
||||
</PRE>
|
||||
|
||||
<P>Shell-style (or perl-style, if you prefer) comments start with the
|
||||
character <CODE>#</CODE> (hash or pound or number or octothorpe or
|
||||
whatever) and continue to the end of the physical line, like C++
|
||||
comments.</P> For example:
|
||||
|
||||
<PRE>
|
||||
# This is the start of a comment. The next line
|
||||
# is a new comment, even though it is logically
|
||||
# part of the previous comment.
|
||||
</PRE>
|
||||
|
||||
<P><STRONG>WARNING:</STRONG> you cannot use the <CODE>;</CODE>
|
||||
(semicolon) character to start a comment such as you would in a zone
|
||||
file. The semicolon indicates the end of a configuration statement,
|
||||
so whatever follows it will be interpreted as the start of the next
|
||||
statement.</P>
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: comments.html,v 1.3 2000/07/27 09:42:11 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,114 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND Configuration File Guide</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<H3>Overview</H3>
|
||||
|
||||
<P>BIND 8 is much more configurable than previous release of BIND.
|
||||
There are entirely new areas of configuration, such as access control lists
|
||||
and categorized logging. Many options that previously applied to all zones
|
||||
can now be used selectively. These features, plus a consideration of future
|
||||
configuration needs led to the creation of a new configuration file format.
|
||||
|
||||
<H3>The Configuration File</H3>
|
||||
|
||||
<H4><A HREF="example.html">Example Configuration</A></H4>
|
||||
|
||||
<H4>Statements</H4>
|
||||
|
||||
<P>A BIND 8 configuration consists of statements and comments.
|
||||
Statements end with a semicolon. Many statements contain a block of
|
||||
substatements, which are also terminated with a semicolon.</P>
|
||||
|
||||
<P>The following statements are supported:
|
||||
<DL>
|
||||
<DT><CODE><A HREF="acl.html">acl</A></CODE>
|
||||
<DD>
|
||||
defines a named IP address matching list, for access control and other uses
|
||||
|
||||
<DT><CODE><A HREF="include.html">include</A></CODE>
|
||||
<DD>
|
||||
includes a file
|
||||
|
||||
<DT><CODE><A HREF="key.html">key</A></CODE>
|
||||
<DD>
|
||||
specifies key information for use in authentication and authorization
|
||||
|
||||
<DT><CODE><A HREF="logging.html">logging</A></CODE>
|
||||
<DD>
|
||||
specifies what the server logs, and where the log messages are sent
|
||||
|
||||
<DT><CODE><A HREF="options.html">options</A></CODE>
|
||||
<DD>
|
||||
controls global server configuration options and sets defaults for other
|
||||
statements
|
||||
|
||||
<DT><CODE><A HREF="controls.html">controls</A></CODE>
|
||||
<DD>
|
||||
declares control channels to be used by the <VAR>ndc</VAR> utility
|
||||
|
||||
<DT><CODE><A HREF="server.html">server</A></CODE>
|
||||
<DD>
|
||||
sets certain configuration options on a per-server basis
|
||||
|
||||
<DT><CODE><A HREF="trusted-keys.html">trusted-keys</A></CODE>
|
||||
<DD>
|
||||
defines DNSSEC keys that are preconfigured into the server and implicitly
|
||||
trusted
|
||||
|
||||
<DT><CODE><A HREF="zone.html">zone</A></CODE>
|
||||
<DD>
|
||||
defines a zone
|
||||
</DL>
|
||||
|
||||
<P>The <CODE>logging</CODE> and <CODE>options</CODE> statements may only
|
||||
occur once per configuration.
|
||||
|
||||
<H4>Comments</HR>
|
||||
|
||||
The BIND 8 <A HREF="comments.html">comment syntax</A> allows for
|
||||
comments to appear anywhere that whitespace may appear in a BIND
|
||||
configuration file. To appeal to programmers of all kinds, they can
|
||||
be written in C, C++, or shell/perl constructs.
|
||||
|
||||
<H3>Converting from BIND 4.9.x</H3>
|
||||
|
||||
<P>BIND 4.9.x configuration files can be converted to the new format
|
||||
by using <CODE>src/bin/named/named-bootconf.pl</CODE>, a perl script that
|
||||
is part of the BIND 8.1 source kit.
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: config.html,v 1.3 2000/07/27 09:42:12 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,76 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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: controls.html,v 1.4 2000/07/27 09:42:13 tale Exp $ -->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND controls Statement</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide--<CODE>controls</CODE> Statement</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
controls {
|
||||
[ inet <VAR><A HREF="docdef.html">ip_addr</A></VAR>
|
||||
port <VAR><A HREF="docdef.html">ip_port</A></VAR>
|
||||
allow { <VAR><A HREF="address_list.html">address_match_list</A></VAR>; }; ]
|
||||
[ unix <VAR><A HREF="docdef.html">path_name</A></VAR>
|
||||
perm <VAR><A HREF="docdef.html">number</A></VAR>
|
||||
owner <VAR><A HREF="docdef.html">number</A></VAR>
|
||||
group <VAR><A HREF="docdef.html">number</A></VAR>; ]
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Usage"><H3>Definition and Usage</H3></A>
|
||||
|
||||
<P>The <CODE>controls</CODE statement declares control channels
|
||||
to be used by system
|
||||
administrators to affect the operation of the local name server. These
|
||||
control channels are used by the <CODE>ndc</CODE> utility to send commands
|
||||
to and retrieve non-DNS results from a name server.</P>
|
||||
|
||||
<P>A <CODE>unix</CODE> control channel is a FIFO in the file system,
|
||||
and access to it is
|
||||
controlled by normal file system permissions.
|
||||
It is created by <CODE>named</CODE> with the specified file mode bits (see
|
||||
the <CODE>chmod</CODE>(1) manual page), user and group owner.
|
||||
Note that, unlike <CODE>chmod</CODE>, the mode bits specified for
|
||||
<CODE>perm</CODE> will normally have a leading 0 so the number
|
||||
is interpreted as octal. Also note that the user and group
|
||||
ownership specified as <CODE>owner</CODE> and <CODE>group</CODE>
|
||||
must be given as numbers, not names.
|
||||
It is recommended that the
|
||||
permissions be restricted to administrative personnel only, or else any
|
||||
user on the system might be able to manage the local name server.</P>
|
||||
|
||||
<P>An <CODE>inet</CODE> control channel is a TCP/IP socket accessible
|
||||
to the Internet, created at the specified <VAR>ip_port</VAR> on the
|
||||
specified <VAR>ip_addr</VAR>.
|
||||
Modern <VAR>telnet</VAR> clients are capable of speaking directly to these
|
||||
sockets, and the control protocol is ARPAnet-style text. It is recommended
|
||||
that 127.0.0.1 be the only <VAR>ip_addr</VAR> used, and this only if you
|
||||
trust all non-privileged users on the local host to manage your name
|
||||
server.</P>
|
||||
@@ -1,135 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND Documentation Definitions</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide--Documentation Definitions</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<H3>Syntactic Miscellany</H3>
|
||||
|
||||
<P>Described below are elements used throughout the BIND configuration
|
||||
file documentation. Elements which are only associated with one
|
||||
statement are described only in the section describing that statement.
|
||||
|
||||
<DL>
|
||||
<DT><VAR>acl_name</VAR>
|
||||
<DD>
|
||||
The name of an <A HREF="address_list.html">address match list</A>,
|
||||
as defined by the <A HREF="acl.html">acl</A> statement.
|
||||
|
||||
<DT><VAR>address_match_list</VAR>
|
||||
<DD>
|
||||
A list of one or more <VAR>ip_address</VAR>, <VAR>ip_prefix</VAR>
|
||||
<VAR>key_id</VAR> or <VAR>acl_name</VAR> elements, as described in the
|
||||
<A HREF="address_list.html">Address Match Lists</A> section.
|
||||
|
||||
<DT><VAR>dotted-decimal</VAR>
|
||||
<DD>
|
||||
One or more integers valued 0 through 255 separated only by dots
|
||||
("."), such as <CODE>123</CODE> or <CODE>45.67</CODE> or
|
||||
<CODE>89.123.45.67</CODE>.
|
||||
|
||||
<DT><VAR>domain_name</VAR>
|
||||
<DD>
|
||||
A quoted string which will be used as a DNS name, for example
|
||||
<CODE>"my.test.domain"</CODE>.
|
||||
|
||||
<DT><VAR>path_name</VAR>
|
||||
<DD>
|
||||
A quoted string which will be used as a pathname, such as
|
||||
<CODE>"zones/master/my.test.domain"</CODE>.
|
||||
|
||||
<DT><VAR>ip_addr</VAR>
|
||||
<DD>
|
||||
An IP address in with exactly four elements in
|
||||
<VAR>dotted-decimal</VAR> notation.
|
||||
|
||||
<DT><VAR>ip_port</VAR>
|
||||
<DD>
|
||||
An IP port <VAR>number</VAR>. <VAR>number</VAR> is limited to 0
|
||||
through 65535, with values below 1024 typically restricted to
|
||||
root-owned processes. In some cases an asterisk (``*'') character
|
||||
can be used as a placeholder to select a random high-numbered port.
|
||||
|
||||
<DT><VAR>ip_prefix</VAR>
|
||||
<DD>
|
||||
An IP network specified in <VAR>dotted-decimal</VAR> form, followed by "/"
|
||||
and then the number of bits in the netmask. E.g. <CODE>127/8</CODE> is
|
||||
the network <CODE>127.0.0.0</CODE> with netmask <CODE>255.0.0.0</CODE>.
|
||||
<CODE>1.2.3.0/24</CODE> is network <CODE>1.2.3.0</CODE> with netmask
|
||||
<CODE>255.255.255.0</CODE>.
|
||||
|
||||
<DT><VAR>key_id</VAR>
|
||||
<DD>
|
||||
A string representing the name of a shared key, to be used for transaction
|
||||
security.
|
||||
|
||||
<DT><VAR>number</VAR>
|
||||
<DD>
|
||||
A non-negative integer with an entire range limited by the range of a
|
||||
C language signed integer (2,147,483,647 on a machine with 32 bit
|
||||
integers). Its acceptable value might further be limited by the
|
||||
context in which it is used.
|
||||
|
||||
<DT><VAR>size_spec</VAR>
|
||||
<DD>
|
||||
A <VAR>number</VAR>, the word <CODE>unlimited</CODE>, or the word
|
||||
<CODE>default</CODE>.
|
||||
|
||||
<P>The maximum value of <VAR>size_spec</VAR> is that of unsigned long
|
||||
integers on the machine. <CODE>unlimited</CODE> requests unlimited use, or
|
||||
the maximum available amount. <CODE>default</CODE> uses the limit that
|
||||
was in force when the server was started.</P>
|
||||
|
||||
<P>A <VAR>number</VAR> can optionally be followed by a scaling factor:
|
||||
<CODE>K</CODE> or <CODE>k</CODE> for kilobytes, <CODE>M</CODE> or
|
||||
<CODE>m</CODE> for megabytes, and <CODE>G</CODE> or <CODE>g</CODE> for
|
||||
gigabytes, which scale by 1024, 1024*1024, and 1024*1024*1024
|
||||
respectively.
|
||||
|
||||
<P>Integer storage overflow is currently silently ignored during
|
||||
conversion of scaled values, resulting in values less than intended,
|
||||
possibly even negative. Using <CODE>unlimited</CODE> is the best way
|
||||
to safely set a really large number.</P>
|
||||
|
||||
<DT><VAR>yes_or_no</VAR>
|
||||
<DD>
|
||||
Either <CODE>yes</CODE> or <CODE>no</CODE>. The words
|
||||
<CODE>true</CODE> and <CODE>false</CODE> are also accepted, as are the
|
||||
numbers <CODE>1</CODE> and <CODE>0</CODE>.
|
||||
|
||||
</DL>
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: docdef.html,v 1.3 2000/07/27 09:42:14 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,82 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND Configuration File Guide -- Example Config File</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide -- Example Config File</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<PRE>
|
||||
|
||||
/*
|
||||
* A simple BIND 8 configuration
|
||||
*/
|
||||
|
||||
logging {
|
||||
category lame-servers { null; };
|
||||
category cname { null; };
|
||||
};
|
||||
|
||||
options {
|
||||
directory "/var/named";
|
||||
};
|
||||
|
||||
controls {
|
||||
inet * port 52 allow { localnets; }; // a BAD idea
|
||||
unix "/var/run/ndc" perm 0600 owner 0 group 0; // the default
|
||||
};
|
||||
|
||||
zone "isc.org" in {
|
||||
type master;
|
||||
file "master/isc.org";
|
||||
};
|
||||
|
||||
zone "vix.com" in {
|
||||
type slave;
|
||||
file "slave/vix.com";
|
||||
masters { 10.0.0.53; };
|
||||
};
|
||||
|
||||
zone "." in {
|
||||
type hint;
|
||||
file "named.cache";
|
||||
};
|
||||
|
||||
zone "0.0.127.in-addr.arpa" in {
|
||||
type master;
|
||||
notify no;
|
||||
file "master/127.0.0";
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: example.html,v 1.3 2000/07/27 09:42:15 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,74 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND include Statement</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide--<CODE>include</CODE> Statement</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
include <VAR><A HREF="docdef.html">path_name</A></VAR>;
|
||||
</PRE>
|
||||
|
||||
<HR>
|
||||
|
||||
<A Name="#Usage"><H3>Definition and Usage</H3></A>
|
||||
|
||||
<P>The <CODE>include</CODE> statement inserts the specified file at
|
||||
the point that the <CODE>include</CODE> statement is encountered. It
|
||||
cannot be used within another statement, though, so a line such as
|
||||
<PRE>
|
||||
acl internal_hosts { include "internal_hosts.acl"; };
|
||||
</PRE>
|
||||
is not allowed.</P>
|
||||
|
||||
<P>Use <CODE>include</CODE> to break the configuration up into
|
||||
easily-managed chunks. For example:
|
||||
|
||||
<PRE>
|
||||
include "/etc/security/keys.bind";
|
||||
include "/etc/acls.bind";
|
||||
</PRE>
|
||||
|
||||
<P>could be used at the top of a BIND configuration file in order to
|
||||
include any ACL or key information.</P>
|
||||
|
||||
<P>Be careful not to type
|
||||
"<CODE>#include</CODE>", like you would in a C
|
||||
program, because "<CODE>#</CODE>" is used to start a
|
||||
comment.</P>
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: include.html,v 1.3 2000/07/27 09:42:16 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,71 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND key Statement</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide--<CODE>key</CODE> Statement</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
key <VAR>key_id</VAR> {
|
||||
algorithm <VAR>algorithm_id</VAR>;
|
||||
secret <VAR>secret_string</VAR>;
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Usage"><H3>Definition and Usage</H3></A>
|
||||
|
||||
<P>The <CODE>key</CODE> statement defines a key ID which can be used
|
||||
in a <A HREF="server.html"><CODE>server</CODE></A> statement to
|
||||
associate an authentication method with a particular name server.
|
||||
|
||||
<P>A key ID must be created with the <CODE>key</CODE>
|
||||
statement before it can be used in a <CODE>server</CODE>
|
||||
definition or an address match list.</P>
|
||||
|
||||
<P>The <VAR>algorithm_id</VAR> is a string that specifies a
|
||||
security/authentication algorithm.
|
||||
<VAR>secret_string</VAR> is the secret to be used by the algorithm,
|
||||
and is treated as a base-64 encoded string.
|
||||
|
||||
<P>The <CODE>key</CODE> statement is intended for use in transaction
|
||||
security. Unless included in a <A HREF="server.html"><CODE>server</CODE></A>
|
||||
statement, it is not used to sign any requests. It is used to verify
|
||||
requests matching the <VAR>key_id</VAR> and <VAR>algorithm_id</VAR>,
|
||||
and sign replies to those requests.
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: key.html,v 1.3 2000/07/27 09:42:17 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,379 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND logging Statement</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide -- <CODE>logging</CODE> Statement</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
logging {
|
||||
[ channel <VAR>channel_name</VAR> {
|
||||
( file <VAR><A HREF="docdef.html">path_name</A></VAR>
|
||||
[ versions ( <VAR>number</VAR> | unlimited ) ]
|
||||
[ size <VAR><A HREF="docdef.html">size_spec</A></VAR> ]
|
||||
| syslog ( kern | user | mail | daemon | auth | syslog | lpr |
|
||||
news | uucp | cron | authpriv | ftp |
|
||||
local0 | local1 | local2 | local3 |
|
||||
local4 | local5 | local6 | local7 )
|
||||
| null );
|
||||
|
||||
[ severity ( critical | error | warning | notice |
|
||||
info | debug [ <VAR>level</VAR> ] | dynamic ); ]
|
||||
[ print-category <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ print-severity <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ print-time <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
}; ]
|
||||
|
||||
[ category <VAR>category_name</VAR> {
|
||||
<VAR>channel_name</VAR>; [ <VAR>channel_name</VAR>; ... ]
|
||||
}; ]
|
||||
...
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<A NAME="Usage"><H3>Definition and Usage</H3></A>
|
||||
|
||||
<P>The first statement in a channel definition must be one of
|
||||
<CODE>file</CODE>, <CODE>syslog</CODE> or <CODE>null</CODE>
|
||||
|
||||
<P>The <CODE>logging</CODE> statement configures a wide variety of
|
||||
logging options for the nameserver. Its <CODE>channel</CODE> phrase
|
||||
associates output methods, format options and severity levels with
|
||||
a name that can then be used with the <CODE>category</CODE> phrase to
|
||||
select how various classes of messages are logged.</P>
|
||||
|
||||
<P>Only one <CODE>logging</CODE> statement is used to define as many
|
||||
channels and categories as are wanted. If there are multiple logging
|
||||
statements in a configuration, the first defined determines the logging,
|
||||
and warnings are issued for the others. If there is no logging statement,
|
||||
the logging configuration will be:</P>
|
||||
|
||||
<PRE>
|
||||
logging {
|
||||
category default { default_syslog; default_debug; };
|
||||
category panic { default_syslog; default_stderr; };
|
||||
category packet { default_debug; };
|
||||
category eventlib { default_debug; };
|
||||
};
|
||||
</PRE>
|
||||
|
||||
The logging configuration is established as soon as the
|
||||
<CODE>logging</CODE> statement is parsed. If you want to redirect
|
||||
messages about processing of the entire configuration file, the
|
||||
<CODE>logging</CODE>statement must appear first. Even if you do not
|
||||
redirect configuration file parsing messages, we recommend
|
||||
always putting the <CODE>logging</CODE> statement first so that this
|
||||
rule need not be consciously recalled if you ever do need want the
|
||||
parser's messages relocated.
|
||||
|
||||
<H4>The <CODE>channel</CODE> phrase</H4>
|
||||
|
||||
<P>All log output goes to one or more "channels"; you can make as many
|
||||
of them as you want.</P>
|
||||
|
||||
<P>Every channel definition must include a clause that says whether
|
||||
messages selected for the channel go to a file, to a particular syslog
|
||||
facility, or are discarded. It can optionally also limit the message
|
||||
severity level that will be accepted by the channel (default is
|
||||
"info"), and whether to include a <CODE>named</CODE>-generated time
|
||||
stamp, the category name and/or severity level (default is not to
|
||||
include any).</P>
|
||||
|
||||
<P>The word <CODE>null</CODE> as the destination option for the
|
||||
channel will cause all messages sent to it to be discarded; other
|
||||
options for the channel are meaningless.</P>
|
||||
|
||||
<P>The <CODE>file</CODE> clause can include limitations both on how
|
||||
large the file is allowed to become, and how many versions of the file
|
||||
will be saved each time the file is opened.
|
||||
|
||||
<P>The <CODE>size</CODE> option for files is simply a hard ceiling on
|
||||
log growth. If the file ever exceeds the size, then
|
||||
<CODE>named</CODE> will just not write anything more to it until the
|
||||
file is reopened; exceeding the size does not automatically trigger a
|
||||
reopen. The default behavior is to not limit the size of the file.</P>
|
||||
|
||||
<P>If you use the <CODE>version</CODE> logfile option, then
|
||||
<CODE>named</CODE> will retain that many backup versions of the file
|
||||
by renaming them when opening. For example, if you choose to keep 3
|
||||
old versions of the file "lamers.log" then just before it is opened
|
||||
lamers.log.1 is renamed to lames.log.2, lamers.log.0 is renamed to
|
||||
lamers.log.1, and lamers.log is renamed to lamers.log.0. No rolled
|
||||
versions are kept by default; any existing log file is simply
|
||||
appended. The <CODE>unlimited</CODE> keyword is synonymous with
|
||||
<CODE>99</CODE> in current BIND releases.</P>
|
||||
|
||||
<P>The argument for the <CODE>syslog</CODE> clause is a syslog
|
||||
facility as described in the <CODE>syslog</CODE> manual page. How
|
||||
<CODE>syslogd</CODE> will handle messages sent to this facility is
|
||||
described in the <CODE>syslog.conf</CODE> manual page. If you have a
|
||||
system which uses a very old version of <CODE>syslog</CODE> that only
|
||||
uses two arguments to the <CODE>openlog()</CODE> function, then this
|
||||
clause is silently ignored.</P>
|
||||
|
||||
<P>The <CODE>severity</CODE> clause works like <CODE>syslog</CODE>'s
|
||||
"priorities", except that they can also be used if you are writing
|
||||
straight to a file rather than using <CODE>syslog</CODE>. Messages
|
||||
which are not at least of the severity level given will not be
|
||||
selected for the channel; messages of higher severity levels will be
|
||||
accepted.</P>
|
||||
|
||||
<P>If you are using <CODE>syslog</CODE>, then the
|
||||
<CODE>syslog.conf</CODE> priorities will also determine what
|
||||
eventually passes through. For example, defining a channel facility
|
||||
and severity as <CODE>daemon</CODE> and <CODE>debug</CODE> but only
|
||||
logging <CODE>daemon.warning</CODE> via <CODE>syslog.conf</CODE> will
|
||||
cause messages of severity <CODE>info</CODE> and <CODE>notice</CODE>
|
||||
to be dropped. If the situation were reversed, with
|
||||
<CODE>named</CODE> writing messages of only <CODE>warning</CODE> or
|
||||
higher, then <CODE>syslogd</CODE> would print all messages it received
|
||||
from the channel.</P>
|
||||
|
||||
<P>The server can supply extensive debugging information when it is in
|
||||
debugging mode. If the server's global debug level is greater than
|
||||
zero, then debugging mode will be active. The global debug level is
|
||||
set either by starting the <CODE>named</CODE> server with the "-d"
|
||||
flag followed by a positive integer, or by sending the running server the
|
||||
SIGUSR1 signal (for example, by using "ndc trace"). The global debug
|
||||
level can be set to zero, and debugging mode turned off, by sending
|
||||
the server the SIGUSR2 signal ("ndc notrace"). All debugging messages
|
||||
in the server have a debug level, and higher debug levels give more
|
||||
more detailed output.
|
||||
Channels that specify a specific debug severity, e.g.
|
||||
|
||||
<PRE>
|
||||
channel specific_debug_level {
|
||||
file "foo";
|
||||
severity debug 3;
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<P>will get debugging output of level 3 or less any time the
|
||||
server is in debugging mode, regardless of the global debugging level.
|
||||
Channels with <code>dynamic</code> severity use the server's global
|
||||
level to determine what messages to print.
|
||||
|
||||
<P>If <CODE>print-time</CODE> has been turned on, then the date and
|
||||
time will be logged. <CODE>print-time</CODE> may be specified for a
|
||||
syslog channel, but is usually pointless since syslog also prints the
|
||||
date and time. If <CODE>print-category</CODE> is requested,
|
||||
then the category of the message will be logged as well. Finally, if
|
||||
<CODE>print-severity</CODE> is on, then the severity level of the
|
||||
message will be logged. The <CODE>print-</CODE> options may be used
|
||||
in any combination, and will always be printed in the following order:
|
||||
time, category, severity. Here is an example where all three
|
||||
<CODE>print-</CODE> options are on:
|
||||
|
||||
<PRE>
|
||||
28-Apr-1997 15:05:32.863 default: notice: Ready to answer queries.
|
||||
</PRE>
|
||||
|
||||
<P>There are four predefined channels that are used for
|
||||
<CODE>named</CODE>'s default logging as follows. How they are used
|
||||
used is described in the next section, The <CODE>category</CODE> phrase.
|
||||
|
||||
<PRE>
|
||||
channel default_syslog {
|
||||
syslog daemon; # send to syslog's daemon facility
|
||||
severity info; # only send priority info and higher
|
||||
};
|
||||
|
||||
channel default_debug {
|
||||
file "named.run"; # write to named.run in the working directory
|
||||
# Note: stderr is used instead of "named.run"
|
||||
# if the server is started with the "-f" option.
|
||||
severity dynamic; # log at the server's current debug level
|
||||
};
|
||||
|
||||
channel default_stderr { # writes to stderr
|
||||
file "<stderr>"; # this is illustrative only; there's currently
|
||||
# no way of specifying an internal file
|
||||
# descriptor in the configuration language.
|
||||
severity info; # only send priority info and higher
|
||||
};
|
||||
|
||||
channel null {
|
||||
null; # toss anything sent to this channel
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<P>Once a channel is defined, it cannot be redefined. Thus you cannot
|
||||
alter the built-in channels directly, but you can modify the default
|
||||
logging by pointing categories at channels you have defined.</P>
|
||||
|
||||
<H4>The <CODE>category</CODE> phrase</H4>
|
||||
|
||||
<P>There are many categories, so you can send the logs you want to see
|
||||
wherever you want, without seeing logs you don't want. If you don't specify
|
||||
a list of channels for a category, then log messages in that category will
|
||||
be sent to the <CODE>default</CODE> category instead. If you don't specify
|
||||
a default category, the following "default default" is used:
|
||||
|
||||
<PRE>
|
||||
category default { default_syslog; default_debug; };
|
||||
</PRE>
|
||||
|
||||
<P>As an example, let's say you want to log security events to a file,
|
||||
but you also want keep the default logging behavior. You'd specify the
|
||||
following:
|
||||
|
||||
<PRE>
|
||||
channel my_security_channel {
|
||||
file "my_security_file";
|
||||
severity info;
|
||||
};
|
||||
category security { my_security_channel; default_syslog; default_debug; };
|
||||
</PRE>
|
||||
|
||||
<P>To discard all messages in a category, specify the
|
||||
<CODE>null</CODE> channel:
|
||||
|
||||
<PRE>
|
||||
category lame-servers { null; };
|
||||
category cname { null; };
|
||||
</PRE>
|
||||
|
||||
<P>The following
|
||||
categories are available:</P>
|
||||
|
||||
<DL>
|
||||
<DT><CODE>default</CODE>
|
||||
<DD>
|
||||
The catch-all. Many things still aren't classified into categories,
|
||||
and they all end up here. Also, if you don't specify any channels for
|
||||
a category, the default category is used instead. If you do not
|
||||
define the default category, the following definition is used:
|
||||
<CODE>category default { default_syslog; default_debug; };</CODE>
|
||||
|
||||
<DT><CODE>config</CODE>
|
||||
<DD>
|
||||
High-level configuration file processing.
|
||||
|
||||
<DT><CODE>parser</CODE>
|
||||
<DD>
|
||||
Low-level configuration file processing.
|
||||
|
||||
<DT><CODE>queries</CODE>
|
||||
<DD>
|
||||
A short log message is generated for every query the server receives.
|
||||
|
||||
<DT><CODE>lame-servers</CODE>
|
||||
<DD>
|
||||
Messages like "Lame server on ..."
|
||||
|
||||
<DT><CODE>statistics</CODE>
|
||||
<DD>
|
||||
Statistics.
|
||||
|
||||
<DT><CODE>panic</CODE>
|
||||
<DD>
|
||||
If the server has to shut itself down due to an internal problem, it
|
||||
will log the problem in this category as well as in the problem's native
|
||||
category. If you do not define the panic category, the following definition
|
||||
is used: <CODE>category panic { default_syslog; default_stderr; };</CODE>
|
||||
|
||||
<DT><CODE>update</CODE>
|
||||
<DD>
|
||||
Dynamic updates.
|
||||
|
||||
<DT><CODE>ncache</CODE>
|
||||
<DD>
|
||||
Negative caching.
|
||||
|
||||
<DT><CODE>xfer-in</CODE>
|
||||
<DD>
|
||||
Zone transfers the server is receiving.
|
||||
|
||||
<DT><CODE>xfer-out</CODE>
|
||||
<DD>
|
||||
Zone transfers the server is sending.
|
||||
|
||||
<DT><CODE>db</CODE>
|
||||
<DD>
|
||||
All database operations.
|
||||
|
||||
<DT><CODE>eventlib</CODE>
|
||||
<DD>
|
||||
Debugging info from the event system. Only one channel may be specified for
|
||||
this category, and it must be a file channel. If you do not define the
|
||||
eventlib category, the following definition is used: <CODE>category eventlib
|
||||
{ default_debug; };</CODE>
|
||||
|
||||
<DT><CODE>packet</CODE>
|
||||
<DD>
|
||||
Dumps of packets received and sent. Only one channel may be specified for
|
||||
this category, and it must be a file channel. If you do not define the
|
||||
packet category, the following definition is used: <CODE>category packet
|
||||
{ default_debug; };</CODE>
|
||||
|
||||
<DT><CODE>notify</CODE>
|
||||
<DD>
|
||||
The NOTIFY protocol.
|
||||
|
||||
<DT><CODE>cname</CODE>
|
||||
<DD>
|
||||
Messages like "... points to a CNAME".
|
||||
|
||||
<DT><CODE>security</CODE>
|
||||
<DD>
|
||||
Approved/unapproved requests.
|
||||
|
||||
<DT><CODE>os</CODE>
|
||||
<DD>
|
||||
Operating system problems.
|
||||
|
||||
<DT><CODE>insist</CODE>
|
||||
<DD>
|
||||
Internal consistency check failures.
|
||||
|
||||
<DT><CODE>maintenance</CODE>
|
||||
<DD>
|
||||
Periodic maintenance events.
|
||||
|
||||
<DT><CODE>load</CODE>
|
||||
<DD>
|
||||
Zone loading messages.
|
||||
|
||||
<DT><CODE>response-checks</CODE>
|
||||
<DD>
|
||||
Messages arising from response checking, such as
|
||||
"Malformed response ...", "wrong ans. name ...",
|
||||
"unrelated additional info ...", "invalid RR type ...", and "bad referral ...".
|
||||
|
||||
</DL>
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: logging.html,v 1.3 2000/07/27 09:42:18 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,162 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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: master.html,v 1.4 2000/07/27 09:42:19 tale Exp $ -->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Master File Format</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration Guide -- Master File Format</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<P>
|
||||
The Master File Format was initially defined in
|
||||
<A HREF=http://ds.internic.net/rfc/rfc1035.txt>RFC 1035</A>
|
||||
and has subsequently been extended.
|
||||
<P>
|
||||
While the Master File Format is class independent all records in a
|
||||
Master File must be of the same class.
|
||||
|
||||
<H3>Master File Directives</H3>
|
||||
<H4>$ORIGIN</H4>
|
||||
Syntax: <CODE>$ORIGIN <domain-name> [<comment>]</CODE>
|
||||
<P>
|
||||
<CODE>$ORIGIN</CODE> set the domain name that will be appended to any
|
||||
unqualified records.
|
||||
When a zone is first read in there is an implict <CODE>$ORIGIN</CODE>
|
||||
<zone-name>.
|
||||
The current <CODE>$ORIGIN</CODE> is appended to the domain specified in the
|
||||
<CODE>$ORIGIN</CODE> argument if it is not absolute.
|
||||
|
||||
<PRE>
|
||||
$ORIGIN EXAMPLE.
|
||||
$ORIGIN MYZONE
|
||||
WWW CNAME MAIN-SERVER
|
||||
</PRE>
|
||||
is equivlent to
|
||||
<PRE>
|
||||
WWW.MYZONE.EXAMPLE. CNAME MAIN-SERVER.MYZONE.EXAMPLE.
|
||||
</PRE>
|
||||
|
||||
<H4>$INCLUDE</H4>
|
||||
Syntax: <CODE>$INCLUDE <filename> [<origin>] [<comment>]</CODE>
|
||||
<P>
|
||||
Read and process the file filename as if it was included into the file at this
|
||||
point. If origin is specified the file is processed with <CODE>$ORIGIN</CODE>
|
||||
set to that value otherwise the current <CODE>$ORIGIN</CODE> is used.
|
||||
<I>NOTE: The behaviour when <origin> is specified differs from that
|
||||
described in
|
||||
<A HREF=http://ds.internic.net/rfc/rfc1035.txt>RFC 1035</A>.</I>
|
||||
<P>
|
||||
The origin and current domain revert to the values they were prior to the
|
||||
<CODE>$INCLUDE</CODE> once the file has been read.
|
||||
<H4>$TTL</H4>
|
||||
Syntax: <CODE>$TTL <default-ttl> [<comment>]</CODE>
|
||||
<P>
|
||||
Set the default Time To Live (TTL) for subsequent records with undefined
|
||||
TTL's. Valid TTL's are of the range 0-2147483647.
|
||||
<P>
|
||||
<CODE>$TTL</CODE> is defined in
|
||||
<A HREF=http://ds.internic.net/rfc/rfc2308.txt>RFC 2308</A>.
|
||||
<H3>BIND Master File Extentions</H3>
|
||||
<H4>$GENERATE</H4>
|
||||
Syntax: <CODE>$GENERATE <range> <lhs> <type> <rhs>
|
||||
[<comment>]</CODE>
|
||||
<P>
|
||||
<CODE>$GENERATE</CODE> is used to create a series of resource records
|
||||
that only differ from each other by an iterator. <CODE>$GENERATE</CODE>
|
||||
can be used to easily generate the sets of records required to support
|
||||
sub /24 reverse delegations described in
|
||||
<A HREF=http://ds.internic.net/rfc/rfc2317.txt>RFC 2317: Classless IN-ADDR.ARPA delegation</A>.
|
||||
|
||||
<PRE>
|
||||
$ORIGIN 0.0.192.IN-ADDR.ARPA.
|
||||
$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
|
||||
$GENERATE 1-127 $ CNAME $.0
|
||||
</PRE>
|
||||
is equivalent to
|
||||
<PRE>
|
||||
0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
|
||||
0.0.0.192.IN-ADDR.ARPA NS SERVER2.EXAMPLE.
|
||||
1.0.0.192.IN-ADDR.ARPA CNAME 1.0.0.0.192.IN-ADDR.ARPA
|
||||
2.0.0.192.IN-ADDR.ARPA CNAME 2.0.0.0.192.IN-ADDR.ARPA
|
||||
...
|
||||
127.0.0.192.IN-ADDR.ARPA CNAME 127.0.0.0.192.IN-ADDR.ARPA
|
||||
</PRE>
|
||||
<DL>
|
||||
<DT>range</DT>
|
||||
<DD>
|
||||
This can be one of two forms:
|
||||
<I>start</I>-<I>stop</I>
|
||||
or
|
||||
<I>start</I>-<I>stop</I>/<I>step</I>. If the first form is
|
||||
used then step is set to 1. All of start, stop and step must be positive.
|
||||
<DT>lhs</DT>
|
||||
<DD>
|
||||
Lhs describes the owner name of the resource records to be created.
|
||||
Any single $ symbols within the LHS side are replaced by the iterator value.
|
||||
To get a $ in the output use a double $, e.g. $$. If the lhs is not absolute
|
||||
the current $ORIGIN is appended to the name.
|
||||
<DT>type</DT>
|
||||
<DD>
|
||||
At present the only supported types are PTR, CNAME and NS.
|
||||
<DT>rhs</DT>
|
||||
<DD>
|
||||
Rhs is a domain name. It is processed similarly to the lhs.
|
||||
<DD>
|
||||
</DL>
|
||||
<H2>Resource Records</H2>
|
||||
Syntax: <CODE>{<domain>|@|<blank>}
|
||||
[<ttl>] [<class>] <type> <rdata>
|
||||
[<comment>]</CODE>
|
||||
<P>
|
||||
All resource records have the same basic syntax.
|
||||
<DL>
|
||||
<DT><CODE>domain</CODE></DT>
|
||||
<DD>
|
||||
Specify the domain name for this record. If it is not absolute the
|
||||
current <CODE>$ORIGIN</CODE> is appended.
|
||||
<DT><CODE>@</CODE></DT>
|
||||
<DD>
|
||||
Use the current <CODE>$ORIGIN</CODE> for the domain name for this record.
|
||||
<DT><CODE>blank</CODE></DT>
|
||||
<DD>
|
||||
Use the last specified domainname.
|
||||
<DT><CODE>ttl</CODE></DT>
|
||||
<DD>
|
||||
This specifies how long this record will be cached by caching servers.
|
||||
The valid range is 0-2147483647.
|
||||
<DT><CODE>class</CODE></DT>
|
||||
<DD>
|
||||
Specify the class of this record. This is usually redundent as the
|
||||
class of a zone is specfied in the configuration file prior to reading
|
||||
the zone file.
|
||||
<DT><CODE>type</CODE></DT>
|
||||
<DD>
|
||||
Specify the type of this record. This describes the contents of the rdata
|
||||
section.
|
||||
<DT><CODE>rdata</CODE></DT>
|
||||
<DD>
|
||||
This is the value of the resource record.
|
||||
</DL>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,793 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND options Statement</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide -- <CODE>options</CODE> Statement</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
options {
|
||||
[ version <VAR>version_string</VAR>; ]
|
||||
[ directory <VAR>path_name</VAR>; ]
|
||||
[ named-xfer <VAR>path_name</VAR>; ]
|
||||
[ dump-file <VAR>path_name</VAR>; ]
|
||||
[ memstatistics-file <VAR>path_name</VAR>; ]
|
||||
[ pid-file <VAR>path_name</VAR>; ]
|
||||
[ statistics-file <VAR>path_name</VAR>; ]
|
||||
[ auth-nxdomain <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ deallocate-on-exit <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ dialup <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ fake-iquery <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ fetch-glue <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ has-old-clients <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ host-statistics <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ multiple-cnames <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ expert-mode <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ notify <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ recursion <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ rfc2308-type1 <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ use-id-pool <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ forward ( only | first ); ]
|
||||
[ forwarders { [ <VAR><A HREF="docdef.html">in_addr</A></VAR> ; [ <VAR><A HREF="docdef.html">in_addr</A></VAR> ; ... ] ] }; ]
|
||||
[ check-names ( master | slave | response ) ( warn | fail | ignore); ]
|
||||
[ allow-query { <VAR>address_match_list</VAR> }; ]
|
||||
[ allow-transfer { <VAR>address_match_list</VAR> }; ]
|
||||
[ blackhole { <VAR>address_match_list</VAR> }; ]
|
||||
[ listen-on [ port <VAR><A HREF="docdef.html">ip_port</A></VAR> ] { <VAR>address_match_list</VAR> }; ]
|
||||
[ query-source [ address ( <VAR><A HREF="docdef.html">ip_addr</A></VAR> | * ) ] [ port ( <VAR><A HREF="docdef.html">ip_port</A></VAR> | * ) ] ; ]
|
||||
[ lame-ttl <VAR>number</VAR>; ]
|
||||
[ max-transfer-time-in <VAR>number</VAR>; ]
|
||||
[ max-ncache-ttl <VAR>number</VAR>; ]
|
||||
[ transfer-format ( one-answer | many-answers ); ]
|
||||
[ transfers-in <VAR>number</VAR>; ]
|
||||
[ transfers-out <VAR>number</VAR>; ]
|
||||
[ transfers-per-ns <VAR>number</VAR>; ]
|
||||
[ maintain-ixfr-base <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ max-ixfr-log-size <VAR>number</VAR>; ]
|
||||
[ coresize <VAR><A HREF="docdef.html">size_spec</A></VAR> ; ]
|
||||
[ datasize <VAR><A HREF="docdef.html">size_spec</A></VAR> ; ]
|
||||
[ files <VAR><A HREF="docdef.html">size_spec</A></VAR> ; ]
|
||||
[ stacksize <VAR><A HREF="docdef.html">size_spec</A></VAR> ; ]
|
||||
[ cleaning-interval <VAR>number</VAR>; ]
|
||||
[ heartbeat-interval <VAR>number</VAR>; ]
|
||||
[ interface-interval <VAR>number</VAR>; ]
|
||||
[ statistics-interval <VAR>number</VAR>; ]
|
||||
[ <A HREF="#topology">topology</A> { <VAR>address_match_list</VAR> }; ]
|
||||
[ <A HREF="#sortlist">sortlist</A> { <VAR>address_match_list</VAR> }; ]
|
||||
[ rrset-order { <VAR>order_spec</VAR> ; [ <VAR>order_spec</VAR> ; ... ] ] };
|
||||
[ tkey-domain <VAR>string</VAR> ; ]
|
||||
[ tkey-dhkey <VAR>string</VAR> ; ]
|
||||
};
|
||||
</PRE>
|
||||
<HR>
|
||||
|
||||
<A NAME="Usage"><H3>Definition and Usage</H3></A>
|
||||
|
||||
<P>The options statement sets up global options to be used by
|
||||
BIND. This statement may appear at only once in a
|
||||
configuration file; if more than one occurrence is found, the
|
||||
first occurrence determines the actual options used,
|
||||
and a warning will be generated. If there is no options statement,
|
||||
an options block with each option set to its default will be used.</P>
|
||||
|
||||
<H4>Pathnames</H4>
|
||||
|
||||
<DL>
|
||||
<DT><CODE>version</CODE>
|
||||
<DD>
|
||||
The version the server should report via the <VAR>ndc</VAR> command
|
||||
or via a query of name <CODE>version.bind</CODE> in class <I>chaos</I>.
|
||||
The default is the real version number of ths server, but some server
|
||||
operators prefer the string <CODE>"surely you must be joking"</CODE>.
|
||||
|
||||
<DT><CODE>directory</CODE>
|
||||
<DD>
|
||||
The working directory of the server. Any non-absolute
|
||||
pathnames in the configuration file will be taken as relative to this
|
||||
directory. The default location for most server output files
|
||||
(e.g. "named.run") is this directory. If a directory is not
|
||||
specified, the working directory defaults to ".", the directory from which the
|
||||
server was started. The directory specified should be an absolute path.
|
||||
|
||||
<DT><CODE>named-xfer</CODE>
|
||||
<DD>
|
||||
The pathname to the named-xfer program that the server uses for
|
||||
inbound zone transfers. If not specified, the default is
|
||||
system dependent (e.g. "/usr/sbin/named-xfer").
|
||||
|
||||
<DT><CODE>dump-file</CODE>
|
||||
<DD>
|
||||
The pathname of the file the server dumps the database to when it
|
||||
receives <CODE>SIGINT</CODE> signal (<CODE>ndc dumpdb</CODE>). If not
|
||||
specified, the default is "named_dump.db".
|
||||
|
||||
<DT><CODE>memstatistics-file</CODE>
|
||||
<DD>
|
||||
The pathname of the file the server writes memory usage statistics to on exit,
|
||||
if <CODE>deallocate-on-exit</CODE> is <CODE>yes</CODE>. If not
|
||||
specified, the default is "named.memstats".
|
||||
|
||||
<DT><CODE>pid-file</CODE>
|
||||
<DD>
|
||||
The pathname of the file the server writes its process ID in. If not
|
||||
specified, the default is operating system dependent, but is usually
|
||||
"/var/run/named.pid" or "/etc/named.pid". The pid-file is used by
|
||||
programs like "ndc" that want to send signals to the running
|
||||
nameserver.
|
||||
|
||||
<DT><CODE>statistics-file</CODE>
|
||||
<DD>
|
||||
The pathname of the file the server appends statistics to when it
|
||||
receives <CODE>SIGILL</CODE> signal (<CODE>ndc stats</CODE>). If not
|
||||
specified, the default is "named.stats".
|
||||
</DL>
|
||||
|
||||
<A name="BooleanOptions"><H4>Boolean Options</H4></A>
|
||||
|
||||
<DL>
|
||||
<DT><CODE>auth-nxdomain</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE>, then the <CODE>AA</CODE> bit is always set on
|
||||
NXDOMAIN responses, even if the server is not actually authoritative.
|
||||
The default is <CODE>yes</CODE>. Do not turn off
|
||||
<CODE>auth-nxdomain</CODE> unless you are sure you know what you are
|
||||
doing, as some older software won't like it.
|
||||
|
||||
<DT><CODE>deallocate-on-exit</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE>, then when the server exits it will painstakingly
|
||||
deallocate every object it allocated, and then write a memory usage report to
|
||||
the <CODE>memstatistics-file</CODE>. The default is <CODE>no</CODE>, because
|
||||
it is faster to let the operating system clean up.
|
||||
<CODE>deallocate-on-exit</CODE> is handy for detecting memory leaks.
|
||||
|
||||
<DT><CODE>dialup</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE>, then the server treats all zones as if they are
|
||||
doing zone transfers across a dial on demand dialup link, which can
|
||||
be brought up by traffic originating from this server. This has
|
||||
different effects according to zone type and concentrates the zone
|
||||
maintenance so that it all happens in a short interval, once every
|
||||
<CODE>heartbeat-interval</CODE> and hopefully during the one call.
|
||||
It also suppresses some of the normal zone maintainance traffic.
|
||||
The default is <CODE>no</CODE>. The <CODE>dialup</CODE>
|
||||
option may also be specified in the <CODE>zone</CODE> statement, in which
|
||||
case it overrides the <CODE>options dialup</CODE> statement.
|
||||
|
||||
<P>
|
||||
If the zone is a <CODE>master</CODE> then the server will send out
|
||||
NOTIFY request to all the slaves. This will trigger the zone up to
|
||||
date checking in the slave (providing it supports NOTIFY) allowing
|
||||
the <CODE>slave</CODE> to verify the zone while the call us up.
|
||||
|
||||
<P>
|
||||
If the zone is a <CODE>slave</CODE> or <CODE>stub</CODE> then the server
|
||||
will suppress the zone regular zone up to date queries and only perform
|
||||
the when the <CODE>heartbeat-interval</CODE> expires.
|
||||
|
||||
<DT><CODE>fake-iquery</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE>, the server will simulate the obsolete DNS query type
|
||||
IQUERY. The default is <CODE>no</CODE>.
|
||||
|
||||
<DT><CODE>fetch-glue</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE> (the default), the server will fetch "glue" resource
|
||||
records it doesn't have when constructing the additional data section of
|
||||
a response. <CODE>fetch-glue no</CODE> can be used in conjunction with
|
||||
<CODE>recursion no</CODE> to prevent the server's cache from growing or
|
||||
becoming corrupted (at the cost of requiring more work from the client).
|
||||
|
||||
<DT><CODE>has-old-clients</CODE>
|
||||
<DD>
|
||||
Setting the option to <CODE>yes</CODE> is equivalent to setting the follow
|
||||
three options <CODE>auth-nxdomain yes;</CODE>, <CODE>maintain-ixfr-base
|
||||
yes;</CODE> and <CODE>rfc2308-type1 no;</CODE>.
|
||||
The use of <CODE>has-old-clients</CODE> with <CODE>auth-nxdomain</CODE>,
|
||||
<CODE>maintain-ixfr-base</CODE> and <CODE>rfc2308-type1</CODE> is order
|
||||
dependant.
|
||||
|
||||
<DT><CODE>host-statistics</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE>, then statistics are kept for every host that the
|
||||
the nameserver interacts with. The default is <CODE>no</CODE>. <I>Note:</I>
|
||||
turning on <CODE>host-statistics</CODE> can consume huge amounts of memory.
|
||||
|
||||
<DT><CODE>maintain-ixfr-base</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE>, then a transaction log is kept for
|
||||
Incremental Zone Transfer. The default is <CODE>no</CODE>.
|
||||
|
||||
<DT><CODE>multiple-cnames</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE>, then multiple CNAME resource records will be
|
||||
allowed for a domain name. The default is <CODE>no</CODE>. Allowing
|
||||
multiple CNAME records is against standards and is not recommended.
|
||||
Multiple CNAME support is available because previous versions of BIND
|
||||
allowed multiple CNAME records, and these records have been used for load
|
||||
balancing by a number of sites.
|
||||
|
||||
<DT><CODE>expert-mode</CODE>
|
||||
<DD>
|
||||
If <CODE>no</CODE> (the default), then warnings for various minor
|
||||
problems (such as lame servers) will be issued.
|
||||
|
||||
<DT><CODE>notify</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE> (the default), DNS NOTIFY messages are sent when a
|
||||
zone the server is authoritative for changes. The use of NOTIFY
|
||||
speeds convergence between the master and its slaves. Slave servers
|
||||
that receive a NOTIFY message and understand it will contact the
|
||||
master server for the zone and see if they need to do a zone transfer, and
|
||||
if they do, they will initiate it immediately. The <CODE>notify</CODE>
|
||||
option may also be specified in the <CODE>zone</CODE> statement, in which
|
||||
case it overrides the <CODE>options notify</CODE> statement.
|
||||
|
||||
<DT><CODE>recursion</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE>, and a DNS query requests recursion, then the
|
||||
server will attempt to do all the work required to answer the query.
|
||||
If recursion is not on, the server will return a referral to the
|
||||
client if it doesn't know the answer. The default is <CODE>yes</CODE>.
|
||||
See also <CODE>fetch-glue</CODE> above.
|
||||
|
||||
<DT><CODE>rfc2308-type1</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE>, the server will send NS records along with the SOA
|
||||
record for negative answers.
|
||||
You need to set this to <CODE>no</CODE> if you have an old BIND
|
||||
server using you as a forwarder that does not understand negative answers
|
||||
which contain both SOA and NS records or you have an old version of sendmail.
|
||||
The correct fix is to upgrade the broken server or sendmail.
|
||||
The default is <CODE>no</CODE>.
|
||||
|
||||
<DT><CODE>use-id-pool</CODE>
|
||||
<DD>
|
||||
If <CODE>yes</CODE>, the server will keep track of its own outstanding
|
||||
query ID's to avoid duplication and increase randomness. This will result
|
||||
in 128KB more memory being consumed the server.
|
||||
The default is <CODE>no</CODE>.
|
||||
</DL>
|
||||
|
||||
<A NAME="Forwarding"><H4>Forwarding</H4></A>
|
||||
|
||||
<P>The forwarding facility can be used to create a large site-wide
|
||||
cache on a few servers, reducing traffic over links to external
|
||||
nameservers. It can also be used to allow queries by servers that do
|
||||
not have direct access to the Internet, but wish to look up exterior
|
||||
names anyway. Forwarding occurs only on those queries for which the
|
||||
server is not authoritative and does not have the answer in its cache.
|
||||
|
||||
<DL>
|
||||
<DT><CODE>forward</CODE>
|
||||
<DD>
|
||||
This option is only meaningful if the <CODE>forwarders</CODE> list is
|
||||
not empty. A value of <CODE>first</CODE>, the default, causes the
|
||||
server to query the forwarders first, and if that doesn't answer the
|
||||
question the server will then look for the answer itself. If
|
||||
<CODE>only</CODE> is specified, the server will only query the
|
||||
forwarders.
|
||||
|
||||
<DT><CODE>forwarders</CODE>
|
||||
<DD>
|
||||
Specifies the IP addresses to be used for forwarding. The default is the
|
||||
empty list (no forwarding).
|
||||
</DL>
|
||||
|
||||
<P>Forwarding can also be configured on a per-zone basis, allowing for
|
||||
the global forwarding options to be overridden in a variety of ways.
|
||||
You can set particular zones to use different forwarders, or have
|
||||
different <CODE>forward only/first</CODE> behavior, or to not forward
|
||||
at all. See the <A HREF="zone.html"><CODE>zone</CODE></A> statement
|
||||
for more information.
|
||||
|
||||
<P>Future versions of BIND 8 will provide a more powerful forwarding
|
||||
system. The syntax described above will continue to be supported.
|
||||
|
||||
<a name="NameChecking"><H4>Name Checking</H4></a>
|
||||
|
||||
<P>The server can check domain names based upon their expected client contexts.
|
||||
For example, a domain name used as a hostname can be checked for compliance
|
||||
with the RFCs defining valid hostnames.
|
||||
|
||||
<P>Three checking methods are available:
|
||||
|
||||
<DL>
|
||||
<DT><CODE>ignore</CODE>
|
||||
<DD>
|
||||
No checking is done.
|
||||
|
||||
<DT><CODE>warn</CODE>
|
||||
<DD>
|
||||
Names are checked against their expected client contexts. Invalid names are
|
||||
logged, but processing continues normally.
|
||||
|
||||
<DT><CODE>fail</CODE>
|
||||
<DD>
|
||||
Names are checked against their expected client contexts. Invalid names are
|
||||
logged, and the offending data is rejected.
|
||||
</DL>
|
||||
|
||||
<P>The server can check names three areas: master zone files, slave
|
||||
zone files, and in responses to queries the server has initiated. If
|
||||
<CODE>check-names response fail</CODE> has been specified, and
|
||||
answering the client's question would require sending an invalid name
|
||||
to the client, the server will send a REFUSED response code to the
|
||||
client.
|
||||
|
||||
<P>The defaults are:
|
||||
|
||||
<PRE>
|
||||
check-names master fail;
|
||||
check-names slave warn;
|
||||
check-names response ignore;
|
||||
</PRE>
|
||||
|
||||
<P><CODE>check-names</CODE> may also be specified in the
|
||||
<A HREF="zone.html"><CODE>zone</CODE></A>
|
||||
statement, in which case it overrides the <CODE>options check-names</CODE>
|
||||
statement. When used in a <CODE>zone</CODE> statement, the area is not
|
||||
specified (because it can be deduced from the zone type).
|
||||
|
||||
<A name="AccessControl"><H4>Access Control</H4></A>
|
||||
|
||||
<P>Access to the server can be restricted based on the IP address of the
|
||||
requesting system. See
|
||||
<VAR><A HREF="address_list.html">address_match_list</A></VAR> for details
|
||||
on how to specify IP address lists.
|
||||
|
||||
<DL>
|
||||
<DT><CODE>allow-query</CODE>
|
||||
<DD>
|
||||
Specifies which hosts are allowed to ask ordinary questions.
|
||||
<CODE>allow-query</CODE> may also be specified in the
|
||||
<CODE>zone</CODE> statement, in which case it overrides the
|
||||
<CODE>options allow-query</CODE> statement. If not specified, the default is
|
||||
to allow queries from all hosts.
|
||||
|
||||
<DT><CODE>allow-transfer</CODE>
|
||||
<DD>
|
||||
Specifies which hosts are allowed to receive zone transfers from the
|
||||
server. <CODE>allow-transfer</CODE> may also be specified in the
|
||||
<CODE>zone</CODE> statement, in which case it overrides the
|
||||
<CODE>options allow-transfer</CODE> statement. If not specified, the default
|
||||
is to allow transfers from all hosts.
|
||||
|
||||
<DT><CODE>blackhole</CODE>
|
||||
<DD>
|
||||
Specifies a list of addresses that the server will not accept queries from
|
||||
or use to resolve a query. Queries from these addresses will not be
|
||||
responded to.
|
||||
</DL>
|
||||
|
||||
<H4>Interfaces</H4>
|
||||
|
||||
<P>The interfaces and ports that the server will answer queries from may
|
||||
be specified using the <CODE>listen-on</CODE> option. <CODE>listen-on</CODE>
|
||||
takes an optional port, and an
|
||||
<VAR><A HREF="address_list.html">address_match_list</A></VAR>. The server will
|
||||
listen on all interfaces allowed by the address match list. If a port is
|
||||
not specified, port 53 will be used.
|
||||
|
||||
<P>Multiple <CODE>listen-on</CODE> statements are allowed. For example,
|
||||
|
||||
<PRE>
|
||||
listen-on { 5.6.7.8; };
|
||||
listen-on port 1234 { !1.2.3.4; 1.2/16; };
|
||||
</PRE>
|
||||
|
||||
will enable the nameserver on port 53 for the IP address 5.6.7.8, and
|
||||
on port 1234 of an address on the machine in net 1.2 that is not
|
||||
1.2.3.4.
|
||||
|
||||
<P>If no <CODE>listen-on</CODE> is specified, the server will listen on port
|
||||
53 on all interfaces.
|
||||
|
||||
<H4>Query Address</H4>
|
||||
|
||||
<P>If the server doesn't know the answer to a question, it will query
|
||||
other nameservers. <CODE>query-source</CODE> specifies the address
|
||||
and port used for such queries. If <CODE>address</CODE> is
|
||||
<CODE>*</CODE> or is omitted, a wildcard IP address
|
||||
(<CODE>INADDR_ANY</CODE>) will be used. If <CODE>port</CODE> is
|
||||
<CODE>*</CODE> or is omitted, a random unprivileged port will be used.
|
||||
The default is
|
||||
|
||||
<PRE>
|
||||
query-source address * port *;
|
||||
</PRE>
|
||||
|
||||
<P>Note: <CODE>query-source</CODE> currently applies only to UDP queries;
|
||||
TCP queries always use a wildcard IP address and a random unprivileged
|
||||
port.
|
||||
|
||||
<A name="ZoneTransfers"><H4>Zone Transfers</H4></A>
|
||||
|
||||
<DL>
|
||||
<DT><CODE>max-transfer-time-in</CODE>
|
||||
<DD>
|
||||
Inbound zone transfers (<CODE>named-xfer</CODE> processes) running
|
||||
longer than this many minutes will be terminated. The default is 120
|
||||
minutes (2 hours).
|
||||
|
||||
<DT><CODE>transfer-format</CODE>
|
||||
<DD>
|
||||
The server supports two zone transfer methods.
|
||||
<CODE>one-answer</CODE> uses one DNS message per resource record
|
||||
transferred. <CODE>many-answers</CODE> packs as many resource records
|
||||
as possible into a message. <CODE>many-answers</CODE> is more
|
||||
efficient, but is only known to be understood by BIND 8.1 and patched
|
||||
versions of BIND 4.9.5. The default is <CODE>one-answer</CODE>.
|
||||
<CODE>transfer-format</CODE> may be
|
||||
overridden on a per-server basis by using the <CODE>server</CODE> statement.
|
||||
|
||||
<DT><CODE>transfers-in</CODE>
|
||||
<DD>
|
||||
The maximum number of inbound zone transfers that can be running
|
||||
concurrently. The default value is 10. Increasing
|
||||
<CODE>transfers-in</CODE> may speed up the convergence of slave zones,
|
||||
but it also may increase the load on the local system.
|
||||
|
||||
<DT><CODE>transfers-out</CODE>
|
||||
<DD>
|
||||
This option will be used in the future to limit the number of
|
||||
concurrent outbound zone transfers. It is checked for syntax, but is
|
||||
otherwise ignored.
|
||||
|
||||
<DT><CODE>transfers-per-ns</CODE>
|
||||
<DD>
|
||||
The maximum number of inbound zone transfers (<CODE>named-xfer</CODE>
|
||||
processes) that can be concurrently transferring from a given remote
|
||||
nameserver. The default value is 2. Increasing
|
||||
<CODE>transfers-per-ns</CODE> may speed up the convergence of slave
|
||||
zones, but it also may increase the load on the remote nameserver.
|
||||
<CODE>transfers-per-ns</CODE> may be overridden on a per-server basis
|
||||
by using the <CODE>transfers</CODE> phrase of the <CODE>server</CODE>
|
||||
statement.
|
||||
</DL>
|
||||
|
||||
<H4>Resource Limits</H4>
|
||||
|
||||
<P>The server's usage of many system resources can be limited. Some
|
||||
operating systems don't support some of the limits. On such systems,
|
||||
a warning will be issued if the unsupported limit is used. Some
|
||||
operating systems don't support limiting resources, and on these systems
|
||||
a <CODE>cannot set resource limits on this system</CODE> message will
|
||||
be logged.
|
||||
|
||||
<P>Scaled values are allowed when specifying resource limits. For
|
||||
example, <CODE>1G</CODE> can be used instead of
|
||||
<CODE>1073741824</CODE> to specify a limit of one gigabyte.
|
||||
<CODE>unlimited</CODE> requests unlimited use, or the maximum
|
||||
available amount. <CODE>default</CODE> uses the limit that was in
|
||||
force when the server was started. See
|
||||
<VAR><A HREF="docdef.html">size_spec</A></VAR> for more details.
|
||||
|
||||
<DL>
|
||||
<DT><CODE>coresize</CODE>
|
||||
<DD>
|
||||
The maximum size of a core dump. The default is <CODE>default</CODE>.
|
||||
|
||||
<DT><CODE>datasize</CODE>
|
||||
<DD>
|
||||
The maximum amount of data memory the server may use. The default is
|
||||
<CODE>default</CODE>.
|
||||
|
||||
<DT><CODE>files</CODE>
|
||||
<DD>
|
||||
The maximum number of files the server may have open concurrently.
|
||||
The default is <CODE>unlimited</CODE>. <I>Note:</I> on some operating
|
||||
systems the server cannot set an unlimited value and cannot determine
|
||||
the maximum number of open files the kernel can support. On such
|
||||
systems, choosing <CODE>unlimited</CODE> will cause the server to use
|
||||
the larger of the <CODE>rlim_max</CODE> for <CODE>RLIMIT_NOFILE</CODE>
|
||||
and the value returned by <CODE>sysconf(_SC_OPEN_MAX)</CODE>. If the
|
||||
actual kernel limit is larger than this value, use <CODE>limit
|
||||
files</CODE> to specify the limit explicitly.
|
||||
|
||||
<DT><CODE>max-ixfr-log-size</CODE>
|
||||
<DD>
|
||||
The <CODE>max-ixfr-log-size</CODE> will be used in a future release of
|
||||
the server to limit the size of the
|
||||
transaction log kept for Incremental Zone Transfer.
|
||||
|
||||
<DT><CODE>stacksize</CODE>
|
||||
<DD>
|
||||
The maximum amount of stack memory the server may use. The default is
|
||||
<CODE>default</CODE>.
|
||||
</DL>
|
||||
|
||||
<H4>Periodic Task Intervals</H4>
|
||||
|
||||
<DL>
|
||||
<DT><CODE>cleaning-interval</CODE>
|
||||
<DD>
|
||||
The server will remove expired resource records from the cache every
|
||||
<CODE>cleaning-interval</CODE> minutes. The default is 60 minutes. If set
|
||||
to 0, no periodic cleaning will occur.
|
||||
|
||||
<DT><CODE>heartbeat-interval</CODE>
|
||||
<DD>
|
||||
The server will perform zone maintenance tasks for all zones marked
|
||||
<CODE>dialup yes</CODE> whenever this interval expires.
|
||||
The default is 60 minutes. Reasonable values are up to 1 day (1440 minutes).
|
||||
If set to 0, no zone maintenance for these zones will occur.
|
||||
<DT><CODE>interface-interval</CODE>
|
||||
<DD>
|
||||
The server will scan the network interface list every
|
||||
<CODE>interface-interval</CODE> minutes. The default is 60 minutes.
|
||||
If set to 0, interface scanning will only occur when the configuration
|
||||
file is loaded. After the scan, listeners will be started on any new
|
||||
interfaces (provided they are allowed by the <CODE>listen-on</CODE>
|
||||
configuration). Listeners on interfaces that have gone away will be
|
||||
cleaned up.
|
||||
|
||||
<DT><CODE>statistics-interval</CODE>
|
||||
<DD>
|
||||
Nameserver statistics will be logged every <CODE>statistics-interval</CODE>
|
||||
minutes. The default is 60. If set to 0, no statistics will be logged.
|
||||
</DL>
|
||||
|
||||
<H4><A NAME="topology">Topology</A></H4>
|
||||
|
||||
<P>All other things being equal, when the server chooses a nameserver
|
||||
to query from a list of nameservers, it prefers the one that is
|
||||
topologically closest to itself. The <CODE>topology</CODE> statement
|
||||
takes an <VAR><A HREF="address_list.html">address_match_list</A></VAR>
|
||||
and interprets it in a special way. Each top-level list element is
|
||||
assigned a distance. Non-negated elements get a distance based on
|
||||
their position in the list, where the closer the match is to the start
|
||||
of the list, the shorter the distance is between it and the server. A
|
||||
negated match will be assigned the maximum distance from the server.
|
||||
If there is no match, the address will get a distance which is further
|
||||
than any non-negated list element, and closer than any negated
|
||||
element. For example,
|
||||
|
||||
<PRE>
|
||||
topology {
|
||||
10/8;
|
||||
!1.2.3/24;
|
||||
{ 1.2/16; 3/8; };
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<P>will prefer servers on network 10 the most, followed by hosts on
|
||||
network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the exception
|
||||
of hosts on network 1.2.3 (netmask 255.255.255.0), which is preferred least
|
||||
of all.
|
||||
|
||||
<P>The default topology is
|
||||
|
||||
<PRE>
|
||||
topology { localhost; localnets; };
|
||||
</PRE>
|
||||
|
||||
<H4><A NAME="sortlist">Resource Record sorting</A></H4>
|
||||
|
||||
<P>
|
||||
When returning multiple RRs,
|
||||
the nameserver will normally return them in
|
||||
<B>Round Robin</B>,
|
||||
i.e. after each request, the first RR is put to the end of the list.
|
||||
As the order of RRs is not defined, this should not cause any problems.
|
||||
</P>
|
||||
<P>
|
||||
The client resolver code should re-arrange the RRs as appropriate,
|
||||
i.e. using any addresses on the local net in preference to other addresses.
|
||||
However, not all resolvers can do this, or are not correctly configured.
|
||||
</P>
|
||||
<P>
|
||||
When a client is using a local server, the sorting can be performed in the
|
||||
server, based on the client's address.
|
||||
This only requires configuring the nameservers, not all the clients.
|
||||
</P>
|
||||
<P>
|
||||
The sortlist statement takes an address match list and interprets it even
|
||||
more specially than the <A HREF="#topology">topology</A> statement does.
|
||||
</P>
|
||||
<P>
|
||||
Each top level statement in the sortlist must itself be an explicit
|
||||
address match list with one or two elements. The first element
|
||||
(which may be an IP address, an IP prefix, an ACL name or nested
|
||||
address match list) of each top level list is checked against the
|
||||
source address of the query until a match is found.
|
||||
</P>
|
||||
<P>
|
||||
Once the source address of the query has been matched, if the top level
|
||||
statement contains only one element, the actual primitive element that
|
||||
matched the source address is used to select the address in the response
|
||||
to move to the beginning of the response. If the statement is a list
|
||||
of two elements, then the second element is treated like the address
|
||||
match list in a topology statement. Each top level element is assigned
|
||||
a distance and the address in the response with the minimum distance is
|
||||
moved to the beginning of the response.
|
||||
</P>
|
||||
<P>
|
||||
In the following example, any queries received from any of the addresses
|
||||
of the host itself will get responses preferring addresses on any of
|
||||
the locally connected networks. Next most preferred are addresses on
|
||||
the 192.168.1/24 network, and after that either the 192.168.2/24 or
|
||||
192.168.3/24 network with no preference shown between these two networks.
|
||||
Queries received from a host on the 192.168.1/24 network will prefer
|
||||
other addresses on that network to the 192.168.2/24 and 192.168.3/24
|
||||
networks. Queries received from a host on the 192.168.4/24 or the
|
||||
192.168.5/24 network will only prefer other addresses on their
|
||||
directly connected networks.
|
||||
<PRE>
|
||||
sortlist {
|
||||
{ localhost; // IF the local host
|
||||
{ localnets; // THEN first fit on the
|
||||
192.168.1/24; // following nets
|
||||
{ 192,168.2/24; 192.168.3/24; }; }; };
|
||||
{ 192.168.1/24; // IF on class C 192.168.1
|
||||
{ 192.168.1/24; // THEN use .1, or .2 or .3
|
||||
{ 192.168.2/24; 192.168.3/24; }; }; };
|
||||
{ 192.168.2/24; // IF on class C 192.168.2
|
||||
{ 192.168.2/24; // THEN use .2, or .1 or .3
|
||||
{ 192.168.1/24; 192.168.3/24; }; }; };
|
||||
{ 192.168.3/24; // IF on class C 192.168.3
|
||||
{ 192.168.3/24; // THEN use .3, or .1 or .2
|
||||
{ 192.168.1/24; 192.168.2/24; }; }; };
|
||||
{ { 192.168.4/24; 192.168.5/24; }; // if .4 or .5, prefer that net
|
||||
};
|
||||
};
|
||||
</PRE>
|
||||
The following example will give reasonable behaviour for the local host
|
||||
and hosts on directly connected networks. It is similar to the behavior
|
||||
of the address sort in BIND 4.9.x. Responses sent to queries from the
|
||||
local host will favor any of the directly connected networks. Responses
|
||||
sent to queries from any other hosts on a directly connected network will
|
||||
prefer addresses on that same network. Responses to other queries will
|
||||
not be sorted.
|
||||
<PRE>
|
||||
sortlist {
|
||||
{ localhost; localnets; };
|
||||
{ localnets; };
|
||||
};
|
||||
</PRE>
|
||||
<!--
|
||||
* XXX - it would be nice to have an ACL called "source" that matched the
|
||||
* source address of a query so that a host could be configured to
|
||||
* automatically prefer itself, and an ACL called "sourcenet", that
|
||||
* would return the primitive IP match element that matched the source
|
||||
* address so that you could do:
|
||||
* { localnets; { sourcenet; { other stuff ...}; };
|
||||
* and automatically get similar behaviour to what you get with:
|
||||
* { localnets; };
|
||||
-->
|
||||
</P>
|
||||
|
||||
<a name="RrsetOrder">
|
||||
<H4>RRset Ordering</H4>
|
||||
|
||||
<P>When multiple records are returned in an answer it may be useful to
|
||||
configure the order the records are placed into the response. For example the
|
||||
records for a zone might be configured to always be returned in the order they
|
||||
are defined in the zone file. Or perhaps a <i>random</i> shuffle of the
|
||||
records as they are returned is wanted. The <var>rrset-order</var> statement
|
||||
permits configuration of the ordering made of the records in a multiple record
|
||||
response. The default, if no ordering is defined, is a cyclic ordering (round
|
||||
robin).
|
||||
|
||||
<P>An <var>order_spec</var> is defined as follows:
|
||||
|
||||
<PRE>
|
||||
[ <var>class</var> class_name ][ <var>type</var> type_name ][ <var>name</var> "FQDN" ] <var>order</var> ordering
|
||||
</PRE>
|
||||
|
||||
<P>If no <var>class</var> is specified, the default is <code>ANY</code>. If no
|
||||
<var>type</var> is specified, the default is <code>ANY</code>. If no
|
||||
<var>name</var> is specified, the default is <code>"*"</code>.
|
||||
|
||||
<P>The legal values for <code>ordering</code> are:
|
||||
|
||||
<DL>
|
||||
<DT><code>fixed</code>
|
||||
<DD>Records are returned in the order they are defined in the zone file.
|
||||
|
||||
<DT><code>random</code>
|
||||
<DD>Records are returned in some random order.
|
||||
|
||||
<DT><code>cyclic</code>
|
||||
<DD>Records are returned in a round-robin order.
|
||||
|
||||
</DL>
|
||||
|
||||
|
||||
<P>For example:
|
||||
|
||||
<PRE>
|
||||
rrset-order {
|
||||
class IN type A name "rc.vix.com" order random;
|
||||
order cyclic;
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<P>will cause any responses for type <VAR>A</VAR> records in class
|
||||
<VAR>IN</VAR> that have "rc.vix.com" as a suffix, to always be returned in
|
||||
random order. All other records are returned in cyclic order.
|
||||
|
||||
<P>If multiple <code>rrset-order</code> statements appear, they are not
|
||||
combined--the last one applies.
|
||||
|
||||
<P>If no <code>rrset-order</code> statement is specified, then a default one
|
||||
of:
|
||||
|
||||
<pre>
|
||||
rrset-order { class ANY type ANY name "*" order cyclic ; };
|
||||
</pre>
|
||||
|
||||
<P>is used.
|
||||
|
||||
<H4>Tuning</H4>
|
||||
|
||||
<DL>
|
||||
<DT><CODE>lame-ttl</CODE>
|
||||
<DD>
|
||||
Sets the number of seconds to cache a lame server indication.
|
||||
0 disables caching. Default is 600 (10 minutes). Maximum value is 1800 (30 minutes).
|
||||
<DT><CODE>max-ncache-ttl</CODE>
|
||||
<DD>
|
||||
To reduce network traffic and increase performance the server store negative
|
||||
answers. <CODE>max-ncache-ttl</CODE> is used to set a maximum retention time
|
||||
for these answers in the server is seconds. The default <CODE>max-ncache-ttl</CODE> is
|
||||
10800 seconds (3 hours). <CODE>max-ncache-ttl</CODE> cannot exceed the
|
||||
maximum retention time for ordinary (positive) answers (7 days) and will be
|
||||
silently truncated to 7 days if set to a value which is greater that 7 days.
|
||||
</DL>
|
||||
|
||||
|
||||
<H4>Security</H4>
|
||||
<P>
|
||||
<DL>
|
||||
<DT><CODE>tkey-domain</CODE>
|
||||
<DD>
|
||||
A quoted string that sets the domain name appended to relative names used in
|
||||
the TKEY key creation process. When an agreement is initiated by the client,
|
||||
it may request a relative name, random name, or an absolute name. If a
|
||||
relative name is used or a random name is created, the value of tkey-domain
|
||||
will be appended.
|
||||
|
||||
<DT><CODE>tkey-dhkey</CODE>
|
||||
<DD>
|
||||
A quoted string that sets the Diffie Hellman key used by the server in a key
|
||||
exchange. A shared secret will be derived from this key, the client's key,
|
||||
and some random data, and the secret will be saved as a TSIG shared secret for
|
||||
later use.
|
||||
</DL>
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: options.html,v 1.4 2000/07/27 09:42:21 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,86 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND server Statement</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide--<CODE>server</CODE> Statement</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
server <VAR><A HREF="docdef.html">ip_addr</A></VAR> {
|
||||
[ bogus <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ support-ixfr <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ transfers <VAR><A HREF="docdef.html">number</A></VAR>; ]
|
||||
[ transfer-format ( one-answer | many-answers ); ]
|
||||
[ keys { <VAR><A HREF="key.html">key_id</A></VAR> [<VAR>key_id</VAR> ... ] }; ]
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Usage"><H3>Definition and Usage</H3></A>
|
||||
|
||||
<P>The server statement defines the characteristics to be
|
||||
associated with a remote name server.</P>
|
||||
|
||||
<P>If you discover that a server is giving out bad data, marking it as
|
||||
<CODE>bogus</CODE> will prevent further queries to it. The default value of
|
||||
<CODE>bogus</CODE> is <CODE>no</CODE>.
|
||||
|
||||
<P>The server supports two zone transfer methods. The first,
|
||||
<CODE>one-answer</CODE>, uses one DNS message per resource record
|
||||
transferred. <CODE>many-answers</CODE> packs as many resource records
|
||||
as possible into a message. <CODE>many-answers</CODE> is more
|
||||
efficient, but is only known to be understood by BIND 8.1 and patched
|
||||
versions of BIND 4.9.5. You can specify which method to use for a
|
||||
server with the <CODE>transfer-format</CODE> option. If
|
||||
<CODE>transfer-format</CODE> is not specified, the <CODE>transfer-format</CODE>
|
||||
specified by the <CODE>options</CODE> statement will be used.
|
||||
|
||||
<P>The <CODE>transfers</CODE> will be used in a future release of the server
|
||||
to limit the number of concurrent in-bound zone transfers from the specified
|
||||
server. It is checked for syntax but is otherwise ignored.
|
||||
|
||||
<P>The <CODE>keys</CODE> clause is used to identify a
|
||||
<VAR>key_id</VAR> defined by the <CODE>key</CODE> statement, to be
|
||||
used for transaction security when talking to the remote server.
|
||||
The <CODE>key</CODE> statememnt must come before the <CODE>server</CODE>
|
||||
statement that references it. When a request is sent to the remote server,
|
||||
a request signature will be generated using the key specified here and
|
||||
appended to the message. A request originating from the remote server is not
|
||||
required to be signed by this key.
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: server.html,v 1.3 2000/07/27 09:42:22 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,75 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND trusted-keys Statement</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide--<CODE>trusted-keys</CODE> Statement</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
trusted-keys {
|
||||
[ <VAR><A HREF="docdef.html">domain_name</A></VAR> <VAR><A HREF="docdef.html">number</A></VAR> <VAR><A HREF="docdef.html">number</A></VAR> <VAR><A HREF="docdef.html">number</A></VAR> <VAR>string</VAR>; ]
|
||||
};
|
||||
|
||||
</PRE>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Usage"><H3>Definition and Usage</H3></A>
|
||||
|
||||
The <CODE>trusted-keys</CODE>
|
||||
statement is for use with DNSSEC-style security, originally specified
|
||||
in RFC 2065. DNSSEC is meant to
|
||||
provide three distinct services: key distribution, data origin
|
||||
authentication, and transaction and request authentication. A
|
||||
complete description of DNSSEC and its use is beyond the scope of this
|
||||
document, and readers interested in more information should start with
|
||||
<A HREF="http://info.internet.isi.edu/in-notes/rfc/files/rfc2065.txt">
|
||||
RFC 2065</A> and then continue with the
|
||||
<A HREF="http://www.ietf.org/ids.by.wg/dnssec.html">
|
||||
Internet Drafts</A>.</P>
|
||||
|
||||
<P>Each trusted key is associated with a domain name. Its attributes are
|
||||
the non-negative integral <VAR>flags</VAR>, <VAR>protocol</VAR>, and
|
||||
<VAR>algorithm</VAR>, as well as a base-64 encoded string representing
|
||||
the key.</P>
|
||||
|
||||
A trusted key is added when a public key for a non-authoritative zone is
|
||||
known, but cannot be securely obtained through DNS. This occurs when
|
||||
a signed zone is a child of an unsigned zone. Adding the trusted
|
||||
key here allows data signed by that zone to be considered secure.</P>
|
||||
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: trusted-keys.html,v 1.3 2000/07/27 09:42:23 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1,280 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<!--
|
||||
- Copyright (C) 1999, 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.
|
||||
-->
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BIND zone Statement</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
<H2>BIND Configuration File Guide--<CODE>zone</CODE> Statement</H2>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Syntax"><H3>Syntax</H3></A>
|
||||
|
||||
<PRE>
|
||||
zone <VAR><A HREF="docdef.html">domain_name</A></VAR> [ ( in | hs | hesiod | chaos ) ] {
|
||||
type master;
|
||||
file <VAR><A HREF="docdef.html">path_name</A></VAR>;
|
||||
[ forward ( only | first ); ]
|
||||
[ forwarders { [ <VAR><A HREF="docdef.html">ip_addr</A></VAR> ; [ <VAR>ip_addr</VAR> ; ... ] ] }; ]
|
||||
[ check-names ( warn | fail | ignore ); ]
|
||||
[ allow-update { <VAR><A HREF="address_list.html">address_match_list</A></VAR> }; ]
|
||||
[ allow-query { <VAR><A HREF="address_list.html">address_match_list</A></VAR> }; ]
|
||||
[ allow-transfer { <VAR><A HREF="address_list.html">address_match_list</A></VAR> }; ]
|
||||
[ dialup <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ notify <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ also-notify { <VAR><A HREF="docdef.html">ip_addr</A></VAR>; [ <VAR>ip_addr</VAR>; ... ] };
|
||||
[ ixfr-base <VAR><A HREF="docdef.html">path_name</A></VAR>; ]
|
||||
[ pubkey <VAR><A HREF="docdef.html">number</A></VAR> <VAR><A HREF="docdef.html">number</A></VAR> <VAR><A HREF="docdef.html">number</A></VAR> <VAR>string</VAR>; ]
|
||||
};
|
||||
|
||||
zone <VAR><A HREF="docdef.html">domain_name</A></VAR> [ ( in | hs | hesiod | chaos ) ] {
|
||||
type slave;
|
||||
[ file <VAR><A HREF="docdef.html">path_name</A></VAR>; ]
|
||||
[ ixfr-base <VAR><A HREF="docdef.html">path_name</A></VAR>; ]
|
||||
masters [ port <VAR><A HREF="docdef.html">ip_port</A></VAR> ] { <VAR><A HREF="docdef.html">ip_addr</A></VAR>; [ <VAR>ip_addr</VAR>; ... ] };
|
||||
[ forward ( only | first ); ]
|
||||
[ forwarders { [ <VAR><A HREF="docdef.html">ip_addr</A></VAR> ; [ <VAR>ip_addr</VAR> ; ... ] ] }; ]
|
||||
[ check-names ( warn | fail | ignore ); ]
|
||||
[ allow-update { <VAR><A HREF="address_list.html">address_match_list</A></VAR> }; ]
|
||||
[ allow-query { <VAR><A HREF="address_list.html">address_match_list</A></VAR> }; ]
|
||||
[ allow-transfer { <VAR><A HREF="address_list.html">address_match_list</A></VAR> }; ]
|
||||
[ transfer-source <VAR><A HREF="docdef.html">ip_addr</A></VAR>; ]
|
||||
[ max-transfer-time-in <VAR>number</VAR>; ]
|
||||
[ dialup <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ notify <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ also-notify { <VAR><A HREF="docdef.html">ip_addr</A></VAR>; [ <VAR>ip_addr</VAR>; ... ] };
|
||||
[ pubkey <VAR><A HREF="docdef.html">number</A></VAR> <VAR><A HREF="docdef.html">number</A></VAR> <VAR><A HREF="docdef.html">number</A></VAR> <VAR>string</VAR>; ]
|
||||
};
|
||||
|
||||
|
||||
zone <VAR><A HREF="docdef.html">domain_name</A></VAR> [ ( in | hs | hesiod | chaos ) ] {
|
||||
type stub;
|
||||
[ file <VAR><A HREF="docdef.html">path_name</A></VAR>; ]
|
||||
masters [ port <VAR><A HREF="docdef.html">ip_port</A></VAR> ] { <VAR><A HREF="docdef.html">ip_addr</A></VAR>; [ <VAR>ip_addr</VAR>; ... ] };
|
||||
[ forward ( only | first ); ]
|
||||
[ forwarders { [ <VAR><A HREF="docdef.html">ip_addr</A></VAR> ; [ <VAR>ip_addr</VAR> ; ... ] ] }; ]
|
||||
[ check-names ( warn | fail | ignore ); ]
|
||||
[ allow-update { <VAR><A HREF="address_list.html">address_match_list</A></VAR> }; ]
|
||||
[ allow-query { <VAR><A HREF="address_list.html">address_match_list</A></VAR> }; ]
|
||||
[ allow-transfer { <VAR><A HREF="address_list.html">address_match_list</A></VAR> }; ]
|
||||
[ dialup <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
||||
[ transfer-source <VAR><A HREF="docdef.html">ip_addr</A></VAR>; ]
|
||||
[ max-transfer-time-in <VAR>number</VAR>; ]
|
||||
[ pubkey <VAR><A HREF="docdef.html">number</A></VAR> <VAR><A HREF="docdef.html">number</A></VAR> <VAR><A HREF="docdef.html">number</A></VAR> <VAR>string</VAR>; ]
|
||||
};
|
||||
|
||||
zone <VAR><A HREF="docdef.html">domain_name</A></VAR> [ ( in | hs | hesiod | chaos ) ] {
|
||||
type forward;
|
||||
[ forward ( only | first ); ]
|
||||
[ forwarders { [ <VAR><A HREF="docdef.html">ip_addr</A></VAR> ; [ <VAR>ip_addr</VAR> ; ... ] ] }; ]
|
||||
[ check-names ( warn | fail | ignore ); ]
|
||||
};
|
||||
|
||||
zone "." [ ( in | hs | hesiod | chaos ) ] {
|
||||
type hint;
|
||||
file <VAR><A HREF="docdef.html">path_name</A></VAR>;
|
||||
[ check-names ( warn | fail | ignore ); ]
|
||||
};
|
||||
</PRE>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME="Usage"><H3>Definition and Usage</H3></A>
|
||||
<H4>Syntax</H4>
|
||||
<P>
|
||||
The <CODE>type</CODE> statement must come first in the body of the
|
||||
zone statement.
|
||||
|
||||
|
||||
<H4>Zone Types</H4>
|
||||
|
||||
<DL>
|
||||
<DT><CODE>master</CODE>
|
||||
<DD>
|
||||
The server has a master copy of the data for the zone and will be able
|
||||
to provide authoritative answers for it.
|
||||
|
||||
|
||||
<DT><CODE>slave</CODE>
|
||||
<DD>
|
||||
A <CODE>slave</CODE> zone is a replica of a master zone. The
|
||||
<CODE>masters</CODE> list specifies one or more IP addresses that the
|
||||
slave contacts to update its copy of the zone. If a <CODE>port</CODE>
|
||||
is specified then checks to see if the zone is current and zone transfers
|
||||
will be done to the port given. If <CODE>file</CODE>
|
||||
is specified, then the replica will be written to this file whenever
|
||||
the zone is changed, and reloaded from this file on a server restart.
|
||||
Use of
|
||||
<CODE>file</CODE> is recommended, since it often speeds server startup
|
||||
and eliminates a needless waste of bandwidth. Note that for large numbers
|
||||
(in the tens or hundreds of thousands) of zones per server, it is best to
|
||||
use a two level naming scheme for zone file names. For example, a slave
|
||||
server for the zone <CODE>vix.com</CODE> might place the zone contents into
|
||||
a file called <CODE>"vi/vix.com"</CODE> where <CODE>vi/</CODE> is just the
|
||||
first two letters of the zone name. (Most operating systems behave very
|
||||
slowly if you put 100K files into a single directory.)
|
||||
|
||||
<DT><CODE>stub</CODE>
|
||||
<DD>
|
||||
A <CODE>stub</CODE> zone is like a slave zone, except that it replicates
|
||||
only the NS records of a master zone instead of the entire zone.
|
||||
|
||||
<DT><CODE>forward</CODE>
|
||||
<DD>
|
||||
A <CODE>forward</CODE> zone is used to <A HREF="options.html#Forwarding">
|
||||
direct all queries</A> in it to other servers. The specification of
|
||||
options in such a zone will override any global options
|
||||
declared in the <A HREF="options.html#Forwarding">options</A> statement.
|
||||
|
||||
<P>If either no <CODE>forwarders</CODE> statement is present in the
|
||||
zone or an empty list for <CODE>forwarders</CODE> is given, then no
|
||||
forwarding will be done for the zone, cancelling the effects of any
|
||||
<CODE>forwarders</CODE> in the <CODE>options</CODE> statement.
|
||||
Thus if you want to use this
|
||||
type of zone to change the behavior of the global <CODE>forward</CODE>
|
||||
option, and not the servers used, then you also need to respecify the
|
||||
global forwarders.
|
||||
|
||||
<DT><CODE>hint</CODE>
|
||||
<DD>
|
||||
The initial set of root nameservers is specified using a
|
||||
<CODE>hint</CODE> zone. When the server starts up, it uses the root hints
|
||||
to find a root nameserver and get the most recent list of root nameservers.
|
||||
</DL>
|
||||
|
||||
<P>Note: previous releases of BIND used the term <EM>primary</EM> for a
|
||||
master zone, <EM>secondary</EM> for a slave zone, and <EM>cache</EM> for
|
||||
a hint zone.</P>
|
||||
|
||||
<H4>Class</H4>
|
||||
|
||||
<P>The zone's name may optionally be followed by a class. If a class
|
||||
is not specified, class <CODE>in</CODE> (for "internet"), is assumed.
|
||||
This is correct for the vast majority of cases.
|
||||
|
||||
<P>The <CODE>hesiod</CODE> class is for an information service from MIT's
|
||||
Project Athena. It is used to share information about various systems
|
||||
databases, such as users, groups, printers and so on. More
|
||||
information can be found at
|
||||
<A HREF="ftp://athena-dist.mit.edu/pub/ATHENA/usenix/athena_changes.PS">MIT</A>.
|
||||
The keyword <CODE>hs</CODE> is a synonym for <CODE>hesiod</CODE>.</P>
|
||||
|
||||
<P>Another MIT development was CHAOSnet, a LAN protocol created in the
|
||||
mid-1970s. It is still sometimes seen on LISP stations and other
|
||||
hardware in the AI community, and zone data for it can be specified
|
||||
with the
|
||||
<CODE>chaos</CODE> class.</P>
|
||||
|
||||
<H4>Options</H4>
|
||||
|
||||
<DL>
|
||||
<DT><CODE>check-names</CODE>
|
||||
<DD>
|
||||
See <A HREF="options.html#NameChecking">Name Checking</A>.
|
||||
|
||||
<DT><CODE>allow-query</CODE>
|
||||
<DD>
|
||||
See the description of <CODE>allow-query</CODE> in the
|
||||
<A HREF="options.html#AccessControl">Access Control</A> section.
|
||||
|
||||
<DT><CODE>allow-update</CODE>
|
||||
<DD>
|
||||
Specifies which hosts are allowed to submit Dynamic DNS updates to the
|
||||
server. The default is to deny updates from all hosts.
|
||||
|
||||
<DT><CODE>allow-transfer</CODE>
|
||||
<DD>
|
||||
See the description of <CODE>allow-transfer</CODE> in
|
||||
the <A HREF="options.html#AccessControl">Access Control</A> section.
|
||||
|
||||
<DT><CODE>transfer-source</CODE>
|
||||
<DD>
|
||||
<CODE>transfer-source</CODE> determines which local address will be bound to
|
||||
the TCP connection used to fetch this zone. If not set, it defaults to a
|
||||
system controlled value which will usually be the address of the interface
|
||||
``closest to'' the remote end. This address must appear in the remote end's
|
||||
<CODE>allow-transfer</CODE> option for this zone if one is specified.
|
||||
|
||||
<DT><CODE>ixfr_base</CODE>
|
||||
<DD>
|
||||
<CODE>ixfr_base</CODE>
|
||||
Specifies the file name used for IXFR transaction log file.
|
||||
|
||||
<DT><CODE>max-transfer-time-in</CODE>
|
||||
<DD>
|
||||
See the description of <CODE>max-transfer-time-in</CODE> in
|
||||
the <A HREF="options.html#ZoneTransfers">Zone Transfers</A> section.
|
||||
|
||||
<DT><CODE>dialup</CODE>
|
||||
<DD>
|
||||
See the description of <CODE>dialup</CODE> in
|
||||
the <A HREF="options.html#BooleanOptions">Boolean Options</A> section.
|
||||
|
||||
<DT><CODE>notify</CODE>
|
||||
<DD>
|
||||
See the description of <CODE>notify</CODE> in
|
||||
the <A HREF="options.html#BooleanOptions">Boolean Options</A> section.
|
||||
|
||||
<DT><CODE>also-notify</CODE>
|
||||
<DD>
|
||||
<CODE>also-notify</CODE> is only meaningful if <CODE>notify</CODE> is
|
||||
active for this zone. The set of machines that will receive a DNS
|
||||
NOTIFY message for this zone is made up of all the listed nameservers
|
||||
for the zone (other than the primary master) plus any IP addresses
|
||||
specified with <CODE>also-notify</CODE>. <CODE>also-notify</CODE> is not
|
||||
meaningful for <CODE>stub</CODE> zones. The default is the empty list.
|
||||
|
||||
<DT><CODE>forward</CODE>
|
||||
<DD>
|
||||
<CODE>forward</CODE> is only meaningful if the zone has a
|
||||
<CODE>forwarders</CODE> list. The <CODE>only</CODE> value causes the
|
||||
lookup to fail after trying the <CODE>forwarders</CODE> and getting no
|
||||
answer, while <CODE>first</CODE> would allow a normal lookup to be tried.
|
||||
|
||||
<DT><CODE>forwarders</CODE>
|
||||
<DD>
|
||||
The <CODE>forwarders</CODE> option in a zone is used to override the
|
||||
list of global forwarders. If it is not specified in a zone of type
|
||||
<CODE>forward</CODE>, <STRONG>no</STRONG> forwarding is done for the
|
||||
zone; the global options are not used.
|
||||
|
||||
<DT><CODE>pubkey</CODE>
|
||||
<DD>
|
||||
A pubkey represents a private key for this zone. It is needed when this is the
|
||||
top level authoritative zone served by this server and there is no chain of
|
||||
trust to a <A HREF="trusted-keys.html">trusted key</A>. It is considered
|
||||
secure, so that data that it signs will be considered secure. The DNSSEC
|
||||
flags, protocol, and algorithm are specified, as well as a base-64 encoded
|
||||
string representing the key.
|
||||
|
||||
</DL>
|
||||
<HR>
|
||||
|
||||
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
||||
| <A HREF="http://www.vix.com/isc/bind.html">BIND Home</A>
|
||||
| <A HREF="http://www.isc.org">ISC</A> ]</P></CENTER>
|
||||
|
||||
<HR>
|
||||
<ADDRESS>
|
||||
Last Updated: $Id: zone.html,v 1.4 2000/07/27 09:42:24 tale Exp $
|
||||
</ADDRESS>
|
||||
</BODY>
|
||||
</HTML>
|
||||
Reference in New Issue
Block a user