I am evaluating version 2.9.5 of Knot, in particular in what concerns key management. This examination has resulted in the following issues/questions, which I would like to bring up to this forum for discussion/clarification:
1. I have been testing with the default Knot out-of-the-box setup, with the following knot.conf file:
server:
listen: [10.0.0.1 ]
log:
- target: syslog
any: info
template:
- id: default
global-module: mod-stats
mod-stats:
- id: default
policy:
- id: RSAPol
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 1024
zone:
- domain: s0.mydomain.com
storage: /var/lib/MyZones/db
file: db.s0
dnssec-signing: on
dnssec-policy: RSAPol
On launching Knot, this works as expected:
- The necessary key pairs are generated and stored in /var/lib/knot/keys in the clear, with files data.db and lock.db created in /var/lib/knot.
- The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db.
2. I next tried with SoftHSM for the low-level cryptographic support. The knot.conf file is the same as above, with the following changes:
- I added a keystore section:
keystore:
- id: SoftHSM
backend: pkcs11
config: "pkcs11:token=KNOT;pin-value=112233 libsofthsm2.so"
- I modified the zone section to use SoftHSM:
zone:
- domain: s0.mydomain.com
storage: /var/lib/MyZones/db
file: db.s0
dnssec-signing: on
dnssec-policy: RSAPol
keystore: SoftHMS
Before proceeding, I removed everything from /var/lib/knot. On launching knot again, this is what happens:
- data.db and lock.db are created under /var/lib/knot, but no key pairs are created under /var/lib/knot/keys.
- Key pairs are created under /var/lib/softhsm/tokens/adf76cd6-5411-843e-6036-b8523580ef94.
- The appropriate zone is signed, with the file containing the signed data under /var/lib/MyZones/db.
This is all pretty much as expected, in that the signing keys have been generated in the space set aside by SoftHSM, and the signatures have been computed by the SoftHSM module.
Now what I was wondering is whether keymgr can be used to manage keys in SofHSM? By default, it would seem to be the case that whenever I generate a key pair with keymgr, the key pair is stored under /var/lib/knot/keys, in the clear. Nothing seems to change under /var/lib/softhsm/tokens as a result of such a keymgr command. This is the case no matter what version of the knot.conf files described above I use.
Here is my question:
Is keymgr capable of managing keys in some separate device - SoftHSM, or a real, hardware HSM - or is it limited to keys generated by the default mechanism, with no HSM?
I notice that in previous versions of Knot, the keymgr utility supported options to use different keystores. Such options seem to be gone from keymgr as distributed with Knot 2.9.5. Can anybody elaborate on why they were removed, and whether some other utility is provided to achieve the same goals?
Ultimately, what I am interested in is to have all of my keys so that they are available to the HSM alone, and I want to find out what tools does Knot provide - if any - to manage those keys, bearing in mind that they will have to be protected in permanent storage until such time that they are meant to be loaded into the HSM to be used. This is crucial, for most HSMs won't keep any keys across power cycles, and even when they do, they number that they can keep will in general be too small for my needs.
Hi Chris,
first of all, you seem to be talking about Knot DNS, so it's proper to
switch to correct mailing list, instead of Knot Resolver's one.
I assume you have read all the single-version migration guides below
https://www.knot-dns.cz/docs/3.0/singlehtml/index.html#upgrade-2-6-x-to-2-7…
. It's clear that when migrating over multiple versions, you need to
take care about all the notes at once.
What databases exactly are you talking about? Knot DNS uses multiple
databases for different purposes, e.g. journal or KASP DB. The good news
is, their format does not change much, and when it does, it's usually
backwards-compatible, with some exceptions.
I would strongly recommend that you clone your environment, perform the
migration in some "playground" setup first, and observe if everything
went well; all before migration your production setup ;) Should you
encounter any issues, please contact us on our mailing-list.
Anyway, you might consider a multi-step migration, so that you would
migrate by just one (major) version at once, like this: 2.6.5 -> 2.7.8
-> 2.8.5 -> 2.9.9 -> 3.0.5.
Thanks!
Libor
Dne 09. 04. 21 v 8:13 Daniel Salzman napsal(a):
>
>
> -------- Forwarded Message --------
> Subject: [knot-resolver-users] Any "gothcas" going from 2.65 to 3.04 I should know about?
> Date: Thu, 08 Apr 2021 23:03:54 -0700
> From: Chris <knot(a)tacomawireless.net>
> Reply-To: Knot Resolver Users List <knot-resolver-users(a)lists.nic.cz>
> To: knot-resolver-users <knot-resolver-users(a)lists.nic.cz>
>
> Hi. Moving a couple of our servers to new hardware, and
> taking that opportunity to upgrade some of the services
> at the same time. The main one being knot. Moving from
> a 2.65 context to 3.04. I've read the upgrade doc, and
> while there isn't a 2.65 --> 3.04. It appears for our
> environment that the changed/removed stanzas won't
> have much of an impact *except* as they relate to the
> database. That is; it appears that it isn't going to
> be a smooth transition, as they appear to be incompatible.
> Is that right? Do I need to rewrite all the keys &&
> serials, and start from scratch? If so, as we have
> a huge number of domains, this will be an enormous task.
> Is this avoidable?
>
> Thank you for any and all insight into this transition.
>
> --Chris
Is there a way to configure Knot to avoid overwriting a zone file when
it's doing automatic signing?
I was hoping some combination of zonefile-load and journal-content
would tell Knot to store its internally managed data in the journal
instead of in the zone file, but I haven't found that combination. I
don't see any other likely candidates in the config options, but
hoping I've missed something...