Flylib.com

Books Software

 
 
 

5.9 Restarting a Name Server Automatically If It Dies


5.9 Restarting a Name Server Automatically If It Dies

5.9.1 Problem

You want a name server to restart automatically if it dies.

5.9.2 Solution

Use the nanny.pl Perl script included in the BIND 9 distribution. After you've unpacked the BIND 9 distribution, you'll find nanny.pl in contrib /nanny/nanny.pl .

nanny.pl runs as a daemon, so just modify the variables at the top of the script as needed and then start it. You may also want to configure your host to start nanny.pl at boot time.

There are four variables you may need to customize:

$pid_file_location = '/var/run/named.pid';
$nameserver_location = 'localhost';
$dig_program = 'dig';
$named_program =  'named';

For example, if you're starting named with one or more command-line options, change $named_program accordingly , like so:

$named_program = 'named -t /etc/namedb -u bind';

5.9.3 Discussion

nanny.pl checks every 30 seconds to see if the named process exists using kill -0 against its process ID, and by querying the local name server with dig . If either test fails, the script restarts the name server.

There's nothing specific to BIND 9 in nanny.pl , so you can use it with BIND 8 name servers, too.

5.9.4 See Also

Section 1.19, for starting the name server from the command line.


5.10 Restarting a Name Server with the Same Arguments

5.10.1 Problem

You want to restart named with ndc , but keep the same command-line arguments.

5.10.2 Solution

Specify the command-line arguments after the restart command. For example:

# ndc restart -c /tmp/named.conf

Or, if you're not sure what the command-line arguments were, use:

# ndc exec

The exec command tells named to exec( ) a new copy of itself, including any command-line argument it was started with.

5.10.3 Discussion

If you run ndc from the command line and named is linked against a faulty copy of getopt( ) , you may need to specify "- -" as the first argument to restart to make sure the options are passed to named correctly.

BIND 9 name servers don't support restart and exec .

5.10.4 See Also

Section 3.2, for setting up ndc to work with a name server; Section 5.5, for a situation in which you'd restart a name server (in this case, to clear the cache); and "Controlling a Name Server" in Chapter 7 of DNS and BIND .


5.11 Controlling Multiple named Processes with rndc

5.11.1 Problem

You want to control multiple named processes running on the same host with rndc .

5.11.2 Solution

Since rndc only supports TCP-based communications with name servers, configure the name servers to listen on different addresses for control messages. For example, if your host runs two named processes -- one listening on 192.168.0.1 for queries, the other listening on 192.168.0.2 -- you might configure the first one with this controls statement in its named.conf file:

controls {
    inet 192.168.0.1 allow { localnets; } keys { rndc-key; };
};

The second might have this controls statement in named.conf :

controls {
    inet 192.168.0.2 allow { localnets; } keys { rndc-key; };
};

If rndc-key is rndc 's default key, you can control the two named processes with:

# rndc -s 192.168.0.1

Or:

# rndc -s 192.168.0.2

5.11.3 Discussion

If you want to use different keys to control the two processes, you can add two server statements to rndc.conf , specifying the proper key to use for each.

You could also set up the two name servers to listen on different control ports, and then use the port server substatement in rndc.conf to distinguish between the two. For example:

server ns1.foo.example {
    port 953;
    key "rndc-key";
};

server ns1-int.foo.example {
    port 1053;
    key "rndc-key";
};

This assumes that both ns1.foo.example and ns1-int.foo.example map to the same address.

5.11.4 See Also

Section 3.4 for configuring rndc to work with a remote name server using the rndc.conf 's server statement.