Absolutely! But the things become tricky when the old provider still uses 7.
Thanks for the info, Thomas On 05.11.20 17:51, libor.peltan wrote: > OK then. > > Just be informed that in newest Linux distributions, namely in Fedora > 33, older algorithms are disabled by GnuTLS, and for now not usable with > Knot. > > So rolling to algorithm >= 8 might be a good idea in relatively short > perspective ;) > > Libor > > Dne 05.11.20 v 17:47 Thomas napsal(a): >> Hi Libor, >> >> ok, thanks. I should have know that...good that knot protects the >> users :D >> >> I will downgrade to algorithm 7 and will make an algorithm rollover >> after the transition. >> >> Thanks, >> Thomas >> >> On 05.11.20 17:37, libor.peltan wrote: >>> 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
