New Install Not Functioning

[LazerDickMcCheese]

The service is failing to start.

root@DietPi:~# sudo service unbound restart Job for unbound.service failed because the control process exited with error code. See "systemctl status unbound.service" and "journalctl -xe" for details. root@DietPi:~# systemctl status unbound.service ● unbound.service - Unbound DNS server Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/unbound.service.d └─dietpi.conf Active: failed (Result: exit-code) since Sat 2023-08-12 19:14:21 BST; 17s ago Docs: man:unbound(8) Process: 6870 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS) Process: 6873 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS) Process: 6876 ExecStart=/usr/sbin/unbound -d -p $DAEMON_OPTS (code=exited, status=1/FAILURE) Process: 6877 ExecStopPost=/usr/lib/unbound/package-helper chroot_teardown (code=exited, status=0/SUCCESS) Main PID: 6876 (code=exited, status=1/FAILURE) CPU: 170ms

Aug 12 19:14:21 DietPi systemd[1]: unbound.service: Scheduled restart job, restart counter is at 5. Aug 12 19:14:21 DietPi systemd[1]: Stopped Unbound DNS server. Aug 12 19:14:21 DietPi systemd[1]: unbound.service: Start request repeated too quickly. Aug 12 19:14:21 DietPi systemd[1]: unbound.service: Failed with result 'exit-code'. Aug 12 19:14:21 DietPi systemd[1]: Failed to start Unbound DNS server.

To reproduce Steps to reproduce the behavior:

1. Delete any old installation Unbound, as it was non-functioning
2. Reinstall Unbound

Expected behavior A clear and concise description of what you expected to happen.

1. sudo apt install unbound
2. unbound.works=true

System:

• Unbound version: 1.13.1
• OS: DietPi v8.20.1
• unbound -V output: root@DietPi:~# unbound -V Version 1.13.1

Configure line: --build=aarch64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/aarch64-linux-gnu --libexecdir=${prefix}/lib/aarch64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --disable-rpath --with-pidfile=/run/unbound.pid --with-rootkey-file=/var/lib/unbound/root.key --with-libevent --with-pythonmodule --enable-subnet --enable-dnstap --enable-systemd --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --libdir=/usr/lib --disable-flto Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 1.1.1n 15 Mar 2022 Linked modules: dns64 python subnetcache respip validator iterator

BSD licensed, see LICENSE in source package for details. Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues

Additional information I was following the Unbound guide from pi-hole.net, but had to stop after the first step. I have no idea how to troubleshoot anything related to Linux.

[metablaster]

I'm having exact same problem restarting unbound when my config file has the line:

auto-trust-anchor-file: "/usr/share/dns/root.key"

If I remove the line restarting unbound works fine.

[gthess]

@LazerDickMcCheese,

Process: 6876 ExecStart=/usr/sbin/unbound -d -p $DAEMON_OPTS (code=exited, status=1/FAILURE)

This means Unbound itself exited with a failure. You can check the logfile to see what the complain is about.

@metablaster, By removing that line you disable DNSSEC, if you were also following an installation guide, make sure that you didn't miss a step.

[metablaster]

@metablaster, By removing that line you disable DNSSEC, if you were also following an installation guide, make sure that you didn't miss a step.

I followed this guide

Here is the default location:

sudo unbound-anchor -vvv

/usr/share/dns/root.key has content
success: the anchor is ok

My config file has the line:

auto-trust-anchor-file: "/usr/share/dns/root.key"

I've run:

sudo unbound-anchor

And also:

sudo unbound-anchor -a /usr/share/dns/root.key

To reproduce the problem I restart service:

sudo systemctl restart unbound

job for unbound.service failed because the control process exited with error code.
See "systemctl status unbound.service" and "journalctl -xeu unbound.service" for details.

And here is what the log says:

error: trust anchor presented twice unbound: [2866:0] error: could not parse auto-trust-anchor-file /var/lib/unbound/root.key line 2 unbound: [2866:0] error: error reading auto-trust-anchor-file: /var/lib/unbound/root.key unbound: [2866:0] error: validator: error in trustanchors config unbound: [2866:0] error: validator: could not apply configuration settings.

There is another trust anchor file located in:

ls /var/lib/unbound/root.key

/var/lib/unbound/root.key

If I set this one in config file instead the error is same.

I'm not sure how to continue to troubleshoot this, any suggestions?

[metablaster]

I figured out what's the problem in my case.

I copied the contents of my config file which were located in /etc/unbound/unbound.conf.d/unbound.conf and pasted into /etc/unbound/unbound.conf

I also removed the line which says include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"

I didn't change anything else and followed the same steps from my post above and it immediately started to work!

The solution is from here: https://github.com/NLnetLabs/unbound/issues/160

It's funny how you guys close the issue and but don't fix the problem. Obviously this is not distro problem because unbound:

1. fails to include additional files as expected.
2. does not parse the contents of the file as specified in the config file
3. prints out errors that are misleading

[gthess]

It's funny how you guys close the issue and but don't fix the problem.

I could understand the frustration but that part was not necessary.

1. Unbound did include the file as expected.
2. Unbound did parse the contents as specified.
3. The error print out points where the error is.

What may have happened is that auto-trust-anchor-file, or another trust option that set ups a trust anchor, is part of the other configuration files; I would guess the main one or the one installed by the system in /etc/unbound/unbound.conf.d/*.conf. When Unbound is done parsing the configuration files it tries to parse the trust anchors where it finds 2 for the same domain, in this case .. That could be an improvement of the log output; printing the anchor's domain name.

In your case I understand that all this is happening on a system with a packaged Unbound installed. I would leave the system configuration intact (with the includes and the included files) because probably there are a lot of supporting scripts and files around that for the distribution. I would then add any extra configuration on the main file after the includes (less favorable since updating Unbound from the system packages would overwrite or complain about the changed contents there), or introduce a new configuration file in the /etc/unbound/unbound.conf.d/ directory as it seems you did in the first place. But again with respecting whatever options are there from the system already.

[metablaster]

I could understand the frustration but that part was not necessary.

Sorry for the other part, yes it's very frustrating when things don't work the way you configure them.

What may have happened is that auto-trust-anchor-file, or another trust option that set ups a trust anchor, is part of the other configuration files; I would guess the main one or the one installed by the system in /etc/unbound/unbound.conf.d/*.conf

Thank you, this information helps to know what's the problem and I can confirm this is true, I took a look into /etc/unbound/unbound.conf.d and noticed there is a file called root-auto-trust-anchor-file.conf The content of this file is: auto-trust-anchor-file: "/var/lib/unbound/root.key"

Which is different from what sudo unbound-anchor -vvv reported as default, that is /usr/share/dns/root.key which is what I've set up in my config file thus resulting in 2 anchor files being pulled in.

From user's perspective therefore sudo unbound-anchor -vvv should have reported this case, or at least the docs should point out the possibility of this and explain how to troubleshoot this specific case.

[kellyling80]

Putting this here for others to reference. Tested on: Raspberry Pi OS lite 6.6.x; Unbound v1.17.1 default Debian package;Default config

There is already a root-auto-trust-anchor-file.conf file in/etc/unbound/unbound.conf.d/ which contains the line . "auto-trust-anchor-file: "/var/lib/unbound/root.key" .Therefore, by default, you don't have to add this into your unbound.conf file.