operation.rst 25 KB
Newer Older
1
.. highlight:: console
2
.. _Operation:
3

4
*********
5
Operation
6
*********
7

8 9 10
The Knot DNS server part ``knotd`` can run either in the foreground, or in the background
using the ``-d`` option. When run in the foreground, it doesn't create a PID file.
Other than that, there are no differences and you can control both the same way.
11

12
The tool ``knotc`` is designed as a user front-end, making it easier to control running
13
server daemon. If you want to control the daemon directly, use ``SIGINT`` to quit
14
the process or ``SIGHUP`` to reload the configuration.
15

16
If you pass neither configuration file (``-c`` parameter) nor configuration
17
database (``-C`` parameter), the server will first attempt to use the default
Daniel Salzman's avatar
Daniel Salzman committed
18 19 20
configuration database stored in ``/var/lib/knot/confdb`` or the
default configuration file stored in ``/etc/knot/knot.conf``. Both the
default paths can be reconfigured with ``--with-storage=path`` or
21
``--with-configdir=path`` respectively.
22 23 24 25 26

Example of server start as a daemon::

    $ knotd -d -c knot.conf

27
Example of server shutdown::
28 29 30

    $ knotc -c knot.conf stop

31 32
For a complete list of actions refer to the program help (``-h`` parameter)
or to the corresponding manual page.
Daniel Salzman's avatar
Daniel Salzman committed
33

34
Also, the server needs to create :ref:`server_rundir` and :ref:`zone_storage`
35
directories in order to run properly.
36

37
.. _Configuration database:
38

39 40 41
Configuration database
======================

42 43
In the case of a huge configuration file, the configuration can be stored
in a binary database. Such a database can be simply initialized::
44

45
    $ knotc conf-init
46

47
or preloaded from a file::
48

49 50 51 52 53
    $ knotc conf-import input.conf

Also the configuration database can be exported into a textual file::

    $ knotc conf-export output.conf
54

55 56 57 58
.. WARNING::
   The import and export commands access the configuration database
   directly, without any interaction with the server. So it is strictly
   recommended to perform these operations when the server is not running.
59 60 61 62 63 64

.. _Dynamic configuration:

Dynamic configuration
=====================

65
The configuration database can be accessed using the server control interface
66
during the running server. To get the full power of the dynamic configuration,
67 68 69
the server must be started with a specified configuration database location
or with the default database initialized. Otherwise all the changes to the
configuration will be temporary (until the server stop).
70

71 72
.. NOTE::
   The database can be :ref:`imported<Configuration database>` in advance.
73

74 75
Most of the commands get an item name and value parameters. The item name is
in the form of ``section[identifier].name``. If the item is multivalued,
76 77 78
more values can be specified as individual (command line) arguments. Beware of
the possibility of pathname expansion by the shell. For this reason, slashed
square brackets or quoted parameters is advisable.
79 80 81

To get the list of configuration sections or to get the list of section items::

82
    $ knotc conf-list
83
    $ knotc conf-list 'server'
84 85 86 87 88

To get the whole configuration or to get the whole configuration section or
to get all section identifiers or to get a specific configuration item::

    $ knotc conf-read
89 90 91
    $ knotc conf-read 'remote'
    $ knotc conf-read 'zone.domain'
    $ knotc conf-read 'zone[example.com].master'
92

93 94
.. WARNING::
   The following operations don't work on OpenBSD!
95 96 97

Modifying operations require an active configuration database transaction.
Just one transaction can be active at a time. Such a transaction then can
98
be aborted or committed. A semantic check is executed automatically before
99 100 101 102 103 104 105 106 107
every commit::

    $ knotc conf-begin
    $ knotc conf-abort
    $ knotc conf-commit

To set a configuration item value or to add more values or to add a new
section identifier or to add a value to all identified sections::

108 109 110 111
    $ knotc conf-set 'server.identity' 'Knot DNS'
    $ knotc conf-set 'server.listen' '0.0.0.0@53' '::@53'
    $ knotc conf-set 'zone[example.com]'
    $ knotc conf-set 'zone.slave' 'slave2'
