Hi Thomas,
the key with tag 32875, having only the "ready" timer set, is obviously
wrong and is causing the observed misbehavior.
Do you have any record of how this situation emerged? For example, a log
file and/or personal memoirs?
Anyway, a side notice: as you probably know, when the configured (in
policy) and current (in keyset) algorithms differs, Knot initiates an
algorithm rollover. That is currently blocked for the specific zone
because it looks like another key rollover is running (the ready key is
present). As a consequence, once (if) you delete the ready key, Knot
immediately starts with algorithm rollover to RSASHA512.
BR,
Libor
Dne 02. 03. 21 v 17:53 Thomas E. napsal(a):
Hi Libor,
sorry for the late reply. We noticed another strange behaviour in our
signer, which might be related to the previously stated issues.
We signed a new zone, I'll refer to it as example.com in the examples,
and it looks like the internal key management got mixed up in the process.
E.g. the following CDS/CDNSKEY combination is published for the zone:
$ dig cds example.com +short
32875 8 2 7E476D751F633B44C1D1ED3A78F986EDCD588E58415CFA10B1256FCB 10336E96
$ dig cdnskey example.com +multiline
example.com. 0 IN CDNSKEY 257 3 8 (
AwEAAdKaHEdWflf.......bW5fiKHe6sQYUjaXj/YCQcn18=
) ; KSK; alg = RSASHA256 ; key id = 32875
So then as usual our process starts and picks up the new CDS/CDNSKEY
records and attempts to upload them to the registry. Then the registry
tells us, that the key is actually not yet published and therefor they
won't accept our domain update.
A quick dig request does in fact support the issue raised by the registry:
$ dig dnskey example.com +multiline
example.com. 7170 IN DNSKEY 257 3 8 (
AwEAAb1nUFjsy.....cueakqu/h4JoqiGRbH0gS77Ylp
) ; KSK; alg = RSASHA256 ; key id = 10051
example.com. 7170 IN DNSKEY 256 3 8 (
wEAAfTyql02Gh................CCp+DOxYYkKrYRdDEc
) ; ZSK; alg = RSASHA256 ; key id = 6123
Using the keymgr Tool we see the following entries for the zone:
~# keymgr -c /etc/knot/knot.conf example.com list
87472c54eb669c66353503caa0a386b1e95602de ksk=yes zsk=no tag=32875
algorithm=8 size=2048 public-only=no pre-active=0 publish=0
ready=1551269424 active=0 retire-active=0 retire=0 post-active=0
revoke=0 remove=0
9304559cacf1f8a6e44a32591c5f6ba6a2ef002b ksk=yes zsk=no tag=10051
algorithm=8 size=2048 public-only=no pre-active=0 publish=1551269695
ready=0 active=1551269803 retire-active=0 retire=0 post-active=0
revoke=0 remove=0
c2bd0743de6b4b07837e4936e983cae059adc928 ksk=no zsk=yes tag=06123
algorithm=8 size=1024 public-only=no pre-active=0 publish=1551269424
ready=0 active=1551269424 retire-active=0 retire=0 post-active=0
revoke=0 remove=0
Two KSK with Alg 8 have been created. Why 2 of them and why with Alg 8?
We don't have Alg 8 in our policy anymore.
Furthermore the key 32875 seems to be ready, but is not published in the
zone, but it has been published as CDNSKEY. The one that is published in
the zone has id 10051. There is something mixed up somehow.
Our redacted knot.conf looks like this:
server:
listen: 192.168.1.123@53
user: knot:knot
log:
- target: /var/log/knot.log
any: info
control:
listen: /var/run/knot/knot.sock
remote:
- id: local-resolver
address: 192.168.1.2
submission:
- id: resolver
parent: local-resolver
policy:
- id: shared
algorithm: RSASHA512
ksk-size: 2048
zsk-size: 1024
zsk-lifetime: 30d
ksk-lifetime: 365d
ksk-shared: true
ksk-submission: resolver
nsec3: true
cds-cdnskey-publish: always
- id: unsigned
algorithm: RSASHA512
ksk-size: 2048
zsk-size: 1024
zsk-lifetime: 30d
ksk-lifetime: 365d
ksk-shared: true
nsec3: true
cds-cdnskey-publish: delete-dnssec
key:
- id: <keya>
algorithm: hmac-sha256
secret: <secreta>
- id: <keyb>
algorithm: hmac-sha256
secret: <secretb>
remote:
- id: <remotea>
address: <ip1>
address: <ip2>
key: <keyb>
- id: <remoteb>
address: <ip3>
key: <keya>
acl:
- id: <remotea>
address: <ip1>
address: <ip2>
key: <keyb>
action: notify
- id: <remoteb>
address: <ip3>
key: <keya>
action: transfer
template:
- id: default
storage: "/var/lib/knot/"
semantic-checks: on
global-module: mod-stats
serial-policy: unixtime
dnssec-signing: off
zonefile-load: difference
- id: signed
storage: "/var/lib/knot/"
dnssec-signing: on
dnssec-policy: shared
serial-policy: unixtime
zonefile-load: difference
- id: unsigned
storage: "/var/lib/knot/"
dnssec-signing: on
dnssec-policy: unsigned
serial-policy: unixtime
zonefile-load: difference
zone:
- domain: example.com.
template: signed
master: [<remotea>]
notify: [<remoteb>]
acl: [<remotea>, <remoteb>]
acl: [<remotea>, <remoteb>]
We have a few thousand zones set up in this way, with only a handful of
them being signed yet.
We know that the algorithm RSASHA512 should not be used, but we wanted
to complete all key rollovers, before attempting another key rollover to
ECDSAP256SHA256.
Thanks a lot,
Thomas
On 20.01.21 21:41, libor.peltan wrote:
Hi Thomas,
could you please send us you configuration (at least the algorithm
currently set) and the output of `keymgr -c <knot_conf> <your.zone> list` ?
Thanks,
Libor
Dne 20. 01. 21 v 20:21 Thomas napsal(a):
Hi,
we performed successfully an algorithm rollover. After changing the
algorithm in the configuration file everything worked as expected. All
zones have been updated to the new algorithm.
When I now sign a new zone the zone is being signed with the old
algorithm's key and an algorithm rollover is being triggered immediately.
Is this an expected behavior? How can I avoid this? Do I have to delete
the old key?
Thanks a lot,
Thomas
--
https://lists.nic.cz/mailman/listinfo/knot-dns-users
