7.7 Configuring a Caching-Only Name Server

7.7.1 Problem

You want to configure a caching-only name server.

7.7.2 Solution

Configure the name server with a root hints file (or, if you run BIND 9, use the built-in root hints) and restrict the queries it handles to the addresses of authorized resolvers using the allow-query options substatement. For example:

acl internal { 192.168.0/24; };

options {
    directory "/var/named";
    allow-query { internal; };
};

// The root hints are compiled into a BIND 9 name server, so this zone 
// statement is optional on those name servers

zone "." {
    type hint;
    file "db.cache";
};

7.7.3 Discussion

You may want to set up a caching-only name server as authoritative for some internal zones, so that you can ensure that data in those zones is reliable. In this configuration, the name server will ignore records from your internal zones in answers from remote name servers, making it hard for a hacker to spoof data in those zones.

Since a caching-only name server's main function is to query other name servers and cache the results, follow the instructions in Section 7.15 to protect against spoofing.

7.7.4 See Also

Section 7.15 for instructions on protecting a name server from spoofing.

7.8 Running a Name Server in a chroot( ) Jail

7.8.1 Problem

You want to run a name server in a chroot( ) jail, so that a hacker successfully breaking in through the named process has limited access to the host's filesystem.

7.8.2 Solution

Set up an environment for the name server to chroot( ) into, then use named 's - t command-line option to specify the name of the directory to chroot( ) to.

A BIND 9 chroot( ) environment, on most Unix systems, should include:

• A working directory for the name server (which can be the chroot( ) directory itself)

• An etc subdirectory, which includes named.conf and the localtime file, copied from /etc/localtime

• A var/run subdirectory for the name server's PID file

• A dev subdirectory, which may need to include the log , random , and zero devices

On my FreeBSD system, here's how I set up the chroot( ) environment:

# mkdir /etc/namedb
# cd /etc/namedb
# mkdir -p dev etc/namedb var/run etc/namedb is the working directory
# cp /etc/localtime etc
# mknod dev/random c 2 3
# mknod dev/zero c 2 12
# vi etc/named.conf

To create the log device, I added the command-line option - a /etc/namedb/dev/log to the startup of the syslog daemon. This tells syslogd to create an extra log device with the specified path (in the chroot( ) environment) and listen on it for logged messages.

Piece of cake!

Once you've set up the chroot( ) environment, start named with the - t command-line option, specifying the directory to chroot( ) to as the option's argument. The first time you do it, check named 's syslog output for any startup errors caused by missing files or directories. Once named starts cleanly in the chroot( ) environment, add the - t option to your system's startup scripts.

7.8.3 Discussion

When running a name server in a chroot( ) environment, be sure to run as a non-root user , too. On many operating systems, a hacker gaining access to a process as root can break out of a chroot( ) jail. See Section 7.9 for instructions on running named as a non-root user.

BIND 8 name servers require a considerably more complicated chroot( ) environment, including a passwd file, shared libraries (unless you build BIND statically linked), and various device files, which is a good reason to recommend using BIND 9 in a chroot( )d setup. If you insist on running a BIND 8 name server chroot( ) ed, see "Running BIND with Least Privilege" in Chapter 11 of DNS and BIND for instructions.

You can simplify the chroot( ) environment slightly by using the pid-file options substatement to tell named to create the PID file with a different pathname. For example, to create the PID file in the name server's working directory, use:

options {
    directory "/var/named";
    pid-file "named.pid";
};

In fact, unless you use dynamically updated zones with DNSSEC, you can do without dev/random in the chroot( ) environment, too. But then you'll have to put up with named logging an error each time it starts.

7.8.4 See Also

Section 1.21 for editing startup scripts, Section 7.9 for running BIND as a user other than root, and "Running BIND with Least Privilege" in Chapter 11 of DNS and BIND.