865 lines
34 KiB
HTML
865 lines
34 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<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 {
|
|
[ hostname <VAR>hostname_string</VAR>; ]
|
|
[ 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>; ]
|
|
[ host-statistics-max <VAR>number</VAR>; ]
|
|
[ multiple-cnames <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
|
[ notify ( <VAR><A HREF="docdef.html">yes_or_no</A></VAR> | explicit ) <; ]
|
|
[ suppress-initial-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>; ]
|
|
[ treat-cr-as-space <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
|
|
[ also-notify { <VAR><A HREF="docdef.html">ip_addr</A></VAR>; [ <VAR><A HREF="docdef.html">ip_addr</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> }; ]
|
|
[ allow-recursion { <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>; ]
|
|
[ min-roots <VAR>number</VAR>; ]
|
|
[ serial-queries <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>; ]
|
|
[ transfer-source <VAR><A HREF="docdef.html">ip_addr</A></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> ; ... ] }; ]
|
|
[ preferred-glue ( A | AAAA ); ]
|
|
[ edns-udp-size <VAR>number</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>Server Information</H4>
|
|
|
|
<DL>
|
|
<DT><CODE>hostname</CODE>
|
|
<DD>
|
|
This defaults to the hostname of the machine hosting the nameserver
|
|
as found by gethostname().
|
|
Its prime purpose is to be able to identify which of a number of anycast
|
|
servers is actually answering your queries by sending a <I>txt</I>
|
|
query for <CODE>hostname.bind</CODE> in class <I>chaos</I> to the anycast
|
|
server and getting back a unique name.
|
|
Setting the hostname to a empty string ("") will disable processing of
|
|
the queries.
|
|
|
|
<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 the server, but some server
|
|
operators prefer the string <CODE>"surely you must be joking"</CODE>.
|
|
Changing the value of this string will not prevent people from identifying
|
|
what version you are running.
|
|
</DL>
|
|
|
|
<H4>Pathnames</H4>
|
|
|
|
<DL>
|
|
<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>, the <CODE>AA</CODE> bit is always set on
|
|
NXDOMAIN responses, even if the server is not actually authoritative.
|
|
The default is <CODE>no</CODE>. Turning <CODE>auth-nxdomain</CODE> will
|
|
allow older clients that require <CODE>AA</CODE> to be set to accept
|
|
NXDOMAIN responses to work.
|
|
|
|
<DT><CODE>deallocate-on-exit</CODE>
|
|
<DD>
|
|
If <CODE>yes</CODE>, the server will painstakingly deallocate every object it
|
|
it allocated, when it exits, 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>, 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> zone, 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> zone, the server
|
|
will suppress the regular "zone up to date" queries and only perform
|
|
them 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 following
|
|
options: <CODE>auth-nxdomain yes;</CODE> and <CODE>rfc2308-type1 no;</CODE>.
|
|
The use of <CODE>has-old-clients</CODE> with <CODE>auth-nxdomain</CODE>
|
|
and <CODE>rfc2308-type1</CODE> is order dependent.
|
|
|
|
<DT><CODE>host-statistics</CODE>
|
|
<DD>
|
|
If <CODE>yes</CODE>, 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>host-statistics-max</CODE>
|
|
<DD>
|
|
The maximum number of host records that will be kept. When this limit is
|
|
reached no new hosts will be added to the host statistics. If the set
|
|
to zero then there is no limit set. The default value is zero.
|
|
|
|
<DT><CODE>maintain-ixfr-base</CODE>
|
|
<DD>
|
|
If <CODE>yes</CODE>, 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>, 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>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 to see if they need to do a zone transfer. If
|
|
they do, they will initiate it immediately. If <CODE>explicit</CODE>,
|
|
the NOTIFY messages will only be sent to the addresses in the
|
|
<CODE>also-notify</CODE> list. 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>suppress-initial-notify</CODE>
|
|
<DD>
|
|
If <CODE>yes</CODE>, suppress the initial notify messages when the server
|
|
first loads. The default is <CODE>no</CODE>.
|
|
|
|
<DT><CODE>recursion</CODE>
|
|
<DD>
|
|
If <CODE>yes</CODE>, and a DNS query requests recursion, 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 from the cache.
|
|
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 by the server.
|
|
The default is <CODE>no</CODE>.
|
|
|
|
<DT><CODE>treat-cr-as-space</CODE>
|
|
<DD>
|
|
If <CODE>yes</CODE>, the server will treat '\r' characters the same way it
|
|
treats a ' ' or '\t'. This may be necessary when loading zone files on a
|
|
UNIX system that were generated on an NT or DOS machine. The default is <CODE>no</CODE>.
|
|
|
|
</DL>
|
|
|
|
<A NAME="Also-notify"><H4>Also-Notify</H4></A>
|
|
|
|
<DT><CODE>also-notify</CODE>
|
|
<P>
|
|
Defines a global list of IP addresses that also get sent NOTIFY messages
|
|
whenever a fresh copy of the zone is loaded. This helps to ensure that
|
|
copies of the zones will quickly converge on ``stealth'' servers.
|
|
If an <CODE>also-notify</CODE> list is given in a <CODE>zone</CODE>
|
|
statement, it will override the <CODE>options also-notify</CODE> statement.
|
|
When a <CODE>zone notify</CODE> statement is set to <CODE>no</CODE>,
|
|
the IP addresses in the global <CODE>also-notify</CODE> list will not get
|
|
sent NOTIFY messages for that zone.
|
|
The default is the empty list (no global notification list).
|
|
|
|
<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>allow-recursion</CODE>
|
|
<DD>
|
|
Specifies which hosts are allowed to make recursive queries through this
|
|
server. If not specified, the default is to allow recursive queries 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 port</CODE> applies only to UDP queries,
|
|
TCP queries always use 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.
|
|
|
|
<DT><CODE>transfer-source</CODE>
|
|
<DD>
|
|
<CODE>transfer-source</CODE> determines which local address will be bound
|
|
to the TCP connection used to fetch all zones transferred inbound by the
|
|
server. 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 the zone being transferred, if one is specified. This statement
|
|
sets the <CODE>transfer-source</CODE> for all zones, but can be overridden
|
|
on a per-zone basis by including a <CODE>transfer-source</CODE> statement
|
|
within the zone block in the configuration file.
|
|
|
|
<DT><CODE>serial-queries</CODE>
|
|
<DD>
|
|
Slave servers will periodically query master servers to find out if zone
|
|
serial numbers have changed. Each such query uses a minute amount of the
|
|
slave server's network bandwidth, but more importantly each query uses a
|
|
small amount of <I>memory</I> in the slave server while waiting for the
|
|
master server to respond. The <CODE>serial-queries</CODE> option sets the
|
|
maximum number of concurrent serial-number queries allowed to be outstanding
|
|
at any given time. The default is four (4).
|
|
<B>Note:</B>
|
|
If a server loads a large (tens or hundreds of thousands) number of slave
|
|
zones, this limit should be raised to the high hundreds or low
|
|
thousands -- otherwise the slave server may never actually become aware of
|
|
zone changes in the master servers. Beware, though, that setting this limit
|
|
arbitrarily high can spend a considerable amount of your slave server's
|
|
network, CPU, and memory resources. As with all tunable limits, this one
|
|
should be changed gently and monitored for its effects.
|
|
</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>
|
|
Limit the size of the transaction log kept for Incremental Zone Transfer.
|
|
Default 0 (unlimited).
|
|
|
|
<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, 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, a default one
|
|
of:
|
|
|
|
<pre>
|
|
rrset-order { class ANY type ANY name "*" order cyclic ; };
|
|
</pre>
|
|
|
|
<P>is used.
|
|
|
|
<H4>Glue Ordering</H4>
|
|
|
|
When running a root nameserver it is sometimes necessary to ensure that
|
|
other nameservers that are priming are successful. This requires
|
|
that glue A records for at least of the nameservers are returned in
|
|
the answer to a priming query. This can be achieved by setting
|
|
<CODE>preferred-glue A;</CODE> which will add A records before other types
|
|
in the additional section.
|
|
|
|
<H4>EDNS</H4>
|
|
|
|
Some firewalls fail to pass EDNS/UDP messages that are larger than
|
|
certain size, 512 or the UDP reassembly buffer. To allow EDNS to
|
|
work across such firewalls it is necessary to advertise a EDNS
|
|
buffer size that is small enough to not trigger failures.
|
|
<CODE>edns-udp-size</CODE> can be use to adjust the advertised size.
|
|
Values less than 512 will be increased to 512 and values greater than
|
|
4096 will be truncated to 4096.
|
|
|
|
<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 stores 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.
|
|
<DT><CODE>min-roots</CODE>
|
|
<DD>
|
|
The minimum number of root servers that is required for a
|
|
request for the root servers to be accepted. Default 2.
|
|
</DL>
|
|
<HR>
|
|
|
|
<CENTER><P>[ <A HREF="config.html">BIND Config. File</A>
|
|
| <A HREF="http://www.isc.org/products/BIND/">BIND Home</A>
|
|
| <A HREF="http://www.isc.org/">ISC</A> ]</P></CENTER>
|
|
|
|
<HR>
|
|
<ADDRESS>
|
|
Last Updated: $Id: options.html,v 1.49.6.1 2003/06/02 09:56:33 marka Exp $
|
|
</ADDRESS>
|
|
</BODY>
|
|
</HTML>
|