15.2. BIND

This section covers BIND (Berkeley Internet Name Domain), the DNS server included in Red Hat Enterprise Linux. It focuses on the structure of its configuration files, and describes how to administer it both locally and remotely.

15.2.1. Empty Zones

BIND configures a number of “empty zones” to prevent recursive servers from sending unnecessary queries to Internet servers that cannot handle them (thus creating delays and SERVFAIL responses to clients who query for them). These empty zones ensure that immediate and authoritative NXDOMAIN responses are returned instead. The configuration option empty-zones-enable controls whether or not empty zones are created, whilst the option disable-empty-zone can be used in addition to disable one or more empty zones from the list of default prefixes that would be used.

The number of empty zones created for RFC 1918 prefixes has been increased, and users of BIND 9.9 and above will see the RFC 1918 empty zones both when empty-zones-enable is unspecified (defaults to yes), and when it is explicitly set to yes.

15.2.2. Configuring the named Service

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

Table 15.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;
};

Note

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 the /var/named/chroot/ directory if the corresponding mount point directories underneath /var/named/chroot/ are empty:

/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

15.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

15.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 15.2, “Predefined Access Control Lists”.

Table 15.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 15.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 15.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 15.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 15.3, “Commonly Used Configuration Options” below.

Table 15.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 through 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 15.4, “Using the options Statement”.

Important

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.

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

Example 15.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 15.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, see Section 15.2.3, “Editing Zone Files”.

