doc: make some links to utilities

doc/configuration.rst

@@ -90,7 +90,7 @@ Access control list (ACL)
 
 The Access control list is a list of rules specifying remotes which are allowed to send certain types of requests to the server.
 Remotes can be specified by a single IP address or a network subnet. A TSIG
-key can also be assigned (see :doc:`keymgr <man_keymgr>` on how to generate a TSIG key).
+key can also be assigned (see :doc:`keymgr<man_keymgr>` on how to generate a TSIG key).
 
 Without any ACL rules, all the actions are denied for the zone. Each ACL rule
 can allow one or more actions for a given address/subnet/TSIG, or deny them.
@@ -464,7 +464,7 @@ with manual key management flag has to be set::
       dnssec-signing: on
       dnssec-policy: manual
 
-To generate signing keys, use the :doc:`keymgr <man_keymgr>` utility.
+To generate signing keys, use the :doc:`keymgr<man_keymgr>` utility.
 Let's use the Single-Type Signing scheme with two algorithms. Run:
 
 .. code-block:: console
@@ -508,7 +508,7 @@ go.
    options to schedule key rollovers and it internally uses timestamps of keys differently
    than in the manual case. As a consequence it might break if the ``retire`` or ``remove`` timestamps
    are set for the manually generated keys currently in use. Make sure to set these timestamps
-   to zero using :doc:`keymgr <man_keymgr>`:
+   to zero using :doc:`keymgr<man_keymgr>`:
 
    .. code-block:: console
 

doc/man/keymgr.8in

@@ -77,9 +77,9 @@ Use specified KASP database path and default configuration.
 \fBNOTE:\fP
 .INDENT 0.0
 .INDENT 3.5
