Chapter 7. DNS (207)

Revision: $Revision: 911 $ ($Date: 2012-05-24 15:53:19 +0200 (Thu, 24 May 2012) $)

This objective has a weight of 6 points.

Basic BIND 9.x configuration (207.1)

Revision: $Revision: 966 $ ($Date: 2012-08-27 10:34:07 +0200 (Mon, 27 Aug 2012) $)

Resources and further reading: Albitz01, DNShowto, BINDfaq.

LPIC 2 objective 207.1 (2 points)

Candidates should be able to configure BIND to function as a caching-only DNS server. This objective includes the ability to convert older BIND configuration files to newer format, managing a running server and configuring logging.

Key Knowledge Areas:

  • BIND 9.x configuration files, terms and utilities.

  • Defining the location of the BIND zone files in BIND configuration files.

  • Reloading modified configuration and zone file.

The following is a partial list of used files, terms, and utilities:

  • /etc/named.conf

  • /var/named/*

  • /usr/sbin/rndc

  • kill

Name-server components in BIND

Name servers like BIND are part of a worldwide DNS system that resolves machine names to IP-addresses.

Table Table 7.1, “Major BIND components” lists the most relevant parts of BIND software on a system. Note that directories may vary across distributions.

Table 7.1. Major BIND components

Program /usr/sbin/namedthe real name server
Program /usr/sbin/rndcname daemon control program
File named.confBIND configuration file
Program /etc/init.d/binddistribution specific startfile
Directory /var/namedworking directory for named

Resolving is controlled by the file nsswitch.conf which is discussed in Chapter 10, Network Client Management (210) .

BIND components will be discussed below.

The named.conf file

The file named.conf is the main configuration file of BIND. It is the first configuration file read by named, the DNS name daemon.

Location of named.conf

LPI lists the location of named.conf in /etc. However, the location may vary across distributions. For example in the Debian Linux distribution named.conf is located in the /etc/bind directory.

A caching-only named.conf file

This is an example named.conf file. The version below is taken from the Debian bind package (some comments removed).

options {
        directory "/var/named";

        // query-source address * port 53;

        // forwarders {
        // };

// reduce log verbosity on issues outside our control
logging {
        category lame-servers { null; };
        category cname { null; };

// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
        type master;
        file "/etc/bind/db.local";

zone "" {
        type master;
        file "/etc/bind/db.127";

zone "" {
        type master;
        file "/etc/bind/db.0";

zone "" {
        type master;
        file "/etc/bind/db.255";

// add entries for other zones below here

The Debian bind package that contains this file, will provide a fully functional caching-only name server. BIND packages of other manufacturers will provide the same functionality.

A caching-only name server resolves names, which are also stored in a cache, so that they can be accessed faster when the nameserver is asked to resolve these names again. But this is what every name server does. The difference is that this is the only task a caching-only name server performs. It does not serve out zones, except for a few internal ones.


The named.conf file contains statements that start with a keyword plus a { (opening curly brace) and end with with a } (closing curly brace). The options statement is an example.

A statement may contain other statements. The forwarders statement is an example of this.

A statement may also contain things like IP addresses or file followed by a filename. These simple things must be terminated by a semi-colon (;).

All kinds of comments are allowed, e.g., // and # as end of line comments. See the named.conf(5) manual page for details.


The ; is NOT valid as a comment sign in named.conf. It IS, however, in BIND zone files, like the file /etc/bind/db.local from the example above.

The options statement

Of the many possible entries (see named.conf(5)) inside an options statement, only the directory, forwarders, forward, version and dialup will be discussed below.


There can be only one options statement in a named.conf file.

Some things within options


Specifies the working directory for the name daemon. A common value is /var/named. Also, zone files without a directory part are looked up in this directory.

Recent distributions separate the configuration directory from the working directory. In a recent Debian Linux distribution, for example, the working directory is specified as /var/cache/bind, but all the configuration files are in /etc/bind. All zone files are also in that directory and must be specified with their directory part, as can be seen in the named.conf example above.


The forwarders statement contains one or more IP addresses of name servers to query. How these addresses are used is specified by the forward statement described below.

The default is no forwarders. Resolving is done through the worldwide (or company local) DNS system.

Usually the specified name servers are those of the Service Provider the system connects to.


The forward works only when forwarders are specified.

Two values can be specified: forward first; (default) and forward only;. With first the first query is sent to the specified name-server addresses, next queries are sent to other name servers. With only queries are limited to the specified name-server addresses.

An example with both forwarders and forward:

    options {
        // ...

        forwarders {

        forward only;

        // ...

In this example bind is told to query only the name servers and


It is possible to query the version from a running name server:

    dig txt chaos version.bind

Note that the BIND version is shown in the output. Because some BIND versions have known exploits, the BIND version is sometimes kept hidden. The version specification:

    version "not revealed";

inside the options statement leads to not revealed responses on version queries.


When a name server sits behind a firewall, that connects to the outside world through a dialup connection, some maintenance normally done by name servers might be unwanted.

The following example, also inside the options part, stops external zone maintenance:

    heartbeat-interval 0;
    dialup yes;

Many more options can be placed inside the options block. See the manual page.

The logging statement

The BIND (version 8 and 9) logging system is too elaborate to discuss in detail here. The distinction between categories and channels is important.

A channel is an output specification. The null channel, for example, dismisses any output sent to the channel.

A category is a type of data. The category security is one of many categories. To log messages of type (category) security, for example, to the default_syslog channel, use the following:

    logging {
        category security { default_syslog; };
        // ...

To turn off logging for certain types of data, send it to the null channel, as is done in the example named.conf shown earlier:

    logging {
            category lame-servers { null; };
            category cname { null; };

This means that messages of types lame-servers and cname are being discarded.

There are reasonable defaults for logging. This means that a named.conf without logging statement is possible.


A maximum of one logging statement is allowed in a named.conf file.

Predefined zone statements

A zone defined in named.conf will be available as @ inside the corresponding zone file. The @ is called the current origin. For example,

    zone "" {
            type master;
            file "/etc/bind/db.127";

will result in a current origin of that is available as @ in file etc/bind/db.127.

Details about zone files, as well as how to create your own zone files and statements will be covered in the section called “Create And Maintain DNS Zones (207.2)”.

The named name server daemon

The named name server daemon is the program that communicates with other name servers to resolve names. It accepts queries, looks in its cache and queries other name servers if it does not yet have the answer.

Once it finds an answer in its own cache or database or receives an answer from another nameserver, it sends the answer back to the name server that sent the query in the first place.

Table Table 7.2, “ Controlling named lists ways to control the named name server.

The rndc program

The rndc (Remote Name Daemon Control) program can be used to control the named name server daemon, locally as well as remotely. It requires a /etc/rndc.key file which contains a key.

key "rndc-key" {
	algorithm hmac-md5;
	secret "tyZqsLtPHCNna5SFBLT0Eg==";

options {
	default-key "rndc-key";
	default-port 953;

The name server configuration file /etc/named.conf needs to have the same key added as well as allow a host with this key to control the name server. The relevant part of that file is shown below.

key "rndc-key" {
 	algorithm hmac-md5;
 	secret "tyZqsLtPHCNna5SFBLT0Eg==";
controls {
	inet port 953
		allow {; } keys { "rndc-key"; };

Running the program rndc-confgen will create a key in case none is available on the system.

A command to the name server can be given as a parameter to rndc, e.g.: rndc reload. This will request the name server to reload its configuration and zone files. All commands specified in this way are understood by the name daemon. The help command presents a list of commands understood by the name server.

While not discussed here rndc may be used to manage several name servers remotely.

Consult the man pages and the "BIND 9 Administrator Reference Manual" for more information on rndc and BIND.

Sending signals to named

It is possible to send signals to the named process to control its behaviour. A full list of signals can be found in the named manpage. One example is the SIGHUP signal, that causes named to reload named.conf and the database files.

Signals are sent to named with the kill command, e.g.,

    kill -HUP 217

This sends a SIGHUP signal to a named process with process id 217, which triggers a reload.

Controlling named with a start/stop script

Most distributions will come with a start/stop script that allows you to start, stop or control named manually, e.g., /etc/init.d/bind in Debian or /etc/init.d/named in RedHat.

Table Table 7.3, “/etc/init.d/bind parameters” lists parameters that a current version of /etc/init.d/bind accepts.

Table 7.3. /etc/init.d/bind parameters

startstarts named
stopstops named
restartstops and restarts named
reloadreloads configuration
force-reloadsame as restart

Copyright Snow B.V. The Netherlands