On Red Hat 9, fully patched, I'm getting the following log entries when I run "service bind start":

Jun 6 21:47:52 Dell-RH9 named[24785]: starting BIND 9.2.1 -u named
Jun 6 21:47:52 Dell-RH9 named[24785]: using 1 CPU
Jun 6 21:47:52 Dell-RH9 named: named startup succeeded
Jun 6 21:47:52 Dell-RH9 named[24785]: loading configuration from '/etc/named.conf'
Jun 6 21:47:52 Dell-RH9 named[24785]: no IPv6 interfaces found
Jun 6 21:47:52 Dell-RH9 named[24785]: listening on IPv4 interface lo, 127.0.0.1#53
Jun 6 21:47:52 Dell-RH9 named[24785]: listening on IPv4 interface eth0, 192.168.0.110#53
Jun 6 21:47:52 Dell-RH9 named[24785]: listening on IPv4 interface ppp0, 209.39.142.209#53
Jun 6 21:47:52 Dell-RH9 named[24785]: command channel listening on 127.0.0.1#953
Jun 6 21:47:52 Dell-RH9 named[24785]: couldn't open pid file '/var/run/named/named.pid': Permission denied
Jun 6 21:47:52 Dell-RH9 named[24785]: exiting (due to early fatal error)


Evidently, it is trying to create the .pid file in the /var/run/named directory, but can't.


My permisions are set as follows:

drwxr-xr-x 29 root root 728 May 2 10:27 /var
drwxr-x--- 15 root root 896 Jun 5 01:57 /var/run
drwxrwx--- 2 named named 48 Jan 25 2003 /var/run/named/

-rwxr-xr-x 2 named named 252928 Jan 25 2003 /usr/sbin/named
-rwxr-xr-x 1 named named 7231 Jan 25 2003 /usr/sbin/named-bootconf
-rwxr-xr-x 1 named named 6732 Jan 25 2003 /usr/sbin/named-checkconf
-rwxr-xr-x 1 named named 7640 Jan 25 2003 /usr/sbin/named-checkzone



My named.conf is as follows:


// generated by named-bootconf.pl

options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
//
// a caching only nameserver config
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey;
};
zone "." IN {
type hint;
file "named.ca";
};

zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};

include "/etc/rndc.key";

just for spite try typing this as root:
and see if the output is any different.

Neither bind nor bind9 is a recognised service. Perhaps you are thinking of Debian or Fedora; in RH9, bind service is activated by named. Never-the-less, I tried your suggestion and got "service not recognised."

I forgot to mention in my thread that I ran all my commands as root.

On a lark, I tried su named -c "service named start" and this time got permission issues from the /var/lock/subsys/named dirctory. After fixing them, I got more permission errors reported in the log (relating to the interfaces). This is getting very complicated... Perhaps I should start over.

Just a guess - maybe named is started in a chroot jail, so when it talks about /var/run/named/ it is actually something like /var/named/var/run/named/ Can you check that?

I haven't setup BIND on RedHat, although I have experience running it on Debian, Solaris and AIX, and will be installing it on RedHat Enterprise in the future.

The named daemon must be started as root, as it needs to listen on reserved port addresses. It is then possible for it to change the user that it runs under in this case -u named means that it will run under the user named.

So although the daemon must be started as root, you should be looking for permissions for the named user.

The -t option is used if you want to run in a chroot environment. I'm not sure whether this will be performed in RedHat, but as it doesn't mention it in the log details you provided I guess it's not doing that.

I think the problem here is the permissions of the /var/run directory. The current permissions do not allow the named user to see the named directory. Try changing /var/run to 755, and see if that allows it to start.

As long as the files in /var/run have the correct permissions there is no reason to not allow read and execute permission to the /var/run directory. If you really don't want to do this then you should implement a chroot environment.

The following information is taken from the bind administrators manual on using chroot if you want to go that way.

===
On UNIX servers, it is possible to run BIND in a chrooted environment (chroot()) by specifying the "-t" option. This can help improve system security by placing BIND in a "sandbox," which will limit the damage done if a server is compromised.

...

In order for a chroot() environment to work properly in a particular directory (for example, /var/named), you will need to set up an environment that includes everything BIND needs to run. From BIND's point of view, /var/named is the root of the filesystem. You will need to adjust the values of options like like directory and pid-file to account for this.

Unlike with earlier versions of BIND, you will typically not need to compile named statically nor install shared libraries under the new root. However, depending on your operating system, you may need to set up things like /dev/zero, /dev/random, /dev/log, and/or /etc/localtime.
===