112

113 114 115 116
.. NOTE::
   Also the include operation can be performed. A non-absolute file
   location is relative to the server binary path, not to the control binary
   path!::
117

118
      $ knotc conf-set 'include' '/tmp/new_zones.conf'
119 120 121 122 123 124

To unset the whole configuration or to unset the whole configuration section
or to unset an identified section or to unset an item or to unset a specific
item value::

    $ knotc conf-unset
125 126 127 128
    $ knotc conf-unset 'zone'
    $ knotc conf-unset 'zone[example.com]'
    $ knotc conf-unset 'zone[example.com].master'
    $ knotc conf-unset 'zone[example.com].master' 'remote2' 'remote5'
129 130 131 132 133 134

To get the change between the current configuration and the active transaction
for the whole configuration or for a specific section or for a specific
identified section or for a specific item::

    $ knotc conf-diff
135 136 137
    $ knotc conf-diff 'zone'
    $ knotc conf-diff 'zone[example.com]'
    $ knotc conf-diff 'zone[example.com].master'
138 139 140 141

An example of possible configuration initialization::

    $ knotc conf-begin
142 143 144 145 146 147 148
    $ knotc conf-set 'server.listen' '0.0.0.0@53' '::@53'
    $ knotc conf-set 'remote[master_server]'
    $ knotc conf-set 'remote[master_server].address' '192.168.1.1'
    $ knotc conf-set 'template[default]'
    $ knotc conf-set 'template[default].storage' '/var/lib/knot/zones/'
    $ knotc conf-set 'template[default].master' 'master_server'
    $ knotc conf-set 'zone[example.com]'
149 150 151
    $ knotc conf-diff
    $ knotc conf-commit

152 153
.. _Running a slave server:

154
Slave mode
155
==========
156 157

Running the server as a slave is very straightforward as you usually
158
bootstrap zones over AXFR and thus avoid any manual zone operations.
159
In contrast to AXFR, when the incremental transfer finishes, it stores
160
the differences in the journal file and doesn't update the zone file
161
immediately but after the :ref:`zone_zonefile-sync` period elapses.
162 163 164

.. _Running a master server:

165
Master mode
166
===========
167

168
If you just want to check the zone files before starting, you can use::
169

170
    $ knotc zone-check example.com
171

172 173 174 175 176 177 178
For an approximate estimation of server's memory consumption, you can use::

    $ knotc zone-memstats example.com

This action prints the count of resource records, percentage of signed
records and finally estimation of memory consumption for each zone, unless
specified otherwise. Please note that the estimated values may differ from the
179 180
actual consumption. Also, for slave servers with incoming transfers
enabled, be aware that the actual memory consumption might be double
181
or higher during transfers.
182

183 184 185 186 187 188 189 190
.. _Editing zones:

Reading and editing zones
=========================

Knot DNS allows you to read or change zone contents online using server
control interface.

191 192 193 194
.. WARNING::
   Avoid concurrent zone file modification, and/or dynamic updates, and/or
   zone changing over control interface. Otherwise, the zone could be inconsistent.

195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218
To get contents of all configured zones, or a specific zone contents, or zone
records with a specific owner, or even with a specific record type::

    $ knotc zone-read --
    $ knotc zone-read example.com
    $ knotc zone-read example.com ns1
    $ knotc zone-read example.com ns1 NS

.. NOTE::
   If the record owner is not a fully qualified domain name, then it is
   considered as a relative name to the zone name.

To start a writing transaction on all zones or on specific zones::

    $ knotc zone-begin --
    $ knotc zone-begin example.com example.net

Now you can list all nodes within the transaction using the ```zone-get```
command, which always returns current data with all changes included. The
command has the same syntax as ```zone-read```.

Within the transaction, you can add a record to a specific zone or to all
zones with an open transaction::

