diff --git a/doc/configuration.texi b/doc/configuration.texi
index 879a702962895c01d0b47bff3aff226113218884..88494590450bf78fa951459fd5cd8378301b31da 100644
--- a/doc/configuration.texi
+++ b/doc/configuration.texi
@@ -76,8 +76,8 @@ possible combinations in the @code{@ref{log}}.
@item
The @code{zones} statement is probably the most important one,
because it defines the zones that Knot DNS will serve. In its most simple
-form you define zone by it's name and defined the filename where Knot
-DNS can find the zone contents. You can turn on more detailed semantic
+form you can define a zone by its name and zone file.
+You can turn on more detailed semantic
checks of zone file in this statement. Refer to @code{@ref{zones List of zone semantic checks}} to see
which checks are enabled by default and which are optional. If Knot is
being run as a master server, experimental feature @code{ixfr-from-differences}
@@ -92,9 +92,11 @@ See @ref{Controlling running daemon} for more information. For more information
Knot DNS doesn't strictly differ between master and slave zones.
The only requirement is to have @code{xfr-in} @code{zones} statement set for given zone,
thus allowing both incoming XFR from that remote and using it as the
-zone master. Also, you can specify relative paths for zone file and in that case,
-zone files will be bootstrapped over AXFR and placed in the storage directory,
-specified in @code{storage}. See @code{@ref{zones}} and @code{@ref{storage}}.
+zone master. Note that you need to explicitly allow incoming NOTIFY, otherwise
+the daemon would reject them.
+Also, you can specify paths, relative to the storage directory.
+See @code{@ref{zones}} and @code{@ref{storage}}.
+If the zone file doesn't exist and @code{xfr-in} is set, it will be bootstrapped over AXFR.
@example
remotes @{
@@ -103,7 +105,7 @@ remotes @{
zones @{
example.com @{
file "example.com"; # relative to 'storage'
- xfr-in master; # uses 'master' remote
+ xfr-in master; # define 'master' for this zone
notify-in master; # also allow NOTIFY from 'master'
@}
@}
@@ -126,7 +128,7 @@ remotes @{
zones @{
example.com @{
file "example.com"; # relative to 'storage'
- xfr-in master; # uses 'master' remote
+ xfr-in master; # define 'master' for this zone
notify-in master; # also allow NOTIFY from 'master'
@}
@}
@@ -138,7 +140,6 @@ As of now it is not possible to associate multiple keys with a remote.
@node Master configuration
@section Master configuration
-By default, zones are treated as master as long as they do not have the @code{xfr-in} set.
You can specify which remotes to allow for outgoing XFR and NOTIFY @code{zones}.
@example
@@ -151,7 +152,7 @@ remotes @{
zones @{
example.com @{
file "/var/zones/example.com";
- xfr-out subnet1, subnet2; # uses 'master' remote
+ xfr-out subnet1, subnet2; # allow outgoing transfers
notify-out slave;
@}
@}
diff --git a/doc/installation.texi b/doc/installation.texi
index 06c53a06a066c6f8587a0dacf5e551f4efc2657f..9dc0ba9e561fcf9d57be133980f7e33afe1d8c9c 100644
--- a/doc/installation.texi
+++ b/doc/installation.texi
@@ -97,17 +97,24 @@ a quite straightforward process using autotools.
@node Configuring and generating Makefiles
@subsection Configuring and generating Makefiles
-For all available options run:
+If you want to compile from Git sources, you need to bootstrap the
+@command{./configure} file first.
@example
-@command{./configure --help}
+$ autoreconf -i -f
+@end example
+
+For all available configure options run:
+
+@example
+$ ./configure --help
@end example
If you have trouble with unknown syscalls under valgrind, disable recvmmsg by
adding a parameter @command{--enable-recvmmsg=no} to configure.
Knot DNS has also support for link time optimizations.
-You can enable it by the configure parameter @command{./configure --enable-lto=no}.
+You can enable it by the configure parameter @command{./configure --enable-lto=yes}.
It is however disabled by default as it is known to be broken in some compiler
versions and may result in an unexpected behaviour.
@@ -127,7 +134,7 @@ $ ./configure --enable-debug=server,packet --enable-debuglevel=verbose
In most simple case you can just run configure without any options.
@example
-@command{./configure}
+$ ./configure
@end example
@node Compilation
@@ -138,7 +145,7 @@ Knot DNS by running @command{make} command, which will produce binaries
and other related files.
@example
-make
+$ make
@end example
Knot DNS build process is safe to parallelize
@@ -149,7 +156,7 @@ the compilation.
For example to use maximum 8 concurrent processes you would use:
@example
-make -j 8
+$ make -j 8
@end example
@node Installation
@@ -164,7 +171,7 @@ switching to root user, e.g. @command{sudo make install}
or @command{su -c 'make install'}.
@example
-make install
+$ make install
@end example
@node Installation from packages
@@ -203,12 +210,12 @@ the root user.
@example
-cat >/etc/apt/sources.list.d/knot.list <<EOF
+$ cat >/etc/apt/sources.list.d/knot.list <<EOF
deb http://deb.knot-dns.cz/debian/ <codename> main
deb-src http://deb.knot-dns.cz/debian/ <codename> main
EOF
-apt-get update
-apt-get install knot
+$ apt-get update
+$ apt-get install knot
@end example
@@ -241,9 +248,9 @@ the PPA.
@example
-sudo add-apt-repository ppa:cz.nic-labs/knot-dns
-sudo apt-get update
-sudo apt-get install knot
+$ sudo add-apt-repository ppa:cz.nic-labs/knot-dns
+$ sudo apt-get update
+$ sudo apt-get install knot
@end example
@@ -256,7 +263,7 @@ in the future, when new version are released.
@node Installing Knot DNS RPMs on Fedora
@subsection Installing Knot DNS RPMs on Fedora
-There are RPM packages for @code{knot} available for i386 and amd64 targets.
+There are RPM packages for @code{Knot DNS} available for i386 and amd64 targets.
If you want use the Fedora repository, add a file with the
following lines into @file{/etc/yum.repos.d/}
diff --git a/doc/running.texi b/doc/running.texi
index d814c622817e318022a32b85c9e4edac6dd2461f..92c7fa8387d4e215923d94b542a8ceb1455356a9 100644
--- a/doc/running.texi
+++ b/doc/running.texi
@@ -80,7 +80,7 @@ Slave zones with relative path specified will be placed in the @code{storage} as
@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
+@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{STORAGE/example.com.diff.db}.
@item
@@ -97,8 +97,15 @@ placed in @file{STORAGE/example.com.db.crc}.
Running the server as a slave is very straightforward as you usually bootstrap
zones over AXFR and thus avoid any manual zone compilation.
-There are two ways to start the server - directly or with the @code{knotc} controller tool.
+When a zone is transferred over AXFR, both the compiled zone and the zone file is
+updated, so no further compilation is needed.
+However when IXFR transfer finishes, it stores the differences in a journal file
+and doesn't update the zone file nor compiled zone immediately,
+but there is a timer that checks periodically for new differences and
+updates both zone file and the compiled zone. You can configure this timer
+with the @code{zonefile-sync} statement in @ref{zones}.
+There are two ways to start the server - directly or with the @code{knotc} controller tool.
First, let us start it directly. 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}.