19 Říj
2018
19 Říj
'18
17:14
Dear Volker,
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
creates an immediately active CSK with a 1 year lifetime. You can check
out all possible timestamp settings in the docs
<https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#generate-arguments>.
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. The policy configuration could
look like this:
policy:
- id: manual
manual: on
algorithm: ECDSAP256SHA256
rrsig-lifetime: 365d
zone:
- domain: example.com.
dnssec-signing: on
dnssec-policy: manual
Then you would only have to perform a manual key rollover while
reloading the zone so that the module computes the new signatures. We
will update the documentation to include this information. 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!
Best regards,
Mark
On 19.10.2018 10:13, Volker Janzen wrote:
Hi all,
I'd like to test the geoip module with a signed zone. The
documentation recommends using manual mode for signing. As far as I
know, the geoip information is not transferred via AXFR. That would
mean, that I've to transfer the signing key to the secondary servers
along with the geoip (and zone) configuration. To reduce caveats with
ZSKs, I'd like to use CSK. As a result I just need to sync one key per
zone to secondary servers. I checked the Knot documentation on how to
use a CSK for a zone, but the CSK is only mentioned twice in the
documentation with no example on how to actually use it. Can someone
point me to a configuration example for setting up a CSK?
Kind regards,
Volker
23 Říj
23 Říj
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
21:11
Dear Volker,
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?
no, there is no special reason, I was just showing an example of how one
would set timers for a key (a rather bad example, I admit).
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.
That sounds reasonable to me. Please let us know how this approach works
for you in practice. We are grateful for any feedback!
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.
Yes, the mdb_* commands only work with the content of the database, the
*.pem files have to be handled separately.
If you have any more questions, please let me know!
Best regards,
Mark
2168
days inactive
2172
days old
2 comments
3 participants
participants (3)
-
Mark Karpilovskij -
mark.karpilovskij＠nic.cz
-
Volker Janzen