219 220
    $ knotc zone-set example.com ns1 3600 A 192.168.0.1
    $ knotc zone-set -- ns1 3600 A 192.168.0.1
221 222 223 224

To remove all records with a specific owner, or a specific rrset, or a
specific record data::

225 226 227
    $ knotc zone-unset example.com ns1
    $ knotc zone-unset example.com ns1 A
    $ knotc zone-unset example.com ns1 A 192.168.0.2
228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243

To see the difference between the original zone and the current version::

    $ knotc zone-diff example.com

Finally, either commit or abort your transaction::

    $ knotc zone-commit example.com
    $ knotc zone-abort example.com

A full example of setting up a completely new zone from scratch::

    $ knotc conf-begin
    $ knotc conf-set zone.domain example.com
    $ knotc conf-commit
    $ knotc zone-begin example.com
244 245 246
    $ knotc zone-set example.com @ 7200 SOA ns hostmaster 1 86400 900 691200 3600
    $ knotc zone-set example.com ns 3600 A 192.168.0.1
    $ knotc zone-set example.com www 3600 A 192.168.0.100
247 248
    $ knotc zone-commit example.com

249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273
.. _Editing zonefile:

Safe reading and editing zone file
==================================

It's always possible to read and edit the zone contents via zone file manipulation.
However, it may lead to confusion if zone contents are continuously changing or
in case of operator's mistake. This paragraph describes a safe way to modify zone
by editing zone file, taking advantage of zone freeze/thaw feature.::

    $ knotc zone-freeze example.com.
    $ while ! knotc zone-status example.com. +freeze | grep -q 'freeze: yes'; do sleep 1; done
    $ knotc zone-flush example.com.

After calling freeze to the zone, there still may be running zone operations (e.g. signing),
causing freeze pending. So we watch the zone status until frozen. Then we can flush the
frozen zone contents.

Now we open a text editor and perform desired changes to the zone file. It's necessary
to increase SOA serial in this step to keep consistency. Finaly, we can load the
modified zone file and if successful, thaw the zone.::

    $ knotc zone-reload example.com.
    $ knotc zone-thaw example.com.

274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290
.. _Journal behaviour:

Journal behaviour
=================

Zone journal keeps some history of changes of the zone. It is useful for
responding IXFR queries. Also if zone file flush is disabled,
journal keeps diff between zonefile and zone for the case of server shutdown.
The history is stored by changesets - diffs of zone contents between two
(usually subsequent) zone serials.

Journals for all zones are stored in common LMDB database. Huge changesets are
split into 70 KiB (this constant is hardcoded) blocks to prevent fragmentation of the DB.
Journal does each operation in one transaction to keep consistency of the DB and performance.
The exception is when store transaction exceeds 5% of the whole DB mapsize, it is split into multiple ones
and some dirty-chunks-management involves.

291 292
Each zone journal has own :ref:`usage limit <zone_max-journal-usage>`
on how much DB space it may occupy. Before hitting the limit,
293 294 295 296 297 298 299 300 301 302 303 304
changesets are stored one-by-one and whole history is linear. While hitting the limit,
the zone is flushed into zone file, and oldest changesets are deleted as needed to free
some space. Actually, twice (again, hardcoded constant) the needed amount is deleted to
prevent too frequent deletes. Further zone file flush is invoked after the journal runs out of deletable
"flushed changesets".

If zone file flush is disabled, instead of flushing the zone, the journal tries to
save space by merging older changesets into one. It works well if the changes rewrite
each other, e.g. periodically changing few zone records, re-signing whole zone...
The diff between zone file and zone is thus preserved, even if journal deletes some
older changesets.

305 306 307 308
If the journal is used to store both zone history and contents, a special changeset
is present with zone contents. When journal gets full, the changes are merged into this
special changeset.

309 310 311 312 313 314
There is also a :ref:`safety hard limit <template_max-journal-db-size>` for overall
journal database size, but it's strongly recommended to set the per-zone limits in
a way to prevent hitting this one. For LMDB, it's hard to recover from the
database-full state. For wiping one zone's journal, see *knotc zone-purge +journal*
command.

