23 Říj
2018
23 Říj
'18
20:59
Dear Mark,
it is true that the method for creating a CSK is not
explicitly
mentioned in the documentation, we shall fix that. You can create a
CSK using our keymgr utility by specifying both 'ksk=yes' and
'zsk=yes' parameters of the 'generate' command. E.g.
$ keymgr -c /path/to/knot.conf example.com. generate ksk=yes
zsk=yes remove=+1y
thank you, this has worked so far. Regarding the remove parameter: is
there a special reason to limit the lifetime to one year? When I'm
following the manual key rollover process, I should be able to generate
a second CSK, when I want to roll, and retire the old key after the
parent DS update with respect to the record TTLs in parent zone. Or am I
missing something?
Please note that the geoip module is currently not
very well
integrated into Knot's DNSSEC workflow. For instance, the only way to
refresh RRSIGs precomputed by the module is to reload it (knotc
zone-reload). One approach for now could be to create a CSK with a
strong algorithm (e.g. the default ECDSAP256SHA256) and a long
lifetime, e.g. 1 year, and to set the same lifetime for the RRSIGs.
When I establish a cron job that forces a zone-reload, I just need to
ensure that the signature lifetime is long enough to handle a cron job
failure, right? Let's say I force a resign every week, a signature
lifetime of one month would be enough.
Then you would only have to perform a manual key
rollover while
reloading the zone so that the module computes the new signatures.
As far as I can tell after my tests I need to increase the SOA of the
zone file and then issue a zone-reload command to get new signatures.
This should be manageable by a cron job.
We will update the documentation to include this
information.
That would be nice.
In addition, you can sync the key from one server to
others by copying
the KASP lmdb database e.g. using the mdb_dump and mdb_load tools. If
you have any further questions, let us know!
I do not understand how this should work exactly. The following contents
are in my test setup inside of /var/lib/knot/keys:
/var/lib/knot/keys/keys
/var/lib/knot/keys/keys/c9516f526152dfdb6783af5eb72f9c088ce9408a.pem
/var/lib/knot/keys/lock.mdb
/var/lib/knot/keys/data.mdb
The database folder for mdb_dump should be /var/lib/knot/keys, right?
Will the dump contain just the data.mdb content? Am I supposed to deploy
the c9516f526152dfdb6783af5eb72f9c088ce9408a.pem file to the slaves on
my own? This does not seem to be contained in the dump file.
Kind regards,
Volker