Hi Thomas,
what you are trying to achieve is prohibited by RFC 4035, section 2.2,
last paragraph.
Sorry, Knot DNS does not enable this.
Libor :)
Dne 05.11.20 v 17:20 Thomas napsal(a):
Hi LIbor,
thanks, that worked.
Yet I have a problem here. I imported the old key with the "import-pub"
method. This key has a different algorithm that the current ones. Is it
possible that this will not work?
When I try to sign the zone after I imported the old key I get the
following error:
2020-11-05T16:14:28+0000 info: [example.] DNSSEC, key, tag 14236,
algorithm RSASHA1_NSEC3_SHA1, KSK, public
2020-11-05T16:14:28+0000 info: [example.] DNSSEC, key, tag 38306,
algorithm RSASHA256, KSK, public, ready, active+
2020-11-05T16:14:28+0000 info: [example.] DNSSEC, key, tag 4378,
algorithm RSASHA256, public, active
2020-11-05T16:14:28+0000 error: [example.] DNSSEC, keys validation
failed (missing active KSK or ZSK)
2020-11-05T16:14:28+0000 error: [example.] DNSSEC, failed to load keys
(missing active KSK or ZSK)
Thanks for your help!
Thomas
On 05.11.20 14:34, libor.peltan wrote:
Hi Thomas,
I guess `keymgr ... delete ...` will do the job. Just check with `list`
first, to check which key is to be deleted.
To promote the changes to a running server, you will need `knotc
zone-sign your.zone.`.
BR,
Libor
Dne 05.11.20 v 14:32 Thomas napsal(a):
Hi Libor,
I come back to this issue from beginning of the year. After successfully
importing the old public keys with "import-pub" command, what is the
best way to remove them after everything is done?
Thanks a lot,
Thomas
On 14.01.20 10:34, libor.peltan wrote:
Hi all,
to make things clear, I would add some notes.
First, one needs to distinguish two possibilities:
1) importing the keys from previous software as they are, both their
public and private parts, and continue signing with the same keys while
switched to new software
For this, you probably utilize some of the keymgr commands: import-pem,
import-pkcs11, import-bind.
2) switching software together with all key's roll-over -- in this case
there is no need for importing the private keys, but for some time, the
new public keys must be pre-published in the old software before the
migration, and for some time the old public keys must be post-published
in the new software
For this, you might use the generate command for creating new Knot keys
and maybe import-pub command to enable post-publishing of old keys (the
Bind format is relatively straight-forward, so it can be "faked"
manually). Note that this might be tricky to do correctly.
(the method (2) is probably the same as "Changing DNS operators",
because they usually don't believe each other so that they would share
private keys ;) )
BR,
Libor
Dne 14.01.20 v 09:59 Daniel Salzman napsal(a):
Hi Thomas,
It's not clear what is the source DNS software. Is it Bind or Knot DNS?
The keymgr import is the right way. But you have to import full keys
(private and public parts) for a seamless operation.
Daniel
On 1/14/20 12:37 AM, Thomas wrote:
Hi!
I need to import dnskeys (KSKs & ZSKs) from an existing zone to my own
zone. This needs to be done due to a name server change without
breaking
the chain of trust according to RFC6781 - Section 4.3.5. "Changing
DNS
Operators"
I read in the KNon documentation that manual added dnskeys will be
removed when the zone gets signed:
"Updating the DNSKEY records. The whole DNSKEY set in zone apex is
replaced by the keys from the KASP database. Note that keys added into
the zone file manually will be removed. To add an extra DNSKEY record
into the set, the key must be imported into the KASP database
(possibly
deactivated)."
So I need to import these keys into the KASP via the keymgr tool,
right?
There is the "keymgr import-pub" method that expects a key in BIND
format. Is that the appropriate method for my task? If so, how do I
convert a DNSKEY Record into a Bind public key file?
Thanks a lot!
Thomas
--
https://lists.nic.cz/mailman/listinfo/knot-dns-users
