Hi Petr,
thank you for the information. I will enable and use CDNSKEY and CDS records.
Maxi
On Montag, 29. Oktober 2018 09:22:00 CET Petr Špaček wrote:
Hi Maxi,
yes, I would strongly recommend you to keep CDS/CDNSKEY enabled. It is
the only industry-standard way to manage DS records.
It is also the safest way to obtain correct data for DS in parent
because it gets generated by Knot DNS policy engine and minimizes risk
of humar error.
Petr Špaček @ CZ.NIC
On 27. 10. 18 22:26, Maximilian Engelhardt wrote:
> Hi Libor,
>
> Thank you for your reply. I disabled the generation of CDS and CDNSKEY
> records in my setup because I'm currently not planning on using them and
> thus didn't see it necessary to publish them. However I see no harm in
> publishing them, so I think I can as well enable them again.
>
> Is using the CDS and CDNSKEY records seen as the preferred way to obtain
> this Information even for manual submission?
>
> Maxi
>
> On Freitag, 26. Oktober 2018 18:49:54 CEST libor.peltan wrote:
>> Hi Maxi,
>>
>> when it comes to updating the parent zone's DS during the rollover, Knot
>> automatically (unless overriden by config) publishes CDS and CDNSKEY
>> records in your zone. You can query your server and use them directly,
>> the parent's DS shall be equal to your CDS.
>>
>> Libor
>>
>> Dne 26.10.18 v 18:24 Maximilian Engelhardt napsal(a):
>>> Hi,
>>>
>>> I'm having a question about DNSSEC KSK rollover and obtaining the
>>> relevant
>>> information for submission to the parent zone of the new key.
>>>
>>> I'm currently using these steps:
>>>
>>> - running "keymgr
example.org list"
>>> - manually identifying the new key using the parameters "ksk=yes"
and
>>> having a look at the created, publish, ready and active parameters. The
>>> new key always seems to be the one with active=0 and I also check the
>>> dates of the other parameters for plausibility. I then note the tag of
>>> the identified key. - using "keymgr
example.org dnskey
<keytag>" or
>>> "keymgr
example.org ds <keytag>" to get the corresponding
information
>>> for
>>> submission to the parent zone.
>>>
>>> Is there an easier way of achieving this, especially without the manual
>>> key
>>> identification step? Ideally would be a single command I can run and
>>> specify the zone of interest and it will output the dnskey and/or ds
>>> information of the new key.
>>>
>>> Thanks,
>>> Maxi