Hi Libor,

thanks for clarification. A "knotc zone-ksk-submitted xx.tld" did the
trick and rollover is now processing.

Yet, I don't fully understand why that manual intervention is necessary
as Knot would be able to find out the state of the DS record by itself.
Is there any particular reason for that? Or is it just due to the design
history of Knot?

Thanks a lot,
Thomas


On 04.03.19 09:23, libor.peltan wrote:
> 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, [email protected] 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

-- 
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

Reply via email to