BIND9 chroot install probs

I installed BIND9 and followed the directions for running named in a chroot fashion on a RH v7.2 box. When I execute /etc/rc.d/init.d/named start, the response is that it started and is running, however, when I execute /etc/rc.d/init.d/named status, it tells me that named is dead but subsys locked. Here are copies of my named.conf and the named startup script...

options {
directory "/etc/namedb";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";
allow-query {
67.112.132.20;
};
recursion no;
};

zone "." {
type hint;
file "root.hint";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
notify no;
};

zone "132.112.67.in-addr.arpa" {
type master;
file "db.67.112.132";
};

#!/bin/sh
#
# named This shell script takes care of starting and stopping
# named (BIND DNS server).
#
# chkconfig: 345 55 45
# description: named (BIND) is a Domain Name Server (DNS) \
# that is used to resolve host names to IP addresses.
# probe: true

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

[ -f /usr/local/sbin/named ] || exit 0

[ -f /chroot/named/etc/named.conf ] || exit 0

# See how we were called.
case "$1" in
start)
# Start daemons.
echo -n "Starting named: "
daemon /usr/local/sbin/named -u named -t /chroot/named -c /etc/named.conf
echo
touch /var/lock/subsys/named
;;
stop)
# Stop daemons.
echo -n "Shutting down named: "
killproc named
rm -f /var/lock/subsys/named
echo
;;
status)
status named
exit $?
;;
restart)
$0 stop
$0 start
exit $?
;;
reload)
/usr/local/sbin/rndc reload
exit $?
;;
probe)
# named knows how to reload intelligently; we don't want linuxconf
# to offer to restart every time
/usr/local/sbin/rndc reload >/dev/null 2>&1 || echo start
exit 0
;;

*)
echo "Usage: named {start|stop|status|restart|reload}"
exit 1
esac

exit 0

Yours is not chroot'ed at all.

>> daemon /usr/local/sbin/named -u named -t /chroot/named -c /etc/named.conf

If BIND is to chroot at /chroot/named, then your directory "/etc/namedb";'s full system path would be -> /chroot/named/etc/namedb and pid-file "/var/run/named.pid"; -> pid-file "/chroot/named/var/run/named.pid";

When BIND is configured in a chroot environment (I don't know the syntax for BIND9), your first few lines would look like so:

#chroot at /chroot/named
options {
directory "/";
pid-file "var/run/named.pid";
statistics-file "var/run/named.stats";

In a chroot environment, all the user/group and permission should be different from non-chroot environment. You will have to do a little more reseach to find out how to chroot BIND.

I've found a critical problem in your named.conf. Looks to me you are not supposed to run BIND as authoritative DNS server in the first place. Though you may run BIND as a cache-only nameserver.
The reason is, let's take a look at the following:

allow-query {
67.112.132.20;
};

64.112.132.20 reverse lookup -> adsl-67-112-132-20.dsl.sndg02.pacbell.net

Pacbell never delegate in-addr.arpa to DSL customers. Therefore, you have no control of your reverse (even you have static IP). When you have no control of it, you can't run BIND and pretend you are authoritative for 20.132.112.67.in-addr.arpa.
Additionally, you don't appear to have a db.yourdomain.com. So why run BIND when you are not supposed to?
You can argue you just want a cache-only nameserver. That's fine but you really should go for dnscache instead. dnscache is 500-700 times faster than BIND. Do a little search in this forum using the search keyword: djb.

In my research, I noticed the gluelessness thing. If I want to be a hoster and controll my own dns (ns1.securedcgi.com), I would need to be authoratative to securedcgi.com (67.112.132.20) as well as the sites I'm hosting (if I'm reading and interpreting correctly). This being the case, wouldn't I need to actually be (no pretending) authoratative for 20.132.112.67.in-addr.arpa? Are there any other alternatives that would allow me to point newly hosted sites at my IP without having to pay an arm and leg? Can I manage hosted sites and name resolution using caching servers only? Thanks in advance

>> I noticed the gluelessness thing

Your situation has nothing to do with gluelessness. Yours would be gluelessness when someone else nameserver is authoritative for securedcgi.com but you appear to host securedcgi.com yourself so you are fine.

>> I would need to be authoratative to securedcgi.com (67.112.132.20) as well as the sites I'm hosting

Correct.

>> wouldn't I need to actually be (no pretending) authoratative for 20.132.112.67.in-addr.arpa?

You can't be authoritative for your reverse with Pacbell. Neither can my DNS servers be authoritative for my static IPs. Though, my ISP (SpeakEasy.net) can configure my reverse to point back to my FQDN (not in-addr.arpa delegation but they can change the PTR record for my static IPs on their end) on request at no charge.
Having a revervse that point back to your FQDN helps alot but not required.

>> would allow me to point newly hosted sites at my IP without having to pay an arm and leg?

You are fine so long as you have a static IP with pacbell. You are authoritative for securedcgi.com as well as other domains you plan on hosting but with a little trouble for having just one static IP. To overcome this problem, you can:

1) Pretend 67.112.132.21 is your static IP as well and add an A record for ns2.securedcgi.com
2) Disable zone transfer.
Yes, 67.112.132.21 is not your IP and you can't run anything on it. But the trouble is that some registrant requires your clients to have 2 or more nameservers.

Having just one static IP will have another problem. Not all dns clients (dnscache) query primary ns1 first, could be randomly. So expect some delay/timeout when people are trying reach your customer's site.

>> Can I manage hosted sites and name resolution using caching servers only?

No. BIND tries to confuse people by combining authoritative dns + cache-only into a big daemon. In djbdns, there are 4 standalone packages:

- dnscache
- tinydns
- axfrdns
- rbldns

For name resolution you just need dnscache, no more, no less. people with dynamic IP can run dnscache just fine. There is no reason to use your ISP's nameservers (cache-only or perhaps with authoritative combined).
I have 4 static IPs on different BSDs boxes each runs dnscache. 3 of those runs on 127.0.0.1 and forwards to another one running on 192.168.0.4 (the master dnscache).
You can run dnscache on 127.0.0.1 without a problem. To run it on 192.168.0.1 so your LAN's workstations can use it, you also need to run authoritative dns (tinydns) on 192.168.0.1. However, you can't bind tinydns to udp 53 because it's already in use by dnscache. That said, you need to create alias to your NIC or run it on another box.

So just go ahead and play around with BIND for a little while, when you get familiar with it, ditch it and go for djbdns.