10.2.2. Configuring the named Service

⁠10.2.2. Configuring the named Service

When the named service is started, it reads the configuration from the files as described in Table 10.1, “The named Service Configuration Files”.

⁠

Table 10.1. The named Service Configuration Files

Path	Description
`/etc/named.conf`	The main configuration file.
`/etc/named/`	An auxiliary directory for configuration files that are included in the main configuration file.

The configuration file consists of a collection of statements with nested options surrounded by opening and closing curly brackets ({ and }). Note that when editing the file, you have to be careful not to make any syntax error, otherwise the named service will not start. A typical /etc/named.conf file is organized as follows:

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;
};

Running BIND in a chroot environment

If you have installed the bind-chroot package, the BIND service will run in the chroot environment. In that case, the initialization script will mount the above configuration files using the mount --bind command, so that you can manage the configuration outside this environment. There is no need to copy anything into the /var/named/chroot/ directory because it is mounted automatically. This simplifies maintenance since you do not need to take any special care of BIND configuration files if it is run in a chroot environment. You can organize everything as you would with BIND not running in a chroot environment.

The following directories are automatically mounted into /var/named/chroot/ if they are empty in the /var/named/chroot/ directory. They must be kept empty if you want them to be mounted into /var/named/chroot/:

/etc/named
/etc/pki/dnssec-keys
/run/named
/var/named
/usr/lib64/bind or /usr/lib/bind (architecture dependent).

The following files are also mounted if the target file does not exist in /var/named/chroot/:

/etc/named.conf
/etc/rndc.conf
/etc/rndc.key
/etc/named.rfc1912.zones
/etc/named.dnssec.keys
/etc/named.iscdlv.key
/etc/named.root.key

Important

Editing files which have been mounted in a chroot environment requires creating a backup copy and then editing the original file. Alternatively, use an editor with “edit-a-copy” mode disabled. For example, to edit the BIND's configuration file, /etc/named.conf, with Vim while it is running in a chroot environment, issue the following command as root:

~]# vim -c "set backupcopy=yes" /etc/named.conf

⁠10.2.2.1. Installing BIND in a chroot Environment

To install BIND to run in a chroot environment, issue the following command as root:

~]# yum install bind-chroot

To enable the named-chroot service, first check if the named service is running by issuing the following command:

~]$ systemctl status named

If it is running, it must be disabled.

To disable named, issue the following commands as root:

~]# systemctl stop named

~]# systemctl disable named

Then, to enable the named-chroot service, issue the following commands as root:

~]# systemctl enable named-chroot

~]# systemctl start named-chroot

To check the status of the named-chroot service, issue the following command as root:

~]# systemctl status named-chroot

⁠10.2.2.2. Common Statement Types

The following types of statements are commonly used in /etc/named.conf:

acl

The acl (Access Control List) statement allows you to define groups of hosts, so that they can be permitted or denied access to the nameserver. It takes the following form:

acl acl-name {
  match-element;
  ...
};

The acl-name statement name is the name of the access control list, and the match-element option is usually an individual IP address (such as 10.0.1.1) or a Classless Inter-Domain Routing (CIDR) network notation (for example, 10.0.1.0/24). For a list of already defined keywords, see Table 10.2, “Predefined Access Control Lists”.

⁠

Table 10.2. Predefined Access Control Lists

Keyword	Description
`any`	Matches every `IP` address.
`localhost`	Matches any `IP` address that is in use by the local system.
`localnets`	Matches any `IP` address on any network to which the local system is connected.
`none`	Does not match any `IP` address.

The acl statement can be especially useful in conjunction with other statements such as options. Example 10.2, “Using acl in Conjunction with Options” defines two access control lists, black-hats and red-hats, and adds black-hats on the blacklist while granting red-hats normal access.

⁠

Example 10.2. Using acl in Conjunction with Options

acl black-hats {
  10.0.2.0/24;
  192.168.0.0/24;
  1234:5678::9abc/24;
};
acl red-hats {
  10.0.1.0/24;
};
options {
  blackhole { black-hats; };
  allow-query { red-hats; };
  allow-query-cache { red-hats; };
};

include

The include statement allows you to include files in the /etc/named.conf, so that potentially sensitive data can be placed in a separate file with restricted permissions. It takes the following form:

include "file-name"

The file-name statement name is an absolute path to a file.

⁠

Example 10.3. Including a File to /etc/named.conf

include "/etc/named.rfc1912.zones";

options

The options statement allows you to define global server configuration options as well as to set 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. It takes the following form:

options {
  option;
  ...
};

For a list of frequently used option directives, see Table 10.3, “Commonly Used Configuration Options” below.

⁠

Table 10.3. Commonly Used Configuration Options

