24 Zář
2021
24 Zář
'21
15:43
Hello List,
I would like to install KNOT-resolver, first test it with DNS over TLS, but
that doesn't work?
My system is an oracle Linux 8.4
I have a Letsencrypt certificate for this system and wanted to integrate it
into kresd, but I get a GNUTLS error?
Sep 22 18:27:30 bbs kresd[446005]: [tls ]
gnutls_certificate_set_x509_key_file(/etc/letsencrypt/live/bbs.xxxx.xxxx/
fullchain_ecdsa.pem,/etc/pki/private/xxxx.xxxx_ec.key) failed: -64
(GNUTLS_E_FILE_ERROR)
Sep 22 18:27:30 bbs kresd[446005]: [system] error while loading config: error
occurred here (config filename:lineno is at the bottom, if config is
involved):#012stack traceback:#012#011[C]: in function 'tls'#012#011/etc/knot-
resolver/kresd.conf:24: in main chunk#012ERROR: Invalid argument (workdir '/
var/lib/knot-resolver')
Sep 22 18:27:30 bbs systemd[1]: kresd(a)1.serbice.service: Main process exited,
code=exited, status=1/FAILURE
Does this not work with a Letsenkrypt certificate or I have another error in
my configuration
My config
-- SPDX-License-Identifier: CC0-1.0
-- vim:syntax=lua:set ts=4 sw=4:
-- Refer to manual: https://knot-resolver.readthedocs.org/en/stable/
-- Uncomment this only if you need to debug problems
-- verbose(true)
log_level('debug')
-- Network interface configuration
net.listen('127.0.0.1', 53, { kind = 'dns' })
net.listen('127.0.0.1', 853, { kind = 'tls' })
--net.listen('127.0.0.1', 443, { kind = 'doh2' })
net.listen('::1', 53, { kind = 'dns', freebind = true })
net.listen('::1', 853, { kind = 'tls', freebind = true })
--net.listen('::1', 443, { kind = 'doh2' })
net.listen('xxx.xxx.xxx.1', 53, { kind = 'dns' })
net.listen('xxx.xxx.xxx.1', 853, { kind = 'tls' })
net.listen('192.168.100.200', 53, { kind = 'dns' })
net.listen('192.168.100.200', 853, { kind = 'tls' })
net.listen('xxx:xxxx:xxxx:xxx::200', 53, { kind = 'dns' })
net.listen('xxx:xxxx:xxxx:xxx::200', 853, { kind = 'tls' })
-- DNS over TLS
net.tls("/etc/letsencrypt/live/bbs.xxxx.xxx/fullchain_ecdsa.pem",
"/etc/pki/
tls/private/xxxx.xxx_ec.key")
-- Load useful modules
modules = {
'hints > iterate', -- Load /etc/hosts and allow custom root hints
'stats', -- Track internal statistics
'predict', -- Prefetch expiring/frequent records
}
I heard / read from a user that knot resolver must have its own rights for the
certificate, but that is not possible, because the key is also intended for
other computers and this creates a system risk? Is this a design problem or a
bug?
Thanks for an answer,
--
mit freundlichen Grüßen / best regards
Günther J. Niederwimmer
24 Zář
24 Zář
16:03
On 24/09/2021 15.43, Günther J. Niederwimmer wrote:
I heard / read from a user that knot resolver must
have its own rights for the
certificate, but that is not possible, because the key is also intended for
other computers and this creates a system risk? Is this a design problem or a
bug?
I would not suggest that the private keys should be world-readable.
Normal installation uses a special user and group for running Knot
Resolver, so you might e.g. switch the file to this group.
Running the daemons as root would seem a higher risk to me, but
otherwise it shouldn't be a problem either. Of course, you can't change
that in kresd.conf, as that's done on systemd level already. I think it
should suffice to use `systemctl edit kresd@.service` and add
[Service]
User=root
Group=root
and the same with `systemctl edit kres-cache-gc.service`.
--Vladimir
18:57
Hello Vladimir,
Am Freitag, 24. September 2021, 16:03:21 CEST schrieb Vladimír Čunát:
On 24/09/2021 15.43, Günther J. Niederwimmer wrote:
I heard / read from a user that knot resolver
must have its own rights for
the certificate, but that is not possible, because the key is also
intended for other computers and this creates a system risk? Is this a
design problem or a bug?
I would not suggest that the private keys should be world-readable.
Normal installation uses a special user and group for running Knot
Resolver, so you might e.g. switch the file to this group.
Running the daemons as root would seem a higher risk to me, but
otherwise it shouldn't be a problem either. Of course, you can't change
that in kresd.conf, as that's done on systemd level already. I think it
should suffice to use `systemctl edit kresd@.service` and add [Service]
User=root
Group=root
and the same with `systemctl edit kres-cache-gc.service`.
Unfortunately, that doesn't work that way? I then get error messages for the
paths and files in paths (permission denied)?
Apparently something is still being coded somewhere in the files? Since I get
Lua errors
I am not a programmer, just a user, so I will not use "DNS over TLS" now and
try to use the knot-resolver sensibly to work!
--
mit freundlichen Grüßen / best regards
Günther J. Niederwimmer
20:08
On 2021-09-24 09:57, Günther J. Niederwimmer wrote:
Hello Vladimir,
Am Freitag, 24. September 2021, 16:03:21 CEST schrieb Vladimír Čunát:
I think what you need to do here, is
ensure that:
1) after adding the service Group && Name entries
2) ensure that the knot-resolver (kresd) working directory is owned by root
*as well as its contents* --
# cd /knot-resolver/working/directoy
# sudo chown -Rh root .
3) restart the knot-resolver service
HTH
--Chris
On 24/09/2021 15.43, Günther J. Niederwimmer
wrote:
I heard / read from a user that knot resolver
must have its own rights for
the certificate, but that is not possible, because the key is also
intended for other computers and this creates a system risk? Is this a
design problem or a bug?
I would not suggest that the private keys should be world-readable.
Normal installation uses a special user and group for running Knot
Resolver, so you might e.g. switch the file to this group.
Running the daemons as root would seem a higher risk to me, but
otherwise it shouldn't be a problem either. Of course, you can't change
that in kresd.conf, as that's done on systemd level already. I think it
should suffice to use `systemctl edit kresd@.service` and add [Service]
User=root
Group=root
and the same with `systemctl edit kres-cache-gc.service`.
Unfortunately, that doesn't work that way? I then get error messages for the
paths and files in paths (permission denied)?
Apparently something is still being coded somewhere in the files? Since I
get
Lua errors
I am not a programmer, just a user, so I will not use "DNS over TLS" now and
try to use the knot-resolver sensibly to work!
--
mit freundlichen Grüßen / best regards
Günther J. Niederwimmer
26 Zář
26 Zář
10:47
For the record, I recalled that /etc/tmpfiles.d/knot-resolver.conf would
be another place to modify.
This would've been much easier with
https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1056
as the ownership changes would happen automatically and tmpfiles
wouldn't be needed. (Unfortunately, as stated there, some distributions
don't have sufficiently new systemd, so overall it would generally be
more trouble than worth so far - perhaps in a few years.)
--Vladimir
1183
days inactive
1185
days old
knot-resolver-users@lists.nic.cz
4 comments
3 participants
participants (3)
-
Chris -
Günther J. Niederwimmer -
Vladimír Čunát