Can't add DNSKEY of different algorithm to help migration
I tried to use knot for my zone to replace an existing dnssec signer. The zone is currently RSA-SHA256. The new knot zone is ECDSAP256SHA256.
My plan was to pull my active ZSK and KSK from the old setup and add it as data in knot. Then do the reverse on the old setup. And then cat the two signed zones into one file and serve that for 2x TTL.
But now I can't because knot won't take my DNSKEY and throws an error (prob because its an unmatched algorithgm for the zone?)
Activity
Hi Paul, thank you for your report.
However, you haven't described really clearly:
- your configuration (automatic signing?, automatic key management?, etc)
- the way you used to insert the other-algorithm keys into the zone (keymgr import-pub?, zone file editing?, other..)
- the resulting error message(s)
The rule of thumb is, that Knot doesn't allow you to violate https://datatracker.ietf.org/doc/html/rfc4035#section-2.2 , for example, it doesn't allow to have just public-only keys of some algorithm in the zone, if there are no active keys for the same algorithm.
Have you tried to perform a manual algorithm roll-over while migrating between different signer implementations?
That requirement is for the zone I end up publishing, with is a concatenation of the old signer zone and the new singer zone :)
I appreciate knot assuming it is generating all the content. Perhaps an option to mark the zone for this would be useful?
It is exactly want I want to do, add a DNSKEY as pure "data" without knot treating it anything other than random zone data it should just publish. I do not expect knot to use this RSA based DNSKEY for any signing itself.
Yes, I am attempting a rollover from old implementation using RSA to new implementation using ECDSA :)
-
Sorry, I don't get it.
What does "concatenation of the zone" mean?
When performing an algorithm rollover, you usually first use keys for signing, and publish them after some delay (while continuing signing). So you maybe need to properly import the other-algorithm keys and set up their timers, but still, it never reaches the phase that they'd be only published and not used for signing.
Libor Peltan commented:
Sorry, I don't get it.
What does "concatenation of the zone" mean?
Signer #1 (closed) is currently deployed using RSA Signer #2 (closed) is currently deployed using ECDSA
Namerservers are serving zone from signer #1 (closed)
Today a DS record was added for the KSK of Signer #2 (closed)
I want to add the DNSKEY or signer #1 (closed) to the DNSKEY set of Signer #2 (closed)
Once that has happened, I will change the namerservers to serve the concatenation of both signers zone. That means everything is double signed.
Then after 2x TTL, I remove old DS and I switch nameservers to only serve zone from signer #2 (closed). And I turn off signer #1 (closed)
When performing an algorithm rollover, you usually first use keys for signing, and publish them after some delay (while continuing signing). So you maybe need to properly import the other-algorithm keys and set up their timers, but still, it never reaches the phase that they'd be only published and not used for signing.
I don’t want to do an algorithm rollover on the new signer using old RSA data. I wanted to avoid needing to import old stuff, run it and then do algorithm rollover.
Paul
-
Hi Paul, aren't you trying to achieve something similar like Ulrich Wisser with an attempt to develop an automated migration tool between uncooperating signers?
My personal opinion is that that is a good and needed thing, however it will never ever really work with algorithm rollover.
Anyway, !1291 (closed) might help even you, especially 12ccde51 .
Libor Peltan https://gitlab.nic.cz/lpeltan commented #741 (comment 214185):
Hi Paul, aren't you trying to achieve something similar like Ulrich Wisser with an attempt to develop an automated migration tool between uncooperating signers?
No. I am trying to migrate between two cooperating signers, new me and old me.
Anyway, !1291 (closed) !1291 (closed)
While it no longer rejects the DNSKEY with these, it seems the added DNSKEY still somehow vanishes in the pipeline and does not end up in the zone.
Paul
I did some testing too. I backported commits: from a7356350 to 89e03764. But results were not good. When editing the zone and insering extra DNSKEY record, when loading zone knot logged:
knotd: warning: [bleve.fi.] check, node bleve.fi., unverifiable signature (record type SOA) knotd: warning: [bleve.fi.] check, node bleve.fi., unverifiable signature (record type DNSKEY)
But after signing extra DNSKEY record is gone.
-
@paulwouters I don't understand why you don't prefer to migrate the signer first (with the same algorithm) and perform an algorithm rollover later.
Libor Peltan https://gitlab.nic.cz/lpeltan commented #741 (comment 214953):
@paulwouters https://gitlab.nic.cz/paulwouters I don't understand why you don't prefer to migrate the signer first (with the same algorithm) and perform an algorithm rollover later
customers like to fix things in one go :) Keep the old stuff old and unchanged and deploy something new to replace the old without touching it too much.
added discussion feature knot labels
@paulwouters !1308 (merged) should help you with the specific requirement :-) I will probably backport this feature to 3.0.8.
@paulwouters have you tested https://www.knot-dns.cz/docs/3.0/singlehtml/index.html#unsafe-operation if it helps?
-
@paulwouters BUMP ?
Yes it works. I successfully managed to publish DNSKEY, CDNSKEY, CDS records with imports from live zone into this new zone. And I added new records from this zone to current zone into the old opendnssec deployment. So everything is cross referenced.
I'm waiting a bit to see if RIPE picks up my CDS to update the DS for my reverse. Then I am ready to cat the two zones into my nameservers and see what breaks :)
