/etc/rc.d/named + BIND from ports?

I'm having a rough time finding any documentation on the "new" /etc/rc.d/named startup script. I made a big jump from BIND 9.6-ESV (built with the "replace base" option) to dns/bind99, so a crusty old named.conf is in the mix as well.

My prior rc.conf directives were pretty brief, not more than this:
Code:
named_enable="YES"
named_flags="-u bind -t /var/named"
Now I'm attempting something like this:
Code:
named_enable="YES"
named_program="/usr/local/sbin/named"
named_conf="/etc/namedb/named.conf"     # Path to the configuration file
named_flags=""                 # Use this for flags OTHER than -u and -c
named_uid="bind"                # User to run named as
named_chrootdir="/var/named"    # Chroot directory (or "" not to auto-chroot it)
named_chroot_autoupdate="YES"   # Automatically install/update chrooted
                                # components of named. See /etc/rc.d/named.
named_symlink_enable="YES"      # Symlink the chrooted pid file
named_wait="NO"                 # Wait for working name service before exiting
named_wait_host="localhost"     # Hostname to check if named_wait is enabled
named_auto_forward="NO"         # Set up forwarders from /etc/resolv.conf
named_auto_forward_only="NO"    # Do "forward only" instead of "forward first"
That results in a very quiet failure:
Code:
Starting named.
/etc/rc.d/named: WARNING: failed to start named
Nothing in the logs.

Here's my questions:

- In the above rc.conf snippets, I'm not clear on which named.conf location to point to - the one that's symlinked in from /etc or the one inside the chroot? Both fail.
- named.conf contains options that also set file paths, I'm not clear on which of those are relative to the chroot or the real root (for example the directory option) - doing anything other than commenting this out gives errors from named-checkconf during startup.
- Am I missing a way to get the rc.d/named script to output some more info when it fails? I'd at least like to see what args it's passing to named.

Lastly, if I start it by hand like so, no problems:

/usr/local/sbin/named -u bind -t /var/named -c /etc/namedb/named.conf

edit: here's the result of setting rc_debug="YES" and trying to start - note that the "-c" option to specify the config file is missing:
Code:
/etc/rc.d/named: DEBUG: run_rc_command: doit: /usr/local/sbin/named  -t /var/named -u bind
/etc/rc.d/named: WARNING: failed to start named
 
A few quick things - the replace base option is already gone. I neglected to mention that this is an 8.4 box, so the chroot option should still be valid.

I can copy configs to /u/l/e, but I suspect that won't solve my issue. I'm really trying to understand how the chroot impacts what paths I'm putting in rc.conf and which named.conf options might conflict with startup flags that /etc/rc.d/named is setting.
 
Wow, that was fascinating. As I expected, I had to tear /etc/rc.d/named apart and step through it to see what was going on. I just finished this, so hopefully my memory is working correctly as I recount the issues I found.

TL;DR - you can't mix BIND from ports with the system named script without some undocumented setup, but people will try since the port does not install any startup script of it's own, nor does it install any sample configs in /usr/local/etc.

So there are a number of things that come together to make this not work.

Here's the first one, which is triggered by having your configs in /etc instead of /usr/local/etc:

Code:
if [ ! "$named_conf" = '/etc/namedb/named.conf' ]; then
        case "$named_flags" in
        -c*|*' -c'*) ;;        # No need to add it
        *) command_args="-c $named_conf $command_args" ;;
        esac
fi
The above will omit the "-c" flag, which will in turn cause named to start with whatever the default config location is.

Bear in mind that if you build BIND from ports and you don't specify a config file location via the "-c" option, it looks for its config in /usr/local/etc/namedb/named.conf. So if you have not moved your BIND config into /usr/local/etc/namedb, named will silently fail to start because it won't have a config file.

The next thing that happens is when /etc/rc.d/named runs named-checkconf to verify the config file exists and parses, it will fail. named-checkconf looks for named.conf one directory up from your namedb directory. If you follow the convention of having your named.conf in the same directory BIND keeps its zone data and the like (traditionally /etc/namedb or /usr/local/etc/namedb, and this is enfoced by the startup script - see next point), startup will fail due to the named-checkconf check. You have to symlink named.conf one directory up in the chroot for the check to be successful.

Lastly, /etc/rc.d/named will determine your config directory from the config file variable. So if you specify /usr/local/etc/namedb/named.conf, the startup script will strip the "named.conf" from that path and use that as your config directory. When running chroot, the startup script creates (using mtree) the necessary hierarchy in your chroot directory. It will not create a /usr/local/etc in the chroot, which will cause the symlinking operation to your non-chroot config dir to fail.

If there were some documentation for the case of using BIND from ports on 8.x or 9.x with chroot enabled, this is roughly what it should contain to ensure success:

  • Tar up your current namedb directory and save it somewhere
  • In rc.conf, make sure named_program is set to point to /usr/local/sbin/named, "named_conf" is set to /usr/local/etc/namedb/named.conf, and that "named_chroot_autoupdate" and "named_chroot" are either set at "YES" or defaults.
  • Manually create a usr/local/etc hierarchy under your chroot dir and populate it with your current config (or create a new config, starting with a copy of the contents of /etc/namedb for reference)
  • In the chroot, create a symink from your named.conf to one directory up (full path or relative does not matter, named-checkconf has a chroot flag that works)
  • Ensure that /usr/local/etc/namedb and /usr/local/etc/named.conf do NOT exist (outside the chroot)

Another issue is the stock BIND (or an older BIND from ports that had replace_base set) - make sure any scripts you have that call any BIND utilities are pointing to the /usr/local/[bin|sbin] versions of the utilities.
 
but, when you receive: named chroot: /etc/namedb is a directory!
you make an error, because /etc/namedb is a symlink !
 
Back
Top