315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492
.. _DNSSEC Key rollovers:

DNSSEC key rollovers
====================

This section describes the process of DNSSEC key rollover and its implementation
in Knot DNS, and how the operator might watch and check that it's working correctly.
The prerequisite is automatic zone signing with enabled
:ref:`automatic key management<dnssec-automatic-ksk-management>`.

The KSK and ZSK rollovers are triggered by the respective zone key getting old according
to the settings (see :ref:`KSK<policy_ksk-lifetime>` and :ref:`ZSK<policy_zsk-lifetime>` lifetimes).

The algorithm rollover happens when the policy :ref:`algorithm<policy_algorithm>`
field is updated to a different value.

The operator may check the next rollover phase time by watching the next zone signing time,
either in the log or via ``knotc zone-status``. There is no special log for finishing a rollover.

.. NOTE::
   There are never two key rollovers running in parallel for one zone. If
   a rollover is triggered while another is in progress, it waits until the
   first one is finished.

.. _DNSSEC KSK rollover example:

KSK rollover example
--------------------

Let's start with the following set of keys::

  2017-10-24T15:40:48 info: [example.com.] DNSSEC, key, tag  4700, algorithm RSASHA256, KSK, public, active
  2017-10-24T15:40:48 info: [example.com.] DNSSEC, key, tag 30936, algorithm RSASHA256, public, active

The last fields hint the key state: ``public`` denotes a key that will be presented
as the DNSKEY record, ``ready`` means that CDS/CDNSKEY records were created,
``active`` tells us if the key is used for signing.

Upon the zone's KSK lifetime expiration, the rollover continues along the
lines of :rfc:`6781#section-4.1.2`::

  2017-10-24T15:41:17 info: [example.com.] DNSSEC, signing zone
  2017-10-24T15:41:18 info: [example.com.] DNSSEC, KSK rollover started
  2017-10-24T15:41:18 info: [example.com.] DNSSEC, key, tag  6674, algorithm RSASHA256, KSK, public
  2017-10-24T15:41:18 info: [example.com.] DNSSEC, key, tag  4700, algorithm RSASHA256, KSK, public, active
  2017-10-24T15:41:18 info: [example.com.] DNSSEC, key, tag 30936, algorithm RSASHA256, public, active
  2017-10-24T15:41:18 info: [example.com.] DNSSEC, signing started
  2017-10-24T15:41:18 info: [example.com.] DNSSEC, successfully signed
  2017-10-24T15:41:18 info: [example.com.] DNSSEC, next signing at 2017-10-24T15:41:22
  ...
  2017-10-24T15:41:22 info: [example.com.] DNSSEC, signing zone
  2017-10-24T15:41:22 info: [example.com.] DNSSEC, key, tag  4700, algorithm RSASHA256, KSK, public, active
  2017-10-24T15:41:22 info: [example.com.] DNSSEC, key, tag  6674, algorithm RSASHA256, KSK, public, ready, active
  2017-10-24T15:41:22 info: [example.com.] DNSSEC, key, tag 30936, algorithm RSASHA256, public, active
  2017-10-24T15:41:22 info: [example.com.] DNSSEC, signing started
  2017-10-24T15:41:22 info: [example.com.] DNSSEC, successfully signed
  2017-10-24T15:41:22 info: [example.com.] DNSSEC, next signing at 2017-10-24T15:41:23
  2017-10-24T15:41:22 notice: [example.com.] DNSSEC, published CDS, CDNSKEY for submission

