Sun, 25 Apr 2004
BIND9 Config
The Debian sarge bind9 package now defaults to running named as a non-root user. This is great, and the bind9 maintaner rocks for taking the time to do this.
If you are not using sarge or a sarge bind9 backport, you need to create a user for named: adduser —system —home /var/cache/bind —group —disabled-password bind
Then, download and install this script and default file:
You should change the defaults in /etc/default/bind9 if you don’t want the
chroot to be in /srv/bind/chroot. The init script takes care of building the
chroot loopback device, mounting it, and creating the chroot directory
structure inside of the loopback filesystem. It also copies your config files
from /etc/bind into your chroot on start and reload. This means you don’t
have to change any habits to take advantage of the chroot!
The chroot on a loopback is due to Linux (and Unix in general) using
filesystems as security boundries. Traditionally, a secure chroot must be
located on its own partition and filesystem. Normally, running a loopback
incurs an undesireable amount of overhead, but named has such low disk IO
requirements that the increased security is worth while. If you don’t have the
Linux loopback device, or if you don’t want to use it for this, set
bind_use_loopback="no" in /etc/default/bind9.
If you are running Red Hat, Stephen Gildea has a version of this init script available.
Occasionally the root name servers change. A running named will notice, but the db.root still needs to be kept up to date so that named will know about changes after a restart. Putting this script in your monthly cron will take care of it for you. You will need to install the dnsutils package.
This config is designed for an infrastructures.org scenerio. Every host runs a local copy of bind which is used as the local nameserver. The local bind uses the organization’s primary name servers as forwarders. The local bind can optionally use TSIG to communicate with the primaries which prevents DNS poisoning attacks, which can be handy when you want to store your Kerberos information in DNS. Note that every machine can act as a caching nameserver for Win32 or MacOS clients; this makes it easier to recover from some disasters (since you can just reconfigure clients to point at any of your Debian hosts for name service immediately). Obviously, your authoritative nameservers will not be using this configuration, but they shouldn’t be the same as your caching nameservers anyway.