Solved Unbound not starting on boot

[Jan-Niklas Meier]

This is a problem that I have been trying to solve for months now. I have a FreeBSD router at home that is also running unbound(8) as a recursive DNS server for my local network. I have it set up with DNSSEC enabled and it is working flawlessly.
It is also set up to be the DNS server for the server itself so that all queries go through unbound.

This all works fine when unbound(8) is manually started after the server booted. I failed to configure unbound in a way that it would automatically start on boot, though. I have it enabled through the following line in my rc.conf as the install instructions described. Not really sure what the 'local' prefix is supposed to mean as no other service seems to have that but I did it anyway.

local_unbound_enable="YES"

I thought that an issue might be the dependence to ntpd(8) where ntpd(8) would need unbound(8) to resolve the time server and unbound(8) would need ntpd(8) to set the time so server responses can be verified. I then changed the NTP server entries to their IP addresses and that didn't help either.

I also can't see any log entries after boot of unbound(8) failing to start but I might be looking in the wrong places...

Does anyone have an idea of what might be going on here?

I'm running 10.2-RELEASE-p12 and unbound 1.5.3.

Below is my unbound.conf:

server:
    verbosity: 1
    num-threads: 4
    interface: 192.168.0.1
    interface: 127.0.0.1
    interface: 192.168.1.1
    interface: 192.168.2.1
    port: 53
    msg-cache-size: 64m
    rrset-cache-size: 128m
    do-ip4: yes
    do-ip6: yes
    do-udp: yes
    do-tcp: yes
    do-daemonize: yes
    access-control: 192.168.0.0/8 allow
    access-control: 192.168.1.0/8 allow
    access-control: 127.0.0.1 allow
    chroot: "/var/unbound"
    directory: "/var/unbound"
    pidfile: "/var/run/local_unbound.pid"
    prefetch: yes
python:
remote-control:

 

[Oko]

Typically unbound fails to start on the boot when one of the interfaces it is suppose to listen to is not up. There is something wrong with your configuration file. Do you have really both

192.168.1.0 and 192.168.2.0
up and running? Make sure there is matching interfaces in access-control section. For example on my home network if the interface

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  lladdr 00:02:b3:9d:02:47
  priority: 0
  media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
  status: active
  inet 192.168.3.1 netmask 0xffffff00 broadcast 192.168.3.255

is not up Unbound is going to fail to start. This is the relevant part of unbound.conf

server:
  interface: 127.0.0.1
  interface: 192.168.3.1
  #interface: 127.0.0.1@5353  # listen on alternative port
  interface: ::1
  do-ip6: no
  do-tcp: no

  access-control: 0.0.0.0/0 refuse
  access-control: 127.0.0.0/8 allow
  access-control: 192.168.3.0/24 allow
  access-control: ::0/0 refuse
  access-control: ::1 allow

 

[chrbr]

Not really sure what the 'local' prefix is supposed to mean as no other service seems to have that but I did it anyway.

The local stands for unbound which is part of the base system. This version serves just localhost - if I am not wrong. There is also dns/unbound which can listen not to localhost only. It might help to change the /etc/rc.conf entry to

unbound_enable="YES"

 

[kpa]

I would guess the problem is in the service start up order, local_unbound is assumed to be used only as the local resolver and not as a resolver/forwarder for other networks. Making it listen on other interfaces probably makes the service start up fail when those interfaces/addresses are not yet configured except for lo0 with 127.0.0.1.

 

[Jan-Niklas Meier]

Wow, thanks a lot for the suggestions and explanations. It was indeed the 192.168.1.0 interface that's not being created during boot because it's being brought up by openvpn later. Removing that entry helped for now. I will nevertheless look into changing to the "other" unbound as suggested.
Thanks again!