For unbound users: add remote control to your configuration


#1

A lot of users have implemented the unbound solution, described here.
You can add a section to the configuration file ( the example configuration only has a server: section). Add the following lines to tour configuration:

# Remote control config section.
remote-control:
	control-enable: yes

and sudo service unbound stop && sudo service unbound start (sudo service unbound restart also works - it’s a habit)

After this change, you will be able to send instructions to unbound from the command line.
First find unbound-control, the location will depend on the version you have implemented (I’m using the compiled (latest) version of unbound.

sudo find / -name unbound-control

Running unbound-control without any options will give you a list of commands you can use.

A useful command would be sudo /usr/sbin/unbound-control verbosity 1, this to increase the increase the logging level. You could increase the log level to identify a problem.
From the unbound man page:

verbosity: <number>
	The verbosity number, level 0 means no verbosity,  only  errors.
	Level  1  gives  operational information. Level 2 gives detailed
	operational information. Level 3 gives query level  information,
	output  per  query.   Level 4 gives algorithm level information.
	Level 5 logs client identification for cache misses.  Default is
 	level  1.  The verbosity can also be increased from the command-
 	line, see unbound(8).

Don’t forget to decrease the log level, when your done!!!

On systems with a lot of users, stopping and starting unbound has a severe impact on unbound’s performance.

DON’T DO THIS IF YOUR NOT WILLING TO TROUBLESHOOT !!!

There is a way to save / restore the unbound cache.
save: sudo /usr/sbin/unbound-control dump_cache > /etc/unbound/unbound_cache.dmp
restore: sudo /usr/sbin/unbound-control load_cache > /etc/unbound/unbound_cache.dmp

There is even solution to automate this, available in the contrib folder of the latest download. It contains a file unbound_cache.sh
To push saving / restoring the cache to the limit, you could add the following to the service file (/lib/systemd/system/unbound.service):

ExecStartPost=-/etc/unbound/unbound_cache.sh -l /etc/unbound/unbound_cache.dmp
ExecStop=-/etc/unbound/unbound_cache.sh -s /etc/unbound/unbound_cache.dmp

and run sudo systemctl daemon-reload to inform the system about the changes.
The - sign in front of the path is a way to tell systemctl to continue, even if this command would fail. All commands in a service file are executed as root.

For these lines to work, you need to download and extract unbound_cache.sh to /etc/unbound.
Don’t forget to edit unbound_cache.sh, you need to edit the location of CONF and BASE

This might lead to a confusing status message, sudo service unbound status says:

 Active: active (running) since Fri 2018-12-28

but also says:

Process: 1222 ExecStartPost=/etc/unbound/unbound_cache.sh -l /etc/unbound/unbound_cache.dmp (code=exited, status=1/FAILURE)
  • Saving and restoring doesn’t seem to work if you reboot the system.
  • If unbound fails to start after a reboot, just delete the cache file (/etc/unbound/unbound_cache.dmp)

have fun…