summaryrefslogtreecommitdiffstats
path: root/doc/requirements.rst
blob: ed114b8ec42ddfdb08196bcb956173a47cf421f3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
.. highlight:: none
.. _Requirements:

************
Requirements
************

Hardware
========

Knot DNS requirements are not very demanding for typical
installations, and a commodity server or a virtual solution will be
sufficient in most cases.

However, please note that there are some scenarios that will require
administrator's attention and some testing of exact requirements before
deploying Knot DNS to a production environment. These cases include
deployment for a large number of zones (DNS hosting), large number
of records in one or more zones (TLD), or large number of requests.

CPU requirements
----------------

The server scales with processing power and also with the number of
available cores/CPUs. Enabling Hyper-threading is convenient if supported.

There is no lower bound on the CPU requirements, but it should support
memory barriers and atomic instructions (i586 and newer).

Network card
------------

The best results have been achieved with multi-queue network cards. The
number of multi-queues should equal the total number of CPU cores (with
Hyper-threading enabled).

Memory requirements
-------------------

The server implementation focuses on performance and thus can be quite
memory demanding. The rough estimate for memory requirements is
3 times the size of the zone in the plain-text format. Again this is only
an estimate and you are advised to do your own measurements before
deploying Knot DNS to production.

.. NOTE::
   To ensure uninterrupted serving of the zone, Knot DNS
   employs the Read-Copy-Update mechanism instead of locking and thus
   requires twice the amount of memory for the duration of incoming
   transfers.

Operating system
================

Knot DNS itself is written in a portable way and can be compiled
and run on most UNIX-like systems, such as Linux, \*BSD, and macOS.

Required libraries
==================

Knot DNS requires a few libraries to be available:

* libedit
* gnutls >= 3.3
* liburcu >= 0.5.4
* lmdb >= 0.9.15

.. NOTE::
   The LMDB library is included with Knot DNS source code. However, linking
   with the system library is preferred.

Optional libraries
==================

International Domain Names support (IDNA2008 or IDNA2003) in :doc:`kdig<man_kdig>`:

* libidn2 (or libidn)

Systemd's startup notification mechanism and journald logging:

* libsystemd

Dnstap support in :doc:`kdig<man_kdig>` or module :ref:`dnstap<mod-dnstap>`:

* fstrm (and protobuf-c if building from source code)

Linux :manpage:`capabilities(7)` support, which allows the server to be started
as a non-root user/group, binding to privileged ports (53), and giving up all
its capabilities, resulting in a completely unprivileged process:

* libcap-ng >= 0.6.4

MaxMind database for **geodb** support in module :ref:`geoip<mod-geoip>`:

* libmaxminddb0

DNS-over-HTTPS (DoH) support in :doc:`kdig<man_kdig>`:

* libnghttp2

The :ref:`XDP functionality <Mode XDP>` and :doc:`kxdpgun <man_kxdpgun>`
tool. These are only supported on Linux operating systems. See the chapter
:ref:`Mode XDP <Mode XDP_pre-requisites>` for software and hardware
recommendations.

* libbpf >= 0.0.6 (or embedded one via `--enable-xdp`)
* libxdp (if libbpf >= 1.0)
* libmnl (for kxdpgun)

DNS-over-QUIC (DoQ) support in :doc:`knotd<man_knotd>`, :doc:`kxdpgun<man_kxdpgun>`,
and :doc:`kdig<man_kdig>`:

* libngtcp2 >= 0.13.0 (or embedded one via `--enable-quic`)
* gnutls >= 3.7.2
* :ref:`Mode XDP` (for knotd and kxdpgun)