[Pkg-dns-devel] Bug#857578: Bug#857578: knot-resolver: The package should not override blindly the config of trust anchors

[Daniel Kahn Gillmor]

On Sun 2017-03-12 16:45:40 -0400, Stephane Bortzmeyer wrote:
> I tried an alternative root and therefore set up trust_anchors.config
> to use the key of this alternative root.
>
> But, by default, the daemon is launched with
> --keyfile=/usr/share/dns/root.key and therefore uses the IANA key ->
> SERVFAIL
>
> I edited /etc/default/kresd, and fixed the problem, but I do not see
> why there are two configuration files, /etc/knot-resolver/kresd.conf
> and /etc/default/kresd. IMHO, the choices made by the sysadmin in
> /etc/knot-resolver/kresd.conf should be respected.

fwiw, i agree with Stephane here, and would actually take it further: i
think it would be great to strip down both /etc/default/kresd and
/etc/knot-resolver/kresd.conf to the point where we don't ship either of
them in the package.

This would result in a kresd that has no default configuration file,
since it is run from /run/knot-resolver/cache and so looks for
/run/knot-resolver/cache/config for its configuration file, which won't
exist because it was created by /usr/lib/tmpfiles.d/kresd.conf.

On systems managed by systemd, the local admin can use "systemctl edit
kresd.service" to override the ExecStart= directive in the [Service]
stanza to point to some preferred configuration with --config, or
override the WorkingDirectory= directive to point to both a preferred
configuration and a stable/persistent cache.  We could add documentation
explaining this approach in README.Debian if it's considered too obscure
at the moment.

That would leave the default knot-resolver package with only
/etc/knot-resolver/icann-ca.pem and /etc/init.d/kresd as configfiles.

I'd argue that we should be shipping icann-ca.pem in some other more
stable (non-config) location (and possibly not in this particular
package) since it's likely to be useful for other system processes too.
And i'd be happy to see /etc/init.d/kresd moved into a
knot-resolver-sysvinit package for those who want to see it run under
that system manager.  (by analogy, a knot-resolver-runit package for
those who want to see it run under runit would also be nice-to-have)

This configfile cleanup would still leave us with Stephane's open
question about how to choose the default trust anchors, and how to
override them.

Note that there are different behaviors for handling the trust anchors
in "managed" or "unmanaged" mode, e.g.:

   https://gitlab.labs.nic.cz/knot/resolver/merge_requests/134

By default, i think kresd bootstraps trust anchors from IANA over the
network.  Including --keyfile=/usr/share/dns/root.key explicitly in the
service handles things but it also breaks configurations like
Stephane's.

I've just opened an upstream report about improving that here:

   https://gitlab.labs.nic.cz/knot/resolver/issues/168

        --dkg


PS other possible approaches to having a well-known "default
configuration" location for systemd-managed systems:

tmpfiles
--------

We could add a line to /usr/lib/tmpfiles.d/kresd.conf to make it copy
the system configuration at machine startup:

   C /run/knot-resolver/cache/config - - - - /etc/knot-resolver/kresd.conf

but this would hvae the unpleasant property of any edits to
/etc/knot-resolver/kresd.conf not taking effect until system reboot.


ExecStart etc.
--------------

Alternately, we could add an explicit directive to kresd.service:

   ExecStartPre=/bin/cp /etc/knot-resolver/kresd.conf /run/knot-resolver/cache/config

that would at least transfer a stable config at service start.

We might want to figure out how to set up an ExecReload as well if
we want that to work.

But this starts to feel like a lot of heavy machinery, when the default
service should Just Work and it'd be nice that case be simple.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-dns-devel/attachments/20170313/5864f133/attachment.sig>