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