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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
@node Running Knot DNS, Troubleshooting, Knot DNS Configuration, Top
@chapter Running Knot DNS
@menu
* Running a slave server::
* Running a master server::
* Controlling running daemon::
@end menu
Knot DNS can run either in the foreground or in a background, with the @code{-d}
option. When run in foreground, it doesn't create a PID file. Other than that,
there are no differences and you can control it just the same way.
@example
Usage: knotd [parameters]
Parameters:
-c, --config [file] Select configuration file.
-d, --daemonize Run server as a daemon.
-v, --verbose Verbose mode - additional runtime information.
-V, --version Print version of the server.
-h, --help Print help and usage.
@end example
Use knotc tool for convenience when working with the server daemon.
As of Knot DNS 1.3.0, the zones are not compiled anymore. That makes working
with the server much more user friendly.
@example
$ knotc -c knot.conf reload
@end example
The tool @code{knotc} is designed as a front-end for user, making it easier
to do everything from server startup to state checking of a running server daemon.
If you want to control the daemon directly, use @code{SIGINT} to quit the process or @code{SIGHUP} to reload configuration.
@example
Usage: knotc [parameters] <action> [action_args]
Parameters:
-c [file], --config=[file] Select configuration file.
-s [server] Remote UNIX socket/IP address
(default $@{rundir@}/knot.sock).
-p [port] Remote server port (only for IP).
-y [[hmac:]name:key] Use key_id specified on the command line.
-k [file] Use key file (as in config section 'keys').
Example:
echo "knotc-key hmac-md5 Wg==" > knotc.key
-f, --force Force operation - override some checks.
-v, --verbose Verbose mode - additional runtime
information.
-V, --version Print knot server version.
-w, --wait Wait for the server to finish stop
operations.
-i, --interactive Interactive mode (do not daemonize).
-h, --help Print help and usage.
Actions:
stop Stop server.
reload Reload configuration and changed zones.
refresh [zone] Refresh slave zone (all if not specified).
flush Flush journal and update zone files.
status Check if server is running.
zonestatus Show status of configured zones.
checkconf Check current server configuration.
checkzone [zone] Check zone (all if not specified).
memstats [zone] Estimate memory consumption for zone
(all if not specified).
@end example
Also, the server needs to create several files in order to run properly. These
files are stored in the folowing directories.
@code{storage} (@pxref{storage}):
@itemize @bullet
@item
@emph{Zone files} - default directory for storing zone files. This can be overriden
using absolute zone file location.
@item
@emph{Journal files} - each zone has a journal file to store differences for IXFR and
dynamic updates. Journal for zone @code{example.com} will be placed in @file{example.com.diff.db}.
@end itemize
@code{rundir} (@pxref{rundir}):
@itemize @bullet
@item
@emph{PID file} - is created automatically when the server is run in background.
@item
@emph{Control sockets} - as a default, UNIX sockets are created here,
but this can be overriden.
@end itemize
@node Running a slave server
@section Running a slave server
Running the server as a slave is very straightforward as you usually bootstrap
zones over AXFR and thus avoid any manual zone compilation.
In contrast to AXFR, when the incremental transfer finishes, it stores the differences in a journal file
and doesn't update the zone file immediately.
There is a timer that checks periodically for new differences and
updates the zone file. You can configure this timer
with the @code{zonefile-sync} statement in @code{zones} (@pxref{zones}).
There are two ways to start the server - in foreground or background.
First, let's start in foreground. If you do not pass any configuration, it will try to
search configuration in default path that is @code{SYSCONFDIR/knot.conf}. The @code{SYSCONFDIR}
depends on what you passed to the @code{./configure}, usually @code{/etc}.
@example
$ knotd -c slave.conf
@end example
To start it as a daemon, just add a @code{-d} parameter. Unlike the foreground mode,
PID file will be created in @code{rundir} directory.
@example
$ knotd -d -c slave.conf # start the daemon
$ knotc -c slave.conf stop # stop the daemon
@end example
When the server is running, you can control the daemon, see @ref{Controlling running daemon}.
@node Running a master server
@section Running a master server
If you want to just check the zone files first before starting,
you can use @code{knotc checkzone} action.
@example
$ knotc -c master.conf checkzone example.com
@end example
For an approximate estimate of server's memory consumption, you can use the @code{knotc memstats} action.
This action prints count of resource records, percentage of signed records and finally estimation
of memory consumption for each zone, unless specified otherwise. Please note that estimated values might
differ from the actual consumption. Also, for slave servers with incoming transfers enabled,
be aware that the actual memory consumption might be double or more during transfers.
@example
$ knotc -c master.conf memstats example.com
@end example
Starting and stopping the daemon is the same as with the slave server in the previous section.
@node Controlling running daemon
@section Controlling running daemon
Knot DNS was designed to allow server reconfiguration on-the-fly without interrupting
its operation. Thus it is possible to change both configuration and zone files and
also add or remove zones without restarting the server. This can be done with the
@code{knotc reload} action.
@example
$ knotc -c master.conf reload # reconfigure and load updated zones
@end example
If you want @emph{IXFR-out} differences created from changes you make to a zone file, enable @ref{ixfr-from-differences}
in @code{zones} statement, then reload your server as seen above.
If @emph{SOA}'s @emph{serial} is not changed no differences will be created. Please note
that this feature is in @emph{experimental} stage and should be used with care.
If you encounter a bug using this feature, please send it to Knot developers (@pxref{Submitting a bugreport}).
If you want to force refresh the slave zones, you can do this with the @code{knotc refresh} action.
@example
$ knotc -c slave.conf refresh
@end example
For a complete list of actions refer to @code{knotc --help} command output.
|
