|
|
 |
|
| |
NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
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:
<statement-1> ["<statement-1-name>"] [<statement-1-class>] {
<option-1>;
<option-2>;
<option-N>;
};
<statement-2> ["<statement-2-name>"] [<statement-2-class>] {
<option-1>;
<option-2>;
<option-N>;
};
<statement-N> ["<statement-N-name>"] [<statement-N-class>] {
<option-1>;
<option-2>;
<option-N>;
};
|
The following types of statements are commonly used in
/etc/named.conf:
The acl statement (or access control
statement) defines groups of hosts which can then be permitted or
denied access to the nameserver.
An acl statement takes the following
form:
acl <acl-name> {
<match-element>;
[<match-element>; ...]
};
|
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:
acl black-hats {
10.0.2.0/24;
192.168.0.0/24;
};
acl red-hats {
10.0.1.0/24;
};
options {
blackhole { black-hats; };
allow-query { red-hats; };
allow-recursion { red-hats; };
}
|
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:
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:
options {
root-delegation-only exclude { "ad"; "ar"; "biz"; "cr"; "cu"; "de"; "dm"; "id;
"lu"; "lv"; "md"; "ms"; "museum"; "name"; "no"; "pa";
"pf"; "se"; "sr"; "to"; "tw"; "us"; "uy"; };
};
|
-
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.
For more information about zone files, see Section 12.3 Zone Files.
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 type slave.
-
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.
The following is a list of lesser used statement types available
within named.conf:
-
controls — Configures various
security requirements necessary to use the rndc command to administer the named service.
Refer to Section
12.4.1 Configuring /etc/named.conf to learn more about how the
controls statement is structured and
available options.
-
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.
-
secret "<key-value>" — The encrypted
key.
Refer to Section
12.4.2 Configuring /etc/rndc.conf for instructions on how to
write a key statement.
-
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.
Refer to Section 12.5.2
Multiple Views for more information about the view statement.
The following is a list of valid comment tags used within
named.conf:
-
// — When placed at the beginning
of a line, that line is ignored by named.
-
# — When placed at the beginning
of a line, that line is ignored by named.
-
/* and */
— When text is enclose in these tags, the block of text is
ignored by named.
|
|
|
