migration.rst 3.95 KB
Newer Older
1
.. highlight:: none
Libor Peltan's avatar
Libor Peltan committed
2
.. _Migration:
3

Libor Peltan's avatar
Libor Peltan committed
4 5 6 7
*********
Migration
*********

8
.. _Upgrade 2.4.x to 2.5.x:
Libor Peltan's avatar
Libor Peltan committed
9

10 11
Upgrade 2.4.x to 2.5.x
======================
Libor Peltan's avatar
Libor Peltan committed
12 13 14 15

This chapter describes some steps necessary after upgrading Knot DNS from
version 2.4.x to 2.5.x.

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
.. _Building changes:

Building changes
----------------

The ``--enable-dnstap`` configure option now enables the dnstap support in
kdig only! To build the dnstap query module, ``--with-module-dnstap`` have
to be used.

Since Knot DNS version 2.5.0 each query module can be configured to be:

- disabled: ``--with-module-``\ MODULE_NAME\ ``=no``
- embedded: ``--with-module-``\ MODULE_NAME\ ``=yes``
- external: ``--with-module-``\ MODULE_NAME\ ``=shared`` (excluding
  ``dnsproxy`` and ``onlinesign``)

The ``--with-timer-mapsize`` configure option was replaced with the runtime
:ref:`template_max-timer-db-size` configuration option.

Libor Peltan's avatar
Libor Peltan committed
35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
.. _KASP DB migration:

KASP DB migration
-----------------

Knot DNS version 2.4.x and earlier uses JSON files to store DNSSEC keys metadata,
one for each zone. 2.5.x versions store those in binary format in a LMDB, all zones
together. The migration is possible with ``pykeymgr`` script::

   $ pykeymgr -i path/to/keydir

The path to KASP DB directory is configuration-dependent, usually it is the ``keys``
subdirectory in the zone storage.

In rare installations, the JSON files might be spread across more directories. In such
case, it is necessary to put them together into one directory and migrate at once.

52
.. _Configuration changes 2.5:
Libor Peltan's avatar
Libor Peltan committed
53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68

Configuration changes
---------------------

It is no longer possible to configure KASP DB per zone or in a non-default
template. Ensure just one common KASP DB configuration in the default
template.

As Knot DNS version 2.5.0 brings dynamically loaded modules, some modules
were renamed for technical reasons. So it is necessary to rename all
occurrences (module section names and references from zones or templates)
of the following module names in the configuration::

   mod-online-sign -> mod-onlinesign

   mod-synth-record -> mod-synthrecord
69

70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87
.. _Upgrade 2.5.x to 2.6.x:

Upgrade 2.5.x to 2.6.x
======================

Upgrading from Knot DNS version 2.5.x to 2.6.x is almost seamless.

.. _Configuration changes 2.6:

Configuration changes
---------------------

The ``dsa`` and ``dsa-nsec3-sha1`` algorithm values are no longer supported
by the :ref:`policy_algorithm` option.

The ``ixfr-from-differences`` zone/template option was deprecated in favor of
the :ref:`zone_zonefile-load` option.

88 89 90 91 92 93 94 95 96 97
.. _Knot DNS for BIND users:

Knot DNS for BIND users
=======================

.. _Automatic DNSSEC signing:

Automatic DNSSEC signing
------------------------

98 99 100
Migrating automatically signed zones from BIND to Knot DNS requires copying
up-to-date zone files from BIND, importing existing private keys, and updating
server configuration:
101 102

1. To obtain current content of the zone which is being migrated,
Jan Včelák's avatar
Jan Včelák committed
103
   request BIND to flush the zone into the zone file: ``rndc flush
104
   example.com``.
105

106 107 108
   .. NOTE::
      If dynamic updates (DDNS) are enabled for the given zone, you
      might need to freeze the zone before flushing it. That can be done
109 110 111
      similarly::

      $ rndc freeze example.com
112

113 114
2. Copy the fresh zone file into the zones :ref:`storage<zone_storage>`
   directory of Knot DNS.
115

116 117
3. Import all existing zone keys into the KASP database. Make sure that all
   the keys were imported correctly::
118

119 120
   $ keymgr example.com. import-bind path/to/Kexample.com.+013+11111
   $ keymgr example.com. import-bind path/to/Kexample.com.+013+22222
121
   $ ...
122
   $ keymgr example.com. list
123

124 125 126 127 128 129
   .. NOTE::
      The server can be run under a dedicated user account, usually ``knot``.
      As the server requires read-write access to the KASP database, the
      permissions must be set correctly. This can be achieved for instance by
      executing all KASP database management commands under sudo::

130
      $ sudo -u knot keymgr ...
131

132
4. Follow :ref:`Automatic DNSSEC signing` steps to configure DNSSEC signing.