I notice that knot 3.1 does not support EdDSA (22519 and 448) when using
softhsm as a PKCS #11 backend. Since this is supported by knot when using
the default cryptographic provider, and also by gnutls 3.6.0 (at least for
the 25519 version) for release 3.6.0 and later, my guess is that this a
limitation in softhsm itself. Could anybody in this forum with the
necessary savvy please confirm (or not) this?
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
}
The whole thing happens when I start kresd with "systemctl start kresd @ 1"?
when I start kresd -v on the command line I don't see any errors but I don't
know if he is using the "/etc/knot-resolver/kresd.conf"?
--
mit freundlichen Grüßen / best regards
Günther J. Niederwimmer
When Knot generates a key pair, it will save it in some directory in the
filesystem - in the clear, when using the default cryptographic provider,
or as an encrypted blob when using SoftHSM, or (possibly) a real HSM.
Imagine that I have a setup with many zones, with a signing policy that
causes them to be re-signed often - say, every hour or so. This implies
that new key pairs will be generated all the time.
My question is, how does Knot manage key pairs that it does not need any
more? It does not seem to remove them automatically. Does it provide any
mechanisms or tools to do so?
I have been looking into the key pre-generation capability of keymgr, and
the following question has come up:
Imagine I pre-generate, say, one month's worth of keys for a given zone.
This zone is defined so that it will be signed automatically on bringing up
the Knot server. Next I start the Knot server. What criteria are used in
order to select the keys, among the pre-generated ones, to be used to sign
this zone?
The reason I am asking is because I pre-generated two years worth of keys
for a particular zone, and when I started the Knot server it took a
significant amount of time selecting the appropriate keys from among the
pre-generated ones.
I am working on a Knot deployment that uses Nitrokey HSM[1] as a PKCS11 platform.
As you might imagine, for a small USB device, the Nitrokey is not exactly the most performant HSM in the world.
My configuration works great with one or two test zones. But when I start ramping up the number of zones, I start seeing weird problems with Knot (e.g. " blocked zone update due to open control transaction" errors ... which don't seem to be errors because my code debug shows the "zone-commit" being run, but it still leaves the Knot database in a weird corrupt state where I cannot even "conf-unset" a domain even if it is clearly existing in "conf-read").
Looking around the internet, it seems "OpenSC use_file_caching " might be the answer[2]. Does Knot support this ?
[1] https://www.nitrokey.com/files/doc/Nitrokey_HSM_factsheet.pdf
[2]https://support.nitrokey.com/t/slow-initialization-of-nitrokey-hsm/2906/6
Hello list,
I am a newbie
I have a problem with KNOT or I don't understand Knot?
What do I have to configure so that knot also dissolves my internal zones?
My config for the zones
# Internal zone
- domain: 4gjn.com.lan
# notify: secondary
file: "/var/lib/knot/zones/4gjn.com.lan.zone"
dnssec-signing: off
zonefile-sync: -1
zonefile-load: difference
journal-content: changes
# master: primary1
# acl: update_acl
# Master zone
- domain: 100.168.192.in-addr.arpa
# notify: secondary
file: "/var/lib/knot/zones/100.168.192.in-addr.arpa.zone"
zonefile-sync: -1
zonefile-load: difference
journal-content: changes
dnssec-signing: off
# master: primary
# acl: acl_secondary
with khost I have this answer on the knot-server
khost 192.168.100.204
204.100.168.192.in-addr.arpa. points to ipa.4gjn.com.lan.
khost ipa.4gjn.com.lan
ipa.4gjn.com.lan. has IPv4 address 192.168.100.204
But with host do I get the answer back?
host 192.168.100.204
Host 204.100.168.192.in-addr.arpa. not found: 3 (NXDOMAIN)
host ipa.4gjn.com.lan
Host ipa.4gjn.com.lan not found: 3 (NXDOMAIN)
is that correct or do I have an error?
ping seems to work
ping ipa.4gjn.com.lan
PING ipa.4gjn.com.lan (192.168.100.204) 56 (84) bytes of data.
Thanks for an answer,
--
mit freundlichen Grüßen / best regards
Günther J. Niederwimmer
Any ideas what might be causing the following error ?
knotc (Knot DNS), version 3.1.0
$ sudo /usr/sbin/knotc zone-backup -- +backupdir /home/foo/test
error: (operation not permitted)
The destination directory exits. It doesn't matter if I run the command as root or knot user, the error is the same.
According to the documentation, one can back up the KASP using the mdb_dump
command. Now I understand things correctly, this will just back up the
public component of key pairs, plus some metadata for the zones the public
keys are associated with.
Are there any provisions in Knot concerning the backing up of the private
components of key pairs, or is this something that must be done separately
and within the context of whatever cryptographic provider is used?
