diff --git a/doc/configuration.texi b/doc/configuration.texi
index d9866c5312bbd3e6056166fc8f2a7e55a487ff1f..40696e6d891fe9a62373c27ea9dc63688d8a4843 100644
--- a/doc/configuration.texi
+++ b/doc/configuration.texi
@@ -65,7 +65,10 @@ port 53, which is the default port for the DNS.
The @code{@ref{log}} statement defines the destination where Knot DNS
will send it's log messages. In this example we told Knot DNS to send
its log messages with priority @code{debug}, @code{warning} and
-@code{notice} into the syslog.
+@code{notice} into the syslog. If you omit this sections, all levels
+will printed to either @code{stdout} or @code{stderr}, and the levels
+from the @code{warning} and more serious to syslog. You can find all
+possible combinations in the @ref{log}.
@item
The @code{@ref{zones}} statement is the one probably most important,
diff --git a/doc/reference.texi b/doc/reference.texi
index 7ab812be6d974bae1bee553f874e596ea7bac112..d16d81a1e5ea4a7eb78c2079cb7e89f49dd9e86e 100644
--- a/doc/reference.texi
+++ b/doc/reference.texi
@@ -394,7 +394,7 @@ The @code{zones} statement contains definition of zones served by Knot DNS.
[ @code{notify-retries} @kbd{integer}@code{;} ]
[ @code{zonefile-sync} ( @kbd{integer} | @kbd{integer}(@code{s} | @code{m} | @code{h} | @code{d})@code{;} ) ]
[ @code{ixfr-fslimit} ( @kbd{integer} | @kbd{integer}(@code{k} | @code{M} | @code{G}) )@code{;} ]
-
+ [ @code{ixfr-from-differences} @kbd{boolean}@code{;} ]
@end example
@node zones Semantic checks
diff --git a/doc/running.texi b/doc/running.texi
index f2da8e65263cf92bbbf483291211bf6d1b447b28..6ace4fa5383ee331c18c9f94582a08bbfddfccd1 100644
--- a/doc/running.texi
+++ b/doc/running.texi
@@ -7,6 +7,69 @@
* Controlling running daemon::
@end menu
+Knot DNS is designed to compile zone files before loading them into server.
+The reason for this is to speed up server startup, but requires a bit of user
+effort, so each time the zone file changes you need to compile it.
+@example
+$ knotc -c knot.conf compile
+@end example
+Or alternatively, you can compile alternatively using the @code{-a} flag.
+@example
+$ knotc -a -c knot.conf start
+$ knotc -a -c knot.conf reload
+$ knotc -a -c knot.conf restart
+@end example
+
+The tool @code{knotc} is designed as a front-end for user, making it easier
+to do everything from zone compilation to controlling the server daemon.
+Here's a list of all possible actions:
+
+@example
+Usage: knotc [parameters] start|stop|restart|reload|running|compile [additional]
+Parameters:
+ -c [file], --config=[file] Select configuration file.
+ -j [num], --jobs=[num] Number of parallel tasks to run (only for 'compile').
+ -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 start/stop operations.
+ -i, --interactive Interactive mode (do not daemonize).
+ -a, --auto Enable automatic recompilation (start or reload).
+ -h, --help Print help and usage.
+Actions:
+ start Start knot server zone (no-op if running).
+ stop Stop knot server (no-op if not running).
+ restart Stops and then starts knot server.
+ reload Reload knot configuration and compiled zones.
+ refresh Refresh all slave zones.
+ running Check if server is running.
+ checkconf Check server configuration.
+
+ checkzone Check zones (accepts specific zones, f.e. 'knotc checkzone example1.com example2.com').
+ compile Compile zones (accepts specific zones, see above).
+@end example
+
+Also, the server needs to create several files in order to run properly.
+All files are placed in the directory described by @ref{storage}.
+PID file can be placed elsewhere using the statement @ref{pidfile}.
+Slave zones with relative path specified will be placed in the @code{storage} as well.
+@itemize @bullet
+@item
+@emph{Compiled zones} - preprocessed zones, for example zone @code{example.com} will be
+placed in @file{STORAGE/example.com.db}.
+@item
+@emph{Journal files} - each zone has a journal file to store changesets for IXFR and
+dynamic updates. Journal for zone @code{example.com} will be
+placed in @file{STORAGE/example.com.diff.db}.
+@item
+@emph{PID file} - unless specified differently by the @ref{pidfile}, it will be placed
+in the @file{STORAGE/knot.pid}.
+@item
+@emph{Checksum files} - in order to identify compiled zone corruption, it
+has a separate checksum file. For @code{example.com} will be
+placed in @file{STORAGE/example.com.db.crc}.
+@end itemize
+
@node Running a slave server
@section Running a slave server
@@ -19,6 +82,7 @@ search configuration in default path that is @code{SYSCONFDIR/knot.conf}. The @c
depends on what you passed to the @code{./configure}, usually @code{/etc}.
@example
+$ knotc -c slave.conf checkconf # check configuration
$ knotd -c slave.conf
@end example
@@ -37,6 +101,13 @@ When the server is running, you can control the daemon, see @ref{Controlling run
Knot DNS first needs to compile the zones before it can load them, therefore you need to
compile them with the @code{knotc compile} action or use flag @code{-a} to compile the zones automatically.
+
+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
+
Starting and stopping the daemon is the same as with the slave server in the previous section.
@example
$ knotc -c master.conf compile
@@ -45,16 +116,9 @@ $ knotc -w -c master.conf start
Or you can compile it automatically:
@example
-$ knotc -c master.conf checkconf # check configuration
$ knotc -a -w -c master.conf start
@end example
-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
-
@node Controlling running daemon
@section Controlling running daemon
@@ -68,6 +132,15 @@ $ knotc -c master.conf compile # compile updated zones
$ knotc -c master.conf reload # reconfigure and load updated zones
@end example
+Or use the @code{-a} again.
+@example
+$ knotc -a -c master.conf reload # compiled updated zones and reconfigure
+@end example
+
+If the @code{ixfr-from-differences} from the @ref{zones} is enabled for the zone,
+it will make a changeset from the zone file differences between reload
+and store it in the journal file. That can be later used for IXFR.
+
But you can still tear-down the server fully and restart with the @code{knotc restart} action.
@example
$ knotc -c master.conf running # check if running