Trying to run two instances of unbound

R

rainer_d

Hi,

I'm trying to run two instances of unbound, chrooted.

This almost works.
I've copied the start-script to unbound2 and replaced unbound with unbound2 where applicable:

Bash: 
#!/bin/sh
#
# $FreeBSD: branches/2019Q1/dns/unbound/files/unbound.in 470572 2018-05-21 19:28:28Z brnrd $
#
# unbound freebsd startup rc.d script, modified from the named script.
# uses the default unbound installation path and pidfile location.
# copy this to /etc/rc.d/unbound
# and put unbound_enable="YES" into rc.conf
#
# unbound_anchorflags can be used to allow you to pass a custom flags to
# unbound-anchor.  Examples include a custom resolv.conf (-f) or a custom
# root.hints (-r).  Useful for when /etc/resolv.conf only contains 127.0.0.1

# PROVIDE: unbound
# REQUIRE: SERVERS cleanvar
# KEYWORD: shutdown

. /etc/rc.subr

name="unbound2"
rcvar=unbound2_enable

command="/usr/local/sbin/unbound"
extra_commands="reload"
start_precmd="start_precmd"

load_rc_config $name

pidfile=`/usr/local/sbin/unbound-checkconf -o pidfile ${unbound2_conf}`
unbound2_enable=${unbound2_enable:-"NO"}
unbound2_anchorflags=${unbound2_anchorflags:-""}
unbound2_conf=${unbound2_conf:-"/usr/local/etc/unbound2/unbound.conf"}
unbound2_flags=${unbound2_flags:-" -c ${unbound2_conf}"}

reload_precmd="/usr/local/sbin/unbound-checkconf ${unbound2_conf} >/dev/null"

start_precmd()
{
        echo -n "Obtaining a trust anchor:"
        if [ "${unbound2_anchorflags}T" = "T" ]; then
                su -m unbound -c /usr/local/sbin/unbound-anchor
        else
                su -m unbound -c "/usr/local/sbin/unbound-anchor ${unbound2_anchorflags}"
        fi
        echo .
        /usr/local/sbin/unbound-checkconf ${unbound2_conf} > /dev/null
        return $?
}

run_rc_command "$1"

Then, I've got rc.conf:
Bash: 
unbound2_enable="YES"
unbound2_conf="/usr/local/etc/unbound2/unbound.conf"
unbound2_chrootdir="/usr/local/etc/unbound2"
unbound2_anchorflags="-C /usr/local/etc/unbound2/unbound.conf.no_chroot"

It seems fetching the anchor does not work chrooted. At least, it didn't for me. Even in the primary instance. So I don't chroot for fetching the anchor, I can live with that.

I'm also creating a log-socket in the chroot and I've also mounted a minimal dev inside it.

Among other stuff, I've got the following in unbound.conf:


Code: 
    chroot: /usr/local/etc/unbound2
    pidfile: "unbound.pid"
        directory: "/usr/local/etc/unbound2"
    auto-trust-anchor-file: /usr/local/etc/unbound2/root.key


As I said, this works - except for the fact that the pid-file is owned by root:wheel and when I try to restart unbound via sudo, it somehow thinks it's not running:


Code: 
(unbound-res-prod <unbound2>) 0 # /usr/local/etc/rc.d/unbound2 status
unbound2 is running as pid 54324.
(unbound-res-prod <unbound2>) 0 # su - otheruser
(unbound-res-prod <~>) 0 $ sudo /usr/local/etc/rc.d/unbound2 status
unbound2 is not running.

Code: 
/usr/local/etc/unbound:
total 121
-rw-r--r--  1 upremote  wheel    14249 Mar  1 15:56 client-acl.conf
drwxr-xr-x  2 unbound   unbound    512 Mar 24  2017 conf.d
-rw-r--r--  1 root      wheel      193 Mar 24  2017 control.conf
dr-xr-xr-x  7 root      wheel      512 Jan 15 16:26 dev
-rw-r--r--  1 root      wheel      133 Mar 24  2017 forward.conf
-rw-r--r--  1 root      wheel      189 Mar 24  2017 lan-zones.conf
-rw-r--r--  1 unbound   wheel      759 Mar  5 10:22 root.key
-rw-r-----  1 root      unbound   2459 Mar 24  2017 unbound_control.key
-rw-r-----  1 root      unbound   1330 Mar 24  2017 unbound_control.pem
-rw-r-----  1 root      unbound   2455 Mar 24  2017 unbound_server.key
-rw-r-----  1 root      unbound   1318 Mar 24  2017 unbound_server.pem
-rw-r--r--  1 root      wheel     2366 Feb 28 17:03 unbound.conf
-rw-r--r--  1 root      unbound    840 Oct 17  2017 unbound.conf.no.chroot
-rw-r--r--  1 root      wheel    37943 Jan  3 08:05 unbound.conf.sample
-rw-r--r--  1 unbound   unbound      6 Mar  5 10:10 unbound.pid
drwxr-xr-x  3 root      unbound    512 Mar 24  2017 var

/usr/local/etc/unbound2:
total 112
-rw-r--r--  1 upremote  wheel    14249 Mar  1 15:56 client-acl.conf
drwxr-xr-x  2 unbound   unbound    512 Mar 24  2017 conf.d
-rw-r--r--  1 root      wheel      193 Mar 24  2017 control.conf
dr-xr-xr-x  4 root      wheel      512 Jan 15 16:26 dev
-rw-r--r--  1 root      wheel      168 Jan 25 11:27 forward.conf
-rw-r--r--  1 root      wheel      187 Jan 25 11:30 lan-zones.conf
-rw-r--r--  1 unbound   wheel      759 Mar  5 09:41 root.key
-rw-r-----  1 root      unbound   2459 Mar 24  2017 unbound_control.key
-rw-r-----  1 root      unbound   1330 Mar 24  2017 unbound_control.pem
-rw-r-----  1 root      unbound   2455 Mar 24  2017 unbound_server.key
-rw-r-----  1 root      unbound   1318 Mar 24  2017 unbound_server.pem
-rw-r--r--  1 root      wheel     2024 Mar  5 09:52 unbound.conf
-rw-r--r--  1 root      unbound    956 Mar  5 10:15 unbound.conf.no_chroot
-rw-r--r--  1 root      wheel    37943 Jan  3 08:05 unbound.conf.sample
-rw-r--r--  1 root      wheel        6 Mar  5 10:22 unbound.pid
drwxr-xr-x  3 root      unbound    512 Mar 24  2017 var

Any idea what's going on here?
 
One is forwarding queries to a BIND resolver that gets an RPZ feed, the other doesn't.
I don't really want to run three jails for this.
 
I see a few obvious problems here. The first is port 53. You can only have one instance bound to it. Where's the other instance supposed to bind to? You can't use other ports as clients will only query on port 53.

rainer_d said:
One is forwarding queries to a BIND resolver that gets an RPZ feed, the other doesn't.
Click to expand...
It's probably a lot easier if you set up different views in BIND.

kb.isc.org

Understanding views in BIND 9

Views add complexity to a BIND configuration, but this article explains how that complexity can be managed and allow views to be used effectively.
kb.isc.org kb.isc.org
 
I use different IPs for each instance of BIND and unbound. There is no conflict.
As I said, it all works, as long as I start and stop everything directly as root.

Unfortunately, unbound cannot receive RPZ-feeds like BIND, else I wouldn't run BIND there at all - it's a necessity rather than something that I chose to do deliberately...

TBH, I don't want to run BIND as outside-facing resolver and I want to configure views in such a setup even less
:eek:
 
You must log in or register to reply here.
Back
Top