The named.conf file is a collection of statements
using nested options surrounded by opening and closing ellipse
characters, { }. Administrators must be careful
when editing named.conf to avoid syntactical
errors as many seemingly minor errors prevent the
named service from starting.
Warning
Do not manually edit the
/etc/named.conf file or any files in the
/var/named/ directory if you are using the
Domain Name Service Configuration Tool. Any manual changes to those
files are overwritten the next time the
Domain Name Service Configuration Tool is used.
A typical named.conf file is organized similar
to the following example:
In this statement, replace
<acl-name> with the name of the
access control list and replace
<match-element> with a semi-colon
separated list of IP addresses. Most of the time, an individual IP
address or IP network notation (such as
10.0.1.0/24) is used to identify the IP addresses
within the acl statement.
The following access control lists are already defined as keywords
to simplify configuration:
any — Matches every IP address.
localhost — Matches any IP address in
use by the local system.
localnets — Matches any IP address
on any network to which the local system is connected.
none — Matches no IP addresses.
When used in conjunction with other statements (such as the
options statement), acl
statements can be very useful in preventing the misuse of a BIND
nameserver.
The following example defines two access control lists and uses an
options statement to define how they are treated
by the nameserver:
This example contains two access control lists,
black-hats and red-hats. Hosts
in the black-hats list are denied access to the
nameserver, while hosts in the red-hats list are
given normal access.
The include statement allows files to be included
in a named.conf file. In this way, sensitive
configuration data (such as keys) can be placed
in a separate file with restrictive permissions.
An include statement takes the following form:
include "<file-name>"
In this statement, <file-name> is
replaced with an absolute path to a file.
The options statement defines global server
configuration options and sets defaults for other statements. It can
be used to specify the location of the named
working directory, the types of queries allowed, and much more.
The options statement takes the following form:
options {
<option>;
[<option>; ...]
};
In this statement, the <option>
directives are replaced with a valid option.
The following are commonly used options:
allow-query — Specifies which hosts
are allowed to query this nameserver. By default, all hosts
are allowed to query. An access control list, or collection of
IP addresses or networks may be used here to only allow
particular hosts to query the nameserver.
allow-recursion — Similar to
allow-query, this option applies to recursive
queries. By default, all hosts are allowed to perform recursive
queries on the nameserver.
blackhole — Specifies which
hosts are not allowed to query the server.
directory — Specifies the
named working directory if different from the
default value, /var/named/.
forward — Specifies the forwarding
behavior of a forwarders directive.
The following options are accepted:
first — Specifies that the
nameservers listed in the forwarders
directive be queried before named
attempts to resolve the name itself.
only — Specifies that
named does not attempt name resolution
itself in the event queries to nameservers specified in the
forwarders directive fail.
forwarders — Specifies a list of
valid IP addresses for nameservers where requests should be forwarded for
resolution.
listen-on — Specifies the network
interface on which named listens for
queries. By default, all interfaces are used.
Using this directive on a DNS server which also acts a gateway, BIND
can be configured to only answer queries that originate from one
of the networks.
A listen-on directive looks like the
following example:
options {
listen-on { 10.0.1.1; };
};
In this example, only requests that arrive from the network
interface serving the private network
(10.0.1.1) are accepted.
notify — Controls whether
named notifies the slave servers when a
zone is updated. It accepts the following options:
yes — Notifies slave servers.
no — Does not notify slave
servers.
explicit — Only notifies slave
servers specified in an also-notify list
within a zone statement.
pid-file — Specifies the location
of the process ID file created by named.
root-delegation-only — Turns on the
enforcement of delegation properties in top-level domains (TLDs)
and root zones with an optional exclude
list. Delegation is the process of
separating a single zone into multiple subzones. In order to create
a delegated zone, items known as NS records
are used. NameServer records (delegation records) announce
the authoritative nameservers for a particular zone.
The following root-delegation-only
example specifies an exclude list of TLDs from whom undelegated
responses are expected and trusted:
statistics-file — Specifies an
alternate location for statistics files. By default,
named statistics are saved to the
/var/named/named.stats file.
Dozens of other options are also available, many of which rely upon
one another to work properly. Refer to the BIND 9
Administrator Reference Manual referenced in Section 12.7.1 Installed Documentation and the
bind.conf man page for more details.
A zone statement defines the characteristics of a
zone such as the location of its configuration file and
zone-specific options. This statement can be used to override the global
options statements.
A zone statement takes the following form:
zone <zone-name><zone-class> {
<zone-options>;
[<zone-options>; ...]
};
In this statement, <zone-name> is
the name of the zone, <zone-class>
is the optional class of the zone, and
<zone-options> is a list of options
characterizing the zone.
The <zone-name> attribute for the
zone statement is particularly important. It is the default value
assigned for the $ORIGIN directive used within
the corresponding zone file located in the
/var/named/ directory. The
named daemon appends the name of the zone to any
non-fully qualified domain name listed in the zone file.
For example, if a zone statement defines the
namespace for example.com, use
example.com as the
<zone-name> so it is placed at the
end of hostnames within the example.com zone
file.
The most common zone statement options include
the following:
allow-query — Specifies the clients
that are allowed to request information about this zone. The
default is to allow all query requests.
allow-transfer — Specifies the slave
servers that are allowed to request a transfer of the zone's
information. The default is to allow all transfer requests.
allow-update — Specifies the hosts that
are allowed to dynamically update information in their
zone. The default is to deny all dynamic update requests.
Be careful when allowing hosts to update information
about their zone. Do not enable this option unless the host
specified is completely trusted. In general, it better to
have an administrator manually update the records for a zone
and reload the named service.
file — Specifies the name of the
file in the named working directory that
contains the zone's configuration data.
masters — Specifies the IP
addresses from which to request authoritative zone information
and is used only if the zone is defined as
typeslave.
notify — Specifies whether or not
named notifies the slave servers when a zone
is updated. This directive accepts the following options:
yes — Notifies slave servers.
no — Does not notify slave
servers.
explicit — Only notifies slave
servers specified in an also-notify list
within a zone statement.
type — Defines the type of zone.
Below is a list of valid options:
delegation-only — Enforces the
delegation status of infrastructure zones such as COM, NET,
or ORG. Any answer that is received without an explicit or
implicit delegation is treated as
NXDOMAIN. This option is only applicable
in TLDs or root zone files used in recursive or caching
implementations.
forward — Forwards all requests
for information about this zone to other nameservers.
hint — A special type of zone
used to point to the root nameservers which resolve queries
when a zone is not otherwise known. No configuration beyond
the default is necessary with a hint
zone.
master — Designates the
nameserver as authoritative for this zone. A zone should be
set as the master if the zone's
configuration files reside on the system.
slave — Designates the
nameserver as a slave server for this zone. Also
specifies the IP address of the master nameserver for the
zone.
zone-statistics — Configures
named to keep statistics concerning this
zone, writing them to either the default location
(/var/named/named.stats) or the file
listed in the statistics-file option in the
server statement. Refer to Section 12.2.2 Other Statement Types for more information
about the server statement.
Most changes to the /etc/named.conf file of a
master or slave nameserver involves adding, modifying, or deleting
zone statements. While these
zone statements can contain many options, most
nameservers require only a small subset to function efficiently.
The following zone statements are very basic
examples illustrating a master-slave nameserver relationship.
The following is an example of a zone
statement for the primary nameserver hosting
example.com (192.168.0.1):
zone "example.com" IN {
type master;
file "example.com.zone";
allow-update { none; };
};
In the statement, the zone is identified as
example.com, the type is set to
master, and the
named service is instructed to read the
/var/named/example.com.zone file. It also tells
named not to allow any other hosts to update.
A slave server's zone statement for
example.com is slightly different from the
previous example. For a slave server, the type is set to
slave and in place of the
allow-update line is a directive telling
named the IP address of the master server.
The following is an example slave server zone
statement for example.com zone:
zone "example.com" {
type slave;
file "example.com.zone";
masters { 192.168.0.1; };
};
This zone statement configures
named on the slave server to query the master
server at the 192.168.0.1 IP address for
information about the example.com zone. The
information the slave server receives from the master server is
saved to the /var/named/example.com.zone file.
key "<key-name>"
— Defines a particular key by name. Keys are used to
authenticate various actions, such as secure updates or the use of
the rndc command. Two options are used with
key:
algorithm
<algorithm-name>
— The type of algorithm used, such as
dsa or
hmac-md5.
logging — Allows for the use of multiple
types of logs, called channels. By using
the channel option within the
logging statement, a customized type of log, with
its own file name (file), size limit
(size), versioning (version),
and level of importance (severity), can be
constructed. Once a customized channel has been defined, a
category option is used to categorize the
channel and begin logging when named is
restarted.
By default, named logs standard messages to
the syslog daemon, which places them in
/var/log/messages. This occurs because
several standard channels are built into BIND with various
severity levels, such as one that handles informational logging
messages (default_syslog) and another that
specifically handles debugging messages
(default_debug). A default category, called
default, uses the built-in channels to do normal
logging without any special configuration.
Customizing the logging process can be a very detailed process
and is beyond the scope of this chapter. For information on
creating custom BIND logs, refer to the BIND 9 Administrator
Reference Manual referenced in Section 12.7.1 Installed Documentation.
server — Specifies options that
affect how named should respond to remote
nameservers, especially in regards to notifications and zone
transfers.
The transfer-format option controls whether one
resource record is sent with each message
(one-answer) or multiple resource records are
sent with each message (many-answers). While
many-answers is more efficient, only newer BIND
nameservers understand it.
trusted-keys — Contains assorted
public keys used for secure DNS (DNSSEC). Refer to Section 12.5.3 Security for more information
concerning BIND security.
view
"<view-name>" —
Creates special views depending upon which network the host
querying the nameserver is on. This allows some hosts to receive
one answer regarding a zone while other hosts receive totally
different information. Alternatively, certain zones may only be
made available to particular trusted hosts while non-trusted hosts
can only make queries for other zones.
Multiple views may be used, but their names must be
unique. The match-clients option specifies the
IP addresses that apply to a particular view. Any
options statements may also be used within a
view, overriding the global options already configured for
named. Most view statements
contain multiple zone statements that apply to
the match-clients list. The order in which
view statements are listed is important, as the
first view statement that matches a particular
client's IP address is used.
