Upgrading to 6.0.0 from 5.x.x

Version 6 of Knot Resolver brings one significant change - it introduces Knot Resolver Manager - a new way for interacting with Knot Resolver. The Manager brings several new features:

• new declarative configuration

• HTTP API to change configuration on the fly without downtime

• it hides complexities of running multiple instances of kresd

Now, you might be worried about the future of kresd. No worries, you can use kresd directly the same way you did before, nothing changes there right now. However, in the long run, we might make breaking changes in the way kresd is configured and using it directly is from now on considered advanced.

With the release of version 6, there is a new way to configure and control your running kresd instances so that you don’t have to configure multiple systemd services. The new Knot Resolver Manager handles it for you. In the table below, you can find comparison of how things were done before and how they can be done now.

Command rosetta

In the table below, you can compare the way Knot Resolver was used before and how it can be used now.

Task	How to do it now	How it was done before
start resolver	systemctl start knot-resolver	systemctl start kresd@1
stop resolver	systemctl stop knot-resolver	systemctl stop kresd@1
start resolver with 4 worker processes	set /workers to 4 in the config file	manually start 4 services by systemctl start kresd@{1,2,3,4}
rolling restart after updating config	systemctl reload knot-resolver (or use API or kresctl)	manually restart individual kresd@ services one by one
open logs of all instances	journalctl -u knot-resolver	journalctl -u system-kresd.slice
open log of a single kresd instances	journalctl -u knot-resolver _PID=xxx	journalctl -u kresd@1
updating config programatically	use HTTP API or kresctl command	write a custom tool to generate new config and restart kresd’s
handling errors during config changes	HTTP API just reports error, resolver keeps running with previous config	custom tools for every user
validate new config	kresctl validate path/to/new/config.yaml (not fully bullet proof), then try to run it	run kresd with the config and see if it fails
look at the Lua config	kresctl convert path/to/new/config.yaml	cat /path/to/config.conf
gather metrics	point Prometheus etc. at the single HTTP API	collect metrics manually from all individual processes