14 Pro
2021
14 Pro
'21
0:36
Hi,
We're preparing to migrate our zones from OpenDNSSEC 1.4 to Knot DNS 3.1
(and eventually the .is zone).
We've already migrated one unsigned zone to the new signers, but next on
the list is first currently signed zone.
We're going to migrate the zone by doing a key rollover, so we'll add
DNSKEY records for the new keys to the zone on the old signer and vice
versa. While we're migrating the zone we have to stop automatic key
rollovers, and I planned to create a new policy 'dnssec_freeze' with
`manual: on` and apply it to zones during migration.
Am I correct that this will stop all automatic key rolloveres, but keep
the signatures updated?
The the migration is complete, DS records and delegations have been
updated etc., I'll change the policy to an automatic policy. Will knot
seamlessly start automatically rolling over keys according to the new
policy?
.einar
14 Pro
14 Pro
1:08
We're preparing to migrate our zones from
OpenDNSSEC 1.4 to Knot DNS
3.1 (and eventually the .is zone).
We've already migrated one unsigned zone to the new signers, but next
on the list is first currently signed zone.
We're going to migrate the zone by doing a key rollover, so we'll add
DNSKEY records for the new keys to the zone on the old signer and vice
versa. While we're migrating the zone we have to stop automatic key
rollovers, and I planned to create a new policy 'dnssec_freeze' with
`manual: on` and apply it to zones during migration.
I just realized that knot replaces the whole dnskey set in the zone with
the keys from the kasp, so my plan to add the dnskey records from the
old signer to the zone before signing is not valid.
I guess we'll have to move the old keys to the new signers.
.einar
2:09
On 14/12/2021 01:08, Einar Bjarni Halldórsson wrote:
Hi Einar,
I just realized that knot replaces the whole dnskey
set in the zone with
the keys from the kasp, so my plan to add the dnskey records from the
old signer to the zone before signing is not valid.
I guess we'll have to move the old keys to the new signers.
You don't need to. You can import the ZSKs from the old signer into
Knot's key database, using the "import-pub" command to "keymgr".
Knot
will publish these alongside its own keys, and sign the DNSKEY RRset
with its own KSK.
This is how we switched signers at RIPE NCC, and it worked perfectly.
You can read more about it here:
https://labs.ripe.net/author/anandb/dnssec-signer-migration/
Regards,
Anand Buddhdev
RIPE NCC
9:11
Welcome Einar,
On 12/14/21 12:36 AM, Einar Bjarni Halldórsson wrote:
Hi,
We're preparing to migrate our zones from OpenDNSSEC 1.4 to Knot DNS 3.1 (and
eventually the .is zone).
We've already migrated one unsigned zone to the new signers, but next on the list is
first currently signed zone.
We're going to migrate the zone by doing a key rollover, so we'll add DNSKEY
records for the new keys to the zone on the old signer and vice versa. While we're
migrating the zone we have to stop
automatic key rollovers, and I planned to create a new policy 'dnssec_freeze'
with `manual: on` and apply it to zones during migration.
As Anand wrote already, you cannot simply modify the DNSKEY RRset in the zone. You have to
use `keymgr import-pub` instead and setting
some key timestamps via `keymgr set` if necessary.
Also you don't need to switch to the manual mode. Knot changes the keys only if there
is any reason for that (e.g. DNSSEC policy modification). If you need more time,
you can just extend the zsk-lifetime.
Am I correct that this will stop all automatic key rolloveres, but keep the signatures
updated?
Yes, that's exactly how the manual key management works.
The the migration is complete, DS records and delegations have been updated etc.,
I'll change the policy to an automatic policy. Will knot seamlessly start
automatically rolling over keys according to
the new policy?
Yes, Knot will continue managing the keys automatically.
Daniel
.einar
11:57
Hi Anand,
You don't need to. You can import the ZSKs from the old signer into
Knot's key database, using the "import-pub" command to "keymgr".
Knot
will publish these alongside its own keys, and sign the DNSKEY RRset
with its own KSK.
After some trial and error, I finally got the keys imported into knot.
Apparently they have to have extension .key and I kept mixing up
import-bind and import-pub...
This is how we switched signers at RIPE NCC, and it
worked perfectly.
You can read more about it here:
https://labs.ripe.net/author/anandb/dnssec-signer-migration/
I've read that article many, many times :) It was one of the reasons we
considered knot as our new signer platform. Your point about knot
configuration files is excellent, which meant that it's very easy to use
ansible playbooks to configure knot. Unfortunately, the same cannot be
said of opendnssec, which has served us well for many years, but having
to run commands to interface with the kasp db is not easy to do well in
ansible.
.einar
887
days inactive
888
days old
4 comments
3 participants
participants (3)
-
Anand Buddhdev -
Daniel Salzman -
Einar Bjarni Halldórsson