Hi Libor, I just signed another zone to see what will happen. Now I see the same behavior again like at the beginning of this thread. Even there is no more RSASHA256 configured in the config, the following has happened:
2021-03-08T16:21:57+0100 info: [example.de.] DNSSEC, signing zone 2021-03-08T16:21:58+0100 info: [example.de.] DNSSEC, algorithm rollover started 2021-03-08T16:21:58+0100 notice: [example.de.] DNSSEC, KSK submission, waiting for confirmation 2021-03-08T16:21:58+0100 info: [example.de.] DNSSEC, key, tag 17362, algorithm RSASHA256, KSK, public, ready, active+ 2021-03-08T16:21:58+0100 info: [example.de.] DNSSEC, key, tag 11280, algorithm RSASHA256, public, active 2021-03-08T16:21:58+0100 info: [example.de.] DNSSEC, key, tag 37878, algorithm RSASHA512, KSK 2021-03-08T16:21:58+0100 info: [example.de.] DNSSEC, key, tag 15117, algorithm RSASHA512, active+ 2021-03-08T16:21:58+0100 info: [example.de.] DNSSEC, signing started 2021-03-08T16:21:58+0100 info: [example.de.] DNSSEC, successfully signed 2021-03-08T16:21:58+0100 info: [example.de.] DNSSEC, next signing at 2021-03-09T17:21:57+0100 2021-03-08T16:21:58+0100 info: [example.de.] zone file updated, serial 1579936456 -> 1615216918 A KSK and ZSK with Alg RSASHA256 have been created and the zone was signed. An algorithm rollover is triggered right after signing. I don't understand why RSASHA256 is still being used. All the best Thomas On 05.03.21 23:41, Thomas wrote: > 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 > -- https://lists.nic.cz/mailman/listinfo/knot-dns-users
