Hi Libor, we experience the same behavior after changing the config. Still 2 KSK (and 2 ZSK) are being created after signing a zone. One with Alg 8 and one with Alg 10. The one with Alg 8 is being used for signing and a rollover is started immediately after signing.
Don't now how to get out of the situation. Somehow there must be a reference to the old Alg 8 somewhere. No idea why a new zone is singed with Alg 8. Is there a way to clean up all the DNSSEC related data somehow? Actually I would be able to un-sign and purge all zones, we are only signing a few until now. But I don't know if this will solve the issue. Thanks, Thomas On 09.03.21 13:40, libor.peltan wrote: > Hi Thomas, > > yes, it shall be very smooth to simply remove the 'share' option from > configuration and continue as before. > > The idea of shared KSK was generally good and a surprising enhancement, > but you might have fallen to a random bug in rarely deployed > configuration combo. > > I'm curious to hear if your issue disappears once you change the config. > > Please let me know, > > Libor > > Dne 09. 03. 21 v 13:15 Thomas E. napsal(a): >> Thanks for the hint with the "cds-cdnskey-publish: always" issue. >> >> We are using shared ksk policy beause we thought it might be a good idea >> to reduce the amount of keys in the database. We are going to sing more >> than 10K zones and thought it might be a good thing to use shared keys >> to speed up backups and restores. >> But if this causes the actual problem I will change it of course. Do you >> know if it's safe to remove the shared policy attribute from the config? >> >> Thanks, >> Thomas >> >> On 08.03.21 17:55, Tuomo Soini wrote: >>> On Mon, 8 Mar 2021 17:09:54 +0100 >>> "Thomas E." <[email protected]> wrote: >>> >>>> 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. >>> This is a very wild guess but I'd suspect this has something to do with >>> ksk-shared: true, note the config below. >>> >>>>>>> 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 >>> Btw. cds-cdnskey-publish: always is against instructions in rfc. those >>> should only be published for rollover only. >>> >>> Is there some reason for using shared ksk? >>> -- https://lists.nic.cz/mailman/listinfo/knot-dns-users
