summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorLibor Peltan <libor.peltan@nic.cz>2020-03-27 18:09:10 +0100
committerDaniel Salzman <daniel.salzman@nic.cz>2020-08-25 21:52:29 +0200
commit46dd3dfff00478c5d6254fa02fc4f6c7b159eb49 (patch)
tree72ec25c328ddbc08e5aaa022bb277b805c410ab3
parentctl: add zone-backup and zone-restore to help (diff)
downloadknot-46dd3dfff00478c5d6254fa02fc4f6c7b159eb49.tar.xz
knot-46dd3dfff00478c5d6254fa02fc4f6c7b159eb49.zip
doc: remove kasp db import/export topic
-rw-r--r--doc/migration.rst2
-rw-r--r--doc/operation.rst61
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