doc: fix deprecated formatters

doc/configuration.rst

@@ -21,11 +21,11 @@ which can be used as a base for your Knot DNS setup::
         my_interface { address 127.0.0.1@53; }
         second_int { address ::1; }
     }
-    
+
     log {
       syslog { any notice, warning, error; }
     }
-    
+
     zones {
       example.com {
         file "/etc/knot/example.com";
@@ -38,14 +38,14 @@ Now let's go step by step through this minimal configuration file:
   DNS will listen for incoming connections. We have defined two
   interfaces: one IPv4 called ``my_interface`` explicitly listening
   on port 53 and second IPv6 called ``second_int`` also listening on
-  port 53, which is the default port for the DNS. See @ref{interfaces}.
+  port 53, which is the default port for the DNS. See :ref:`interfaces`.
 * The ``log`` statement defines the log facilities for Knot DNS.
   In this example we told Knot DNS to send its log messages with the severities
   ``debug``, ``warning`` and ``notice`` into the syslog.
   If you omit this sections, all severities will printed to
   either ``stdout`` or ``stderr``, and the severities
   from the ``warning`` and more serious to syslog. You can find all
-  possible combinations in the @ref{log}.
+  possible combinations in the :ref:`log`.
 * The ``zones`` statement is probably the most important one,
   because it defines the zones that Knot DNS will serve.  In its most simple
   form you can define a zone by its name and zone file.
@@ -60,14 +60,12 @@ it as the zone master. If ``update-in`` is set and zone has a master,
 any accepted DNS UPDATE will be forwarded to master.  Also 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 @ref{zones} and @ref{storage}.  If the zone
+storage directory.  See :ref:`zones` and :ref:`storage`.  If the zone
 file doesn't exist and ``xfr-in`` is set, it will be bootstrapped over
-AXFR.
-
-::
+AXFR::
 
     remotes {
-      master { address 127.0.0.1@@53; }
+      master { address 127.0.0.1@53; }
       subnet1 { address 192.168.1.0/24; }
     }
 
@@ -84,15 +82,13 @@ AXFR.
 You can also use TSIG for access control. For this, you need to configure a TSIG key
 and assign it to a remote.  Supported algorithms for TSIG key are:
 | ``hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, hmac-sha512``
-Key secret is written in a base64 encoded format. See @ref{keys}.
-
-::
+Key secret is written in a base64 encoded format. See :ref:`keys`::
 
     keys {
       key0 hmac-md5 "Wg=="; # keyname algorithm secret
     }
     remotes {
-      master { address 127.0.0.1@@53; key key0; }
+      master { address 127.0.0.1@53; key key0; }
     }
     zones {
       example.com {
@@ -107,12 +103,10 @@ As of now it is not possible to associate multiple keys with a remote.
 Master configuration
 ====================
 
-You can specify which remotes to allow for outgoing XFR and NOTIFY ``zones``.
-
-::
+You can specify which remotes to allow for outgoing XFR and NOTIFY ``zones``::
 
     remotes {
-      slave { address 127.0.0.1@@53; }
+      slave { address 127.0.0.1@53; }
       any { address 0.0.0.0/0; }
       subnet1 { address 192.168.1.0/8; }
       subnet2 { address 192.168.2.0/8; }
@@ -125,11 +119,9 @@ You can specify which remotes to allow for outgoing XFR and NOTIFY ``zones``.
         update-in subnet1; # only allow DNS UPDATE from subnet1
       }
     }
-    @end example
-    
-    You can also secure outgoing XFRs with TSIG.
-    
-    @example
+
+You can also secure outgoing XFRs with TSIG::
+
     keys {
       key0 hmac-md5 "Wg=="; # keyname algorithm secret
     }
@@ -148,13 +140,11 @@ Configuring multiple interfaces
 
 Knot DNS support binding to multiple available interfaces in the
 ``interfaces`` section.  You can also use the special addresses for
-"any address" like ``0.0.0.0`` or ``[::]``.
-
-::
+"any address" like ``0.0.0.0`` or ``[::]``::
 
     interfaces {
-      if1 { address 192.168.1.2@@53; }
-      anyv6 { address [::]@@53; }
+      if1 { address 192.168.1.2@53; }
+      anyv6 { address [::]@53; }
     }
 
 Using DNS UPDATE
@@ -193,15 +183,15 @@ susceptible to replay attack in a short timeframe.
 Example configuration::
 
     control {
-    	listen-on { address 127.0.0.1@@5533; }
+    	listen-on { address 127.0.0.1@5533; }
     }
 
 Enabling zone semantic checks
 =============================
 
 You can turn on more detailed semantic checks of zone file in this
-``zones`` statement (@pxref{zones}). Refer to @ref{zones List of zone
-semantic checks} to see which checks are enabled by default and which
+``zones`` statement :ref:`zones`. Refer to :ref:`zones List of zone
+semantic checks` to see which checks are enabled by default and which
 are optional.
 
 Creating IXFR differences from zone file changes
@@ -209,9 +199,9 @@ Creating IXFR differences from zone file changes
 
 If Knot is being run as a master server, feature
 ``ixfr-from-differences`` can be enabled to create IXFR differences
-from changes made to the master zone file.  See @ref{Controlling
-running daemon} for more information. For more about ``zones``
-statement see @ref{zones}.
+from changes made to the master zone file.  See :ref:`Controlling
+running daemon` for more information. For more about ``zones``
+statement see :ref:`zones`.
 
 Using Response Rate Limiting
 ============================
@@ -225,14 +215,14 @@ potentially flooding the victim with a large unsolicited DNS
 responses.
 
 As of Knot DNS version 1.2.0, RRL is compiled in, but disabled by
-default.  You can enable it with the @ref{rate-limit} option in the
-@ref{system} section.  Setting to a value greater than ``0`` means
+default.  You can enable it with the :ref:`rate-limit` option in the
+:ref:`system` section.  Setting to a value greater than ``0`` means
 that every flow is allowed N responses per second, (i.e. ``rate-limit
 50;`` means ``50`` responses per second).  It is also possible to
 configure SLIP interval, which causes every Nth blocked response to be
 slipped as a truncated response. Not that some error responses cannot
 be truncated and are slipped as-is.  For more information, refer to
-@ref{rate-limit-slip}.  It is advisable to not set slip interval to a
+:ref:`rate-limit-slip`.  It is advisable to not set slip interval to a
 value larger than 1.
 
 Example configuration::
@@ -255,21 +245,19 @@ Example configuration
 ---------------------
 
 The example configuration enables automatic signing for all zones
-using @ref{dnssec-enable} option in the ``zones`` section, but the
+using :ref:`dnssec-enable` option in the ``zones`` section, but the
 signing is explicitly disabled for zone ``example.dev`` using the same
 option directly in zone configuration. The location of directory with
-signing keys is set globally by option @ref{dnssec-keydir}.
-
-::
+signing keys is set globally by option :ref:`dnssec-keydir`::
 
     zones {
       dnssec-enable on;
       dnssec-keydir "/var/lib/knot/keys";
-    
+
       example.com {
         file "example.com.zone";
       }
-    
+
       example.dev {
         file "example.dev.zone";
         dnssec-enable off;
@@ -307,7 +295,7 @@ Currently the signing policy is not configurable, except for signature
 lifetime.
 
 * Signature lifetime can be set in configuration globally for all
-  zones and for each zone in particular. @xref{signature-lifetime}. If
+  zones and for each zone in particular. :ref:`signature-lifetime`. If
   not set, the default value is 30 days.
 * Signature is refreshed 2 hours before expiration. The signature
   lifetime must thus be set to more than 2 hours.
@@ -358,7 +346,7 @@ extend it or even change it altogether.
 it will not be discussed here.
 
 The general syntax for importing a query module is described in the
-@ref{query_module} configuration reference.  Basically, each module is
+:ref:`query_module` configuration reference.  Basically, each module is
 described by a name and a configuration string.  Below is a list of
 modules and configuration string reference.
 
@@ -366,42 +354,42 @@ modules and configuration string reference.
 ----------------------------------------------------
 
 This module is able to synthetise either forward or reverse records for given prefix and subnet.
-The module configuration string looks like this: @code{(forward|reverse) <prefix> <ttl> <address>/<netblock>}.
+The module configuration string looks like this: ``(forward|reverse) <prefix> <ttl> <address>/<netblock>``.
 
 Records are synthetised only if the query can't be satisfied from the zone. Both IPv4 and IPv6 are supported.
-@emph{Note: 'prefix' doesn't allow dots, address parts in the synthetic names are separated with a dash.}
+*Note: 'prefix' doesn't allow dots, address parts in the synthetic names are separated with a dash.*
 
 Here are a few examples:
-@emph{Note: long names are snipped for readability.}
+*Note: long names are snipped for readability.*
 
-@subsubsection Automatic forward records
+Automatic forward records
+-------------------------
 
-@code{synth_record "forward dynamic- 400 2620:0:b61::/52"} on @code{example.} zone will result in following
+``synth_record "forward dynamic- 400 2620:0:b61::/52"`` on ``example.`` zone will result in following
 answer::
 
     $ kdig AAAA dynamic-2620-0000-0b61-0100-0000-0000-0000-0000.example.
     ...
     ;; QUESTION SECTION:
     ;; dynamic-2620-0000-0b61-0100-0000-0000-0000-0000.example. 0	IN	AAAA
-    
+
     ;; ANSWER SECTION:
     dynamic-2620-0000-0b61-0100... 400 IN AAAA 2620:0:b61:100::
-    @end example
-    
-    You can also have CNAME aliases to the dynamic records, which are going to be further resoluted.
-    @example
+
+You can also have CNAME aliases to the dynamic records, which are going to be further resoluted::
+
     $ kdig AAAA hostalias.example.
     ...
     ;; QUESTION SECTION:
     ;hostalias.example. 0	IN	AAAA
-    
+
     ;; ANSWER SECTION:
     hostalias.example. 3600 IN CNAME dynamic-2620-0000-0b61-0100...
     dynamic-2620-0000-0b61-0100... 400  IN AAAA  2620:0:b61:100::
 
 Automatic reverse records
 -------------------------
-    
+
 Module can be configured to synthetise reverse records as well.  With
 the ``synth_record "reverse dynamic- example. 400 2620:0:b61::/52"``
 string in the ``1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa.`` zone
@@ -411,13 +399,11 @@ configuration::
     ...
     ;; QUESTION SECTION:
     ;; 1.0.0...1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa. 0	IN	PTR
-    
+
     ;; ANSWER SECTION:
     ... 400 IN PTR dynamic-2620-0000-0b61-0000-0000-0000-0000-0001.example.
 
-Here's a full configuration of the aforementioned zones. Note that the zone files have to exist.
-
-::
+Here's a full configuration of the aforementioned zones. Note that the zone files have to exist::
 
     example. {
       query_module {
@@ -435,10 +421,10 @@ Here's a full configuration of the aforementioned zones. Note that the zone file
         synth_record "reverse dynamic- example. 400 2620:0:b61::/52";
       }
     }
-    
+
 Limitations
 ^^^^^^^^^^^
-    
+
 * As of now, there is no authenticated denial of nonexistence (neither
   NSEC or NSEC3 is supported) nor DNSSEC signed records.  However,
   since the module is hooked in the query processing plan, it will be

doc/installation.rst

@@ -109,7 +109,7 @@ For example::
     $ ./configure --enable-debug=server,packet --enable-debuglevel=brief
     $ ./configure --enable-debug=server,packet --enable-debuglevel=verbose
 
-For more detailed information, see @ref{Debug messages}. ##TODO
+For more detailed information, see :ref:`Debug messages`. ##TODO
 
 In most simple case you can just run configure without any options::
 
@@ -213,7 +213,7 @@ a following command as the root user::
 
 Using official distribution repository is highly recommended, however you may
 want to run ``Knot DNS`` on older releases of Fedora. In this case you can
-set up an unofficial repository by creating @file{/etc/yum.repos.d/knot.conf}
+set up an unofficial repository by creating :file:`/etc/yum.repos.d/knot.conf`
 file with the following content::
 
     [knot]
@@ -229,7 +229,7 @@ builds for i686 and x86_64 architecture.
 
 When upgrading to Fedora 18 or higher, backup the configuration and
 switch to the latest package provided in the official repository by running the
-following command as the root user:
+following command as the root user::
 
     # yum distro-sync knot
 

doc/introduction.rst

@@ -44,7 +44,7 @@ Git repository browser: `gitlab.labs.nic.cz/knot/tree/master <https://gitlab.lab
 
 Knot DNS issue tracker: `gitlab.labs.nic.cz/knot/issues <https://gitlab.labs.nic.cz/knot/issues>`_
 
-Knot DNS users mailing list: `knot-dns-users@lists.nic.cz <mailto:knot-dns-users@@lists.nic.cz>`_
+Knot DNS users mailing list: `knot-dns-users@lists.nic.cz <mailto:knot-dns-users@lists.nic.cz>`_
 
 Scope of this document
 ----------------------

doc/migration.rst

@@ -21,7 +21,7 @@ generated by Bind.
 1. To obtain current content of the zone which is being migrated,
    request Bind to flush the zone into the zone file: ``rndc flush
    example.com``.
-   
+
    Note: If dynamic updates (DDNS) are enabled for the given zone, you
    might need to freeze the zone before flushing it.  That can be done
    similarly: ``rndc freeze example.com``

doc/reference.rst

@@ -39,7 +39,7 @@ else.
       [ rate-limit-slip integer; ]
       [ max-udp-payload integer; ]
     }
-    
+
 .. _system Statement Definition and Usage:
 
 ``system`` Statement Definition and Usage
@@ -270,7 +270,7 @@ system Example
       user knot.knot;
       max-udp-payload 4096;
     }
-    
+
 .. _keys:
 
 ``keys`` Statement
@@ -347,8 +347,8 @@ keys Example
 
 .. _interfaces:
 
-interfaces Statement
-====================
+``interfaces`` Statement
+========================
 
 The ``interfaces`` statement contains IP interfaces where Knot DNS
 listens for incoming queries.
@@ -398,9 +398,9 @@ Long form::
     }
 
 Short form::
-    
+
     interfaces {
-      my_second_ip { address 198.51.100.1@@53; }
+      my_second_ip { address 198.51.100.1@53; }
     }
 
 Short form without port (defaults to 53)::
@@ -437,7 +437,7 @@ different zone.
              [ via [ interface_id | ip_address ]; ]
           }
         )
-      [ remote_id @dots{}; @dots{}; ]
+      [ remote_id ...; ...; ]
     }
 
 .. _remotes Statement Definition and Grammar:
