diff --git a/doc/configuration.texi b/doc/configuration.texi
index 70f3fb0455ab1f524b400002f1006c6d7a0d2c9d..879a702962895c01d0b47bff3aff226113218884 100644
--- a/doc/configuration.texi
+++ b/doc/configuration.texi
@@ -53,28 +53,28 @@ Now let's go step by step through this minimal configuration file:
 @enumerate 
 
 @item
-In @code{@ref{system}} statement we have configured @code{@ref{storage}}
+In @code{system} statement we have configured @code{storage}
 directory where Knot DNS will store compiled zone files, 
-PID file and for slave zone also their journal files.
+PID file and for slave zone also their journal files. (See @code{@ref{system}} and @code{@ref{storage}})
 
 @item
-The @code{@ref{interfaces}} statement defines interfaces where Knot
+The @code{interfaces} statement defines interfaces where Knot
 DNS will listen for incoming connections. We have defined two
-interfaces: one IPv4 called @code{my_interface} explicitly listening
-on port 53 and second IPv6 called @code{second_int} also listening on
-port 53, which is the default port for the DNS.
+interfaces: one IPv4 called @kbd{my_interface} explicitly listening
+on port 53 and second IPv6 called @kbd{second_int} also listening on
+port 53, which is the default port for the DNS. See @code{@ref{interfaces}}.
 
 @item
-The @code{@ref{log}} statement defines the log facilities for Knot DNS.
+The @code{log} statement defines the log facilities for Knot DNS.
 In this example we told Knot DNS to send its log messages with the severities
 @code{debug}, @code{warning} and @code{notice} into the syslog.
 If you omit this sections, all severities will printed to
 either @code{stdout} or @code{stderr}, and the severities
 from the @code{warning} and more serious to syslog. You can find all
-possible combinations in the @ref{log}.
+possible combinations in the @code{@ref{log}}.
 
 @item
