diff options
author | Libor Peltan <libor.peltan@nic.cz> | 2020-03-27 18:09:10 +0100 |
---|---|---|
committer | Daniel Salzman <daniel.salzman@nic.cz> | 2020-08-25 21:52:29 +0200 |
commit | 46dd3dfff00478c5d6254fa02fc4f6c7b159eb49 (patch) | |
tree | 72ec25c328ddbc08e5aaa022bb277b805c410ab3 | |
parent | ctl: add zone-backup and zone-restore to help (diff) | |
download | knot-46dd3dfff00478c5d6254fa02fc4f6c7b159eb49.tar.xz knot-46dd3dfff00478c5d6254fa02fc4f6c7b159eb49.zip |
doc: remove kasp db import/export topic
-rw-r--r-- | doc/migration.rst | 2 | ||||
-rw-r--r-- | doc/operation.rst | 61 |
2 files changed, 11 insertions, 52 deletions
diff --git a/doc/migration.rst b/doc/migration.rst index 1113c730b..63747bb35 100644 --- a/doc/migration.rst +++ b/doc/migration.rst @@ -104,7 +104,7 @@ Upgrading from Knot DNS version 2.7.x to 2.8.x is seamless. However, if the previous version was migrated (possibly indirectly) from version 2.5.x, the format of the keys stored in -:ref:`Keys And Signature Policy Database <DNSSEC Export Import KASP DB>` +Keys And Signature Policy Database is no longer compatible and needs to be updated. The easiest ways to update how keys are stored in KASP DB is to modify diff --git a/doc/operation.rst b/doc/operation.rst index 3665c01d1..6ffc4cb08 100644 --- a/doc/operation.rst +++ b/doc/operation.rst @@ -862,57 +862,6 @@ Emergency key replacement: * Align the keys with the new states (backup key as active, compromised key as public) * Re-sign the zone -.. _DNSSEC Export Import KASP DB: - -Export/import KASP DB -====================== - -If you would like make a backup of your KASP DB or transfer your cryptographic -keys to a different server, -you may utilize the ``mdb_dump`` and ``mdb_load`` tools provided by the -`lmdb-utils <https://packages.ubuntu.com/bionic/lmdb-utils>`_ -package on Ubuntu and Debian or by the `lmdb <https://rpms.remirepo.net/rpmphp/zoom.php?rpm=lmdb>`_ -package on Fedora, CentOS and RHEL. -These tools allow you to convert the contents of any LMDB database to a portable plain text format -which can be imported to any other LMDB database. Note that the `keys` subdirectory of the -:ref:`database_kasp-db` directory containing the \*.pem files has to be copied separately. - -.. NOTE:: - Make sure to freeze DNSSEC events on a running server prior to applying the following - commands to its KASP DB. Use the ``knotc zone-freeze`` and ``knotc zone-thaw`` commands - as described in :ref:`Editing zone file`. - -Use the ``mdb_dump -a`` command with the configured :ref:`database_kasp-db` directory -as an argument to convert the contents of the LMDB database to a portable text format: - -.. code-block:: console - - $ mdb_dump -a /path/to/keys - -Save the output of the command to a text file. You may then import the file -into a different LMDB database using the ``mdb_load -f`` command, supplying the path -to the file and the path to the database directory as arguments: - -.. code-block:: console - - $ mdb_load -f /path/to/dump_file /path/to/keys - -.. NOTE:: - Depending on your use case, it might be necessary to call ``knotc zone-sign`` - (e.g. to immediately sign the zones with the new imported keys) or ``knotc zone-reload`` - (e.g. to refresh DNSSEC signatures generated by the :ref:`geoip module<mod-geoip>`) - after importing new content into the KASP DB of a running server. - -.. TIP:: - In order to seamlessly deploy a restored backup of KASP DB with respect to - a possibly ongoing DNSSEC key rollover, it's recommended to set - :ref:`propagation-delay <policy_propagation-delay>` to the sum of: - - - The maximum delay between beginning of the zone signing and publishing - re-signed zone on all public slave servers. - - How long it takes to the backup server to start up with the restored data. - - The period between taking backup snapshots of the live environment. - .. _DNSSEC Import of keys to HSM: Import of keys to HSM @@ -1057,6 +1006,16 @@ The restore procedure does not care for keys deleted after taking the snapshot. Thus, after restore, there might remain some redundant ``.pem`` files of obsolete signing keys. +.. TIP:: + In order to seamlessly deploy a restored backup of KASP DB with respect to + a possibly ongoing DNSSEC key rollover, it's recommended to set + :ref:`propagation-delay <policy_propagation-delay>` to the sum of: + + - The maximum delay between beginning of the zone signing and publishing + re-signed zone on all public slave servers. + - How long it takes to the backup server to start up with the restored data. + - The period between taking backup snapshots of the live environment. + .. _Statistics: Statistics |