Hi,
my knot installation (3.0.5) gives me this notice:
notice: config, non-default 'template[default].storage' detected, please
configure also 'db.storage' to avoid compatibility issues with future
versions
I have searched the docs to find out what I have to do, but did not find
any specific information. Can you give me a hint what needs to be done here?
Thanks a lot,
Thomas
The documentation for `keymgr' says that the subcommand `del-all-old' is
related to offline KSK, but it also seems to work for online KSK.
Moments ago I had the following keys of which e381* had just been marked as
removed:
$ keymgr -c knot.conf tm list -b iso
e381198aea254a1dbceb3c5b153cbefaa98c959a 31943 KSK ECDSAP256SHA256 publish=2022-05-12T11:43:56Z ready=2022-05-12T11:43:56Z active=2022-05-12T11:43:56Z retire=2022-05-12T12:35:42Z revoke=2022-05-12T12:33:42Z remove=2022-05-12T12:37:42Z
d68e6803daa3e3ee34dd07d6966df0c402594fb2 26288 ZSK ECDSAP256SHA256 publish=2022-05-12T12:28:18Z active=2022-05-12T12:28:18Z
b0cc879e9b9f5faae647c7019a12821e62150378 62610 KSK ECDSAP256SHA256 publish=2022-05-12T12:30:49Z ready=2022-05-12T12:30:49Z active=2022-05-12T12:30:49Z
$ keymgr -c knot.conf tm del-all-old
OK
$ keymgr -c knot.conf tm list -b iso
d68e6803daa3e3ee34dd07d6966df0c402594fb2 26288 ZSK ECDSAP256SHA256 publish=2022-05-12T12:28:18Z active=2022-05-12T12:28:18Z
b0cc879e9b9f5faae647c7019a12821e62150378 62610 KSK ECDSAP256SHA256 publish=2022-05-12T12:30:49Z ready=2022-05-12T12:30:49Z active=2022-05-12T12:30:49Z
and the PEM key file has also been removed.
Is this to be expected? Would it be a good idea to add a note to the
documentation clarifying this?
Best regards,
-JP
Hello,
I'd like to be able to do automatic ZSK and manual KSK rollovers. Basically the
KSK should have an endless validity but I might want to roll it with
(manually-trigerred) RFC 5011 semantics.
It it permissible to have a policy such as shown below and then explicitly
use `keymgr' commands to generate new keys and set `revoke', `retire' and
`remove' timers on the older key?
Testing indicates that it works as desired, I'm just unsure whether key
manipulation is permitted.
policy:
- id: autoHSM
keystore: pemstore
single-type-signing: off
manual: off
ksk-shared: off
ksk-lifetime: 0
zsk-lifetime: 30d
cds-cdnskey-publish: rollover
Thank you,
-JP
Hello,
keymgr(8) lists keys in plain text which is fine for processing with awk(1)
et.al. Are there any plans to make it output JSON? I'm thinking along the lines
of making parsing future-proof:
[
{
"id": "a982d72174a48a3ef083a97e5aae02cc47f58762",
"ksk": true,
"zsk": false,
"key_tag": 61676,
"algo": 8,
"size": 2048,
"public-only": false,
"pre-active": 0,
"publish": 1652161461,
"ready": 1652161581,
"active": 1652161642,
"retire-active": 1652168902,
"retire": 0,
"post-active": 0,
"revoke": 0,
"remove": 1652168962
}
]
keymgr_list_keys() calls either of print_key_full() / print_key_brief() to do
the work, and I think it would be quite easy to add support for JSON.
Is this something I should make happen?
-JP
Hello,
I need to migrate away from an HSM-backed OpenDNSSEC installation which uses a
Thales nCipher for key storage and am experimenting with Knot DNS 3.1.8 (on
CentOS 7, FWIW).
I've compiled Knot, and it is able to access said HSM via PKCS#11. I have
configured a zone with a manual policy.
policy:
- id: manualHSM
keystore: thales
single-type-signing: on
manual: on
After importing keys from the HSM with `keymgr import-kcs11', knotd launches
and signs the zone with KSK/ZSK as expected.
What I would then like to have happen is to have periodic ZSK rollovers as well
as periodic KSK rollovers. In order to accomplish this I have changed the
zone's policy to
policy:
- id: autoHSM
keystore: thales
single-type-signing: off
manual: off
algorithm: rsasha256
ksk-size: 2048
zsk-size: 1024
zone-max-ttl: 60
dnskey-ttl: 60
propagation-delay: 60
nsec3: on
nsec3-iterations: 0
nsec3-salt-length: 0
nsec3-salt-lifetime: 0
ksk-lifetime: 7200
zsk-lifetime: 3600
A restart of knotd then begins by creating a new ZSK and rolling it, and the
KSK is rolled automatically after 7200 seconds. (These timers are for testing
only.)
So far no complaints whatsoever -- this is working exactly as I had hoped it
would. I am assuming that it is permissible to change a zone's policy in flight.
What I'd like is confirmation that the KSK roll will actually never occur
immediately, but only after a first period has elapsed.
Can I rely on this behavior, i.e. that the first KSK roll will occur only after
a first `ksk-lifetime' period?
Best regards,
-JP
Hi,
for the transition of a TLD I need to import the current providers KSK
into my zone. I use the "keymgr import-pub" command for this. I have
done that a few times in the past and it worked very well.
I have now installed the most current version of Knot (3.0.10) and did
the same procedure. But after importing the KSK the zone can't be signed
anymore. It seems like Knot doesn't recognize that this imported key is
a "public-only" key. Knot throws an error and complains that the private
key could not be loaded.
The zone's keys (.example) before the import of the KSK:
# keymgr example list
0b94a3f9fef3ae531fc5ee1334ddd2876db7cd9a ksk=yes zsk=no tag=12595
algorithm=7 size=2048 public-only=no pre-active=0 publish=1650495677
ready=1650495677 active=1650659051 retire-active=0 retire=0
post-active=0 revoke=0 remove=0
13cc082655ddf7160787ef945ad7edb6406bb70e ksk=no zsk=yes tag=05477
algorithm=7 size=1024 public-only=no pre-active=0 publish=1650495677
ready=0 active=1650495677 retire-active=0 retire=0 post-active=0
revoke=0 remove=0
Imported the KSK with the following command:
# keymgr example import-pub /etc/knot/public.key
2c135e77b7f48475a837ad0d28a9459f0e7ce621
OK
The zone's keys (.example) after the import of the KSK:
# keymgr example list
0b94a3f9fef3ae531fc5ee1334ddd2876db7cd9a ksk=yes zsk=no tag=12595
algorithm=7 size=2048 public-only=no pre-active=0 publish=1650495677
ready=1650495677 active=1650659051 retire-active=0 retire=0
post-active=0 revoke=0 remove=0
13cc082655ddf7160787ef945ad7edb6406bb70e ksk=no zsk=yes tag=05477
algorithm=7 size=1024 public-only=no pre-active=0 publish=1650495677
ready=0 active=1650495677 retire-active=0 retire=0 post-active=0
revoke=0 remove=0
2c135e77b7f48475a837ad0d28a9459f0e7ce621 ksk=yes zsk=no tag=35421
algorithm=7 size=2048 public-only=yes pre-active=0 publish=1650660072
ready=0 active=0 retire-active=0 retire=0 post-active=0 revoke=0 remove=0
The imported key (tag 35421) has the flag "public-only=yes", as expected.
But when I now sign the zone, the log shows this errors:
Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] control, received
command 'zone-sign'
Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] DNSSEC, dropping
previous signatures, re-signing zone
Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] DNSSEC, key, tag
12595, algorithm RSASHA1_NSEC3_SHA1, KSK, public, active
Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] DNSSEC, key, tag
35421, algorithm RSASHA1_NSEC3_SHA1, KSK, public, active+
Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] DNSSEC, key, tag
5477, algorithm RSASHA1_NSEC3_SHA1, public, active
Apr 22 20:43:24 lab-nic knotd[2831]: error: [example.] DNSSEC, failed to
load private keys (not exists)
Apr 22 20:43:24 lab-nic knotd[2831]: error: [example.] DNSSEC, failed to
load keys (not exists)
Apr 22 20:43:24 lab-nic knotd[2831]: info: [example.] DNSSEC, next
signing at 2022-04-22T21:43:24+0000
Apr 22 20:43:24 lab-nic knotd[2831]: error: [example.] zone event
'DNSSEC re-sign' failed (not exists)
The imported key should not have the "active" flag:
info: [example.] DNSSEC, key, tag 35421, algorithm RSASHA1_NSEC3_SHA1,
KSK, public, active+
It seems to me that the imported key is not seen as a "public-only" key
anymore and therefore Knot is looking for the corresponding private key,
which of course fails.
I attached an strace output, with the signing operation. But that
doesn't seem to be helpful because the signing command itself doesn't fail.
Thanks,
Thomas
Just to clarify some semantics of the config format.
Is each individual 'remote' ID considered to be a single server,
regardless of the number of addresses it has?
For the notify case, it looks like knot will send to each address in a
remote ID in serial, and stop as soon as one replies. That suggests
the above semantics, but I wanted to make sure I'm interpreting this
behaviour correctly before I complicate my config by adding a lot more
remotes. I am currently treating each remote as an organisation,
lumping all of that organisation's servers together under a single ID.
I'm trying to find a way to poll for any zones where knot is currently
waiting on DS submission to the parent.
I'm aware of the structured logging sent to systemd-journald but I see
this as not particularly useful for monitoring, as the event could be
missed by a dead daemon, bug in code, etc. I'd much prefer to be able
to actively monitor states by polling.
It looks like the only way I can do that right now is to run `keymgr
list` and analyze the output. If I'm reading the documentation
correctly, all I need to look for is a key that is `ksk=yes`, `ready
!= 0`, and `active = 0`.
Does that seem correct? Am I missing something simpler? :)