-The @code{@ref{zones}} statement is the one probably most important,
+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
@@ -82,7 +82,7 @@ checks of zone file in this statement. Refer to @code{@ref{zones List of zone se
 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}
 can be enabled to create IXFR changesets from changes made to the master zone file.
-See @ref{Controlling running daemon} for more information.
+See @ref{Controlling running daemon} for more information. For more information about @code{zones} statement see @code{@ref{zones}}.
 @end enumerate
 
 @page
@@ -90,11 +90,11 @@ See @ref{Controlling running daemon} for more information.
 @section Slave configuration
 
 Knot DNS doesn't strictly differ between master and slave zones.
-The only requirement is to have @code{xfr-in} @code{@ref{zones}} statement set for given zone,
+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{@ref{storage}}.
+specified in @code{storage}. See @code{@ref{zones}} and @code{@ref{storage}}.
 
 @example
 remotes @{
@@ -114,7 +114,7 @@ and assign it to a remote.
 Supported algorithms for TSIG key are:@*
 @code{hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, hmac-sha512}
 @*
-Key secret is written in a base64 encoded format. @code{@ref{keys}}
+Key secret is written in a base64 encoded format. See @code{@ref{keys}}.
 
 @example
 keys @{
@@ -138,8 +138,8 @@ 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 don't have the @code{xfr-in} set.
-You can specify which remotes to allow for outgoing XFR and NOTIFY @code{@ref{zones}}.
+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
 remotes @{
@@ -177,7 +177,7 @@ zones @{
 @node Configuring multiple interfaces
 @section Configuring multiple interfaces
 
-Knot DNS support binding to multiple available interfaces in the @code{@ref{interfaces}}.
+Knot DNS support binding to multiple available interfaces in the @code{interfaces} section.
 @*You can also use the special addresses for "any address" like @code{0.0.0.0} or @code{[::]}.
 
 @example
diff --git a/doc/reference.texi b/doc/reference.texi
index df9e030a710bdeba28c54e501daa6fbbb6e49cdf..33966c2d1018bad3202cca2060d4a83632c4ab89 100644
--- a/doc/reference.texi
+++ b/doc/reference.texi
@@ -110,7 +110,7 @@ system @{
 
 Specifies a custom PID file location.
 
-Default value: @file{knot.pid} in @code{@ref{storage}} directory.
+Default value: @file{knot.pid} in @code{storage} directory.
 
 @example
 system @{
@@ -333,7 +333,7 @@ interfaces @{
 The @code{remotes} statement sets up all remote servers for zone
 transfers.  Knot DNS does not distinguish between client or server in
 this section.  Role of the server is determined at the time of its
-usage in the @code{@ref{zones}} section.  One server may act as a
+usage in the @code{zones} section.  One server may act as a
 client for one zone (e.g. downloading the updates) and as a master
 server for a different zone.
 
@@ -498,7 +498,7 @@ If no $ORIGIN directive is found inside actual zone file, this domain name will
 
 The @code{file} statement defines a path to the zone file.
 You can either use an absolute path or a relative path.
-In that case, the zone file path will be relative to the @code{storage} directory @ref{storage}.
+In that case, the zone file path will be relative to the @code{storage} directory (@pxref{storage}).
 
 @node xfr-in
 @subsubsection xfr-in
diff --git a/doc/running.texi b/doc/running.texi
index 3c163e81ba37a633f10f709fed09829948c1457f..d814c622817e318022a32b85c9e4edac6dd2461f 100644
--- a/doc/running.texi
+++ b/doc/running.texi
@@ -20,7 +20,7 @@ $ knotc -a -c knot.conf start|reload|restart
 
 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.
-To communicate with the binary, it reads the PID from the @emph{PID file} specified in the configuration @ref{pidfile} and sends POSIX signals to it.
+To communicate with the binary, it reads the PID from the @emph{PID file} specified in the configuration @code{pidfile} and sends POSIX signals to it (@code{@pxref{pidfile}}).
 If you want to control the daemon directly, use @code{SIGINT} to quit the process or @code{SIGHUP} to reload configuration. Signal @code{SIGUSR2} is currently used to refresh slave zones.
 
 @example
@@ -72,8 +72,8 @@ Parameters:
 @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}.
+All files are placed in the directory described by @code{storage} (@code{@pxref{storage}}).
+PID file can be placed elsewhere using the @code{pidfile} statement (@code{@pxref{pidfile}}).
 Slave zones with relative path specified will be placed in the @code{storage} as well.
 @itemize @bullet
 @item
@@ -84,7 +84,7 @@ placed in @file{STORAGE/example.com.db}.
 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
+@emph{PID file} - unless specified differently by the @code{pidfile}, it will be placed
 in the @file{STORAGE/knot.pid}.
 @item
 @emph{Checksum files} - in order to identify compiled zone corruption, it
@@ -99,7 +99,7 @@ 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.
 
-First, let's start it directly. If you don't pass any configuration, it will try to
+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}.
 
@@ -161,11 +161,10 @@ $ knotc -a -c master.conf reload # compile zones and reconfigure
 @end example
 
 If you want @emph{IXFR-out} changesets created from changes you make to a zone file, enable @code{ixfr-from-differences}
-in @ref{zones} statement, then compile the zone and reload your server as seen above.
+in @code{zones} statement, then compile the zone and reload your server as seen above.
 If @emph{SOA}'s @emph{serial} is not changed no changesets 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
-as explained in @ref{Submitting a bugreport} reporting.
+If you encounter a bug using this feature, please send it to Knot developers (@pxref{Submitting a bugreport}).
 
 You can also choose to tear-down the server fully and restart with the @code{knotc restart} action.
 @example
diff --git a/doc/troubleshooting.texi b/doc/troubleshooting.texi
index e00c28a2081d36679a7a5d5612e71631521e8c3c..bba2e24a069fde6580d08e2ca66b0459d281af87 100644
--- a/doc/troubleshooting.texi
+++ b/doc/troubleshooting.texi
@@ -7,7 +7,7 @@
 * Debug messages::
 @end menu
 
-First of all, check the logs. For logging settings see @ref{log}.
+First of all, check the logs (@pxref{log}).
 By default, Knot DNS logs all error messages to syslog. Enabling at least
 the @code{warning} message severity may help you identify some problems. 
 
@@ -78,7 +78,7 @@ and fix the bug. In these cases it may be useful to turn on debug messages.
 
 Two steps are required in order to log debug messages. First you need to 
 allow the debug messages in the server. Then the logging must be configured
-to log debug messages (see @ref{log}). It is recommended to log these 
+to log debug messages (@pxref{log}). It is recommended to log these 
 messages to a file. Firstly, the debug output may be rather large and 
 secondly it is easier to use the data for debugging.