At this point new KSK has to be submitted to the parent zone. Knot detects the updated parent's DS
record automatically if :ref:`parent DS check<Submission section>` is configured, otherwise the
operator must confirm it manually with ``knotc zone-ksk-submitted``::

  2017-10-24T15:41:23 info: [example.com.] DNSSEC, signing zone
  2017-10-24T15:41:23 info: [example.com.] DNSSEC, key, tag  6674, algorithm RSASHA256, KSK, public, active
  2017-10-24T15:41:23 info: [example.com.] DNSSEC, key, tag  4700, algorithm RSASHA256, KSK, public, active
  2017-10-24T15:41:23 info: [example.com.] DNSSEC, key, tag 30936, algorithm RSASHA256, public, active
  2017-10-24T15:41:23 info: [example.com.] DNSSEC, signing started
  2017-10-24T15:41:23 info: [example.com.] DNSSEC, zone is up-to-date
  2017-10-24T15:41:23 info: [example.com.] DNSSEC, next signing at 2017-10-24T15:41:28
  ...
  2017-10-24T15:41:28 info: [example.com.] DNSSEC, signing zone
  2017-10-24T15:41:28 info: [example.com.] DNSSEC, key, tag  4700, algorithm RSASHA256, KSK, public
  2017-10-24T15:41:28 info: [example.com.] DNSSEC, key, tag  6674, algorithm RSASHA256, KSK, public, active
  2017-10-24T15:41:28 info: [example.com.] DNSSEC, key, tag 30936, algorithm RSASHA256, public, active
  2017-10-24T15:41:28 info: [example.com.] DNSSEC, signing started
  2017-10-24T15:41:28 info: [example.com.] DNSSEC, successfully signed
  2017-10-24T15:41:28 info: [example.com.] DNSSEC, next signing at 2017-10-24T15:41:33
  ...
  2017-10-24T15:41:33 info: [example.com.] DNSSEC, signing zone
  2017-10-24T15:41:33 info: [example.com.] DNSSEC, key, tag  6674, algorithm RSASHA256, KSK, public, active
  2017-10-24T15:41:33 info: [example.com.] DNSSEC, key, tag 30936, algorithm RSASHA256, public, active
  2017-10-24T15:41:33 info: [example.com.] DNSSEC, signing started
  2017-10-24T15:41:33 info: [example.com.] DNSSEC, successfully signed
  2017-10-24T15:41:33 info: [example.com.] DNSSEC, next signing at 2017-10-24T15:41:47

Algorithm rollover example
--------------------------

Let's start with the following set of keys::

  2017-10-24T14:53:06 info: [example.com.] DNSSEC, key, tag 65225, algorithm RSASHA256, KSK, public, active
  2017-10-24T14:53:06 info: [example.com.] DNSSEC, key, tag 47014, algorithm RSASHA256, public, active

