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
