4 Bře
2019
4 Bře
'19
9:23
Hi Thomas,
87472c54eb669c66353503caa0a386b1e95602de ksk=yes
zsk=no tag=32875
algorithm=8 size=2048 public-only=no created=1551267572 pre-active=0
publish=1551430817 ready=1551430817 active=0 retire-active=0 retire=0
post-active=0 remove=0
Hmm, shouldn't it be "active=1"?
ready=<sometimestamp> active=0 means that the submission of the initial
KSK has not been completed - Knot is not aware of the correct DS record
in the parent zone. Thus does he not start any key rollover.
Is this parameter mandatory?
ksk-submission: test_zone_sbm
It's precisely a link to configuration section which tells Knot how it
shall ask for parent DS. It's not mandatory, but it's really handy.
Thanks a lot,
Thomas
BR,
Libor
On 03.03.19 18:45, daniel.salzman(a)nic.cz wrote:
> Hi Thomas,
>
> Have you submitted the initial KSK (it shouldn't be in the ready state)?
> If it isn't submitted, no further rollover can happen.
>
> Try something like:
>
> policy:
> - id: test
> ksk-lifetime: 1200
> zsk-lifetime: 600
> propagation-delay: 0
> dnskey-ttl: 60
>
> And ensure the maximum TTL value in the zone is low.
>
> Best,
> Daniel
>
> On 2019-03-03 17:26, Thomas wrote:
>> Hi,
>>
>> we are testing knot at the moment and are struggling with the concept of
>> automatic KSK rollovers. We are planning to fetch the current CDS for
>> further automatic processing and try to figure out how to achieve a
>> policy that performs KSK rollovers in a short period of time for testing
>> purposes. Until now we have not seen any KSK rollovers and we are not
>> sure why this is not happening. Can someone show me an example of a
>> policy that schedules a KSK rollover within a very short period, let's
>> say once a day? What policy parameters must be set? And what must be the
>> zone's parameters in terms of TTL and SOA values (expire, refresh, etc)?
>>
>>
>> Thanks a lot,
>> Thomas