19.4. Using rndc

BIND includes a utility called rndc which allows command line administration of the named daemon from the localhost or a remote host.
In order to prevent unauthorized access to the named daemon, BIND uses a shared secret key authentication method to grant privileges to hosts. This means an identical key must be present in both /etc/named.conf and the rndc configuration file, /etc/rndc.conf.

Note

If you have installed the bind-chroot package, the BIND service will run in the /var/named/chroot environment. All configuration files will be moved there. As such, the rndc.conf file is located in /var/named/chroot/etc/rndc.conf.
Note that since the rndc utility does not run in a chroot environment, /etc/rndc.conf is a symlink to /var/named/chroot/etc/rndc.conf.

19.4.1. Configuring /etc/named.conf

In order for rndc to connect to a named service, there must be a controls statement in the BIND server's /etc/named.conf file.
The controls statement, shown in the following example, allows rndc to connect from the localhost. 
controls {
	inet 127.0.0.1
		allow { localhost; } keys { <key-name>; };
};
This statement tells named to listen on the default TCP port 953 of the loopback address and allow rndc commands coming from the localhost, if the proper key is given. The <key-name> specifies a name in the key statement within the /etc/named.conf file. The next example illustrates a sample key statement. 
key "<key-name>" {
	algorithm hmac-md5;
	secret "<key-value>";
};
In this case, the <key-value> uses the HMAC-MD5 algorithm. Use the following command to generate keys using the HMAC-MD5 algorithm: 
dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name>
A key with at least a 256-bit length is a good idea. The actual key that should be placed in the <key-value> area can be found in the <key-file-name> file generated by this command.

Warning

Because /etc/named.conf is world-readable, it is advisable to place the key statement in a separate file, readable only by root, and then use an include statement to reference it. For example: 
include "/etc/rndc.key";

19.4.1.1. Firewall Blocking Communication

If a firewall is blocking connections from the named daemon to other nameservers, the recommended best practice is to change the firewall settings whenever possible.

Warning

DNS resolvers, that are not configured to perform DNSSEC validation or that need to query DNS zones that are not protected by DNSSEC only, use a 16-bit transaction identifier (TXID) and the destination UDP port number to check whether the DNS reply was sent by the server they queried for DNS data.
Previously, BIND always used a fixed UDP source port when sending DNS queries. BIND used either a port configured using the query-source (and query-source-v6) directive, or one randomly chosen at startup. When a static query source port is used, TXID offers insufficient protection against spoofed replies and allows an attacker to efficiently perform cache-poisoning attacks. To address this issue, BIND was updated to allow the use of a randomly-selected source port for each DNS query, making it more difficult for an attacker to spoof replies, when the query packets cannot be detected. A security update [3] was released for all the affected Red Hat Enterprise Linux versions. Additionally, the default configuration provided by the caching-nameserver package was updated to no longer specify a fixed query source port.
When deploying BIND as a DNS resolver, ensure that BIND is not forced, by the aforementioned configuration directives, to use a fixed query source port. Your firewall configuration must also permit the use of random query source ports. Previously, it was common practice to configure BIND to use port 53 as a query source port, and only allow DNS queries from that port on the firewall.

19.4.2. Configuring /etc/rndc.conf

The key is the most important statement in /etc/rndc.conf. 
key "<key-name>" {
	algorithm hmac-md5;
	secret "<key-value>";
};
The <key-name> and <key-value> should be exactly the same as their settings in /etc/named.conf.
To match the keys specified in the target server's /etc/named.conf, add the following lines to /etc/rndc.conf. 
options {
	default-server  localhost;
	default-key     "<key-name>";
};
This directive sets a global default key. However, the rndc configuration file can also specify different keys for different servers, as in the following example: 
server localhost {
	key  "<key-name>";
};

Important

Make sure that only the root user can read or write to the /etc/rndc.conf file.
For more information about the /etc/rndc.conf file, refer to the rndc.conf man page.

19.4.3. Command Line Options

An rndc command takes the following form: 
rndc <options> <command> <command-options>
When executing rndc on a properly configured localhost, the following commands are available:
  • halt — Stops the named service immediately.
  • querylog — Logs all queries made to this nameserver.
  • refresh — Refreshes the nameserver's database.
  • reload — Reloads the zone files but keeps all other previously cached responses. This command also allows changes to zone files without losing all stored name resolutions.
    If changes made only affect a specific zone, reload only that specific zone by adding the name of the zone after the reload command.
  • stats — Dumps the current named statistics to the /var/named/named.stats file.
  • stop — Stops the server gracefully, saving any dynamic update and Incremental Zone Transfers (IXFR) data before exiting.
Occasionally, it may be necessary to override the default settings in the /etc/rndc.conf file. The following options are available:
  • -c <configuration-file> — Specifies the alternate location of a configuration file.
  • -p <port-number> — Specifies a port number to use for the rndc connection other than the default port 953.
  • -s <server> — Specifies a server other than the default-server listed in /etc/rndc.conf.
  • -y <key-name> — Specifies a key other than the default-key option in /etc/rndc.conf.
Additional information about these options can be found in the rndc man page.

[3] The security update was RHSA-2008:0533.