How ncd Works

Before ndc there was the kill command. In the beginning, sending HUP to named caused files to be re-read, as is usual for UNIX daemons. As time passed, other signals were added to do other things. The first versions of ndc, as found in BIND 4, were shell scripts that simply provided a handy tool to send all these signals to named. ndc in BIND 8, however, can use a named pipe to communicate with BIND and get messages back about how and what BIND is doing. But it also can still use signals to deliver the message to BIND. In BIND 9, the evolution is complete, and ndc is called rndc for remote ndc. It uses an encrypted network connection to send commands and a shared secret or key to authenticate itself to named.

However, it is still handy to be able to send signals to a named to control it. These are the signals:

INT	Dump database; ndc dumpdb
ABRT	Dump statistics (BIND 4); ndc stats. Also known as IOT
ILL	Dump statistics (BIND 8)
HUP	Reload database; ndc reload
USR1	Increment debug level; ndc trace
USR2	Reset debug level; ndc notrace
WINCH	Enable/disable query logging; ndc querylog
TERM	Exit, stop, quit; ndc stop

Admittedly, this is most handy when you're struggling with a setup problem that has stopped named from using the normal communications channel.

ndc in BIND 8 prefers to use a named socket a channel in ndc terms usually named /var/run/ndc. A security issue exists with named sockets because some versions of UNIX do not permit, or enforce, permission bits on sockets. This allows anyone to access the socket and control your named. The fix is to create a directory that is available to only the users meant to control your named. The name of the socket is controlled by the controls statement in named.conf:

 controls {     …     unix "/var/ndc/ndc"       perm 0600       owner 0           // root       group 0;          // wheel     … }; 

As this example should make obvious, on OSs that enforce access permissions on named sockets, you can set the permission bits the socket is supposed to have. The benefit of this is that a user with the correct file group membership can use ndc to control named, so the user doesn't have to be root to do the job. This is a big advantage. Of course, ndc does not read named.conf, and when you change the path, you must give it an option so it can find the socket:

 $ ndc -c /var/ndc/ndc reload Reload initiated. 

BIND 8 can also be controlled by network sockets, although I would not recommend that. The only way to access-control it would be to restrict access to the hosts allowed to use the network socket. By default, BIND does not listen for ndc messages on any network socket.

In addition to the old tricks, ndc can now perform a number of new tricks through the socket.

status

The last line of output from ndc status can be a bit disconcerting:

 $ ndc status named 8.2.2-P5 Mon Feb 28 10:17:53 EST 2000  \         root@lookfar:/usr/src/bind-8.2.2_P5/src/bin/named number of zones allocated: 64 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF server is DONE priming server IS NOT loading its configuration 

The last line means that named is not reading the configuration right now. It is not an error; your configuration file will be quite big before you will get to see it still loading. The number of zones allocated has nothing to do with how many zones are loaded; it simply indicates how large the zone data structure is. It is enlarged in chunks of 64 zones as necessary. The debug level is for dynamic logging, as discussed in Chapter 3, "Maintenance and Enhancements." xfers running, xfers deferred, and SOA queries in progress have to do with the mechanics of zone transfers. If the number of deferred xfers keeps growing, you might have a problem that bears looking into. The parameters controlling this are described later in this chapter. priming refers to loading the hints zone.