Hi Libor,
I try to summarize what we have done:
We have been running the config about one year with Algorithm RSASHA256
(8). End of January we changed the value in the config to RSASHA512 (10).
The algorithm rollover took place immediatly as expected. After all
zones have been changed to the new algorithm we siged a new zone.
We experienced that the new zone was still being signed with Alg 8. But
also a key with Alg 10 was created and another algorithm rollover took
place immediatly. This behaviour was reported by me at the beginning of
this thread. We asked ourselves why a key with Algorithm 8 has been
created. What could have been the reason for that? Our config already
had RSASHA512 at that time.
Then, after while, we again signed a new zone and it got even more
confusing. This time 2 Keys with Algorithm 8 have been created. This is
the actual situation.
Somehow the key management is messed up. I wonder if we can find out the
reason for that. I don't think that we did something unsual. Are there
any issues in our config? Is the shared policy maybe a problem?
All the best,
Thomas
On 02.03.21 19:48, libor.peltan wrote:
Hi Thomas,auffälligke
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