options
Statementoptions { [ hostname hostname_string; ] [ version version_string; ] [ directory path_name; ] [ named-xfer path_name; ] [ dump-file path_name; ] [ memstatistics-file path_name; ] [ pid-file path_name; ] [ statistics-file path_name; ] [ auth-nxdomain yes_or_no; ] [ deallocate-on-exit yes_or_no; ] [ dialup yes_or_no; ] [ fake-iquery yes_or_no; ] [ fetch-glue yes_or_no; ] [ has-old-clients yes_or_no; ] [ host-statistics yes_or_no; ] [ host-statistics-max number; ] [ multiple-cnames yes_or_no; ] [ notify ( yes_or_no | explicit ) <; ] [ suppress-initial-notify yes_or_no; ] [ recursion yes_or_no; ] [ rfc2308-type1 yes_or_no; ] [ use-id-pool yes_or_no; ] [ treat-cr-as-space yes_or_no; ] [ also-notify { ip_addr; [ ip_addr; ... ] }; ] [ forward ( only | first ); ] [ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ] [ check-names ( master | slave | response ) ( warn | fail | ignore); ] [ allow-query { address_match_list }; ] [ allow-transfer { address_match_list }; ] [ allow-recursion { address_match_list }; ] [ blackhole { address_match_list }; ] [ listen-on [ port ip_port ] { address_match_list }; ] [ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ] ; ] [ lame-ttl number; ] [ max-transfer-time-in number; ] [ max-ncache-ttl number; ] [ min-roots number; ] [ serial-queries number; ] [ transfer-format ( one-answer | many-answers ); ] [ transfers-in number; ] [ transfers-out number; ] [ transfers-per-ns number; ] [ transfer-source ip_addr; ] [ maintain-ixfr-base yes_or_no; ] [ max-ixfr-log-size number; ] [ coresize size_spec ; ] [ datasize size_spec ; ] [ files size_spec ; ] [ stacksize size_spec ; ] [ cleaning-interval number; ] [ heartbeat-interval number; ] [ interface-interval number; ] [ statistics-interval number; ] [ topology { address_match_list }; ] [ sortlist { address_match_list }; ] [ rrset-order { order_spec ; [ order_spec ; ... ] }; ] [ preferred-glue ( A | AAAA ); ] };
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.
hostname
hostname.bind
in class chaos to the anycast
server and getting back a unique name.
Setting the hostname to a empty string ("") will disable processing of
the queries.
version
version.bind
in class chaos.
The default is the real version number of the server, but some server
operators prefer the string "surely you must be joking"
.
Changing the value of this string will not prevent people from identifying
what version you are running.
directory
named-xfer
dump-file
SIGINT
signal (ndc dumpdb
). If not
specified, the default is "named_dump.db".
memstatistics-file
deallocate-on-exit
is yes
. If not
specified, the default is "named.memstats".
pid-file
statistics-file
SIGILL
signal (ndc stats
). If not
specified, the default is "named.stats".
auth-nxdomain
yes
, the AA
bit is always set on
NXDOMAIN responses, even if the server is not actually authoritative.
The default is yes
. Do not turn off
auth-nxdomain
unless you are sure you know what you are
doing, as some older software won't like it.
deallocate-on-exit
yes
, the server will painstakingly deallocate every object it
it allocated, when it exits, and then write a memory usage report to
the memstatistics-file
. The default is no
, because
it is faster to let the operating system clean up.
deallocate-on-exit
is handy for detecting memory leaks.
dialup
yes
, 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
heartbeat-interval
and hopefully during the one call.
It also suppresses some of the normal zone maintainance traffic.
The default is no
. The dialup
option may also be specified in the zone
statement, in which
case it overrides the options dialup
statement.
If the zone is a master
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 slave
to verify the zone while the call us up.
If the zone is a slave
or stub
zone, the server
will suppress the regular "zone up to date" queries and only perform
them when the heartbeat-interval
expires.
fake-iquery
yes
, the server will simulate the obsolete DNS query type
IQUERY. The default is no
.
fetch-glue
yes
(the default), the server will fetch "glue" resource
records it doesn't have when constructing the additional data section of
a response. fetch-glue no
can be used in conjunction with
recursion no
to prevent the server's cache from growing or
becoming corrupted (at the cost of requiring more work from the client).
has-old-clients
yes
is equivalent to setting the following
options: auth-nxdomain yes;
and rfc2308-type1 no;
.
The use of has-old-clients
with auth-nxdomain
and rfc2308-type1
is order dependent.
host-statistics
yes
, statistics are kept for every host that the
the nameserver interacts with. The default is no
. Note:
turning on host-statistics
can consume huge amounts of memory.
host-statistics-max
maintain-ixfr-base
yes
, a transaction log is kept for
Incremental Zone Transfer. The default is no
.
multiple-cnames
yes
, multiple CNAME resource records will be
allowed for a domain name. The default is no
. 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.
notify
yes
(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 explicit
,
the NOTIFY messages will only be sent to the addresses in the
also-notify
list. The notify
option may also be specified in the zone
statement, in which
case it overrides the options notify
statement.
suppress-initial-notify
yes
, suppress the initial notify messages when the server
first loads. The default is no
.
recursion
yes
, 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 yes
.
See also fetch-glue
above.
rfc2308-type1
yes
, the server will send NS records along with the SOA
record for negative answers from the cache.
You need to set this to no
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 no
.
use-id-pool
yes
, 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 no
.
treat-cr-as-space
yes
, 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 no
.
also-notify
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 also-notify
list is given in a zone
statement, it will override the options also-notify
statement.
When a zone notify
statement is set to no
,
the IP addresses in the global also-notify
list will not get
sent NOTIFY messages for that zone.
The default is the empty list (no global notification list).
Forwarding
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.
forward
forwarders
list is
not empty. A value of first
, 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
only
is specified, the server will only query the
forwarders.
forwarders
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 forward only/first
behavior, or to not forward
at all. See the zone
statement
for more information.
Future versions of BIND 8 will provide a more powerful forwarding
system. The syntax described above will continue to be supported.
Name Checking
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.
Three checking methods are available:
ignore
warn
fail
The server can check names three areas: master zone files, slave
zone files, and in responses to queries the server has initiated. If
check-names response fail
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.
The defaults are:
check-names master fail; check-names slave warn; check-names response ignore;
check-names
may also be specified in the
zone
statement, in which case it overrides the options check-names
statement. When used in a zone
statement, the area is not
specified (because it can be deduced from the zone type).
Access Control
Access to the server can be restricted based on the IP address of the requesting system. See address_match_list for details on how to specify IP address lists.
allow-query
allow-query
may also be specified in the
zone
statement, in which case it overrides the
options allow-query
statement. If not specified, the default is
to allow queries from all hosts.
allow-transfer
allow-transfer
may also be specified in the
zone
statement, in which case it overrides the
options allow-transfer
statement. If not specified, the default
is to allow transfers from all hosts.
allow-recursion
blackhole
The interfaces and ports that the server will answer queries from may
be specified using the listen-on
option. listen-on
takes an optional port, and an
address_match_list. The server will
listen on all interfaces allowed by the address match list. If a port is
not specified, port 53 will be used.
Multiple listen-on
statements are allowed. For example,
listen-on { 5.6.7.8; }; listen-on port 1234 { !1.2.3.4; 1.2/16; };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.
If no listen-on
is specified, the server will listen on port
53 on all interfaces.
If the server doesn't know the answer to a question, it will query
other nameservers. query-source
specifies the address
and port used for such queries. If address
is
*
or is omitted, a wildcard IP address
(INADDR_ANY
) will be used. If port
is
*
or is omitted, a random unprivileged port will be used.
The default is
query-source address * port *;
Note: query-source port
applies only to UDP queries,
TCP queries always use a random unprivileged port.
Zone Transfers
max-transfer-time-in
named-xfer
processes) running
longer than this many minutes will be terminated. The default is 120
minutes (2 hours).
transfer-format
one-answer
uses one DNS message per resource record
transferred. many-answers
packs as many resource records
as possible into a message. many-answers
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 one-answer
.
transfer-format
may be
overridden on a per-server basis by using the server
statement.
transfers-in
transfers-in
may speed up the convergence of slave zones,
but it also may increase the load on the local system.
transfers-out
transfers-per-ns
named-xfer
processes) that can be concurrently transferring from a given remote
nameserver. The default value is 2. Increasing
transfers-per-ns
may speed up the convergence of slave
zones, but it also may increase the load on the remote nameserver.
transfers-per-ns
may be overridden on a per-server basis
by using the transfers
phrase of the server
statement.
transfer-source
transfer-source
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 allow-transfer
option for the zone being transferred, if one is specified. This statement
sets the transfer-source
for all zones, but can be overridden
on a per-zone basis by including a transfer-source
statement
within the zone block in the configuration file.
serial-queries
serial-queries
option sets the
maximum number of concurrent serial-number queries allowed to be outstanding
at any given time. The default is four (4).
Note:
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.
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 cannot set resource limits on this system
message will
be logged.
Scaled values are allowed when specifying resource limits. For
example, 1G
can be used instead of
1073741824
to specify a limit of one gigabyte.
unlimited
requests unlimited use, or the maximum
available amount. default
uses the limit that was in
force when the server was started. See
size_spec for more details.
coresize
default
.
datasize
default
.
files
unlimited
. Note: 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 unlimited
will cause the server to use
the larger of the rlim_max
for RLIMIT_NOFILE
and the value returned by sysconf(_SC_OPEN_MAX)
. If the
actual kernel limit is larger than this value, use limit
files
to specify the limit explicitly.
max-ixfr-log-size
stacksize
default
.
cleaning-interval
cleaning-interval
minutes. The default is 60 minutes. If set
to 0, no periodic cleaning will occur.
heartbeat-interval
dialup yes
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.
interface-interval
interface-interval
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 listen-on
configuration). Listeners on interfaces that have gone away will be
cleaned up.
statistics-interval
statistics-interval
minutes. The default is 60. If set to 0, no statistics will be logged.
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 topology
statement
takes an address_match_list
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,
topology { 10/8; !1.2.3/24; { 1.2/16; 3/8; }; };
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.
The default topology is
topology { localhost; localnets; };
When returning multiple RRs, the nameserver will normally return them in Round Robin, 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.
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.
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.
The sortlist statement takes an address match list and interprets it even more specially than the topology statement does.
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.
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.
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.
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 }; };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.
sortlist { { localhost; localnets; }; { localnets; }; };
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 random shuffle of the records as they are returned is wanted. The rrset-order 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).
An order_spec is defined as follows:
[ class class_name ][ type type_name ][ name "FQDN" ] order ordering
If no class is specified, the default is ANY
. If no
type is specified, the default is ANY
. If no
name is specified, the default is "*"
.
The legal values for ordering
are:
fixed
random
cyclic
For example:
rrset-order { class IN type A name "rc.vix.com" order random; order cyclic; };
will cause any responses for type A records in class IN that have "rc.vix.com" as a suffix, to always be returned in random order. All other records are returned in cyclic order.
If multiple rrset-order
statements appear, they are not
combined--the last one applies.
If no rrset-order
statement is specified, a default one
of:
rrset-order { class ANY type ANY name "*" order cyclic ; };
is used.
preferred-glue A;
which will add A records before other types
in the additional section.
lame-ttl
max-ncache-ttl
max-ncache-ttl
is used to set a maximum retention time
for these answers in the server is seconds. The default max-ncache-ttl
is
10800 seconds (3 hours). max-ncache-ttl
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.
min-roots
[ BIND Config. File | BIND Home | ISC ]