@@ -501,10 +501,10 @@ with this ``remote``.  This section is optional.
         # via 82.35.64.59;    # direct IPv4
         # via [::cafe];       # direct IPv6
       }
-    
+
       # Short form:
       server1 {
-        address 127.0.0.1@@53001;
+        address 127.0.0.1@53001;
       }
     }
 
@@ -572,11 +572,11 @@ specified in :ref:`remotes` section.
         # ...
       }
     }
-    
+
     groups {
       admins { alice, bob }
     }
-    
+
     # example usage:
     control {
       # ...
@@ -603,10 +603,10 @@ default UNIX sockets.
 
     control {
       [ listen-on {
-        ( address ip_address[@@port_number] |
+        ( address ip_address[@port_number] |
           { address ip_address; [ port port_number; ] } )
       } ]
-      [ allow remote_id [, remote_id, @dots{} ]; ]
+      [ allow remote_id [, remote_id, ... ]; ]
     }
 
 .. _control Statement Definition and Grammar:
@@ -664,16 +664,16 @@ The ``zones`` statement contains definition of zones served by Knot DNS.
       [ zone_options ]
       zone_id {
         file "string";
-        [ xfr-in remote_id [, remote_id, @dots{} ]; ]
-        [ xfr-out remote_id [, remote_id, @dots{} ]; ]
-        [ notify-in remote_id [, remote_id, @dots{} ]; ]
-        [ notify-out remote_id [, remote_id, @dots{} ]; ]
-        [ update-in remote_id [, remote_id, @dots{} ]; ]
-        [ query_module { module_name "string"; [ module_name "string"; @dots{} ] } ]
+        [ xfr-in remote_id [, remote_id, ... ]; ]
+        [ xfr-out remote_id [, remote_id, ... ]; ]
+        [ notify-in remote_id [, remote_id, ... ]; ]
+        [ notify-out remote_id [, remote_id, ... ]; ]
+        [ update-in remote_id [, remote_id, ... ]; ]
+        [ query_module { module_name "string"; [ module_name "string"; ... ] } ]
         [ zone_options ]
       }
     }
-    
+
     zone_options :=
       [ storage "string"; ]
       [ semantic-checks boolean; ]
@@ -701,7 +701,7 @@ The ``zones`` statement contains definition of zones served by Knot DNS.
 
 ``zone_id`` is a zone origin, and as such is a domain name that may or
 may not end with a ".".  If no $ORIGIN directive is found inside
-actual zone file, this domain name will be used in place of "@@".  SOA
+actual zone file, this domain name will be used in place of "@".  SOA
 record in the zone must have this name as its owner.
 
 .. _file:
@@ -858,9 +858,9 @@ but zone file on a disk will only be synced after ``zonefile-sync``
 time has expired (or synced manually via ``knotc flush`` - see
 :ref:`Running Knot DNS`).  This is applicable when the zone is updated
 via IXFR, DDNS or automatic DNSSEC signing.  Possible values are 0 to
-INT_MAX, optionally suffixed by unit size (s/m/h/d) - @emph{1s} is one
-second, @emph{1m} one minute, @emph{1h} one hour and @emph{1d} one day
-with default value set to @emph{0s}.
+INT_MAX, optionally suffixed by unit size (s/m/h/d) - *1s* is one
+second, *1m* one minute, *1h* one hour and *1d* one day
+with default value set to *0s*.
 
 *Important note:* If you are serving large zones with frequent
 updates where the immediate sync to zone file is not desirable, set
@@ -941,7 +941,7 @@ Default value: ``increment``
 ::
 
     zones {
-    
+
       # Shared options for all listed zones
       storage "/var/lib/knot";
       ixfr-from-differences off;
@@ -984,7 +984,7 @@ The ``semantic-checks`` statement turns on extra zone file semantic
 checks.  Several checks are enabled by default and cannot be turned
 off.  If an error is found using these mandatory checks, the zone file
 will not be loaded.  Upon loading a zone file, occurred errors and
-counts of their occurrence will be logged to @emph{stderr}.  These
+counts of their occurrence will be logged to *stderr*.  These
 checks are the following:
 
 * An extra record together with CNAME record (except for RRSIG and DS)
@@ -1028,10 +1028,10 @@ an error:
 
     log {
       [ log_name {
-        [ category severity [, severity @dots{} ]; ]
+        [ category severity [, severity ... ]; ]
       } ]
       [ log_file filename {
-        [ category severity [, severity @dots{} ]; ]
+        [ category severity [, severity ... ]; ]
       } ]
     }
 
@@ -1106,17 +1106,17 @@ log Example
 ::
 
     log {
-    
+
       syslog {
         any error;
         zone warning, notice;
         server info;
       }
-    
+
       stderr {
         any error, warning;
       }
-    
+
       file "/tmp/knot-sample/knotd.debug" {
         server debug;
       }
@@ -1152,7 +1152,7 @@ configuration file currently being processed.
 ::
 
     include "keys.conf";
-    
+
     remotes {
       ctl {
         address 127.0.0.1;
@@ -1160,5 +1160,5 @@ configuration file currently being processed.
       }
       include "remotes.conf";
     }
-    
+
     include "zones";

doc/troubleshooting.rst

@@ -14,7 +14,7 @@ Submitting a bugreport
 If you are unable to solve the problem by yourselves, you can submit a
 bugreport to the Knot DNS team.  For security issues (e.g.  crash) do
 not use the public mailinglist.  Instead, write to
-`knot-dns@labs.nic.cz <mailto:knot-dns@@labs.nic.cz>`_.  All other bugs
+`knot-dns@labs.nic.cz <mailto:knot-dns@labs.nic.cz>`_.  All other bugs
 and questions may be directed to the Knot DNS users mailinglist
 (`knot-dns-users@lists.nic.cz <mailto:knot-dns-users@lists.nic.cz>`_).