RIPE NCC DNS operations update
Dear colleagues, On Tuesday 3 May, we performed a DNSSEC Key Signing Key (KSK) roll-over for all the zones that we maintain and sign. During this roll-over, we dropped the Zone Signing Keys (ZSKs), and began signing the zones with just their new KSKs. Technically, these keys are the same as any other KSKs, but since they sign the entire zone, and there's no ZSK, such KSKs are informally known as Combined Signing Keys (CSKs). We use Knot DNS for signing, and we enabled the "single-type-signing" option for our zones. We then triggered the key roll-over. Knot DNS waited and watched for DS record updates, and then gracefully introduced and withdrew keys by waiting for the appropriate amount of time as determined by Time To Live (TTL) values in the zones. On Monday 9 May, a new version of the RIPE Database was deployed. This version communicates with our new version of Zonemaster. When users submit domain objects to the RIPE Database, it submits a pre-delegation check to Zonemaster, and only allows the update if Zonemaster returns a result without any errors. This new version of Zonemaster has several bug fixes, improved tests, and most importantly, support for the newest DNSSEC algorithms, algorithm 15 (ED25519) and algorithm 16 (ED448). Regards, Anand Buddhdev RIPE NCC
On 11 May 2022, at 12:53, Anand Buddhdev <anandb@ripe.net> wrote:
On Tuesday 3 May, we performed a DNSSEC Key Signing Key (KSK) roll-over for all the zones that we maintain and sign. During this roll-over, we dropped the Zone Signing Keys (ZSKs), and began signing the zones with just their new KSKs. Technically, these keys are the same as any other KSKs, but since they sign the entire zone, and there's no ZSK, such KSKs are informally known as Combined Signing Keys (CSKs).
Many thanks for the update Anand. Could you give a bit more detail on why you decided to dump the ZSKs? Was it just a matter of having fewer keys to manage and fewer moving parts that could break?
On 11/05/2022 14:07, Jim Reid wrote: Hi Jim,
Many thanks for the update Anand.
Could you give a bit more detail on why you decided to dump the ZSKs? Was it just a matter of having fewer keys to manage and fewer moving parts that could break?
Managing keys isn't an issue, since it is all automated by the signer. Our main reason is that we do not have separate storage for the KSKs and ZSKs. They were all stored together on the signer. Additionally, our ECDSA KSKs and ZSKs were of the same size. Therefore, there is no additional protection offered by separating them, and so it is reasonable to use a CSK. Regards, Anand Buddhdev RIPE NCC
On 11 May 2022, at 13:20, Anand Buddhdev <anandb@ripe.net> wrote:
Our main reason is that we do not have separate storage for the KSKs and ZSKs. They were all stored together on the signer. Additionally, our ECDSA KSKs and ZSKs were of the same size. Therefore, there is no additional protection offered by separating them, and so it is reasonable to use a CSK.
Makes sense. Like everything else you do. Thanks Anand.
participants (2)
-
Anand Buddhdev -
Jim Reid