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



## spork (Feb 15, 2015)

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:

```
named_enable="YES"
named_flags="-u bind -t /var/named"
```
Now I'm attempting something like this:

```
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:

```
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:

```
/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
```


----------



## wblock@ (Feb 15, 2015)

My recommendation is to stop mixing the base and ports versions, and just treat it like a regular port.  Put the configuration files in /usr/local/etc/namedb.  Don't use the replace base option, keep them separate.  The chroot option is gone in the port, at least for FreeBSD 10 and later.  If you want improved security, run it in a jail as shown here: https://www.freebsd.org/doc/en_US.I...k/jails-ezjail.html#jails-ezjail-example-bind.


----------



## spork (Feb 15, 2015)

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.


----------



## spork (Feb 16, 2015)

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:


```
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.


----------



## cielo2 (May 22, 2018)

but, when you receive: named chroot: /etc/namedb is a directory! 
you make an error, because /etc/namedb is a symlink !


----------



## gkontos (May 22, 2018)

cielo2 said:


> but, when you receive: named chroot: /etc/namedb is a directory!
> you make an error, because /etc/namedb is a symlink !



You are replying to a 3+ year old thread. The OP was probably trying to replace bind from base to ports.


----------