When the zone's DNSSEC policy algorithm is changed to ``ECDSAP256SHA256`` and the
server is reloaded, the rollover continues along the lines of :rfc:`6781#section-4.1.4`::

  2017-10-24T14:53:26 info: [example.com.] DNSSEC, algorithm rollover started
  2017-10-24T14:53:26 info: [example.com.] DNSSEC, key, tag 34608, algorithm ECDSAP256SHA256, KSK
  2017-10-24T14:53:26 info: [example.com.] DNSSEC, key, tag 13674, algorithm ECDSAP256SHA256, active
  2017-10-24T14:53:26 info: [example.com.] DNSSEC, key, tag 65225, algorithm RSASHA256, KSK, public, active
  2017-10-24T14:53:26 info: [example.com.] DNSSEC, key, tag 47014, algorithm RSASHA256, public, active
  2017-10-24T14:53:26 info: [example.com.] DNSSEC, signing started
  2017-10-24T14:53:26 info: [example.com.] DNSSEC, successfully signed
  2017-10-24T14:53:26 info: [example.com.] DNSSEC, next signing at 2017-10-24T14:53:34
  ...
  2017-10-24T14:53:34 info: [example.com.] DNSSEC, signing zone
  2017-10-24T14:53:34 info: [example.com.] DNSSEC, key, tag 34608, algorithm ECDSAP256SHA256, KSK, public, active
  2017-10-24T14:53:34 info: [example.com.] DNSSEC, key, tag 13674, algorithm ECDSAP256SHA256, public, active
  2017-10-24T14:53:34 info: [example.com.] DNSSEC, key, tag 65225, algorithm RSASHA256, KSK, public, active
  2017-10-24T14:53:34 info: [example.com.] DNSSEC, key, tag 47014, algorithm RSASHA256, public, active
  2017-10-24T14:53:34 info: [example.com.] DNSSEC, signing started
  2017-10-24T14:53:34 info: [example.com.] DNSSEC, successfully signed
  2017-10-24T14:53:34 info: [example.com.] DNSSEC, next signing at 2017-10-24T14:53:44
  ...
  2017-10-24T14:53:44 info: [example.com.] DNSSEC, signing zone
  2017-10-24T14:53:44 info: [example.com.] DNSSEC, key, tag 34608, algorithm ECDSAP256SHA256, KSK, public, ready, active
  2017-10-24T14:53:44 info: [example.com.] DNSSEC, key, tag 13674, algorithm ECDSAP256SHA256, public, active
  2017-10-24T14:53:44 info: [example.com.] DNSSEC, key, tag 65225, algorithm RSASHA256, KSK, public, active
  2017-10-24T14:53:44 info: [example.com.] DNSSEC, key, tag 47014, algorithm RSASHA256, public, active
  2017-10-24T14:53:44 info: [example.com.] DNSSEC, signing started
  2017-10-24T14:53:44 info: [example.com.] DNSSEC, successfully signed
  2017-10-24T14:53:44 info: [example.com.] DNSSEC, next signing at 2017-10-31T13:52:37
  2017-10-24T14:53:44 notice: [example.com.] DNSSEC, published CDS, CDNSKEY for submission

Again, KSK submission follows as in :ref:`KSK rollover example<DNSSEC ksk rollover example>`.::

  2017-10-24T14:54:20 info: [example.com.] control, received command 'zone-ksk-submitted'
  2017-10-24T14:54:20 info: [example.com.] DNSSEC, signing zone
  2017-10-24T14:54:20 info: [example.com.] DNSSEC, key, tag 34608, algorithm ECDSAP256SHA256, KSK, public, active
  2017-10-24T14:54:20 info: [example.com.] DNSSEC, key, tag 13674, algorithm ECDSAP256SHA256, public, active
  2017-10-24T14:54:20 info: [example.com.] DNSSEC, key, tag 65225, algorithm RSASHA256, KSK, public, active
  2017-10-24T14:54:20 info: [example.com.] DNSSEC, key, tag 47014, algorithm RSASHA256, public, active
  2017-10-24T14:54:20 info: [example.com.] DNSSEC, signing started
  2017-10-24T14:54:21 info: [example.com.] DNSSEC, zone is up-to-date
  2017-10-24T14:54:21 info: [example.com.] DNSSEC, next signing at 2017-10-24T14:54:30
  ...
  2017-10-24T14:54:30 info: [example.com.] DNSSEC, signing zone
  2017-10-24T14:54:30 info: [example.com.] DNSSEC, key, tag 34608, algorithm ECDSAP256SHA256, KSK, public, active
  2017-10-24T14:54:30 info: [example.com.] DNSSEC, key, tag 13674, algorithm ECDSAP256SHA256, public, active
  2017-10-24T14:54:30 info: [example.com.] DNSSEC, key, tag 65225, algorithm RSASHA256, KSK
  2017-10-24T14:54:30 info: [example.com.] DNSSEC, key, tag 47014, algorithm RSASHA256, active
  2017-10-24T14:54:30 info: [example.com.] DNSSEC, signing started
  2017-10-24T14:54:30 info: [example.com.] DNSSEC, successfully signed
  2017-10-24T14:54:30 info: [example.com.] DNSSEC, next signing at 2017-10-24T14:54:40
  ...
  2017-10-24T14:54:40 info: [example.com.] DNSSEC, signing zone
  2017-10-24T14:54:40 info: [example.com.] DNSSEC, key, tag 34608, algorithm ECDSAP256SHA256, KSK, public, active
  2017-10-24T14:54:40 info: [example.com.] DNSSEC, key, tag 13674, algorithm ECDSAP256SHA256, public, active
  2017-10-24T14:54:40 info: [example.com.] DNSSEC, signing started
  2017-10-24T14:54:40 info: [example.com.] DNSSEC, successfully signed
  2017-10-24T14:54:40 info: [example.com.] DNSSEC, next signing at 2017-10-31T13:53:26