Table 15.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 15.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 secondary server for this zone. Primary server is specified in the `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 15.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 15.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 primary server.

In Example 15.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 secondary zones in the /var/named/slaves/ directory, otherwise the service will fail to transfer the zone.

Example 15.6. A Zone Statement for a Secondary nameserver

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

15.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.

See Section 15.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.

See Section 15.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, see the BIND 9 Administrator Reference Manual referenced in Section 15.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). See Section 15.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, see Section 15.2.6.1, “Multiple Views”.

15.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 */

15.2.3. Editing Zone Files

As outlined in Section 15.1.1, “Name server Zones”, zone files contain information about a namespace. They are stored in the named working directory located in /var/named/ by default. Each zone file is named according to the file option in the zone statement, usually in a way that relates to the domain in and identifies the file as containing zone data, such as example.com.zone.

Table 15.5. The named Service Zone Files
Path	Description
`/var/named/`	The working directory for the `named` service. The nameserver is not allowed to write to this directory.
`/var/named/slaves/`	The directory for secondary zones. This directory is writable by the `named` service.
`/var/named/dynamic/`	The directory for other files, such as dynamic `DNS` (DDNS) zones or managed DNSSEC keys. This directory is writable by the `named` service.
`/var/named/data/`	The directory for various statistics and debugging files. This directory is writable by the `named` service.

A zone file consists of directives and resource records. Directives tell the nameserver to perform tasks or apply special settings to the zone, resource records define the parameters of the zone and assign identities to individual hosts. While the directives are optional, the resource records are required in order to provide name service to a zone.

All directives and resource records should be entered on individual lines.

15.2.3.1. Common Directives

Directives begin with the dollar sign character ($) followed by the name of the directive, and usually appear at the top of the file. The following directives are commonly used in zone files:

$INCLUDE

The $INCLUDE directive allows you to include another file at the place where it appears, so that other zone settings can be stored in a separate zone file.

Example 15.7. Using the $INCLUDE Directive

$INCLUDE /var/named/penguin.example.com

$ORIGIN

The $ORIGIN directive allows you to append the domain name to unqualified records, such as those with the host name only. Note that the use of this directive is not necessary if the zone is specified in /etc/named.conf, since the zone name is used by default.

In Example 15.8, “Using the $ORIGIN Directive”, any names used in resource records that do not end in a trailing period (the . character) are appended with example.com.

Example 15.8. Using the $ORIGIN Directive

$ORIGIN example.com.

$TTL

The $TTL directive allows you to set the default Time to Live (TTL) value for the zone, that is, how long is a zone record valid. Each resource record can contain its own TTL value, which overrides this directive.

Increasing this value allows remote nameservers to cache the zone information for a longer period of time, reducing the number of queries for the zone and lengthening the amount of time required to propagate resource record changes.

Example 15.9. Using the $TTL Directive

$TTL 1D

15.2.3.2. Common Resource Records

The following resource records are commonly used in zone files:

A

The Address record specifies an IP address to be assigned to a name. It takes the following form:

hostname IN A IP-address

If the hostname value is omitted, the record will point to the last specified hostname.

In Example 15.10, “Using the A Resource Record”, the requests for server1.example.com are pointed to 10.0.1.3 or 10.0.1.5.

Example 15.10. Using the A Resource Record

server1  IN  A  10.0.1.3
         IN  A  10.0.1.5

CNAME

The Canonical Name record maps one name to another. Because of this, this type of record is sometimes referred to as an alias record. It takes the following form:

alias-name IN CNAME real-name

CNAME records are most commonly used to point to services that use a common naming scheme, such as www for Web servers. However, there are multiple restrictions for their usage:

CNAME records should not point to other CNAME records. This is mainly to avoid possible infinite loops.
CNAME records should not contain other resource record types (such as A, NS, MX, and so on). The only exception are DNSSEC related records (RRSIG, NSEC, and so on) when the zone is signed.
Other resource records that point to the fully qualified domain name (FQDN) of a host (NS, MX, PTR) should not point to a CNAME record.

In Example 15.11, “Using the CNAME Resource Record”, the A record binds a host name to an IP address, while the CNAME record points the commonly used www host name to it.

Example 15.11. Using the CNAME Resource Record

server1  IN  A      10.0.1.5
www      IN  CNAME  server1

MX

The Mail Exchange record specifies where the mail sent to a particular namespace controlled by this zone should go. It takes the following form:

IN MX preference-value email-server-name

The email-server-name is a fully qualified domain name (FQDN). The preference-value allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The MX resource record with the lowest preference-value is preferred over the others. However, multiple email servers can possess the same value to distribute email traffic evenly among them.

In Example 15.12, “Using the MX Resource Record”, the first mail.example.com email server is preferred to the mail2.example.com email server when receiving email destined for the example.com domain.

Example 15.12. Using the MX Resource Record

example.com.  IN  MX  10  mail.example.com.
              IN  MX  20  mail2.example.com.

NS

The Nameserver record announces authoritative nameservers for a particular zone. It takes the following form:

IN NS nameserver-name

The nameserver-name should be a fully qualified domain name (FQDN). Note that when two nameservers are listed as authoritative for the domain, it is not important whether these nameservers are secondary nameservers, or if one of them is a primary server. They are both still considered authoritative.

Example 15.13. Using the NS Resource Record

IN  NS  dns1.example.com.
IN  NS  dns2.example.com.

PTR

The Pointer record points to another part of the namespace. It takes the following form:

last-IP-digit IN PTR FQDN-of-system

The last-IP-digit directive is the last number in an IP address, and the FQDN-of-system is a fully qualified domain name (FQDN).

PTR records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. See Section 15.2.3.4.2, “A Reverse Name Resolution Zone File” for examples of PTR records in use.

SOA

The Start of Authority record announces important authoritative information about a namespace to the nameserver. Located after the directives, it is the first resource record in a zone file. It takes the following form:

@  IN  SOA  primary-name-server hostmaster-email (
       serial-number
       time-to-refresh
       time-to-retry
       time-to-expire
       minimum-TTL )

The directives are as follows:

The @ symbol places the $ORIGIN directive (or the zone's name if the $ORIGIN directive is not set) as the namespace being defined by this SOA resource record.
The primary-name-server directive is the host name of the primary nameserver that is authoritative for this domain.
The hostmaster-email directive is the email of the person to contact about the namespace.
The serial-number directive is a numerical value incremented every time the zone file is altered to indicate it is time for the named service to reload the zone.
The time-to-refresh directive is the numerical value secondary nameservers use to determine how long to wait before asking the primary nameserver if any changes have been made to the zone.
The time-to-retry directive is a numerical value used by secondary nameservers to determine the length of time to wait before issuing a refresh request in the event that the primary nameserver is not answering. If the primary server has not replied to a refresh request before the amount of time specified in the time-to-expire directive elapses, the secondary servers stop responding as an authority for requests concerning that namespace.
In BIND 4 and 8, the minimum-TTL directive is the amount of time other nameservers cache the zone's information. In BIND 9, it defines how long negative answers are cached for. Caching of negative answers can be set to a maximum of 3 hours (3H).

When configuring BIND, all times are specified in seconds. However, it is possible to use abbreviations when specifying units of time other than seconds, such as minutes (M), hours (H), days (D), and weeks (W). Table 15.6, “Seconds compared to other time units” shows an amount of time in seconds and the equivalent time in another format.

Table 15.6. Seconds compared to other time units
Seconds	Other Time Units
60	`1M`
1800	`30M`
3600	`1H`
10800	`3H`
21600	`6H`
43200	`12H`
86400	`1D`
259200	`3D`
604800	`1W`
31536000	`365D`

Example 15.14. Using the SOA Resource Record

@  IN  SOA  dns1.example.com.  hostmaster.example.com. (
       2001062501  ; serial
       21600       ; refresh after 6 hours
       3600        ; retry after 1 hour
       604800      ; expire after 1 week
       86400 )     ; minimum TTL of 1 day

15.2.3.3. Comment Tags

Additionally to resource records and directives, a zone file can also contain comments. Comments are ignored by the named service, but can prove useful when providing additional information to the user. Any text after the semicolon character to the end of the line is considered a comment. For example:

   604800  ; expire after 1 week

15.2.3.4. Example Usage

The following examples show the basic usage of zone files.

15.2.3.4.1. A Simple Zone File

Example 15.15, “A simple zone file” demonstrates the use of standard directives and SOA values.

Example 15.15. A simple zone file

$ORIGIN example.com.
$TTL 86400
@         IN  SOA  dns1.example.com.  hostmaster.example.com. (
              2001062501  ; serial
              21600       ; refresh after 6 hours
              3600        ; retry after 1 hour
              604800      ; expire after 1 week
              86400 )     ; minimum TTL of 1 day
;
;
          IN  NS     dns1.example.com.
          IN  NS     dns2.example.com.
dns1      IN  A      10.0.1.1
          IN  AAAA   aaaa:bbbb::1
dns2      IN  A      10.0.1.2
          IN  AAAA   aaaa:bbbb::2
;
;
@         IN  MX     10  mail.example.com.
          IN  MX     20  mail2.example.com.
mail      IN  A      10.0.1.5
          IN  AAAA   aaaa:bbbb::5
mail2     IN  A      10.0.1.6
          IN  AAAA   aaaa:bbbb::6
;
;
; This sample zone file illustrates sharing the same IP addresses
; for multiple services:
;
services  IN  A      10.0.1.10
          IN  AAAA   aaaa:bbbb::10
          IN  A      10.0.1.11
          IN  AAAA   aaaa:bbbb::11

ftp       IN  CNAME  services.example.com.
www       IN  CNAME  services.example.com.
;
;

In this example, the authoritative nameservers are set as dns1.example.com and dns2.example.com, and are tied to the 10.0.1.1 and 10.0.1.2 IP addresses respectively using the A record.

The email servers configured with the MX records point to mail and mail2 through A records. Since these names do not end in a trailing period, the $ORIGIN domain is placed after them, expanding them to mail.example.com and mail2.example.com.

Services available at the standard names, such as www.example.com (WWW), are pointed at the appropriate servers using the CNAME record.

This zone file would be called into service with a zone statement in the /etc/named.conf similar to the following:

zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-update { none; };
};

15.2.3.4.2. A Reverse Name Resolution Zone File

A reverse name resolution zone file is used to translate an IP address in a particular namespace into a fully qualified domain name (FQDN). It looks very similar to a standard zone file, except that the PTR resource records are used to link the IP addresses to a fully qualified domain name as shown in Example 15.16, “A reverse name resolution zone file”.

Example 15.16. A reverse name resolution zone file

$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@  IN  SOA  dns1.example.com.  hostmaster.example.com. (
       2001062501  ; serial
       21600       ; refresh after 6 hours
       3600        ; retry after 1 hour
       604800      ; expire after 1 week
       86400 )     ; minimum TTL of 1 day
;
@  IN  NS   dns1.example.com.
;
1  IN  PTR  dns1.example.com.
2  IN  PTR  dns2.example.com.
;
5  IN  PTR  server1.example.com.
6  IN  PTR  server2.example.com.
;
3  IN  PTR  ftp.example.com.
4  IN  PTR  ftp.example.com.

In this example, IP addresses 10.0.1.1 through 10.0.1.6 are pointed to the corresponding fully qualified domain name.

This zone file would be called into service with a zone statement in the /etc/named.conf file similar to the following:

zone "1.0.10.in-addr.arpa" IN {
  type master;
  file "example.com.rr.zone";
  allow-update { none; };
};

There is very little difference between this example and a standard zone statement, except for the zone name. Note that a reverse name resolution zone requires the first three blocks of the IP address reversed followed by .in-addr.arpa. This allows the single block of IP numbers used in the reverse name resolution zone file to be associated with the zone.

15.2.4. Using the rndc Utility

The rndc utility is a command-line tool that allows you to administer the named service, both locally and from a remote machine. Its usage is as follows:

rndc [option...] command [command-option]

15.2.4.1. Configuring the Utility

To prevent unauthorized access to the service, named must be configured to listen on the selected port (953 by default), and an identical key must be used by both the service and the rndc utility.

Table 15.7. Relevant files
Path	Description
`/etc/named.conf`	The default configuration file for the `named` service.
`/etc/rndc.conf`	The default configuration file for the `rndc` utility.
`/etc/rndc.key`	The default key location.

The rndc configuration is located in /etc/rndc.conf. If the file does not exist, the utility will use the key located in /etc/rndc.key, which was generated automatically during the installation process using the rndc-confgen -a command.

The named service is configured using the controls statement in the /etc/named.conf configuration file as described in Section 15.2.2.3, “Other Statement Types”. Unless this statement is present, only the connections from the loopback address (127.0.0.1) will be allowed, and the key located in /etc/rndc.key will be used.

For more information on this topic, see manual pages and the BIND 9 Administrator Reference Manual listed in Section 15.2.8, “Additional Resources”.

Important

To prevent unprivileged users from sending control commands to the service, make sure only root is allowed to read the /etc/rndc.key file:

~]# chmod o-rwx /etc/rndc.key

15.2.4.2. Checking the Service Status

To check the current status of the named service, use the following command:

~]# rndc status
version: 9.7.0-P2-RedHat-9.7.0-5.P2.el6
CPUs found: 1
worker threads: 1
number of zones: 16
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

15.2.4.3. Reloading the Configuration and Zones

To reload both the configuration file and zones, type the following at a shell prompt:

~]# rndc reload
server reload successful

This will reload the zones while keeping all previously cached responses, so that you can make changes to the zone files without losing all stored name resolutions.

To reload a single zone, specify its name after the reload command, for example:

~]# rndc reload localhost
zone reload up-to-date

Finally, to reload the configuration file and newly added zones only, type:

~]# rndc reconfig

Note

If you intend to manually modify a zone that uses Dynamic DNS (DDNS), make sure you run the freeze command first:

~]# rndc freeze localhost

Once you are finished, run the thaw command to allow the DDNS again and reload the zone:

~]# rndc thaw localhost
The zone reload and thaw was successful.

15.2.4.4. Updating Zone Keys

To update the DNSSEC keys and sign the zone, use the sign command. For example:

~]# rndc sign localhost

Note that to sign a zone with the above command, the auto-dnssec option has to be set to maintain in the zone statement. For example:

zone "localhost" IN {
  type master;
  file "named.localhost";
  allow-update { none; };
  auto-dnssec maintain;
};

15.2.4.5. Enabling the DNSSEC Validation

To enable the DNSSEC validation, issue the following command as root:

~]# rndc validation on

Similarly, to disable this option, type:

~]# rndc validation off

See the options statement described in Section 15.2.2.2, “Common Statement Types” for information on how to configure this option in /etc/named.conf.

The Red Hat Enterprise Linux 7 Security Guide has a comprehensive section on DNSSEC.

15.2.4.6. Enabling the Query Logging

To enable (or disable in case it is currently enabled) the query logging, issue the following command as root:

~]# rndc querylog

To check the current setting, use the status command as described in Section 15.2.4.2, “Checking the Service Status”.

15.2.5. Using the dig Utility

The dig utility is a command-line tool that allows you to perform DNS lookups and debug a nameserver configuration. Its typical usage is as follows:

dig [@server] [option...] name type

See Section 15.2.3.2, “Common Resource Records” for a list of common values to use for type.

15.2.5.1. Looking Up a Nameserver

To look up a nameserver for a particular domain, use the command in the following form:

dig name NS

In Example 15.17, “A sample nameserver lookup”, the dig utility is used to display nameservers for example.com.

Example 15.17. A sample nameserver lookup

~]$ dig example.com NS

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57883
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            99374   IN      NS      a.iana-servers.net.
example.com.            99374   IN      NS      b.iana-servers.net.

;; Query time: 1 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:04:06 2010
;; MSG SIZE  rcvd: 77

15.2.5.2. Looking Up an IP Address

To look up an IP address assigned to a particular domain, use the command in the following form:

dig name A

In Example 15.18, “A sample IP address lookup”, the dig utility is used to display the IP address of example.com.

Example 15.18. A sample IP address lookup

~]$ dig example.com A

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4849
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            155606  IN      A       192.0.32.10

;; AUTHORITY SECTION:
example.com.            99175   IN      NS      a.iana-servers.net.
example.com.            99175   IN      NS      b.iana-servers.net.

;; Query time: 1 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:07:25 2010
;; MSG SIZE  rcvd: 93

15.2.5.3. Looking Up a Host Name

To look up a host name for a particular IP address, use the command in the following form:

dig -x address

In Example 15.19, “A Sample Host Name Lookup”, the dig utility is used to display the host name assigned to 192.0.32.10.

Example 15.19. A Sample Host Name Lookup

~]$ dig -x 192.0.32.10

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> -x 192.0.32.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29683
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6

;; QUESTION SECTION:
;10.32.0.192.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
10.32.0.192.in-addr.arpa. 21600 IN      PTR     www.example.com.

;; AUTHORITY SECTION:
32.0.192.in-addr.arpa.  21600   IN      NS      b.iana-servers.org.
32.0.192.in-addr.arpa.  21600   IN      NS      c.iana-servers.net.
32.0.192.in-addr.arpa.  21600   IN      NS      d.iana-servers.net.
32.0.192.in-addr.arpa.  21600   IN      NS      ns.icann.org.
32.0.192.in-addr.arpa.  21600   IN      NS      a.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     13688   IN      A       192.0.34.43
b.iana-servers.org.     5844    IN      A       193.0.0.236
b.iana-servers.org.     5844    IN      AAAA    2001:610:240:2::c100:ec
c.iana-servers.net.     12173   IN      A       139.91.1.10
c.iana-servers.net.     12173   IN      AAAA    2001:648:2c30::1:10
ns.icann.org.           12884   IN      A       192.0.34.126

;; Query time: 156 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:25:15 2010
;; MSG SIZE  rcvd: 310

15.2.6. Advanced Features of BIND

Most BIND implementations only use the named service to provide name resolution services or to act as an authority for a particular domain. However, BIND version 9 has a number of advanced features that allow for a more secure and efficient DNS service.

Important

Before attempting to use advanced features like DNSSEC, TSIG, or IXFR (Incremental Zone Transfer), make sure that the particular feature is supported by all nameservers in the network environment, especially when you use older versions of BIND or non-BIND servers.

All of the features mentioned are discussed in greater detail in the BIND 9 Administrator Reference Manual referenced in Section 15.2.8.1, “Installed Documentation”.

15.2.6.1. Multiple Views

Optionally, different information can be presented to a client depending on the network a request originates from. This is primarily used to deny sensitive DNS entries from clients outside of the local network, while allowing queries from clients inside the local network.

To configure multiple views, add the view statement to the /etc/named.conf configuration file. Use the match-clients option to match IP addresses or entire networks and give them special options and zone data.

15.2.6.2. Incremental Zone Transfers (IXFR)

Incremental Zone Transfers (IXFR) allow a secondary nameserver to only download the updated portions of a zone modified on a primary nameserver. Compared to the standard transfer process, this makes the notification and update process much more efficient.

Note that IXFR is only available when using dynamic updating to make changes to primary zone records. If manually editing zone files to make changes, Automatic Zone Transfer (AXFR) is used.

15.2.6.3. Transaction SIGnatures (TSIG)

Transaction SIGnatures (TSIG) ensure that a shared secret key exists on both primary and secondary nameservers before allowing a transfer. This strengthens the standard IP address-based method of transfer authorization, since attackers would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key.

Since version 9, BIND also supports TKEY, which is another shared secret key method of authorizing zone transfers.

Important

When communicating over an insecure network, do not rely on IP address-based authentication only.

15.2.6.4. DNS Security Extensions (DNSSEC)

Domain Name System Security Extensions (DNSSEC) provide origin authentication of DNS data, authenticated denial of existence, and data integrity. When a particular domain is marked as secure, the SERVFAIL response is returned for each resource record that fails the validation.

Note that to debug a DNSSEC-signed domain or a DNSSEC-aware resolver, you can use the dig utility as described in Section 15.2.5, “Using the dig Utility”. Useful options are +dnssec (requests DNSSEC-related resource records by setting the DNSSEC OK bit), +cd (tells recursive nameserver not to validate the response), and +bufsize=512 (changes the packet size to 512B to get through some firewalls).

15.2.6.5. Internet Protocol version 6 (IPv6)

Internet Protocol version 6 (IPv6) is supported through the use of AAAA resource records, and the listen-on-v6 directive as described in Table 15.3, “Commonly Used Configuration Options”.

15.2.7. Common Mistakes to Avoid

The following is a list of recommendations on how to avoid common mistakes users make when configuring a nameserver:

Use semicolons and curly brackets correctly: An omitted semicolon or unmatched curly bracket in the /etc/named.conf file can prevent the named service from starting.
Use period (the . character) correctly: In zone files, a period at the end of a domain name denotes a fully qualified domain name. If omitted, the named service will append the name of the zone or the value of $ORIGIN to complete it.
Increment the serial number when editing a zone file: If the serial number is not incremented, the primary nameserver will have the correct, new information, but the secondary nameservers will never be notified of the change, and will not attempt to refresh their data of that zone.
Configure the firewall: If a firewall is blocking connections from the named service to other nameservers, the recommended practice is to change the firewall settings.
Warning
Using a fixed UDP source port for DNS queries is a potential security vulnerability that could allow an attacker to conduct cache-poisoning attacks more easily. To prevent this, by default DNS sends from a random ephemeral port. Configure your firewall to allow outgoing queries from a random UDP source port. The range 1024 to 65535 is used by default.

15.2.8. Additional Resources

The following sources of information provide additional resources regarding BIND.

15.2.8.1. Installed Documentation

BIND features a full range of installed documentation covering many different topics, each placed in its own subject directory. For each item below, replace version with the version of the bind package installed on the system:

/usr/share/doc/bind-version/: The main directory containing the most recent documentation. The directory contains the BIND 9 Administrator Reference Manual in HTML and PDF formats, which details BIND resource requirements, how to configure different types of nameservers, how to perform load balancing, and other advanced topics.
/usr/share/doc/bind-version/sample/etc/: The directory containing examples of named configuration files.

rndc(8): The manual page for the rndc name server control utility, containing documentation on its usage.
named(8): The manual page for the Internet domain name server named, containing documentation on assorted arguments that can be used to control the BIND nameserver daemon.
lwresd(8): The manual page for the lightweight resolver daemon lwresd, containing documentation on the daemon and its usage.
named.conf(5): The manual page with a comprehensive list of options available within the named configuration file.
rndc.conf(5): The manual page with a comprehensive list of options available within the rndc configuration file.

15.2.8.2. Online Resources

https://access.redhat.com/site/articles/770133: A Red Hat Knowledgebase article about running BIND in a chroot environment, including the differences compared to Red Hat Enterprise Linux 6.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/: The Red Hat Enterprise Linux 7 Security Guide has a comprehensive section on DNSSEC.
https://www.icann.org/namecollision: The ICANN FAQ on domain name collision.

15.2. BIND

15.2.1. Empty Zones

15.2.2. Configuring the named Service

15.2.2.1. Installing BIND in a chroot Environment

15.2.2.2. Common Statement Types

15.2.2.3. Other Statement Types

15.2.2.4. Comment Tags

15.2.3. Editing Zone Files

15.2.3.1. Common Directives

15.2.3.2. Common Resource Records

15.2.3.3. Comment Tags

15.2.3.4. Example Usage

15.2.3.4.1. A Simple Zone File

15.2.3.4.2. A Reverse Name Resolution Zone File

15.2.4. Using the rndc Utility

15.2.4.1. Configuring the Utility

15.2.4.2. Checking the Service Status

15.2.4.3. Reloading the Configuration and Zones

15.2.4.4. Updating Zone Keys

15.2.4.5. Enabling the DNSSEC Validation

15.2.4.6. Enabling the Query Logging

15.2.5. Using the dig Utility

15.2.5.1. Looking Up a Nameserver

15.2.5.2. Looking Up an IP Address

15.2.5.3. Looking Up a Host Name

15.2.6. Advanced Features of BIND

15.2.6.1. Multiple Views

15.2.6.2. Incremental Zone Transfers (IXFR)

15.2.6.3. Transaction SIGnatures (TSIG)

15.2.6.4. DNS Security Extensions (DNSSEC)

15.2.6.5. Internet Protocol version 6 (IPv6)

15.2.7. Common Mistakes to Avoid

15.2.8. Additional Resources

15.2.8.1. Installed Documentation

15.2.8.2. Online Resources

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links