23 Říj
2018
23 Říj
'18
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