14 Bře
2021
14 Bře
'21
0:14
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." <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?
>>