-Keymgr runs with the same user privileges as configured for knotd. For example,
-if keymgr is run as root, but the configured user is knot,
-it won\(aqt be able to read files (PEM files, KASP db, ...) readable only by root.
+Keymgr runs with the same user privileges as configured for knotd\&.
+For example, if keymgr is run as root, but the configured user
+is knot, it won\(aqt be able to read files (PEM files, KASP db, ...) readable only by root.
 .UNINDENT
 .UNINDENT
 .SS Commands

doc/man_keymgr.rst

@@ -51,9 +51,9 @@ Config options
   Use specified KASP database path and default configuration.
 
 .. NOTE::
-   Keymgr runs with the same user privileges as configured for knotd. For example,
-   if keymgr is run as root, but the configured :ref:`user<server_user>` is knot,
-   it won't be able to read files (PEM files, KASP db, ...) readable only by root.
+   Keymgr runs with the same user privileges as configured for :doc:`knotd<man_knotd>`.
+   For example, if keymgr is run as ``root``, but the configured :ref:`user<server_user>`
+   is ``knot``, it won't be able to read files (PEM files, KASP db, ...) readable only by ``root``.
 
 Commands
 ........

doc/man_khost.rst

@@ -12,7 +12,7 @@ Description
 -----------
 
 This utility sends a DNS query for the *name* to the *server* and prints a reply
-in more user-readable form. For more advanced DNS queries use :program:`kdig`
+in more user-readable form. For more advanced DNS queries use :doc:`kdig<man_kdig>`
 instead.
 
 Parameters

doc/migration.rst

@@ -19,8 +19,8 @@ Building changes
 ----------------
 
 The ``--enable-dnstap`` configure option now enables the dnstap support in
-kdig only! To build the dnstap query module, ``--with-module-dnstap`` have
-to be used.
+:doc:`kdig<man_kdig>` only! To build the dnstap query module, ``--with-module-dnstap``
+have to be used.
 
 Since Knot DNS version 2.5.0 each query module can be configured to be:
 
@@ -217,7 +217,7 @@ server configuration:
 
    .. NOTE::
       If the server configuration file or database is not at the default location,
-      add a configuration parameter (-c or -C). See :doc:`keymgr <man_keymgr>`
+      add a configuration parameter (-c or -C). See :doc:`keymgr<man_keymgr>`
       for more info about required access rights to the key files.
 
 4. Follow :ref:`Automatic DNSSEC signing` steps to configure DNSSEC signing.

doc/operation.rst

@@ -5,13 +5,14 @@
 Operation
 *********
 
-The Knot DNS server part ``knotd`` can run either in the foreground, or in the background
-using the ``-d`` option. When run in the foreground, it doesn't create a PID file.
-Other than that, there are no differences and you can control both the same way.
+The Knot DNS server part :doc:`knotd<man_knotd>` can run either in the foreground,
+or in the background using the ``-d`` option. When run in the foreground, it
+doesn't create a PID file.  Other than that, there are no differences and you
+can control both the same way.
 
-The tool ``knotc`` is designed as a user front-end, making it easier to control running
-server daemon. If you want to control the daemon directly, use ``SIGINT`` to quit
-the process or ``SIGHUP`` to reload the configuration.
+The tool :doc:`knotc<man_knotc>` is designed as a user front-end, making it easier
+to control running server daemon. If you want to control the daemon directly,
+use ``SIGINT`` to quit the process or ``SIGHUP`` to reload the configuration.
 
 If you pass neither configuration file (``-c`` parameter) nor configuration
 database (``-C`` parameter), the server will first attempt to use the default
@@ -306,9 +307,9 @@ The process how the server loads a zone is influenced by the configuration of th
 :ref:`zonefile-load <zone_zonefile-load>` and :ref:`journal-content <zone_journal-content>`
 parameters (also DNSSEC signing applies), the existence of a zone file and journal
 (and their relative out-of-dateness), and whether it is a cold start of the server
-or a zone reload (e.g. invoked by the knotc interface). Please note that zone transfers
-are not taken into account here – they are planned after the zone is loaded
-(including AXFR bootstrap).
+or a zone reload (e.g. invoked by the :doc:`knotc<man_knotc>` interface). Please note
+that zone transfers are not taken into account here – they are planned after the zone
+is loaded (including AXFR bootstrap).
 
 If the zone file exists and is not excluded by the configuration, it is first loaded
 and according to its SOA serial number relevant journal changesets are applied.
@@ -472,7 +473,7 @@ Special states for algorithm rollover:
 
 - ``post-active`` — The key is no longer published in the zone, but still used for signing.
 
-The states listed above are relevant for :doc:`keymgr <man_keymgr>` operations like generating
+The states listed above are relevant for :doc:`keymgr<man_keymgr>` operations like generating
 a key, setting its timers and listing KASP database.
 
 On the other hand, the key "states" displayed in the server log lines while zone signing
@@ -736,7 +737,7 @@ The Zone Signing Key is always fully available to the daemon in order to sign co
 The server (or the "ZSK side") only uses ZSK to sign zone contents and its changes. Before
 performing a ZSK rollover, the DNSKEY records will be pre-generated and signed by the
 signer (the "KSK side"). Both sides exchange keys in the form of human-readable messages with the help
-of :doc:`keymgr <man_keymgr>` utility.
+of :doc:`keymgr<man_keymgr>` utility.
 
 Pre-requisites
 --------------

doc/requirements.rst

@@ -72,7 +72,7 @@ Knot DNS requires a few libraries to be available:
 Optional libraries
 ==================
 
-International Domain Names support (IDNA2008 or IDNA2003) in **kdig**:
+International Domain Names support (IDNA2008 or IDNA2003) in :doc:`kdig<man_kdig>`:
 
 * libidn2 (or libidn)
 
@@ -80,7 +80,7 @@ Systemd's startup notification mechanism and journald logging:
 
 * libsystemd
 
-Dnstap support in **kdig** or module :ref:`dnstap<mod-dnstap>`:
+Dnstap support in :doc:`kdig<man_kdig>` or module :ref:`dnstap<mod-dnstap>`:
 
 * fstrm (and protobuf-c if building from source code)
 

src/knot/modules/dnstap/dnstap.rst

@@ -29,7 +29,7 @@ which can be either a file or a UNIX socket::
    more details.
 
 .. NOTE::
-   Dnstap log files can also be created or read using ``kdig``.
+   Dnstap log files can also be created or read using :doc:`kdig<man_kdig>`.
 
 .. _dnstap: http://dnstap.info/