Option	Description
`allow-query`	Specifies which hosts are allowed to query the nameserver for authoritative resource records. It accepts an access control list, a collection of `IP` addresses, or networks in the CIDR notation. All hosts are allowed by default.
`allow-query-cache`	Specifies which hosts are allowed to query the nameserver for non-authoritative data such as recursive queries. Only `localhost` and `localnets` are allowed by default.
`blackhole`	Specifies which hosts are not allowed to query the nameserver. This option should be used when a particular host or network floods the server with requests. The default option is `none`.
`directory`	Specifies a working directory for the `named` service. The default option is `/var/named/`.
`disable-empty-zone`	Used to disable one or more empty zones from the list of default prefixes that would be used. Can be specified in the options statement and also in view statements. It can be used multiple times.
`dnssec-enable`	Specifies whether to return DNSSEC related resource records. The default option is `yes`.
`dnssec-validation`	Specifies whether to prove that resource records are authentic via DNSSEC. The default option is `yes`.
`empty-zones-enable`	Controls whether or not empty zones are created. Can be specified only in the options statement.
`forwarders`	Specifies a list of valid `IP` addresses for nameservers to which the requests should be forwarded for resolution.
`forward`	Specifies the behavior of the `forwarders` directive. It accepts the following options: `first` — The server will query the nameservers listed in the `forwarders` directive before attempting to resolve the name on its own. `only` — When unable to query the nameservers listed in the `forwarders` directive, the server will not attempt to resolve the name on its own.
`listen-on`	Specifies the `IPv4` network interface on which to listen for queries. On a `DNS` server that also acts as a gateway, you can use this option to answer queries originating from a single network only. All `IPv4` interfaces are used by default.
`listen-on-v6`	Specifies the `IPv6` network interface on which to listen for queries. On a `DNS` server that also acts as a gateway, you can use this option to answer queries originating from a single network only. All `IPv6` interfaces are used by default.
`max-cache-size`	Specifies the maximum amount of memory to be used for server caches. When the limit is reached, the server causes records to expire prematurely so that the limit is not exceeded. In a server with multiple views, the limit applies separately to the cache of each view. The default option is `32M`.
`notify`	Specifies whether to notify the secondary nameservers when a zone is updated. It accepts the following options: `yes` — The server will notify all secondary nameservers. `no` — The server will not notify any secondary nameserver. `master-only` — The server will notify primary server for the zone only. `explicit` — The server will notify only the secondary servers that are specified in the `also-notify` list within a zone statement.
`pid-file`	Specifies the location of the process ID file created by the `named` service.
`recursion`	Specifies whether to act as a recursive server. The default option is `yes`.
`statistics-file`	Specifies an alternate location for statistics files. The `/var/named/named.stats` file is used by default.

Note

The directory used by named for runtime data has been moved from the BIND default location, /var/run/named/, to a new location /run/named/. As a result, the PID file has been moved from the default location /var/run/named/named.pid to the new location /run/named/named.pid. In addition, the session-key file has been moved to /run/named/session.key. These locations need to be specified by statements in the options section. See Example 10.4, “Using the options Statement”.

Restrict recursive servers to selected clients only

To prevent distributed denial of service (DDoS) attacks, it is recommended that you use the allow-query-cache option to restrict recursive DNS services for a particular subset of clients only.

Refer to the BIND 9 Administrator Reference Manual referenced in Section 10.2.8.1, “Installed Documentation”, and the named.conf manual page for a complete list of available options.

⁠

Example 10.4. Using the options Statement

options {
  allow-query       { localhost; };
  listen-on port    53 { 127.0.0.1; };
  listen-on-v6 port 53 { ::1; };
  max-cache-size    256M;
  directory         "/var/named";
  statistics-file   "/var/named/data/named_stats.txt";

  recursion         yes;
  dnssec-enable     yes;
  dnssec-validation yes;

  pid-file          "/run/named/named.pid";
  session-keyfile   "/run/named/session.key";
};

zone

The zone statement allows you to define the characteristics of a zone, such as the location of its configuration file and zone-specific options, and can be used to override the global options statements. It takes the following form:

zone zone-name [zone-class] {
  option;
  ...
};

The zone-name attribute is the name of the zone, zone-class is the optional class of the zone, and option is a zone statement option as described in Table 10.4, “Commonly Used Options in Zone Statements”.

The zone-name attribute is particularly important, as 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 that it is placed at the end of host names within the example.com zone file.

For more information about zone files, refer to Section 10.2.3, “Editing Zone Files”.

⁠

Table 10.4. Commonly Used Options in Zone Statements

