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 -- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
