Hi,
We're new in the dnssec field, and we hope we understand the basics,
also thanks to the much appreciated help received through this list and
through searching it's archives, thanks again!
We would like to ask two more short questions, but first a we will
explain how we currently understand things.
Our dns domain is sub.company.com, and we will activate DNSSEC somewhere
next week, by doing:
- enable dnssec for the zone / reverse zone in knot.conf
- restart knot
- display the generated dnssec keys, using:
> keymgr sub.company.com dnskey
> keymgr sub.company.com ds
(plus the reverse)
- send the outputs of the above to the admins at company.com
- after they have entered the keys in their dns, the world can check &
verify our dnssec, and things are operational.
- verify everything at https://dnssec-analyzer.verisignlabs.com/
Now the two questions.
We have set in knot.conf:
zsk-lifetime: 30d
ksk-lifetime: 365d
We understand that with the above config, monthly zsk key rollovers
happen automatically "inside" knot, but the yearly rollover (ksk) needs
to be manually propagated by us to the parent dns. (through for example
secured email to the admins at company.com)
Question one:
Is there some kind of notification mechanism in knot, that reminds us
(through email for example) that a ksk is about to expire, and keys need
to be renewed at company.com dns? I cannot find such a function. Does it
not exist? Or do we misunderstand something? It seems to be so vital.
Question two:
How unreasonable/insecure would it be to take a longer ksk lifetime than
one year, let's say 10 years. With the idea that we can always manually
renew keys earlier, in case we need to.
Feedback on the above is welcome. We have scheduled a maintenance moment
next week with the admins on company.com to send them the keys and
activate dnssec.
Thanks in advance for any feedback/pointers you can provide.
Best regards,
MJ
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.