.. _DNSSEC Shared KSK:

DNSSEC shared KSK
=================

Knot DNS allows, with automatic DNSSEC key management, to configure a shared KSK for multiple zones.
By enabling :ref:`policy_ksk-shared`, we tell Knot to share all newly-created KSKs
among all the zones with the same :ref:`DNSSEC signing policy<Policy section>` assigned.

The feature works as follows. Each zone still manages its keys separately. If a new KSK shall be
generated for the zone, it first checks if it can grab another zone's shared KSK instead -
that is the last generated KSK in any of the zones with the same policy assigned.
Anyway, only the cryptographic material is shared, the key may have different timers
in each zone.

Consequences:

If we have an initial setting with brand new zones without any DNSSEC keys,
the initial keys for all zones are generated. With shared KSK, they will all have the same KSK,
but different ZSKs. The KSK rollovers may take place at slightly different time for each of the zones,
but the resulting new KSK will be shared again among all of them.

If we have zones already having their keys, turning on the shared KSK feature triggers no action.
But when a KSK rollover takes place, they will use the same new key afterwards.

Libor Peltan's avatar
Libor Peltan committed
493 494 495 496 497 498 499 500 501 502
.. _DNSSEC Delete algorithm:

DNSSEC delete algorithm
=======================

This is a way how to "disconnect" a signed zone from DNSSEC-aware parent zone.
More precisely, we tell the parent zone to remove our zone's DS record by
publishing a special formatted CDNSKEY and CDS record. This is mostly useful
if we want to turn off DNSSEC on our zone so it becomes insecure, but not bogus.

503 504 505 506
With automatic DNSSEC signing and key management by Knot, this is as easy as
configuring :ref:`policy_child-records-publish` option and reloading the configuration.
We check if the special CDNSKEY and CDS records with the rdata "0 3 0 AA==" and "0 0 0 00",
respectively, appeared in the zone.
Libor Peltan's avatar
Libor Peltan committed
507 508 509

After the parent zone notices and reflects the change, we wait for TTL expire
(so all resolvers' caches get updated), and finally we may do anything with the
510
zone, e.g. turning off DNSSEC, removing all the keys and signatures as desired.
511

512 513
.. _Controlling running daemon:

514
Daemon controls
515
===============
516 517

Knot DNS was designed to allow server reconfiguration on-the-fly
518
without interrupting its operation. Thus it is possible to change
519
both configuration and zone files and also add or remove zones without
520
restarting the server. This can be done with::
521

522
    $ knotc reload
523

524
If you want to refresh the slave zones, you can do this with::
525

526
    $ knotc zone-refresh
527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547

.. _Statistics:

Statistics
==========

The server provides some general statistics and optional query module statistics
(see :ref:`mod-stats<mod-stats>`).

Server statistics or global module statistics can be shown by::

    $ knotc stats
    $ knotc stats server             # Show all server counters
    $ knotc stats mod-stats          # Show all mod-stats counters
    $ knotc stats server.zone-count  # Show specific server counter

Per zone statistics can be shown by::

    $ knotc zone-stats example.com mod-stats

To show all supported counters even with 0 value use the force option.
548 549 550 551 552 553 554 555 556

A simple periodic statistic dumping to a YAML file can also be enabled. See
:ref:`statistics_section` for the configuration details.

As the statistics data can be accessed over the server control socket,
it is possible to create an arbitrary script (Python is supported at the moment)
which could, for example, publish the data in the JSON format via HTTP(S)
or upload the data to a more efficient time series database. Take a look into
the python folder of the project for these scripts.