named.conf(4)
NAME
named.conf - configuration file for in.named
SYNOPSIS
/etc/named.conf
DESCRIPTION
BIND version 8 is a much more configurable version than pre-
vious releases of BIND. New areas of configuration include
access control lists and categorized logging. Many options
that previously applied to all zones can now be used selec-
tively. The new configuration file format in named.conf
incorporates these features and allows for consideration of
future configuration needs.
General Syntax
A BIND 8 configuration file consists of two general
features, statements and comments.
All statements end with a semicolon. Many statements allow
substatements, which also terminate with a semicolon. BIND 8
supports the following statements:
logging
Specifies what the server logs, and where the log mes-
sages are sent.
options
Controls global server configuration options and sets
defaults for other statements.
zone Defines a zone.
acl Defines a named IP address matching list, for access
control and other uses.
key Specifies key information for use in authentication
and authorization.
trusted-keys
Defines DNSSEC keys that are preconfigured into the
server and implicitly trusted.
server
Sets certain configuration options for individual
remote servers.
controls
Declares control channels to be used by the ndc(1M)
utility.
include
Includes another file.
The logging and options statements may only occur once per
configuration, while the rest may appear numerous times.
Further detail on each statement is provided in individual
sections below.
Comments may 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++, shell or perl con-
structs.
C-style comments start with the two characters /* (slash,
star) and end with */ (star, slash). Because comments are
completely delimited by these characters, they can be used
to comment either a portion of a line or to span multiple
lines.
C-style comments cannot be nested. For example, the follow-
ing is not valid because the entire comment ends with the
first */:
/* 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. */
C++ style comments start with the two characters // (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 // pair. For example:
// This is the start of a comment. The next line
// is a new comment, even though it is logically
// part of the previous comment.
Shell-style or perl-style comments start with the character
# (hash or pound or number or octothorpe or whatever) and
like C++ comments, continue to the end of the physical line.
For example:
# This is the start of a comment. The next line
# is a new comment, even though it is logically
# part of the previous comment.
You can covert BIND 4.9.x configuration files to the new
format by using named-bootconf(1M).
Documentation Definitions
The elements described below are used throughout the BIND
configuration file documentation. Elements which are only
associated with one statement are described only in the sec-
tion describing that statement.
acl_name
The name of an address_match_list as defined by the
acl statement.
address_match_list
A list of one or more ip_addr, ip_prefix, key_id, or
acl_name elements, as described in the ADDRESS MATCH
LISTS section.
dotted-decimal
One or more integers valued 0 through 255 separated
only by dots (``.''), such as 123, 45.67 or
89.123.45.67.
domain_name
A quoted string which will be used as a DNS name, for
example "my.test.domain".
path_name
A quoted string which will be used as a pathname, such
as "zones/master/my.test.domain".
ip_add
An IP address in with exactly four elements in
dotted-decimal notation.
ip_port
An IP port number. number 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.
ip_prefix
IP network specified in dotted-decimal form, followed
by ``/'' and then the number of bits in the netmask.
For example, 127/8 is the network 127.0.0.0 with net-
mask 255.0.0.0. 1.2.3.0/28 is network 1.2.3.0 with
netmask 255.255.255.240.
key_name
A string representing the name of a shared key, to be
used for transaction security.
number
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 be further limited by the
context in which it is used.
size_spec
number, the word unlimited, or the word default.
The maximum value of size_spec is that of unsigned
long integers on the machine. unlimited requests
unlimited use, or the maximum available amount.
default uses the limit that was in force when the
server was started.
A number can optionally be followed by a scaling fac-
tor: K or k for kilobytes, M or m for megabytes, and
G or g for gigabytes, which scale by 1024, 1024*1024,
and 1024*1024*1024 respectively.
Integer storage overflow is currently silently ignored
during conversion of scaled values, resulting in
values less than intended, possibly even negative.
Using unlimited is the best way to safely set a really
large number.
yes_or_no
Either yes or no. The words true and false are also
accepted, as are the numbers 1 and 0.
ADDRESS MATCH LISTS
Syntax
address_match_list = 1*address_match_element
address_match_element = [ "!" ] ( address_match_list /
ip_address / ip_prefix /
acl_name / "key " key_id ) ";"
Definition and Usage
Address match lists are primarily used to determine access
control for various server operations. They are also used
to define priorities for querying other name servers and to
set the addresses on which in.named(1M) in.named will listen
for queries. The elements which constitute an address match
list can be any of the following:
o an ip-address (in dotted-decimal notation)
o an ip-prefix (in the '/'-notation)
o A key_id, as defined by the key statement
o the name of an address match list previously defined
with the acl statement
o or, another address_match_list.
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 acl statement.
The addition of the key clause made the name of this syntac-
tic element something of a misnomer, since security keys can
be used to validate access without regard to a host or net-
work address. Nonetheless, the term ``address match
list'' is still used throughout the documentation.
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, for defining
listen-on ports, or as a topology, and whether the element
is negated.
When used as an access control list, a non-negated match
allows access, and a negated match denies access. If there
is no match at all in the list, access is denied. The
clauses allow-query, allow-transfer, allow-update, allow-
recursion and blackhole all use address match lists like
this. Similarly, the listen-on option will cause the server
to not accept queries on any of the machine's addresses that
do not match the list.
When used with the topology option, 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.
Because of the first-match aspect of the algorithm, an ele-
ment 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
1.2.3/24; !1.2.3.13
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
!1.2.3.13; 1.2.3/24
fixes that problem by having 1.2.3.13 blocked by the nega-
tion but all other 1.2.3.* hosts fall through.
THE LOGGING STATEMENT
Syntax
logging {
[ channel channel_name {
( file path_name
[ versions ( number | unlimited ) ]
[ size size_spec ]
| 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 [ level ] | dynamic ); ]
[ print-category yes_or_no; ]
[ print-severity yes_or_no; ]
[ print-time yes_or_no; ]
}; ]
[ category category_name {
channel_name; [ channel_name; ... ]
}; ]
...
};
Definition and Usage
The logging statement configures a wide variety of logging
options for the name server. Its channel phrase associates
output methods, format options and severity levels with a
name that can then be used with the category phrase to
select how various classes of messages are logged.
Only one logging statement is used to define as many chan-
nels 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 oth-
ers. If there is no logging statement, the logging confi-
guration will be:
logging {
category default { default_syslog; default_debug; };
category panic { default_syslog; default_stderr; };
category packet { default_debug; };
category eventlib { default_debug; };
};
The logging configuration is established as soon as the log-
ging statement is parsed. If you want to redirect messages
about processing of the entire configuration file, the log-
ging statement must appear first. Even if you do not
redirect configuration file parsing messages, we recommend
always putting the logging statement first so that this rule
need not be consciously recalled if you ever do want to
relocate the parser's messages.
The Channel Phrase
All log output goes to one or more ``channels." You can make
as many of them as you want.
Every channel definition must include a clause that says
whether messages selected for the channel go to a file, to a
particular syslog(3C) facility, or are discarded. It can
optionally also limit the message severity level that will
be accepted by the channel (the default is info), and
whether to include a time stamp generated by in.named(1M),
the category name, or severity level. The default is not to
include any of those three.
The word null as the destination option for the channel will
cause all messages sent to it to be discarded. Other options
for the channel are meaningless.
The file 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.
The size option for files is simply a hard ceiling on log
growth. If the file ever exceeds the size, then in.named
will not write anything more to it until the file is reo-
pened. That the size is exceeded does not automatically
trigger a reopen. The default behavior does not limit the
size of the file.
If you use the version logfile option, then in.named will
retain the backup versions of the file by renaming them when
it opens them. 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 lamers.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 unlimited keyword
is synonymous with 99 in current BIND releases. Example
usage of size and versions options:
channel an_example_level {
file "lamers.log" versions 3 size 20m;
print-time yes;
print-category yes;
};
The argument for the syslog() clause is a syslog() facility
as described in the syslog(3C) manual page. How syslogd(1M)
will handle messages sent to this facility is described in
the syslog.conf(4).
The severity clause works like the priority levels for sys-
log(), except that they can also be used if you are writing
straight to a file rather than using syslog(). 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.
If you are using syslog(), then the syslog.conf priorities
will also determine what eventually passes through. For
example, defining a channel facility and severity as daemon
and debug but only logging daemon warnings by means of
syslog.conf will cause messages of severity info and notice
to be dropped. If the situation were reversed, with
in.named writing messages of only warning or higher, then
syslogd will print all messages it receives from the chan-
nel.
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 the debugging mode will be
active. The global debug level is set either by starting the
in.named 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 (as with ndc notrace). All
debugging messages in the server have a debug level, and
higher debug levels give more more detailed output. Chan-
nels that specify a specific debug severity, for example:
channel specific_debug_level {
file "foo";
severity debug 3;
};
will get debugging output of level 3 or less any time the
server is in debugging mode, regardless of the global debug-
ging level. Channels with dynamic severity use the server's
global level to determine what messages to print.
If print-time has been turned on, then the date and time
will be logged. print-time may be specified for a syslog()
channel, but is usually unnecessary since syslog() also
prints the date and time. If print-category is requested,
then the category of the message will be logged as well.
Finally, if print-severity is on, then the severity level of
the message will be logged. The print- options may be used
in any combination, and will always be printed in the fol-
lowing order: time, category, severity. Here is an example
where all three print- options are on:
28-Apr-1997 15:05:32.863 default: notice: Ready to answer queries.
There are four predefined channels that are used for default
logging in.named(1M). How they are used is described in the
next section, The Category Phrase.
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
};
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 chan-
nels you have defined.
The Category Phrase
There are many categories, so you can send the logs you want
to see wherever you want, without seeing logs you do not
want. If you do not specify a list of channels for a
category, then log messages in that category will be sent to
the default category instead. If you do not specify a
default category, the following ``default default'' is used:
category default { default_syslog; default_debug; };
To log security events to a file but also keep the default
logging behavior, specify the following:
channel my_security_channel {
file "my_security_file";
severity info;
};
category security { my_security_channel;
default_syslog; default_debug; };
To discard all messages in a category, specify the null
channel:
category lame-servers { null; };
category cname { null; };
The following categories are available:
default
The catch-all. Many things still are not classified
into categories, and they all end up here. Also, if
you don not 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
category default { default_syslog; default_debug; };
config
High-level configuration file processing.
parser
Low-level configuration file processing.
queries
A short log message is generated for every query the
server receives.
lame-servers
Messages like ``Lame server on ...''
statistics
Statistics.
panic If the server has to shut itself down due to an inter-
nal 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:
category panic { default_syslog; default_stderr; };
update
Dynamic updates.
ncache
Negative caching.
xfer-in
Zone transfers the server is receiving.
xfer-out
Zone transfers the server is sending
db All database operations.
eventlib
Debugging information 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:
category eventlib { default_debug; };
packet
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:
category packet { default_debug; };
notify
The Notify protocol.
cname Messages like ``... points to a CNAME''.
security
Approved or unapproved requests.
os Operating system problems.
insist
Internal consistency check failures.
maintenance
Periodic maintenance events.
load Load.
response-checks
Messages arising from response checking, such as
``Malformed response ...'', ``wrong ans. name ...'',
``unrelated additional info ...'', ``invalid RR type
...'', and ``bad referral ...''.
THE OPTIONS STATEMENT
Syntax
options {
[ 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; ]
[ recursion yes_or_no; ]
[ rfc2308-type1 yes_or_no; ]
[ use-id-pool yes_or_no; ]
[ treat-cr-as-space yes_or_no; ]
[ also-notify yes_or_no; ]
[ forward ( only | first ); ]
[ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ]
[ check-names ( master | slave | response ) ( warn | fail | ignore); ]
[ allow-query { address_match_list }; ]
[ allow-recursion { address_match_list }; ]
[ allow-transfer { 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; ]
[ 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 ; ... ] };
};
Definition and Usage
The options statement sets up global options to be used by
BIND. This statement may appear only once in a configura-
tion file. If more than one occurrence is found, the first
occurrence determines the 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.
Pathnames
version
The version the server should report by means of the
ndc(1M) command or by means of a query of name
version.bind in class chaos. The default is the real
version number of the server.
directory
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, for example, 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.
named-xfer
The pathname to the named-xfer program that the server
uses for inbound zone transfers. If not specified,
the default is /usr/sbin/named-xfer.
dump-file
The pathname of the file to which the server dumps the
database when it receives a SIGINT signal, for exam-
ple, as sent by ndc dump. If not specified, the
default is named_dump.db.
memstatistics-file
The pathname of the file the server writes memory
usage statistics to on exit, if deallocate-on-exit is
yes. If not specified, the default is named.memstats.
pid-file
The pathname of the file in which the server writes
its process ID. If not specified, the default is
/var/run/named.pid.
statistics-file
The pathname of the file the server appends statistics
to when it receives a SIGILL signal. If not specified,
the default is named.stats.
Boolean Operations
auth-nxdomain
If the value is yes, then the AA bit is always set on
NXDOMAIN responses, even if the server is not actu-
ally 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 will not like
it.
deallocate-on-exit
If the value is yes, then when the server exits it
will painstakingly deallocate every object it allo-
cated, 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
If the value is yes, then the server treats all zones
as if they are doing zone transfers across a dial on a
demand dialup link, which can be brought up by traffic
originating from this server. This has different
effects according to the zone type. It concentrates
the zone maintenance so that it all happens in a short
interval, once every heartbeat-interval and hope-
fully, during the one call. It also suppresses some
of the normal zone maintenance 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 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
the slave supports NOTIFY, and allowing the slave to
verify the zone while they call us up. If the zone is
a slave or stub, then the server will suppress the
regular zone up to date queries, and only perform them
when the heartbeat-interval expires.
fake-iquery
If yes, the server will simulate the obsolete DNS
query type IQUERY. The default is no.
fetch-glue
If yes (the default), the server will fetch ``glue''
resource records it does not have when it constructs
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. However, it requires more work from the
client.
has-old-clients
Setting the option to yes is equivalent to setting the
following three options: auth-nxdomain yes, maintain-
ixfr-base yes, and rfc2308-type1 no. has-old-clients
with auth-nxdomain, maintain-ixfr-base, and rfc2308-
type1 is order dependant.
host-statistics
If yes, then statistics are kept for every host with
which the name server interacts. The default is no.
Turning on host-statistics can consume huge amounts
of memory.
host-statistics-max
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 host-statistics-max is set
to zero, then there is no limit set. The default value
is zero.
maintain-ixfr-base
If yes, a IXFR database file is kept for all dynami-
cally updated zones. This enables the server to
answer IXFR queries, which speeds up zone transfers
enormously. The default value is no.
multiple-cnames
If yes, then multiple CNAME resource records will be
allowed for a domain name. The default is no. Allow-
ing 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
If yes (the default), DNS NOTIFY messages are sent
when a zone for which the server is authoritative
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. If
they do, they will initiate it immediately. The
notify option may also be specified in the zone state-
ment, in which case it overrides the options notify
statement.
recursion
If yes, 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 does not
know the answer. The default is yes. See also fetch-
glue above.
rfc2308-type1
If yes, the server will send NS records along with the
SOA record for negative answers. If you have an old
BIND server using you as a forwarder, which does not
understand negative answers that contain both SOA and
NS records, or you have an old version of
sendmail(1M), set this to no. The correct fix is to
upgrade the broken server or sendmail. The default is
no.
use-id-pool
If yes, the server will keep track of its own out-
standing query ID's to avoid duplication and increase
randomness. As a result, the server will consume
128KB more memory. The default is no.
treat-cr-as-space
If yes, the server will treat <CR> characters the same
way it treats a <space> or <tab>. This may be neces-
sary when loading zone files on a UNIX system that
were generated on either an NT or a DOS machine. The
default is no.
Also-Notify
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. This reduces traffic over
links to external name servers. 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
This option is only meaningful if the forwarders list
is not empty. A value of first, the default, causes
the server to query the forwarders first. If the for-
warders do not answer the question, the server will
then look for the answer itself. If only is speci-
fied, the server will only query the forwarders.
forwarders
Specifies the IP addresses to be used for forwarding.
The default is the empty list (no forwarding).
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, have different forward only or forward
first behavior, or not forward at all. See THE ZONE STATE-
MENT section for more information.
Future versions of BIND 8 may provide a more powerful for-
warding 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 host-
name can be checked for compliance with the RFCs that define
valid hostnames.
Three checking methods are available:
ignore
No checking is done.
warn Names are checked against their expected client con-
texts. Invalid names are logged, but processing con-
tinues normally.
fail Names are checked against their expected client con-
texts. Invalid names are logged, and the offending
data is rejected.
The server can check names three areas: master zone files,
slave zone files, and responses to queries the server has
initiated. If check-names response fail has been specified,
and to answer 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:
o check-names master fail
o check-names slave warn
o 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, as
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 or by means of shared
secret keys. See ADDRESS MATCH LISTS for details on how to
specify access criteria.
allow-query
Specifies which hosts are allowed to ask ordinary
questions. 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:
allow-recursion
Specifies which hosts are allowed to ask recur-
sive questions. allow-recursion may also be
specified in the zone statement, in which case
it overrides the options allow-recursion state-
ment.
If not specified, the default is to allow
recursive queries from all hosts.
allow-transfer
Specifies which hosts are allowed to receive
zone transfers from the server. 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.
blackhole
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
receive a response.
Interfaces
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 name server 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.
Query Address
If the server does not know the answer to a question, it
will query other name servers. 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 *;
query-source currently applies only to UDP queries; TCP
queries always use a wildcard IP address and a random
unprivileged port.
Zone Transfers
max-transfer-time-in
Inbound zone transfers ( named-xfer processes) running
longer than max-transfer-time-in minutes will be ter-
minated. The default value for max-transfer-time-in
is 120 minutes (2 hours).
transfer-format
The server supports two zone transfer methods. 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
The maximum number of inbound zone transfers that can
be running concurrently. The default value is 10.
Increasing transfers-in may speed up the convergence
of slave zones, but it also may increase the load on
the local system.
transfers-out
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.
transfers-per-ns
The maximum number of inbound zone transfers ( named-
xfer processes) that can be concurrently transferred
from a given remote name server. The default value is
2. Increasing transfers-per-ns may speed up the con-
vergence of slave zones, but it also may increase the
load on the remote name server. 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 usu-
ally 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 zones being
transferred, if one is specified. This statement sets
the transfer-source for all zones, but can be overri-
den on a per-zone basis by including a transfer-source
statement within the zone block in the configuration
file.
Resource Limits
The server's usage of many system resources can be limited.
Some operating systems do not support some of the limits.
On such systems, a warning will be issued if the unsup-
ported limit is used. Some operating systems do not support
resource limits, and on these systems a
set resource limits on this system
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. Other values include: unlimited
requests, unlimited use, or the maximum available amount.
The value default uses the limit that was in force when the
server was started. See the definition of size_spec for
more details.
coresize
The maximum size of a core dump. The default value is
default.
datasize
The maximum amount of data memory the server may use.
The default value is default.
files The maximum number of files the server may have open
concurrently. The default value is unlimited. Note
that 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 from
getrlimit(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
The max-ixfr-log-size will be used in a future release
of the server to limit the size of the transaction log
kept for Incremental Zone Transfer.
stacksize
The maximum amount of stack memory the server may use.
The default value is default.
Periodic Task Intervals
cleaning-interval
The server will remove expired resource records from
the cache every cleaning-interval minutes. The
default is 60 minutes. If set to 0, no periodic
cleaning will occur.
heartbeat-interval
The server will perform zone maintenance tasks for all
zones marked 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
The server will scan the network interface list every
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 inter-
faces, provided they are allowed by the listen-on
configuration.. Listeners on interfaces that have
gone away will be cleaned up.
statistics-interval
Name server statistics will be logged every
statistics-interval minutes. The default is 60. If
set to 0, no statistics will be logged.
Topology
All other things being equal, when the server chooses a name
server to query from a list of name servers, 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 dis-
tance. 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 max-
imum 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, followed by hosts on net-
work 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 the least preferred.
The default topology is:
topology { localhost; localnets; };
Resource Record Sorting
When returning multiple resource records ("RRs"), the name
server will normally return them in round robin, that is,
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 rearrange the RRs as
appropriate, for example, using any addresses on the local
network before other addresses. However, not all resolvers
can do this, or are not correctly configured to do so.
When a client is using a local server, the sorting can be
performed by the server, based on the client's address. This
only requires configuring the name servers, not all the
clients.
The sortlist statement takes an address match list and
interprets it even more specially than the topology state-
ment does.
Each top level statement in the sortlist must itself be an
explicit address match list with one or two elements. The
first element of each top level list, which may be an IP
address, an IP prefix, an acl name or nested address match
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 that
prefer addresses on any of the locally connected networks.
Next most preferred are addresses on the 192.168.1/24 net-
work, 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 behavior 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; };
};
RRset Ordering
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. Perhaps you want a random shuffle
of the records as they are returned. The rrset-order state-
ment permits you to configure the order 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 Records are returned in the order they are defined in
the zone file.
random
Records are returned in some random order.
cyclic
Records are returned in a round-robin order.
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 com-
bined. The last one applies.
If no rrset-order statement is specified, the following
default statement is used:
rrset-order { class ANY type ANY name "*" order cyclic ; };
Tuning
lame-ttl
Sets the number of seconds to cache a lame server
indication. 0 disables caching. The default is 600
(10 minutes). The maximum value is 1800 (30 minutes).
max-ncache-ttl
To reduce network traffic and increase performance,
the server store negative answers. max-ncache-ttl is
used to set a maximum retention time for these answers
in the server in seconds. The default max-ncache-ttl
is 10800 seconds (3 hours). max-ncache-ttl cannot
exceed the maximum retention time for ordinary (posi-
tive) answers (7 days) and will be silently truncated
to 7 days if set to a value which is greater than 7
days.
min-roots
The minimum number of root servers that is required
for a request for the root servers to be accepted.
The default is 2.
THE ZONE STATEMENT
Syntax
zone domain_name [ ( in | hs | hesiod | chaos ) ] {
type master;
file path_name;
[ check-names ( warn | fail | ignore ); ]
[ allow-update { address_match_list }; ]
[ allow-query { address_match_list }; ]
[ allow-transfer { address_match_list };
[ forward ( only | first ); ]
[ forwarders { [ip_addr; [ip_addr; ... ] ] }; ]
[ dialup yes_or_no; ]
[ notify yes_or_no; ]
[ also-notify { ip_addr; [ ip_addr; ... ] };
[ pubkey number number number string; ]
};
zone domain_name [ ( in | hs | hesiod | chaos ) ] {
type ( slave | stub );
[ file path_name; ]
masters [ port ip_port ] { ip_addr; [ ip_addr; ... ] };
[ check-names ( warn | fail | ignore ); ]
[ allow-update { address_match_list }; ]
[ allow-query { address_match_list }; ]
[ allow-transfer { address_match_list }; ]
[ forward ( only | first ); ]
[ forwarders { [ip_addr; [ip_addr; ... ] ] }; ]
[ transfer-source ip_addr; ]
[ max-transfer-time-in number; ]
[ notify yes_or_no; ]
[ also-notify { ip_addr; [ ip_addr; ... ] };
[ pubkey number number number string; ]
};
zone domain_name [ ( in | hs | hesiod | chaos ) ] {
type forward;
[ forward ( only | first ); ]
[ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]
[ check-names ( warn | fail | ignore ); ]
};
zone "." [ ( in | hs | hesiod | chaos ) ] {
type hint;
file path_name;
[ check-names ( warn | fail | ignore ); ]
};
Definition and Usage
The zone statement is used to define how information about
particular DNS zones is managed by the server. There are
five different zone types.
master
The server has a master copy of the data for the zone
and will be able to provide authoritative answers for
it.
slave A slave zone is a replica of a master zone. The mas-
ters list specifies one or more IP addresses that the
slave contacts to update its copy of the zone. If a
port is specified, it then checks to see if the zone
is current and makes zone transfers to the port given.
If a file is specified, then the replica will be
written to the named file. Use of the file clause is
highly recommended, since it often speeds server
startup and eliminates a needless waste of bandwidth.
stub A stub zone is like a slave zone, except that it
replicates only the NS records of a master zone
instead of the entire zone.
forward
A forward zone is used to direct all queries in it to
other servers, as described in THE OPTIONS STATEMENT
section. The specification of options in such a zone
will override any global options declared in the
options statement.
If no forwarders clause is present in the zone or an
empty list for forwarders is given, then no forwarding
will be done for the zone, cancelling the effects of
any forwarders in the options statement. Thus if you
want to use this type of zone to change only the
behavior of the global forward option, and not the
servers used, then you also need to respecify the glo-
bal forwarders.
hint The initial set of root name servers is specified
using a hint zone. When the server starts up, it uses
the root hints to find a root name server and get the
most recent list of root name servers.
Previous releases of BIND used the term primary for a master
zone, secondary for a slave zone, and cache for a hint
zone.
Classes
The zone's name may optionally be followed by a class. If a
class is not specified, class in (for "internet"), is
assumed. This is correct for the vast majority of cases.
The hesiod class is for an information service from MIT's
Project Athena. It is used to share information about vari-
ous systems databases, such as users, groups, and printers.
More information can be found at ftp://athena-
dist.mit.edu/pub/ATHENA/usenix/athena_changes.PS. The key-
word hs is a synonym for hesiod.
Another MIT development was CHAOSnet, a LAN protocol created
in the mid-1970s. It is still sometimes seen on LISP sta-
tions and other hardware in the AI community, and zone data
for it can be specified with the chaos class.
Options
check-names
See the subsection on Name Checking in THE OPTIONS
STATEMENT.
allow-query
See the description of allow-query in the Access Con-
trol subsection of THE OPTIONS STATEMENT.
allow-update
Specifies which hosts are allowed to submit dynamic
DNS updates to the server. The default is to deny
updates from all hosts.
allow-transfer
See the description of allow-transfer in the Access
Control subsection of THE OPTIONS STATEMENT.
transfer-source
transfer-source 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 allow-transfer option for
this zone if one is specified.
max-transfer-time-in
See the description of max-transfer-time-in in the
Zone Transfers subsection of THE OPTIONS STATEMENT.
dialup
See the description of dialup in the Boolean Options
subsection of THE OPTIONS STATEMENT.
notify
See the description of notify in the Boolean Options
subsection of the THE OPTIONS STATEMENT.
also-notify
also-notify is only meaningful if notify 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 name servers for the zone (other than the pri-
mary master), plus any IP addresses specified with
also-notify. also-notify is not meaningful for stub
zones. The default is the empty list.
forward
forward is only meaningful if the zone has a forward-
ers list. The only value causes the lookup to fail
after trying the forwarders and getting no answer,
while first would allow a normal lookup to be tried.
forwarders
The forwarders option in a zone is used to override
the list of global forwarders. If it is not specified
in a zone of type forward, no forwarding is done for
the zone, and the global options are not used.
pubkey
The DNSSEC flags, protocol, and algorithm are speci-
fied, as well as a base-64 encoded string representing
the key.
THE ACL STATEMENT
Syntax
acl name {
address_match_list
};
Definition and Usage
The acl statement creates a named address match list. It
gets its name from a primary use of address match lists:
Access Control Lists (acls).
An address match list's name must be defined with acl before
it can be used elsewhere. No forward references are allowed.
The following acls are built-in:
any Allows all hosts.
none Denies all hosts.
localhosts
Allows the IP addresses of all interfaces on the sys-
tem.
localnets
Allows any host on a network for which the system has
an interface.
THE KEY STATEMENT
Syntax
key key_id {
algorithm algorithm_id;
secret secret_string;
};
Definition and Usage
The key statement defines a key ID which can be used in a
server statement to associate with a particular name server
a method of authentication that is more rigorous than simple
IP address matching. A key ID must be created with the key
statement before it can be used in a server definition or an
address match list.
The algorithm_id is a string that specifies a
security/authentication algorithm. secret_string is the
secret to be used by the algorithm, and is treated as a
base-64 encoded string. If you have a secret_string in your
named.conf file, make sure that it is not be readable by
anyone beside superuser.
THE TRUSTED-KEYS STATEMENT
Syntax
trusted-keys {
[ domain_name flags protocol algorithm key; ]
};
Definition and Usage
The trusted-keys 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 authenti-
cation.
The contributed section of the ISC BIND distribution
includes a dns_signer utility to sign zone data according
to the DNSSEC specifications. The utility is provided as-
is, without any expressed or implied warranties. The contri-
buted source could be retrieved from the
/isc/bind/src/cur/bind-8 directory at ISC's FTP site,
ftp.isc.org.
Each trusted key is associated with a domain name. Its
attributes are the non-negative integral flags, protocol,
and algorithm, as well as a base-64 encoded string
representing the key.
Any number of trusted keys can be specified.
THE SERVER STATEMENT
Syntax
server ip_addr {
[ bogus yes_or_no; ]
[ transfers number; ]
[ transfer-format ( one-answer | many-answers ); ]
[ keys { key_id [ key_id ... ] }; ]
};
Definition and Usage
The server statement defines the characteristics to be asso-
ciated with a remote name server.
If you discover that a server is giving out bad data, mark-
ing it as bogus will prevent further queries to it. The
default value of bogus is no.
If you mark a server as bogus, all other addresses for that
server will be marked as bogus when a match is made when
looking up a server's address by name.
The server supports two zone transfer methods. The first,
one-answer, uses one DNS message per resource record
transferred. The second method, many-answers packs as many
resource records as possible into a message. many-answers is
more efficient, but is only 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 transfer-format option.
If transfer-format is not specified, the transfer-format
specified by the options statement will be used.
The transfers 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.
The key clause is used to identify a key_id defined by the
key statement, to be used for transaction security when
talking to the remote server. The key statement must come
before the server statement that references it.
The key statement is intended for future use by the server.
It is checked for syntax but is otherwise ignored.
THE CONTROLS STATEMENT
Syntax
controls {
[ inet ip_addr
port ip_port
allow { address_match_list; }; ]
[ unix path_name
perm number
owner number
group number; ]
};
Definition and Usage
The controls 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
ndc(1M) utility to send commands to and retrieve non-DNS
results from a name server.
A UNIX control channel is a FIFO in the file system, and
access to it is controlled by normal file system permis-
sions. It is created by in.named(1M) with the specified
file mode bits, user and group owner. See chmod(1). Note
that, unlike chmod, the mode bits specified for perm will
normally have a leading 0 so the number is interpreted as
octal. Also note that the user and group ownership speci-
fied as owner and group 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 sys-
tem may be able to manage the local name server.
An inet control channel is a TCP/IP socket accessible to the
Internet, created at the specified ip_port on the specified
ip_addr. Modern telnet 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 ip_addr used, and this only if you trust all non-
privileged users on the local host to manage your name
server.
THE INCLUDE STATEMENT
Syntax
include path_name;
Definition and Usage
The include statement inserts the specified file at the
point that the include statement is encountered. It cannot
be used within another statement, though, so a line such as
acl internal_hosts { include internal_hosts.acl; };
is not allowed.
Use include to break the configuration up into easily-
managed chunks. For example:
include "/etc/security/keys.bind";
include "/etc/acls.bind";
could be used at the top of a BIND configuration file in
order to include any acl or key information.
Be careful not to use ``#include," like you would in a C
program, because ``#'' is used to start a comment.
EXAMPLES
Example 1: Simple Configuration File
The simplest configuration file that is still realistically
useful is one which simply defines a hint zone that has a
full path to the root servers file, for example:
zone "." in {
type hint;
file "/var/named/root.cache";
};
Example 2: Another Example of a Configuration File
Here is a more typical real-world example.
/*
* A simple BIND 8 configuration
*/
logging {
category lame-servers { null; };
category cname { null; };
};
options {
directory "/var/named";
};
controls {
inet * port 52 allow { any; }; // 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 "0.0.127.in-addr.arpa" in {
type master;
file "master/127.0.0";
};
zone "." in {
type hint;
file "root.cache";
};
FILES
/etc/named.conf
The BIND 8 in.named configuration file.
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Interface Stability | Standard BIND 8.2.4 |
|_____________________________|_____________________________|
SEE ALSO
chmod(1), in.named(1M), named-bootconf(1M), ndc(1M),
syslogd(1M), syslog(3C), syslog.conf(4), attributes(5)
Eastlake, D., 3rd, Kaufman, C. RFC 2065, Domain Name System
Security Extensions. Network Working Group. January 1997.
Man(1) output converted with
man2html