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 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?
The documentation for keymgr describes the import-bind command as follows:
import-bind BIND_key_file
Imports a BIND-style key into KASP database (converting it to PEM format).
Takes one argument: path to BIND key file (private or public, but both MUST
exist).
What is imported into the KASP exactly? I thought that the KASP database
consisted of public keys alone. This aside, importing a private key will
depend on whether the cryptographic provider supports such an operation -
many HSMs, in particular those with stringent FIPS 140-compliance
requirements, will in general refuse to do so.
So, what does this command do with the private key? Is it turned over to
the cryptographic provider, returning an error if this provider refuses to
import private keys? If such is the case, is the public key still imported
into the KASP, even though there will be no matching private key for it
anywhere in the system?
One can of course use a public key without a matching private key, but in a
DNSSEC software framework like Knot, where the bulk of the activity
consists of carrying out signing operations, the presence of a complete key
pair would seem to be essential.
Hi,
For various reasons I need to write a Go wrapper around knotc conf.
The problem is I am seeing weird behaviour (the below is stdout from my Go script):
########
Command being run: /usr/sbin/knotc conf-begin
OK
Command being run: /usr/sbin/knotc conf-set 'server.version' '299'error: (invalid item) 'server.version' = '299'
Command being run: /usr/sbin/knotc conf-abortOK
########
If I take the "usr/sbin/knotc conf-set 'server.version' '299'" string generated by Go and paste it onto CLI, it returns OK ?
I have tried adding "-v" flag but that does not produce any interesting output.
Any idea where I might be going wrong here ? Why am I getting "error: (invalid item)" when Go executes the command, but not when I run it manually ?
Thanks !
Tha man page for keymgr says that the keymgr generate command
(quote) Generates new DNSSEC key and stores it in KASP database. (unquote)
What is exactly stored in the KASP database?
The reason I am asking is because the actual cryptographic key will be
available in the clear only when using the default key store. When using an
HSM (or event softhsm) only the HSM will have access to the key in the
clear. So, what is it that gets stored in the KASP database when an HSM is
used for generating keys?