Option	Description
`allow-query`	Specifies which clients are allowed to request information about this zone. This option overrides global `allow-query` option. All query requests are allowed by default.
`allow-transfer`	Specifies which secondary servers are allowed to request a transfer of the zone's information. All transfer requests are allowed by default.
`allow-update`	Specifies which hosts are allowed to dynamically update information in their zone. The default option is to deny all dynamic update requests. Note that you should be careful when allowing hosts to update information about their zone. Do not set `IP` addresses in this option unless the server is in the trusted network. Instead, use TSIG key as described in Section 10.2.6.3, “Transaction SIGnatures (TSIG)”.
`file`	Specifies the name of the file in the `named` working directory that contains the zone's configuration data.
`masters`	Specifies from which `IP` addresses to request authoritative zone information. This option is used only if the zone is defined as `type` `slave`.
`notify`	Specifies whether to notify the secondary nameservers when a zone is updated. It accepts the following options: `yes` — The server will notify all secondary nameservers. `no` — The server will not notify any secondary nameserver. `master-only` — The server will notify primary server for the zone only. `explicit` — The server will notify only the secondary servers that are specified in the `also-notify` list within a zone statement.
`type`	Specifies the zone type. It accepts the following 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 (Top-Level Domain) 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. Master server is specified in `masters` directive.

Most changes to the /etc/named.conf file of a primary or secondary nameserver involve adding, modifying, or deleting zone statements, and only a small subset of zone statement options is usually needed for a nameserver to work efficiently.

In Example 10.5, “A Zone Statement for a Primary nameserver”, 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 allows only a secondary nameserver (192.168.0.2) to transfer the zone.

⁠

Example 10.5. A Zone Statement for a Primary nameserver

zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-transfer { 192.168.0.2; };
};

A secondary server's zone statement is slightly different. The type is set to slave, and the masters directive is telling named the IP address of the master server.

In Example 10.6, “A Zone Statement for a Secondary nameserver”, the named service is configured to query the primary server at the 192.168.0.1 IP address for information about the example.com zone. The received information is then saved to the /var/named/slaves/example.com.zone file. Note that you have to put all slave zones in the /var/named/slaves/ directory, otherwise the service will fail to transfer the zone.

⁠

Example 10.6. A Zone Statement for a Secondary nameserver

zone "example.com" {
  type slave;
  file "slaves/example.com.zone";
  masters { 192.168.0.1; };
};

⁠10.2.2.3. Other Statement Types

The following types of statements are less commonly used in /etc/named.conf:

controls

The controls statement allows you to configure various security requirements necessary to use the rndc command to administer the named service.

Refer to Section 10.2.4, “Using the rndc Utility” for more information on the rndc utility and its usage.

key

The key statement allows you to define 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 to be used (for example, hmac-md5).
secret "key-value" — The encrypted key.

Refer to Section 10.2.4, “Using the rndc Utility” for more information on the rndc utility and its usage.

logging

The logging statement allows you to use multiple types of logs, so called channels. By using the channel option within the statement, you can construct a customized type of log with its own file name (file), size limit (size), version number (version), and level of importance (severity). Once a customized channel is defined, a category option is used to categorize the channel and begin logging when the named service is restarted.

By default, named sends standard messages to the rsyslog daemon, which places them in /var/log/messages. Several standard channels are built into BIND with various severity levels, such as default_syslog (which handles informational logging messages) and default_debug (which specifically handles debugging messages). 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 10.2.8.1, “Installed Documentation”.

server

The server statement allows you to specify options that affect how the named service should respond to remote nameservers, especially with regard to notifications and zone transfers.

The transfer-format option controls the number of resource records that are sent with each message. It can be either one-answer (only one resource record), or many-answers (multiple resource records). Note that while the many-answers option is more efficient, it is not supported by older versions of BIND.

trusted-keys

The trusted-keys statement allows you to specify assorted public keys used for secure DNS (DNSSEC). Refer to Section 10.2.6.4, “DNS Security Extensions (DNSSEC)” for more information on this topic.

view

The view statement allows you to create 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 can be used as long as their names are unique. The match-clients option allows you to specify the IP addresses that apply to a particular view. If the options statement is used within a view, it overrides the already configured global options. Finally, most view statements contain multiple zone statements that apply to the match-clients list.

Note that the order in which the view statements are listed is important, as the first statement that matches a particular client's IP address is used. For more information on this topic, refer to Section 10.2.6.1, “Multiple Views”.

⁠10.2.2.4. Comment Tags

Additionally to statements, the /etc/named.conf file can also contain comments. Comments are ignored by the named service, but can prove useful when providing additional information to a user. The following are valid comment tags:

//

Any text after the // characters to the end of the line is considered a comment. For example:

notify yes;  // notify all secondary nameservers

#

Any text after the # character to the end of the line is considered a comment. For example:

notify yes;  # notify all secondary nameservers

/* and */

Any block of text enclosed in /* and */ is considered a comment. For example:

notify yes;  /* notify all secondary nameservers */