Hi Philip,
On 01/09/2026 16:11, Philip Homburg wrote:
In your letter dated Fri, 28 Aug 2026 09:06:53 +0200 you wrote:
There was some concern raised during the WG session that it
will not work with Cascade in its current design. Maybe Philip could
comment on this.
I finally found some time to try this with Cascade. As I expected, Cascade
would require quite a few changes to make this work in any kind of supported
way.
However, with quite a bit of manual work using unofficial interfaces I first
recoverd from a lost ZSK and later from a lot KSK.
An RFC can only give a high level overview of what to do and I think
this draft succeeds in doing that.
I am happy to read that! Thanks for trying it out.
Could you send a few lines of text to add to the implementation section?
I found one weird remark in the current text. Section 4.4 (ZONEMD
considerations) has:
"Therefore a new ZONEMD record SHOULD be generated and DNSSEC-signed."
Maybe this needs some text on what to do when the ZSK was lost?
Would this be ok?
"If the CSK or ZSK is being replaced, the ZONEMD record can only be
signed with the new key. It is assumed that validators will retrieve the
ZONEMD record together with a fresh copy of the zone, which includes any
newly added ZSK or CSK. Otherwise, validation and verification of the
new ZONEMD record will fail."
One thing I didn't try and that I now think of, if the ZSK is lost then
in theory the KSK could be imported as CSK and then the zone can be
signed and served normally.
Interesting idea. If the ZSK signing happens on separate hardware this
trick does assume that it is possible to extract the private key from
the KSK signer, which may not be the case.
Kind regards,
Martin
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
