Commit e5d26ebe authored by Libor Peltan's avatar Libor Peltan

doc: algorithm rollover with keymgr described

parent 9ca6e039
......@@ -277,6 +277,54 @@ each other, e.g. periodically changing few zone records, re-signing whole zone..
The diff between zone file and zone is thus preserved, even if journal deletes some
older changesets.
.. _Algorithm rollover:
DNSSEC keys algorithm rollover
Algorithm rollover is a process of changing DNSSEC signing keys, where the
new keys are of different algorithm. The zone signatures must never go Bogus
during the process, even considering records cached in resolvers. The process
is generally described in RFC 6781. Following are some hints how to implement
algorithm rollover when using Knot DNS.
The prerequisite is having a zone with automatic DNSSEC signing enabled, active
KSK and ZSK present. (The CSK case should work analogously, not mentioned further.)
It is recommended to disable automatic key management during the rollover. Note
that from the view of common key rollovers, here we must put the keys into a weird
state: active, but not published. This is done by hard-setting their timers so that
created <= active < publish < retire.
First we need to generate new keys. They must be first used for signing, and
after some period (propagation delay let's say 1h + zone records' TTL let's say
1h) published. We have to preprate the timestamps carefully, using the notation
'now+2h' can be creepy with "now" changing between the Keymgr invokes. We then
resign the zone just to force knotd to reload zone keys::
$ NOW=$(date +%s)
$ NOW2H=$((NOW + 7200))
$ keymgr generate algorithm=14 size=384 ksk=yes \
ready=$NOW2H active=0 publish=$NOW2H
$ keymgr generate algorithm=14 size=384 ksk=no \
ready=$NOW active=$NOW publish=$NOW2H
$ knotc zone-sign
After waiting for the keys to get published as scheduled, we may tell the parent
zone operator to renew our DS record. As the KSK is in ready state, we have the
CDS/CDNSKEY records in our zone. After waiting again for some propagation period,
we continue with removing old KSK and putting old ZSK into active-not-published
state (we must first obtain the keys' IDs with 'keymgr list'). We may
also confirm the new KSK submission (which reloads KASP DB as a side-effect)::
$ keymgr set $OLD_KSK_ID retire=now+0 remove=now+0
$ keymgr set $OLD_ZSK_ID publish=0
$ knotc zone-ksk-submitted
Finally, after one more propagation period, we remove old ZSK::
$ keymgr set $OLD_ZSK_ID retire=now+0 remove=now+1
$ knotc zone-sign
.. _Controlling running daemon:
Daemon controls
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment