Hi Anand, ah, cool, thanks! Freezing the zone is to lock it for updates? E.g. when someone wants to perform a ddns update while I edit the zone manually? Thanks, Thomas On 12.01.20 20:01, Anand Buddhdev wrote:

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 >

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    >>

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 >>>>

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 >>>>>>

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 >>>>>>>>

Hi, the command "keymgr <zone> ds" gives me 2 DS records. One of Type 2 and one of Type 4. Is it possible to get Type 1 also? Thanks, Thomas

Hi, the command "keymgr <zone> ds" gives me 2 DS records. One of Type 2 and one of Type 4. Is it possible to get Type 1 also? Thanks, Thomas