The removal of BIND from base in stable/10 left us with the option of running BIND from ports either in a jail, or as an ordinary service. The old BIND in base was able to run in a chroot environment, isolated from the rest of the system.

Some of us believe a chroot is a good compromise between running BIND as an unisolated service or in a jail. I personally believe the removal of /etc/namedb and /var/named as part of make delete-old is premature, as most of us would like to continue keeping all BIND related files in /var/named/etc/namedb.

Harald Schmalzbauer has been kind enough to recreate a chroot environment for dns/bind910. I guess the same patches can be used for dns/bind99 with some minor tweaking.

Take a look at Harald’s contribution if you feel a jail is too much work for a simple service like DNS.


Here’s what I have discovered and done:

Place the mtree-addition.patch and named.in_chroot-autochroot.patch files in /usr/ports, and run:

cd /usr/ports
patch < named.in_chroot-autochroot.patch

If you run stable/10 or above, then you also need this patch:

cd /usr/ports
patch < mtree-addition.patch

Subversion may complain about uncommitted local changes to the affected files while synchronising your ports tree. You should revert these changes, and patch the required files again.

Make sure you have good backups of /usr/local/etc/namedb and /var/named before running BIND from ports for the first time. If you use ZFS and /var/named is a ZFS dataset, then the proper use of snapshots along the way gives you the benefit of a online safety net.

Simply add these two lines to /etc/rc.conf, if you run stable/8, stable/9, stable/10, or head:

named_enable="YES"
named_chrootdir="/var/named"

If you run stable/8 or stable/9, then you should probably stick to the BIND in base, but otherwise you need to add a third line to /etc/rc.conf:

named_program="/usr/local/sbin/named"

If you use ZFS on stable/10 and above, and /usr/local/etc/namedb is a separate ZFS dataset, then you must:

  1. move all files away from /usr/local/etc/namedb,
  2. destroy the dataset,
  3. recreate /usr/local/etc/namedb as a directory, and
  4. move the files back into place.

On stable/10 and above, the startup script will move all files from /usr/local/etc/namedb to ${named_chrootdir}/etc/namedb, and turn /usr/local/etc/namedb into a symlink pointing to ${named_chrootdir}/etc/namedb. The latter is the reason for destroying any ZFS dataset mounted at /usr/local/etc/namedb.