1.. highlight:: console 2.. _Operation: 3 4********* 5Operation 6********* 7 8The Knot DNS server part :doc:`knotd<man_knotd>` can run either in the foreground, 9or in the background using the ``-d`` option. When run in the foreground, it 10doesn't create a PID file. Other than that, there are no differences and you 11can control both the same way. 12 13The tool :doc:`knotc<man_knotc>` is designed as a user front-end, making it easier 14to control a running server daemon. If you want to control the daemon directly, 15use ``SIGINT`` to quit the process or ``SIGHUP`` to reload the configuration. 16 17If you pass neither configuration file (``-c`` parameter) nor configuration 18database (``-C`` parameter), the server will first attempt to use the default 19configuration database stored in ``/var/lib/knot/confdb`` or the 20default configuration file stored in ``/etc/knot/knot.conf``. Both the 21default paths can be reconfigured with ``--with-storage=path`` or 22``--with-configdir=path`` respectively. 23 24Example of server start as a daemon:: 25 26 $ knotd -d -c knot.conf 27 28Example of server shutdown:: 29 30 $ knotc -c knot.conf stop 31 32For a complete list of actions refer to the program help (``-h`` parameter) 33or to the corresponding manual page. 34 35Also, the server needs to create :ref:`server_rundir` and :ref:`zone_storage` 36directories in order to run properly. 37 38.. _Configuration database: 39 40Configuration database 41====================== 42 43In the case of a huge configuration file, the configuration can be stored 44in a binary database. Such a database can be simply initialized:: 45 46 $ knotc conf-init 47 48or preloaded from a file:: 49 50 $ knotc conf-import input.conf 51 52Also the configuration database can be exported into a textual file:: 53 54 $ knotc conf-export output.conf 55 56.. WARNING:: 57 The import and export commands access the configuration database 58 directly, without any interaction with the server. Therefore, any data 59 not yet committed to the database won't be exported. And the server won't 60 reflect imported configuration correctly. So it is strictly recommended to 61 import new configuration when the server is not running. 62 63.. _Dynamic configuration: 64 65Dynamic configuration 66===================== 67 68The configuration database can be accessed using the server control interface 69while the server is running. To get the full power of the dynamic configuration, 70the server must be started with a specified configuration database location 71or with the default database initialized. Otherwise all the changes to the 72configuration will be temporary (until the server is stopped). 73 74.. NOTE:: 75 The database can be :ref:`imported<Configuration database>` in advance. 76 77Most of the commands get an item name and value parameters. The item name is 78in the form of ``section[identifier].name``. If the item is multivalued, 79more values can be specified as individual (command line) arguments. 80 81.. CAUTION:: 82 Beware of the possibility of pathname expansion by the shell. For this reason, 83 it is advisable to escape (with backslash) square brackets or to quote command parameters if 84 not executed in the interactive mode. 85 86To get the list of configuration sections or to get the list of section items:: 87 88 $ knotc conf-list 89 $ knotc conf-list 'server' 90 91To get the whole configuration or to get the whole configuration section or 92to get all section identifiers or to get a specific configuration item:: 93 94 $ knotc conf-read 95 $ knotc conf-read 'remote' 96 $ knotc conf-read 'zone.domain' 97 $ knotc conf-read 'zone[example.com].master' 98 99.. WARNING:: 100 The following operations don't work on OpenBSD! 101 102Modifying operations require an active configuration database transaction. 103Just one transaction can be active at a time. Such a transaction then can 104be aborted or committed. A semantic check is executed automatically before 105every commit:: 106 107 $ knotc conf-begin 108 $ knotc conf-abort 109 $ knotc conf-commit 110 111To set a configuration item value or to add more values or to add a new 112section identifier or to add a value to all identified sections:: 113 114 $ knotc conf-set 'server.identity' 'Knot DNS' 115 $ knotc conf-set 'server.listen' '0.0.0.0@53' '::@53' 116 $ knotc conf-set 'zone[example.com]' 117 $ knotc conf-set 'zone.slave' 'slave2' 118 119.. NOTE:: 120 Also the include operation can be performed. A non-absolute file 121 location is relative to the server binary path, not to the control binary 122 path! 123 124 :: 125 126 $ knotc conf-set 'include' '/tmp/new_zones.conf' 127 128To unset the whole configuration or to unset the whole configuration section 129or to unset an identified section or to unset an item or to unset a specific 130item value:: 131 132 $ knotc conf-unset 133 $ knotc conf-unset 'zone' 134 $ knotc conf-unset 'zone[example.com]' 135 $ knotc conf-unset 'zone[example.com].master' 136 $ knotc conf-unset 'zone[example.com].master' 'remote2' 'remote5' 137 138To get the change between the current configuration and the active transaction 139for the whole configuration or for a specific section or for a specific 140identified section or for a specific item:: 141 142 $ knotc conf-diff 143 $ knotc conf-diff 'zone' 144 $ knotc conf-diff 'zone[example.com]' 145 $ knotc conf-diff 'zone[example.com].master' 146 147.. CAUTION:: 148 While it is possible to change most of the configuration parameters 149 dynamically or via configuration file reload, a few of the parameters 150 in the section ``server`` require restarting the server, such that the changes 151 take effect. These parameters are: 152 :ref:`rundir<server_rundir>`, 153 :ref:`user<server_user>`, 154 :ref:`pidfile<server_pidfile>`, 155 :ref:`tcp-reuseport<server_tcp-reuseport>`, 156 :ref:`udp-workers<server_udp-workers>`, 157 :ref:`tcp-workers<server_tcp-workers>`, 158 :ref:`background-workers<server_background-workers>`, and 159 :ref:`listen<server_listen>`. 160 161An example of possible configuration initialization:: 162 163 $ knotc conf-begin 164 $ knotc conf-set 'server.listen' '0.0.0.0@53' '::@53' 165 $ knotc conf-set 'remote[master_server]' 166 $ knotc conf-set 'remote[master_server].address' '192.168.1.1' 167 $ knotc conf-set 'template[default]' 168 $ knotc conf-set 'template[default].storage' '/var/lib/knot/zones/' 169 $ knotc conf-set 'template[default].master' 'master_server' 170 $ knotc conf-set 'zone[example.com]' 171 $ knotc conf-diff 172 $ knotc conf-commit 173 174.. _Secondary mode: 175 176Secondary (slave) mode 177====================== 178 179Running the server as a secondary server is very straightforward as you 180usually bootstrap zones over AXFR and thus avoid any manual zone operations. 181In contrast to AXFR, when the incremental transfer finishes, it stores 182the differences in the journal file and doesn't update the zone file 183immediately but after the :ref:`zone_zonefile-sync` period elapses. 184 185.. _Primary mode: 186 187Primary (master) mode 188===================== 189 190If you just want to check the zone files before starting, you can use:: 191 192 $ knotc zone-check example.com 193 194.. _Editing zones: 195 196Reading and editing zones 197========================= 198 199Knot DNS allows you to read or change zone contents online using the server 200control interface. 201 202.. WARNING:: 203 Avoid concurrent zone access when a zone event (zone file load, refresh, 204 DNSSEC signing, dynamic update) is in progress or pending. In such a case 205 zone events must be frozen before. For more information on how to freeze the 206 zone read :ref:`Editing zone file`. 207 208To get contents of all configured zones, or a specific zone contents, or zone 209records with a specific owner, or even with a specific record type:: 210 211 $ knotc zone-read -- 212 $ knotc zone-read example.com 213 $ knotc zone-read example.com ns1 214 $ knotc zone-read example.com ns1 NS 215 216.. NOTE:: 217 If the record owner is not a fully qualified domain name, then it is 218 considered as a relative name to the zone name. 219 220To start a writing transaction on all zones or on specific zones:: 221 222 $ knotc zone-begin -- 223 $ knotc zone-begin example.com example.net 224 225Now you can list all nodes within the transaction using the ```zone-get``` 226command, which always returns current data with all changes included. The 227command has the same syntax as ```zone-read```. 228 229Within the transaction, you can add a record to a specific zone or to all 230zones with an open transaction:: 231 232 $ knotc zone-set example.com ns1 3600 A 192.168.0.1 233 $ knotc zone-set -- ns1 3600 A 192.168.0.1 234 235To remove all records with a specific owner, or a specific rrset, or 236specific record data:: 237 238 $ knotc zone-unset example.com ns1 239 $ knotc zone-unset example.com ns1 A 240 $ knotc zone-unset example.com ns1 A 192.168.0.2 241 242To see the difference between the original zone and the current version:: 243 244 $ knotc zone-diff example.com 245 246Finally, either commit or abort your transaction:: 247 248 $ knotc zone-commit example.com 249 $ knotc zone-abort example.com 250 251A full example of setting up a completely new zone from scratch:: 252 253 $ knotc conf-begin 254 $ knotc conf-set zone.domain example.com 255 $ knotc conf-commit 256 $ knotc zone-begin example.com 257 $ knotc zone-set example.com @ 7200 SOA ns hostmaster 1 86400 900 691200 3600 258 $ knotc zone-set example.com ns 3600 A 192.168.0.1 259 $ knotc zone-set example.com www 3600 A 192.168.0.100 260 $ knotc zone-commit example.com 261 262.. NOTE:: 263 If quotes are necessary for record data specification, remember to escape them:: 264 265 $ knotc zone-set example.com @ 3600 TXT \"v=spf1 a:mail.example.com -all\" 266 267.. _Editing zone file: 268 269Reading and editing the zone file safely 270======================================== 271 272It's always possible to read and edit zone contents via zone file manipulation. 273It may lead to confusion, however, if the zone contents are continuously being 274changed by DDNS, DNSSEC signing and the like. In such a case, the safe way to 275modify the zone file is to freeze zone events first:: 276 277 $ knotc -b zone-freeze example.com. 278 $ knotc -b zone-flush example.com. 279 280After calling freeze on the zone, there still may be running zone operations (e.g. signing), 281causing freeze pending. Because of this, the blocking mode is used to ensure 282the operation was finished. Then the zone can be flushed to a file. 283 284Now the zone file can be safely modified (e.g. using a text editor). 285If :ref:`zone_zonefile-load` is not set to `difference-no-serial`, it's also necessary to 286**increase SOA serial** in this step to keep consistency. Finally, we can load the 287modified zone file and if successful, thaw the zone:: 288 289 $ knotc -b zone-reload example.com. 290 $ knotc zone-thaw example.com. 291 292.. _Zone loading: 293 294Zone loading 295============ 296 297The process of how the server loads a zone is influenced by the configuration of the 298:ref:`zonefile-load <zone_zonefile-load>` and :ref:`journal-content <zone_journal-content>` 299parameters (also DNSSEC signing applies), the existence of a zone file and journal 300(and their relative out-of-dateness), and whether it is a cold start of the server 301or a zone reload (e.g. invoked by the :doc:`knotc<man_knotc>` interface). Please note 302that zone transfers are not taken into account here – they are planned after the zone 303is loaded (including AXFR bootstrap). 304 305If the zone file exists and is not excluded by the configuration, it is first loaded 306and according to its SOA serial number, relevant journal changesets are applied. 307If this is a zone reload and we have :ref:`zone_zonefile-load` set to `difference`, the difference 308between old and new contents is computed and stored in the journal like an update. 309The zone file should be either unchanged since last load or changed with incremented 310SOA serial. In the case of a decreased SOA serial, the load is interrupted with 311an error; if unchanged, it is increased by the server. 312 313If the procedure described above succeeds without errors, the resulting zone contents are (after potential DNSSEC signing) 314used as the new zone. 315 316The option :ref:`zone_journal-content` set to `all` lets the server, beside better performance, keep 317track of the zone contents also across server restarts. It makes the cold start 318effectively work like a zone reload with the old contents loaded from the journal 319(unless this is the very first start with the zone not yet saved into the journal). 320 321.. _Journal behaviour: 322 323Journal behaviour 324================= 325 326The zone journal keeps some history of changes made to the zone. It is useful for 327responding to IXFR queries. Also if :ref:`zone file flush <zone_zonefile-sync>` is disabled, the 328journal keeps the difference between the zone file and the current zone in case of server shutdown. 329The history is stored in changesets – differences of zone contents between two 330(usually subsequent) zone versions (specified by SOA serials). 331 332Journals of all zones are stored in a common LMDB database. Huge changesets are 333split into 70 KiB [#fn-hc]_ blocks to prevent fragmentation of the DB. The 334journal does each operation in one transaction to keep consistency of the DB and performance. 335 336Each zone journal has its own occupation limits :ref:`maximum usage <zone_journal-max-usage>` 337and :ref:`maximum depth <zone_journal-max-depth>`. Changesets are stored in the journal 338one by one. When hitting any of the limits, the zone is flushed into the zone file 339if there are no redundant changesets to delete, and the oldest changesets are deleted. 340In the case of the size limit, twice [#fn-hc]_ the needed amount of space is purged 341to prevent overly frequent deletes. 342 343If :ref:`zone file flush <zone_zonefile-sync>` is disabled, then instead of flushing 344the zone, the journal tries to save space by merging the changesets into a special one. 345This approach is effective if the changes rewrite each other, e.g. periodically 346changing the same zone records, re-signing the whole zone etc. Thus the difference between the zone 347file and the zone is still preserved even if the journal deletes some older changesets. 348 349If the journal is used to store both zone history and contents, a special changeset 350is present with zone contents. When the journal gets full, the changes are merged into this 351special changeset. 352 353There is also a :ref:`safety hard limit <database_journal-db-max-size>` for overall 354journal database size, but it's strongly recommended to set the per-zone limits in 355a way to prevent hitting this one. For LMDB, it's hard to recover from the 356database-full state. For wiping one zone's journal, see *knotc zone-purge +journal* 357command. 358 359.. [#fn-hc] This constant is hardcoded. 360 361.. _Handling, zone file, journal, changes, serials: 362 363Handling zone file, journal, changes, serials 364============================================= 365 366Some configuration options regarding the zone file and journal, together with operation 367procedures, might lead to unexpected results. This chapter points out 368potential interference and both recommends and warns before some combinations thereof. 369Unfortunately, there is no optimal combination of configuration options, 370every approach has some disadvantages. 371 372Example 1 373--------- 374 375Keep the zone file updated:: 376 377 zonefile-sync: 0 378 zonefile-load: whole 379 journal-content: changes 380 381These are default values. The user can always check the current zone 382contents in the zone file, and also modify it (recommended with server turned-off or 383taking the :ref:`safe way<Editing zone file>`). The journal serves here just as a source of 384history for secondary servers' IXFR. Some users dislike that the server overwrites their 385prettily prepared zone file. 386 387Example 2 388--------- 389 390Zonefileless setup:: 391 392 zonefile-sync: -1 393 zonefile-load: none 394 journal-content: all 395 396Zone contents are stored only in the journal. The zone is updated by DDNS, 397zone transfer, or via the control interface. The user might have filled the 398zone contents initially from a zone file by setting :ref:`zone_zonefile-load` to 399`whole` temporarily. 400It's also a good setup for secondary servers. Anyway, it's recommended to carefully tune 401the journal-size-related options to avoid surprises like the journal getting full. 402 403Example 3 404--------- 405 406Input-only zone file:: 407 408 zonefile-sync: -1 409 zonefile-load: difference 410 journal-content: changes 411 412The user can make changes to the zone by editing the zone file, and his pretty zone file 413is never overwritten or filled with DNSSEC-related autogenerated records – they are 414only stored in the journal. 415 416The zone file's SOA serial must be properly set to a number which is higher than the 417current SOA serial in the zone (not in the zone file) if manually updated! 418 419Example 4 420--------- 421 422Auto-increment SOA serial:: 423 424 zonefile-sync: -1 425 zonefile-load: difference-no-serial 426 journal-content: all 427 428This is similar to the previous setup, but the SOA serial is handled by the server 429automatically. So the user no longer needs to care about it in the zone file. 430 431However, this requires setting :ref:`zone_journal-content` to `all` so that 432the information about the last real SOA serial is preserved in case of server re-start. 433 434.. _DNSSEC Key states: 435 436DNSSEC key states 437================= 438 439During its lifetime, a DNSSEC key finds itself in different states. Most of the time it 440is used for signing the zone and published in the zone. In order to exchange 441the key, one type of a key rollover is necessary, and during this rollover, 442the key goes through various states with respect to the rollover type and also the 443state of the other key being rolled-over. 444 445First, let's list the states of the key being rolled-in. 446 447Standard states: 448 449- ``active`` — The key is used for signing. 450- ``published`` — The key is published in the zone, but not used for signing. If the key is 451 a KSK or CSK, it is used for signing the DNSKEY RRSet. 452- ``ready`` (only for KSK) — The key is published in the zone and used for signing. The 453 old key is still active, since we are waiting for the DS records in the parent zone to be 454 updated (i.e. "KSK submission"). 455 456Special states for algorithm rollover: 457 458- ``pre-active`` — The key is not yet published in the zone, but it's used for signing the zone. 459- ``published`` — The key is published in the zone, and it's still used for signing since the 460 pre-active state. 461 462Second, we list the states of the key being rolled-out. 463 464Standard states: 465 466- ``retire-active`` — The key is still used for signing, and is published in the zone, waiting for 467 the updated DS records in parent zone to be acked by resolvers (KSK case) or synchronizing 468 with KSK during algorithm rollover (ZSK case). 469- ``retired`` — The key is no longer used for signing. If ZSK, the key is still published in the zone. 470- ``removed`` — The key is not used in any way (in most cases such keys are deleted immediately). 471 472Special states for algorithm rollover: 473 474- ``post-active`` — The key is no longer published in the zone, but still used for signing. 475 476Special states for :rfc:`5011` trust anchor roll-over 477 478- ``revoke`` (only for KSK) — The key is published and used for signing, and the Revoked flag is set. 479 480.. NOTE:: 481 Trust anchor roll-over is not implemented with automatic key management. 482 483 The ``revoke`` state can only be established using :doc:`keymgr<man_keymgr>` when using 484 :ref:`dnssec-manual-key-management`. 485 486The states listed above are relevant for :doc:`keymgr<man_keymgr>` operations like generating 487a key, setting its timers and listing KASP database. 488 489Note that the key "states" displayed in the server log lines while zone signing 490are not according to those listed above, but just a hint as to what the key is currently used for 491(e.g. "public, active" = key is published in the zone and used for signing). 492 493.. _DNSSEC Key rollovers: 494 495DNSSEC key rollovers 496==================== 497 498This section describes the process of DNSSEC key rollover and its implementation 499in Knot DNS, and how the operator might watch and check that it's working correctly. 500The prerequisite is automatic zone signing with enabled 501:ref:`automatic key management<dnssec-automatic-ksk-management>`. 502 503The KSK and ZSK rollovers are triggered by the respective zone key getting old according 504to the settings (see :ref:`KSK<policy_ksk-lifetime>` and :ref:`ZSK<policy_zsk-lifetime>` lifetimes). 505 506The algorithm rollover starts when the policy :ref:`algorithm<policy_algorithm>` 507field is updated to a different value. 508 509The signing scheme rollover happens when the policy :ref:`signing scheme<policy_single-type-signing>` 510field is changed. 511 512It's also possible to change the algorithm and signing scheme in one rollover. 513 514The operator may check the next rollover phase time by watching the next zone signing time, 515either in the log or via ``knotc zone-status``. There is no special log for finishing a rollover. 516 517.. NOTE:: 518 There are never two key rollovers running in parallel for one zone. If 519 a rollover is triggered while another is in progress, it waits until the 520 first one is finished. 521 522The ZSK rollover is performed with Pre-publish method, KSK rollover uses Double-Signature 523scheme, as described in :rfc:`6781`. 524 525.. _Automatic KSK and ZSK rollovers example: 526 527Automatic KSK and ZSK rollovers example 528--------------------------------------- 529 530Let's start with the following set of keys:: 531 532 2021-05-10T20:50:00+0200 info: [example.com.] DNSSEC, key, tag 50613, algorithm ECDSAP256SHA256, KSK, public, active 533 2021-05-10T20:50:00+0200 info: [example.com.] DNSSEC, key, tag 62932, algorithm ECDSAP256SHA256, public, active 534 535The last fields hint the key state: ``public`` denotes a key that will be presented 536as the DNSKEY record, ``ready`` means that CDS/CDNSKEY records were created, 537``active`` tells us that the key is used for signing, while ``active+`` is an 538active key undergoing a roll-over or roll-in. 539 540For demonstration purposes, the following configuration is used:: 541 542 submission: 543 - id: test_submission 544 check-interval: 2s 545 parent: dnssec_validating_resolver 546 547 policy: 548 - id: test_policy 549 ksk-lifetime: 5m 550 zsk-lifetime: 2m 551 propagation-delay: 2s 552 dnskey-ttl: 10s 553 zone-max-ttl: 15s 554 ksk-submission: test_submission 555 556Upon the zone's KSK lifetime expiration, a new KSK is generated and the rollover 557continues along the lines of :rfc:`6781#section-4.1.2`:: 558 559 # KSK Rollover (50613 -> 9081) 560 561 2021-05-10T20:50:00+0200 info: [example.com.] DNSSEC, signing zone 562 2021-05-10T20:50:00+0200 info: [example.com.] DNSSEC, KSK rollover started 563 2021-05-10T20:50:00+0200 info: [example.com.] DNSSEC, key, tag 50613, algorithm ECDSAP256SHA256, KSK, public, active 564 2021-05-10T20:50:00+0200 info: [example.com.] DNSSEC, key, tag 62932, algorithm ECDSAP256SHA256, public, active 565 2021-05-10T20:50:00+0200 info: [example.com.] DNSSEC, key, tag 9081, algorithm ECDSAP256SHA256, KSK, public, active+ 566 2021-05-10T20:50:00+0200 info: [example.com.] DNSSEC, signing started 567 2021-05-10T20:50:00+0200 info: [example.com.] DNSSEC, successfully signed 568 2021-05-10T20:50:00+0200 info: [example.com.] DNSSEC, next signing at 2021-05-10T20:50:12+0200 569 570 ... (propagation-delay + dnskey-ttl) ... 571 572 2021-05-10T20:50:12+0200 info: [example.com.] DNSSEC, signing zone 573 2021-05-10T20:50:12+0200 notice: [example.com.] DNSSEC, KSK submission, waiting for confirmation 574 2021-05-10T20:50:12+0200 info: [example.com.] DNSSEC, key, tag 50613, algorithm ECDSAP256SHA256, KSK, public, active 575 2021-05-10T20:50:12+0200 info: [example.com.] DNSSEC, key, tag 62932, algorithm ECDSAP256SHA256, public, active 576 2021-05-10T20:50:12+0200 info: [example.com.] DNSSEC, key, tag 9081, algorithm ECDSAP256SHA256, KSK, public, ready, active+ 577 2021-05-10T20:50:12+0200 info: [example.com.] DNSSEC, signing started 578 2021-05-10T20:50:12+0200 info: [example.com.] DNSSEC, successfully signed 579 2021-05-10T20:50:12+0200 info: [example.com.] DNSSEC, next signing at 2021-05-17T20:49:56+0200 580 581At this point the new KSK has to be submitted to the parent zone. Knot detects the updated parent's DS 582record automatically (and waits for additional period of the DS's TTL before retiring the old key) 583if :ref:`parent DS check<Submission section>` is configured, otherwise the 584operator must confirm it manually (using ``knotc zone-ksk-submitted``):: 585 586 2021-05-10T20:50:12+0200 info: [example.com.] DS check, outgoing, remote 127.0.0.1@5300, KSK submission check: negative 587 2021-05-10T20:50:14+0200 info: [example.com.] DS check, outgoing, remote 127.0.0.1@5300, KSK submission check: negative 588 2021-05-10T20:50:16+0200 info: [example.com.] DS check, outgoing, remote 127.0.0.1@5300, KSK submission check: positive 589 2021-05-10T20:50:16+0200 notice: [example.com.] DNSSEC, KSK submission, confirmed 590 2021-05-10T20:50:16+0200 info: [example.com.] DNSSEC, signing zone 591 2021-05-10T20:50:16+0200 info: [example.com.] DNSSEC, key, tag 50613, algorithm ECDSAP256SHA256, KSK, public, active+ 592 2021-05-10T20:50:16+0200 info: [example.com.] DNSSEC, key, tag 62932, algorithm ECDSAP256SHA256, public, active 593 2021-05-10T20:50:16+0200 info: [example.com.] DNSSEC, key, tag 9081, algorithm ECDSAP256SHA256, KSK, public, active 594 2021-05-10T20:50:16+0200 info: [example.com.] DNSSEC, signing started 595 2021-05-10T20:50:16+0200 info: [example.com.] DNSSEC, successfully signed 596 2021-05-10T20:50:16+0200 info: [example.com.] DNSSEC, next signing at 2021-05-10T20:50:23+0200 597 598 ... (parent's DS TTL is 7 seconds) ... 599 600 2021-05-10T20:50:23+0200 info: [example.com.] DNSSEC, signing zone 601 2021-05-10T20:50:23+0200 info: [example.com.] DNSSEC, key, tag 62932, algorithm ECDSAP256SHA256, public, active 602 2021-05-10T20:50:23+0200 info: [example.com.] DNSSEC, key, tag 9081, algorithm ECDSAP256SHA256, KSK, public, active 603 2021-05-10T20:50:23+0200 info: [example.com.] DNSSEC, signing started 604 2021-05-10T20:50:23+0200 info: [example.com.] DNSSEC, successfully signed 605 2021-05-10T20:50:23+0200 info: [example.com.] DNSSEC, next signing at 2021-05-10T20:51:56+0200 606 607Upon the zone's ZSK lifetime expiration, a new ZSK is generated and the rollover 608continues along the lines of :rfc:`6781#section-4.1.1`:: 609 610 # ZSK Rollover (62932 -> 33255) 611 612 2021-05-10T20:51:56+0200 info: [example.com.] DNSSEC, signing zone 613 2021-05-10T20:51:56+0200 info: [example.com.] DNSSEC, ZSK rollover started 614 2021-05-10T20:51:56+0200 info: [example.com.] DNSSEC, key, tag 62932, algorithm ECDSAP256SHA256, public, active 615 2021-05-10T20:51:56+0200 info: [example.com.] DNSSEC, key, tag 9081, algorithm ECDSAP256SHA256, KSK, public, active 616 2021-05-10T20:51:56+0200 info: [example.com.] DNSSEC, key, tag 33255, algorithm ECDSAP256SHA256, public 617 2021-05-10T20:51:56+0200 info: [example.com.] DNSSEC, signing started 618 2021-05-10T20:51:56+0200 info: [example.com.] DNSSEC, successfully signed 619 2021-05-10T20:51:56+0200 info: [example.com.] DNSSEC, next signing at 2021-05-10T20:52:08+0200 620 621 ... (propagation-delay + dnskey-ttl) ... 622 623 2021-05-10T20:52:08+0200 info: [example.com.] DNSSEC, signing zone 624 2021-05-10T20:52:08+0200 info: [example.com.] DNSSEC, key, tag 62932, algorithm ECDSAP256SHA256, public 625 2021-05-10T20:52:08+0200 info: [example.com.] DNSSEC, key, tag 9081, algorithm ECDSAP256SHA256, KSK, public, active 626 2021-05-10T20:52:08+0200 info: [example.com.] DNSSEC, key, tag 33255, algorithm ECDSAP256SHA256, public, active 627 2021-05-10T20:52:08+0200 info: [example.com.] DNSSEC, signing started 628 2021-05-10T20:52:08+0200 info: [example.com.] DNSSEC, successfully signed 629 2021-05-10T20:52:08+0200 info: [example.com.] DNSSEC, next signing at 2021-05-10T20:52:25+0200 630 631 ... (propagation-delay + zone-max-ttl) ... 632 633 2021-05-10T20:52:25+0200 info: [example.com.] DNSSEC, signing zone 634 2021-05-10T20:52:25+0200 info: [example.com.] DNSSEC, key, tag 9081, algorithm ECDSAP256SHA256, KSK, public, active 635 2021-05-10T20:52:25+0200 info: [example.com.] DNSSEC, key, tag 33255, algorithm ECDSAP256SHA256, public, active 636 2021-05-10T20:52:25+0200 info: [example.com.] DNSSEC, signing started 637 2021-05-10T20:52:25+0200 info: [example.com.] DNSSEC, successfully signed 638 2021-05-10T20:52:25+0200 info: [example.com.] DNSSEC, next signing at 2021-05-10T20:54:08+0200 639 2021-05-10T20:54:08+0200 info: [example.com.] DNSSEC, signing zone 640 641Further rollovers:: 642 643 ... (zsk-lifetime - propagation-delay - zone-max-ttl) ... 644 645 # Another ZSK Rollover (33255 -> 49526) 646 647 2021-05-10T20:54:08+0200 info: [example.com.] DNSSEC, signing zone 648 2021-05-10T20:54:08+0200 info: [example.com.] DNSSEC, ZSK rollover started 649 2021-05-10T20:54:08+0200 info: [example.com.] DNSSEC, key, tag 9081, algorithm ECDSAP256SHA256, KSK, public, active 650 2021-05-10T20:54:08+0200 info: [example.com.] DNSSEC, key, tag 33255, algorithm ECDSAP256SHA256, public, active 651 2021-05-10T20:54:08+0200 info: [example.com.] DNSSEC, key, tag 49526, algorithm ECDSAP256SHA256, public 652 2021-05-10T20:54:08+0200 info: [example.com.] DNSSEC, signing started 653 2021-05-10T20:54:08+0200 info: [example.com.] DNSSEC, successfully signed 654 2021-05-10T20:54:08+0200 info: [example.com.] DNSSEC, next signing at 2021-05-10T20:54:20+0200 655 656 ... 657 658 # Another KSK Rollover (9081 -> 9179) 659 660 2021-05-10T20:55:00+0200 info: [example.com.] DNSSEC, signing zone 661 2021-05-10T20:55:00+0200 info: [example.com.] DNSSEC, KSK rollover started 662 2021-05-10T20:55:00+0200 info: [example.com.] DNSSEC, key, tag 9081, algorithm ECDSAP256SHA256, KSK, public, active 663 2021-05-10T20:55:00+0200 info: [example.com.] DNSSEC, key, tag 49526, algorithm ECDSAP256SHA256, public, active 664 2021-05-10T20:55:00+0200 info: [example.com.] DNSSEC, key, tag 9179, algorithm ECDSAP256SHA256, KSK, public, active+ 665 2021-05-10T20:55:00+0200 info: [example.com.] DNSSEC, signing started 666 2021-05-10T20:55:00+0200 info: [example.com.] DNSSEC, successfully signed 667 2021-05-10T20:55:00+0200 info: [example.com.] DNSSEC, next signing at 2021-05-10T20:55:12+0200 668 669 ... 670 671.. TIP:: 672 If systemd is available, the KSK submission event is logged into journald 673 in a structured way. The intended use case is to trigger a user-created script. 674 Example:: 675 676 journalctl -f -t knotd -o json | python3 -c ' 677 import json, sys 678 for line in sys.stdin: 679 k = json.loads(line); 680 if "KEY_SUBMISSION" in k: 681 print("%s, zone=%s, keytag=%s" % (k["__REALTIME_TIMESTAMP"], k["ZONE"], k["KEY_SUBMISSION"])) 682 ' 683 684.. _DNSSEC Shared KSK: 685 686DNSSEC shared KSK 687================= 688 689Knot DNS allows, with automatic DNSSEC key management, to configure a shared KSK for multiple zones. 690By enabling :ref:`policy_ksk-shared`, we tell Knot to share all newly-created KSKs 691among all the zones with the same :ref:`DNSSEC signing policy<Policy section>` assigned. 692 693The feature works as follows. Each zone still manages its keys separately. If a new KSK shall be 694generated for the zone, it first checks if it can grab another zone's shared KSK instead - 695that is the last generated KSK in any of the zones with the same policy assigned. 696Anyway, only the cryptographic material is shared, the key may have different timers 697in each zone. 698 699.. rubric:: Consequences: 700 701If we have an initial setting with brand new zones without any DNSSEC keys, 702the initial keys for all zones are generated. With shared KSK, they will all have the same KSK, 703but different ZSKs. The KSK rollovers may take place at slightly different times for each of the zones, 704but the resulting new KSK will be shared again among all of them. 705 706If we have zones which already have their keys, turning on the shared KSK feature triggers no action. 707But when a KSK rollover takes place, they will use the same new key afterwards. 708 709.. WARNING:: 710 Changing the policy :ref:`id<policy_id>` must be done carefully if shared 711 KSK is in use. 712 713.. _DNSSEC Delete algorithm: 714 715DNSSEC delete algorithm 716======================= 717 718This is how to "disconnect" a signed zone from a DNSSEC-aware parent zone. 719More precisely, we tell the parent zone to remove our zone's DS record by 720publishing a special formatted CDNSKEY and CDS record. This is mostly useful 721if we want to turn off DNSSEC on our zone so it becomes insecure, but not bogus. 722 723With automatic DNSSEC signing and key management by Knot, this is as easy as 724configuring :ref:`policy_cds-cdnskey-publish` option and reloading the configuration. 725We check if the special CDNSKEY and CDS records with the rdata "0 3 0 AA==" and "0 0 0 00", 726respectively, appeared in the zone. 727 728After the parent zone notices and reflects the change, we wait for TTL expire 729(so all resolvers' caches get updated), and finally we may do anything with the 730zone, e.g. turning off DNSSEC, removing all the keys and signatures as desired. 731 732.. _DNSSEC Offline KSK: 733 734DNSSEC Offline KSK 735================== 736 737Knot DNS allows a special mode of operation where the private part of the Key Signing Key is 738not available to the daemon, but it is rather stored securely in an offline storage. This requires 739that the KSK/ZSK signing scheme is used (i.e. :ref:`policy_single-type-signing` is off). 740The Zone Signing Key is always fully available to the daemon in order to sign common changes to the zone contents. 741 742The server (or the "ZSK side") only uses ZSK to sign zone contents and its changes. Before 743performing a ZSK rollover, the DNSKEY records will be pre-generated and signed by the 744signer (the "KSK side"). Both sides exchange keys in the form of human-readable messages with the help 745of the :doc:`keymgr<man_keymgr>` utility. 746 747Pre-requisites 748-------------- 749 750For the ZSK side (i.e. the operator of the DNS server), the pre-requisites are: 751 752- a properly configured :ref:`DNSSEC policy <Policy section>` (e.g. :ref:`zsk-lifetime <policy_zsk-lifetime>`), 753- :ref:`manual <policy_manual>` set to `on` 754- :ref:`offline-ksk <policy_offline-ksk>` set to `on` 755- :ref:`dnskey-ttl <policy_dnskey-ttl>` and :ref:`zone-max-ttl <policy_zone-max-ttl>` set up explicitly 756- a complete KASP DB with just ZSK(s) 757 758For the KSK side (i.e. the operator of the KSK signer), the pre-requisites are: 759 760- Knot configuration equal to the ZSK side (at least relevant parts of corresponding 761 :ref:`policy <Policy section>`, :ref:`zone <Zone section>`, and :ref:`template <Template section>` 762 sections must be identical) 763- a KASP DB with the KSK(s) 764 765Generating and signing future ZSKs 766---------------------------------- 767 7681. Use the ``keymgr pregenerate`` command on the ZSK side to prepare the ZSKs for a specified period of time in the future. The following example 769 generates ZSKs for the *example.com* zone for 6 months ahead starting from now:: 770 771 $ keymgr -c /path/to/ZSK/side.conf example.com. pregenerate +6mo 772 773 If the time period is selected as e.g. *2 x* :ref:`policy_zsk-lifetime` *+ 4 x* :ref:`policy_propagation-delay`, it will 774 prepare roughly two complete future key rollovers. The newly-generated 775 ZSKs remain in non-published state until their rollover starts, i.e. the time 776 they would be generated in case of automatic key management. 777 7782. Use the ``keymgr generate-ksr`` command on the ZSK side to export the public parts of the future ZSKs in a form 779 similar to DNSKEY records. You might use the same time period as in the first step:: 780 781 $ keymgr -c /path/to/ZSK/side.conf example.com. generate-ksr +0 +6mo > /path/to/ksr/file 782 783 Save the output of the command (called the Key Signing Request or KSR) to a file and transfer it to the KSK side e.g. via e-mail. 784 7853. Use the ``keymgr sign-ksr`` command on the KSK side with the KSR file from the previous step as a parameter:: 786 787 $ keymgr -c /path/to/KSK/side.conf example.com. sign-ksr /path/to/ksr/file > /path/to/skr/file 788 789 This creates all the future forms of the DNSKEY, CDNSKEY and CSK records and all the respective RRSIGs and prints them on output. Save 790 the output of the command (called the Signed Key Response or SKR) to a file and transfer it back to the ZSK side. 791 7924. Use the ``keymgr import-skr`` command to import the records and signatures from the SKR file generated in the last step 793 into the KASP DB on the ZSK side:: 794 795 $ keymgr -c /path/to/ZSK/side.conf example.com. import-skr /path/to/skr/file 796 7975. Use the ``knotc zone-keys-load`` command to trigger a zone re-sign on the ZSK-side and set up the future re-signing events correctly.:: 798 799 $ knotc -c /path/to/ZSK/side.conf zone-keys-load example.com. 800 8016. Now the future ZSKs and DNSKEY records with signatures are ready in KASP DB for later usage. 802 Knot automatically uses them at the correct time intervals. 803 The entire procedure must be repeated before the time period selected at the beginning passes, 804 or whenever a configuration is changed significantly. Importing new SKR over some previously-imported 805 one leads to deleting the old offline records. 806 807Offline KSK and manual ZSK management 808------------------------------------- 809 810If the automatically preplanned ZSK roll-overs (first step) are not desired, just set the :ref:`policy_zsk-lifetime` 811to zero, and manually pregenerate ZSK keys and set their timers. Then follow the steps 812``generate-ksr — sign-ksr — import-skr — zone-keys-load`` and repeat the ceremony when necessary. 813 814Offline KSK roll-over 815--------------------- 816 817The KSKs (on the KSK side) must be managed manually, but manual KSK roll-over is possible. Just plan the steps 818of the KSK roll-over in advance, and whenever the KSK set or timers are changed, re-perform the relevant rest of the ceremony 819``sign-ksr — import-skr — zone-keys-load``. 820 821Emergency SKR 822------------- 823 824A general recommendation for large deployments is to have some backup pre-published keys, so that if the current ones are 825compromised, they can be rolled-over to the backup ones without any delay. But in the case of Offline KSK, according to 826the procedures above, both ZSK and KSK immediate rollovers require the KSR-SKR ceremony. 827 828However, a trick can be done to achieve really immediate key substitution. This is no longer about Knot DNS functionality, 829just a hint for the operator. 830 831The idea is to perform every KSR-SKR ceremony twice: once with normal state of the keys (the backup key is only published), 832and once with the keys already exchanged (the backup key is temporarily marked as active and the standard key temporarily 833as public only). The second (backup) SKR should be saved for emergency key replacement. 834 835Summary of the steps: 836 837* Prepare KSK and ZSK side as usual, including public-only emergency key 838* Perform normal Offline KSK ceremony: 839 840 * Pre-generate ZSKs (only in the case of automatic ZSK management) 841 * Generate KSR 842 * Sign KSR on the KSK side 843 * Import SKR 844 * Re-sign the zone 845 846* Freeze the zone on the ZSK side 847* Temporarily set the backup key as active and the normal key as publish-only 848* Perform backup Offline KSK ceremony: 849 850 * Generate KSR (only if the backup key is a replacement for ZSK) 851 * Sign the KSR on the KSK side 852 * Save the SKR to a backup storage, don't import it yet 853 854* Return the keys to the previous state 855* Thaw the zone on the ZSK side 856 857Emergency key replacement: 858 859* Import the backup SKR 860* Align the keys with the new states (backup key as active, compromised key as public) 861* Re-sign the zone 862 863.. _DNSSEC Import of keys to HSM: 864 865Import of keys to HSM 866===================== 867 868Knot DNS stores DNSSEC keys in textual PEM format (:rfc:`7468`), 869while many HSM management software require the keys for import to be in binary 870DER format (`Rec. ITU-T X.690 <https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.690>`_). 871Keys can be converted from one format to another by software tools such as 872``certtool`` from `GnuTLS <https://www.gnutls.org/>`_ suite or 873``openssl`` from `OpenSSL <https://www.openssl.org/>`_ suite. 874 875In the examples below, ``c4eae5dea3ee8c15395680085c515f2ad41941b6`` is used as the key ID, 876``c4eae5dea3ee8c15395680085c515f2ad41941b6.pem`` represents the filename of the key in PEM format 877as copied from the Knot DNS zone's :ref:`KASP database directory <database_kasp-db>`, 878``c4eae5dea3ee8c15395680085c515f2ad41941b6.priv.der`` represents the file containing the private 879key in DER format as generated by the conversion tool, and 880``c4eae5dea3ee8c15395680085c515f2ad41941b6.pub.der`` represents the file containing the public 881key in DER format as generated by the conversion tool. 882 883.. code-block:: console 884 885 $ certtool -V -k --outder --infile c4eae5dea3ee8c15395680085c515f2ad41941b6.pem \ 886 --outfile c4eae5dea3ee8c15395680085c515f2ad41941b6.priv.der 887 888 $ certtool -V --pubkey-info --outder --load-privkey c4eae5dea3ee8c15395680085c515f2ad41941b6.pem \ 889 --outfile c4eae5dea3ee8c15395680085c515f2ad41941b6.pub.der 890 891As an alternative, ``openssl`` can be used instead. It is necessary to specify either ``rsa`` or ``ec`` 892command according to the algorithm used by the key. 893 894.. code-block:: console 895 896 $ openssl rsa -outform DER -in c4eae5dea3ee8c15395680085c515f2ad41941b6.pem \ 897 -out c4eae5dea3ee8c15395680085c515f2ad41941b6.priv.der 898 899 $ openssl rsa -outform DER -in c4eae5dea3ee8c15395680085c515f2ad41941b6.pem \ 900 -out c4eae5dea3ee8c15395680085c515f2ad41941b6.pub.der -pubout 901 902Actual import of keys (both public and private keys from the same key pair) to an HSM can be done 903via PKCS #11 interface, by ``pkcs11-tool`` from `OpenSC <https://github.com/OpenSC/OpenSC/wiki>`_ toolkit 904for example. In the example below, ``/usr/local/lib/pkcs11.so`` is used as a name of the PKCS #11 library 905or module used for communication with the HSM. 906 907.. code-block:: console 908 909 $ pkcs11-tool --module /usr/local/lib/pkcs11.so --login \ 910 --write-object c4eae5dea3ee8c15395680085c515f2ad41941b6.priv.der --type privkey \ 911 --usage-sign --id c4eae5dea3ee8c15395680085c515f2ad41941b6 912 913 $ pkcs11-tool --module /usr/local/lib/pkcs11.so -login \ 914 --write-object c4eae5dea3ee8c15395680085c515f2ad41941b6.pub.der --type pubkey \ 915 --usage-sign --id c4eae5dea3ee8c15395680085c515f2ad41941b6 916 917.. _Controlling a running daemon: 918 919Daemon controls 920=============== 921 922Knot DNS was designed to allow server reconfiguration on-the-fly 923without interrupting its operation. Thus it is possible to change 924both configuration and zone files and also add or remove zones without 925restarting the server. This can be done with:: 926 927 $ knotc reload 928 929If you want to refresh the secondary zones, you can do this with:: 930 931 $ knotc zone-refresh 932 933.. _Data and metadata backup: 934 935Data and metadata backup 936======================== 937 938Some of the zone-related data, such as zone contents or DNSSEC signing keys, 939and metadata, like zone timers, might be worth backing up. For the sake of 940consistency, it's usually necessary to shut down the server, or at least freeze all 941the zones, before copying the data like zone files, KASP database, etc, to 942a backup location. To avoid this necessity, Knot DNS provides a feature to 943back up some or all of the zones seamlessly. 944 945Online backup 946------------- 947 948While the server is running and the zones normally loaded (even when they are 949constantly/frequently being updated), the user can manually trigger the 950backup by calling:: 951 952 $ knotc zone-backup +backupdir /path/of/backup 953 954To back up just some of the zones (instead of all), the user might provide 955their list:: 956 957 $ knotc zone-backup +backupdir /path/to/backup zone1.com. zone2.com. ... 958 959The backup directory should be empty or non-existing and it must be accessible 960and writable for the :ref:`server_user` account under which knotd is running. 961The backup procedure will begin soon and will happen zone-by-zone 962(partially in parallel if more :ref:`server_background-workers` are configured). 963**The user shall check the logs for the outcome of each zone's backup attempt.** 964The knotc's ``-b`` parameter might be used if the user desires to wait until 965the backup work is done and a simple result status is printed out. 966 967.. TIP:: 968 There is a plain ASCII text file in the backup directory, 969 ``knot_backup.label``, that contains some useful information about the 970 backup, such as the backup creation date & time, the server identity, etc. 971 Care must always be taken **not to remove this file** from the backup nor to 972 damage it. 973 974Offline restore 975--------------- 976 977If the Online backup was performed for all zones, it's possible to 978restore the backed up data by simply copying them to their normal locations, 979since they're simply copies. For example, the user can copy (overwrite) 980the backed up KASP database files to their configured location. 981 982This restore of course must be done when the server is stopped. After starting up 983the server, it should run in the same state as at the time of backup. 984 985This method is recommended in the case of complete data loss, for example 986physical server failure. 987 988.. NOTE:: 989 The online backup procedure stores all zone files in a single directory 990 using their default file names. If the original directory layout was 991 different, then the required directory structure must be created manually 992 for offline restore and zone files must be placed individually to their 993 respective directories. If the zone file names don't follow the default 994 pattern, they must be renamed manually to match the configuration. These 995 limitations don't apply to the online restore procedure. 996 997Online restore 998-------------- 999 1000This procedure is symmetrical to Online backup. By calling:: 1001 1002 $ knotc zone-restore +backupdir /path/of/backup 1003 1004the user triggers a one-by-one zone restore from the backup on a running 1005server. Again, a subset of zones might be specified. It must be specified 1006if the backup was created for only a subset of zones. 1007 1008.. NOTE:: 1009 For restore of backups that have been created by Knot DNS releases prior 1010 to 3.1, it's necessary to use the ``-f`` option. Since this option also 1011 turns off some verification checks, it shouldn't be used in other cases. 1012 1013Limitations 1014----------- 1015 1016Neither configuration file nor :ref:`Configuration database` is backed up 1017by zone backup. The configuration has to be synchronized before zone restore 1018is performed! 1019 1020If the private keys are stored in a HSM (anything using a PKCS#11 interface), 1021they are not backed up. This includes internal metadata of the PKCS#11 provider 1022software, such as key mappings, authentication information, and the configuration 1023of the provider. Details are vendor-specific. 1024 1025The restore procedure does not care for keys deleted after taking the snapshot. 1026Thus, after restore, there might remain some redundant ``.pem`` files 1027of obsolete signing keys. 1028 1029.. TIP:: 1030 In order to seamlessly deploy a restored backup of KASP DB with respect to 1031 a possibly ongoing DNSSEC key rollover, it's recommended to set 1032 :ref:`propagation-delay <policy_propagation-delay>` to the sum of: 1033 1034 - The maximum delay between beginning of the zone signing and publishing 1035 re-signed zone on all public secondary servers. 1036 - How long it takes for the backup server to start up with the restored data. 1037 - The period between taking backup snapshots of the live environment. 1038 1039.. _Statistics: 1040 1041Statistics 1042========== 1043 1044The server provides some general statistics and optional query module statistics 1045(see :ref:`mod-stats<mod-stats>`). 1046 1047Server statistics or global module statistics can be shown by:: 1048 1049 $ knotc stats 1050 $ knotc stats server # Show all server counters 1051 $ knotc stats mod-stats # Show all mod-stats counters 1052 $ knotc stats server.zone-count # Show specific server counter 1053 1054Per zone statistics can be shown by:: 1055 1056 $ knotc zone-stats example.com mod-stats 1057 1058To show all supported counters even with 0 value, use the force option. 1059 1060A simple periodic statistic dump to a YAML file can also be enabled. See 1061:ref:`statistics_section` for the configuration details. 1062 1063As the statistics data can be accessed over the server control socket, 1064it is possible to create an arbitrary script (Python is supported at the moment) 1065which could, for example, publish the data in JSON format via HTTP(S) 1066or upload the data to a more efficient time series database. Take a look into 1067the python folder of the project for these scripts. 1068 1069.. _Mode XDP: 1070 1071Mode XDP 1072======== 1073 1074Thanks to recent Linux kernel capabilities, namely eXpress Data Path and AF_XDP 1075address family, Knot DNS offers a high-performance DNS over UDP packet processing 1076mode. The basic idea is to filter DNS messages close to the network device and 1077effectively forward them to the nameserver without touching the network stack 1078of the operating system. Other messages (including DNS over TCP) are processed 1079as usual. 1080 1081If :ref:`xdp_listen` is configured, the server creates 1082additional XDP workers, listening on specified interface(s) and port(s) for DNS 1083over UDP queries. Each XDP worker handles one RX and TX network queue pair. 1084 1085.. _Mode XDP_pre-requisites: 1086 1087Pre-requisites 1088-------------- 1089 1090* Linux kernel 4.18+ (5.x+ is recommended for optimal performance) compiled with 1091 the `CONFIG_XDP_SOCKETS=y` option. The XDP mode isn't supported in other operating systems. 1092* A multiqueue network card, which offers enough Combined RX/TX channels, with 1093 native XDP support is highly recommended. Successfully tested cards: 1094 1095 * Intel series 700 (driver `i40e`), maximum number of channels per interface is 64. 1096 * Intel series 500 (driver `ixgbe`), maximum number of channels per interface is 64. 1097 The number of CPUs available has to be at most 64! 1098 1099* If the `knotd` service is not directly executed in the privileged mode, some 1100 additional Linux capabilities have to be set: 1101 1102 Execute command:: 1103 1104 systemctl edit knot 1105 1106 And insert these lines:: 1107 1108 [Service] 1109 CapabilityBoundingSet=CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_RESOURCE 1110 AmbientCapabilities=CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_RESOURCE 1111 1112 The `CAP_SYS_RESOURCE` is needed on Linux < 5.11. 1113 1114Optimizations 1115------------- 1116 1117Some helpful commands:: 1118 1119 ethtool -N <interface> rx-flow-hash udp4 sdfn 1120 ethtool -N <interface> rx-flow-hash udp6 sdfn 1121 ethtool -L <interface> combined <?> 1122 ethtool -G <interface> rx <?> tx <?> 1123 renice -n 19 -p $(pgrep '^ksoftirqd/[0-9]*$') 1124 1125Limitations 1126----------- 1127 1128* VLAN segmentation is not supported. 1129* Dynamic DNS over XDP is not supported. 1130* MTU higher than 1792 bytes is not supported. 1131* Multiple BPF filters per one network device are not supported. 1132* Systems with big-endian byte ordering require special recompilation of the nameserver. 1133* IPv4 header and UDP checksums are not verified on received DNS messages. 1134* DNS over XDP traffic is not visible to common system tools (e.g. firewall, tcpdump etc.). 1135* BPF filter is not automatically unloaded from the network device. Manual filter unload:: 1136 1137 ip link set dev <ETH> xdp off 1138