9 Bře
2021
9 Bře
'21
13:40
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." <list(a)crashcom.info> 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?
>