Merge branch 'pspacek/arm-hyperlinks' into 'main'

ARM hyperlinking

See merge request isc-projects/bind9!6509

bin/nsupdate/nsupdate.rst

@@ -256,7 +256,7 @@ The command formats and their meanings are as follows:
    in ``krb5.conf``. If no realm is specified, the saved realm is
    cleared.
 
-``check-names [yes_or_no]``
+``check-names [boolean]``
    This command turns on or off check-names processing on records to be added.
    Check-names has no effect on prerequisites or records to be deleted.
    By default check-names processing is on. If check-names processing

bin/rndc/rndc.rst

@@ -21,7 +21,7 @@ rndc - name server control utility
 Synopsis
 ~~~~~~~~
 
-:program:`rndc` [**-b** source-address] [**-c** config-file] [**-k** key-file] [**-s** server] [**-p** port] [**-q**] [**-r**] [**-V**] [**-y** key_id] [[**-4**] | [**-6**]] {command}
+:program:`rndc` [**-b** source-address] [**-c** config-file] [**-k** key-file] [**-s** server] [**-p** port] [**-q**] [**-r**] [**-V**] [**-y** server_key] [[**-4**] | [**-6**]] {command}
 
 Description
 ~~~~~~~~~~~
@@ -38,7 +38,7 @@ algorithms are HMAC-MD5 (for compatibility), HMAC-SHA1, HMAC-SHA224,
 HMAC-SHA256 (default), HMAC-SHA384, and HMAC-SHA512. They use a shared
 secret on each end of the connection, which provides TSIG-style
 authentication for the command request and the name server's response.
-All commands sent over the channel must be signed by a key_id known to
+All commands sent over the channel must be signed by a server_key known to
 the server.
 
 :program:`rndc` reads a configuration file to determine how to contact the name
@@ -101,10 +101,10 @@ Options
 
    This option enables verbose logging.
 
-.. option:: -y key_id
+.. option:: -y server_key
 
-   This option indicates use of the key ``key_id`` from the configuration file. For control message validation to succeed, ``key_id`` must be known
+   This option indicates use of the key ``server_key`` from the configuration file. For control message validation to succeed, ``server_key`` must be known
-   by :iscman:`named` with the same algorithm and secret string. If no ``key_id`` is specified,
+   by :iscman:`named` with the same algorithm and secret string. If no ``server_key`` is specified,
    :program:`rndc` first looks for a key clause in the server statement of
    the server being used, or if no server statement is present for that
    host, then in the default-key clause of the options statement. Note that
@@ -650,7 +650,7 @@ would specify a zone called "-redirect".)
 Limitations
 ~~~~~~~~~~~
 
-There is currently no way to provide the shared secret for a ``key_id``
+There is currently no way to provide the shared secret for a ``server_key``
 without using the configuration file.
 
 Several error messages could be clearer.

doc/arm/advanced.inc.rst

@@ -23,17 +23,17 @@ Dynamic update is a method for adding, replacing, or deleting records in
 a primary server by sending it a special form of DNS messages. The format
 and meaning of these messages is specified in :rfc:`2136`.
 
-Dynamic update is enabled by including an ``allow-update`` or an
+Dynamic update is enabled by including an :any:`allow-update` or an
-``update-policy`` clause in the ``zone`` statement.
+:any:`update-policy` clause in the :any:`zone` statement.
 
-If the zone's ``update-policy`` is set to ``local``, updates to the zone
+If the zone's :any:`update-policy` is set to ``local``, updates to the zone
 are permitted for the key ``local-ddns``, which is generated by
 :iscman:`named` at startup. See :ref:`dynamic_update_policies` for more details.
 
 Dynamic updates using Kerberos-signed requests can be made using the
-TKEY/GSS protocol, either by setting the ``tkey-gssapi-keytab`` option
+TKEY/GSS protocol, either by setting the :any:`tkey-gssapi-keytab` option
-or by setting both the ``tkey-gssapi-credential`` and
+or by setting both the :any:`tkey-gssapi-credential` and
-``tkey-domain`` options. Once enabled, Kerberos-signed requests are
+:any:`tkey-domain` options. Once enabled, Kerberos-signed requests are
 matched against the update policies for the zone, using the Kerberos
 principal as the signer for the request.
 
@@ -121,12 +121,12 @@ necessary change history information is available. These include primary
 zones maintained by dynamic update and secondary zones whose data was
 obtained by IXFR. For manually maintained primary zones, and for secondary
 zones obtained by performing a full zone transfer (AXFR), IXFR is
-supported only if the option ``ixfr-from-differences`` is set to
+supported only if the option :any:`ixfr-from-differences` is set to
 ``yes``.
 
 When acting as a secondary server, BIND 9 attempts to use IXFR unless it is
 explicitly disabled. For more information about disabling IXFR, see the
-description of the ``request-ixfr`` clause of the ``server`` statement.
+description of the :any:`request-ixfr` clause of the :namedconf:ref:`server` statement.
 
 When a secondary server receives a zone via AXFR, it creates a new copy of the
 zone database and then swaps it into place; during the loading process, queries
@@ -136,7 +136,7 @@ degrade query performance during the transfer. If a server receiving an IXFR
 request determines that the response size would be similar in size to an AXFR
 response, it may wish to send AXFR instead. The threshold at which this
 determination is made can be configured using the
-``max-ixfr-ratio`` option.
+:any:`max-ixfr-ratio` option.
 
 .. _split_dns:
 

doc/arm/catz.inc.rst

@@ -47,10 +47,10 @@ removes, or reconfigures member zones based on the data received.
 
 To use a catalog zone, it must first be set up as a normal zone on both the
 primary and secondary servers that are configured to use it. It
-must also be added to a ``catalog-zones`` list in the ``options`` or
+must also be added to a :any:`catalog-zones` list in the :namedconf:ref:`options` or
-``view`` statement in :iscman:`named.conf`. This is comparable to the way a
+:any:`view` statement in :iscman:`named.conf`. This is comparable to the way a
 policy zone is configured as a normal zone and also listed in a
-``response-policy`` statement.
+:any:`response-policy` statement.
 
 To use the catalog zone feature to serve a new member zone:
 
@@ -66,7 +66,7 @@ The change to the catalog zone is propagated from the primary to all
 secondaries using the normal AXFR/IXFR mechanism. When the secondary receives the
 update to the catalog zone, it detects the entry for the new member
 zone, creates an instance of that zone on the secondary server, and points
-that instance to the ``primaries`` specified in the catalog zone data. The
+that instance to the :any:`primaries` specified in the catalog zone data. The
 newly created member zone is a normal secondary zone, so BIND
 immediately initiates a transfer of zone contents from the primary. Once
 complete, the secondary starts serving the member zone.
@@ -85,8 +85,8 @@ Configuring Catalog Zones
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 .. namedconf:statement:: catalog-zones
 
-Catalog zones are configured with a ``catalog-zones`` statement in the
+Catalog zones are configured with a :any:`catalog-zones` statement in the
-``options`` or ``view`` section of :iscman:`named.conf`. For example:
+:namedconf:ref:`options` or :any:`view` section of :iscman:`named.conf`. For example:
 
 ::
 
@@ -117,7 +117,7 @@ specified in any order.
 ``in-memory``
    This option, if set to ``yes``, causes member zones to be
    stored only in memory. This is functionally equivalent to configuring a
-   secondary zone without a ``file`` option. The default is ``no``; member
+   secondary zone without a :any:`file` option. The default is ``no``; member
    zones' content is stored locally in a file whose name is
    automatically generated from the view name, catalog zone name, and
    member zone name.
@@ -137,8 +137,8 @@ specified in any order.
    interval has elapsed. The default is 5 seconds.
 
 Catalog zones are defined on a per-view basis. Configuring a non-empty
-``catalog-zones`` statement in a view automatically turns on
+:any:`catalog-zones` statement in a view automatically turns on
-``allow-new-zones`` for that view. This means that :option:`rndc addzone`
+:any:`allow-new-zones` for that view. This means that :option:`rndc addzone`
 and :option:`rndc delzone` also work in any view that supports catalog
 zones.
 
@@ -202,7 +202,7 @@ Global custom properties are set at the apex of the catalog zone, e.g.:
 
 BIND currently supports the following custom properties:
 
--  A simple ``primaries`` definition:
+-  A simple :any:`primaries` definition:
 
    ::
 
@@ -213,9 +213,9 @@ BIND currently supports the following custom properties:
    either an A or AAAA record. If multiple primaries are set, the order in
    which they are used is random.
 
-   Note: ``masters`` can be used as a synonym for ``primaries``.
+   Note: ``masters`` can be used as a synonym for :any:`primaries`.
 
--  A ``primaries`` with a TSIG key defined:
+-  A :any:`primaries` with a TSIG key defined:
 
    ::
 
@@ -227,9 +227,9 @@ BIND currently supports the following custom properties:
    key set. The TSIG key must be configured in the configuration file.
    ``label`` can be any valid DNS label.
 
-   Note: ``masters`` can be used as a synonym for ``primaries``.
+   Note: ``masters`` can be used as a synonym for :any:`primaries`.
 
--  ``allow-query`` and ``allow-transfer`` ACLs:
+-  :any:`allow-query` and :any:`allow-transfer` ACLs:
 
    ::
 
@@ -237,8 +237,8 @@ BIND currently supports the following custom properties:
                allow-transfer.ext.catalog.example.    IN APL !1:10.0.0.1/32 1:10.0.0.0/24
 
 
-   These custom properties are the equivalents of ``allow-query`` and
+   These custom properties are the equivalents of :any:`allow-query` and
-   ``allow-transfer`` options in a zone declaration in the :iscman:`named.conf`
+   :any:`allow-transfer` options in a zone declaration in the :iscman:`named.conf`
    configuration file. The ACL is processed in order; if there is no
    match to any rule, the default policy is to deny access. For the
    syntax of the APL RR, see :rfc:`3123`.
@@ -256,12 +256,12 @@ custom properties, but in the member zone subdomain:
 
 Custom properties defined for a specific zone override the
 global custom properties defined in the catalog zone. These in turn override the
-global options defined in the ``catalog-zones`` statement in the
+global options defined in the :any:`catalog-zones` statement in the
 configuration file.
 
 Note that none of the global records for a custom property are inherited if any
 records are defined for that custom property for the specific zone. For example,
-if the zone had a ``primaries`` record of type A but not AAAA, it
+if the zone had a :any:`primaries` record of type A but not AAAA, it
 would *not* inherit the type AAAA record from the global custom property
 or from the global option in the configuration file.
 

doc/arm/config-auth.inc.rst

@@ -39,8 +39,6 @@ may support any combination of primary and secondary zones.
    For reasons of backward compatibility BIND 9 treats "primary" and "master" as
    synonyms, as well as "secondary" and "slave."
 
-.. _notify:
-
 The following diagram shows the relationship between the primary and secondary
 name servers. The text below explains the process in detail.
 
@@ -168,10 +166,10 @@ the :iscman:`named.conf` file has been modified as shown:
 
 The added statements and blocks are commented in the above file.
 
-The :ref:`zone<zone_clause>` block, and :ref:`allow-query<allow-query>`,
+The :any:`zone` block, and :ref:`allow-query<allow-query>`,
 :any:`allow-query-cache`,
 :ref:`allow-transfer<allow-transfer>`, :ref:`file<file>`,
-:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :ref:`type<type>`
+:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :any:`type`
 statements are described in detail in the appropriate sections.
 
 .. _sample_secondary:
@@ -250,11 +248,11 @@ The :ref:`named.conf<named_conf>` file has been modified as shown:
 
 The statements and blocks added are all commented in the above file.
 
-The :ref:`zone<zone_clause>` block, and :ref:`allow-query<allow-query>`,
+The :any:`zone` block, and :ref:`allow-query<allow-query>`,
 :any:`allow-query-cache`,
 :ref:`allow-transfer<allow-transfer>`, :ref:`file<file>`,
 :ref:`notify<notify_st>`, :ref:`primaries<primaries>`,
-:ref:`recursion<recursion>`, and :ref:`type<type>` statements are described in
+:ref:`recursion<recursion>`, and :any:`type` statements are described in
 detail in the appropriate sections.
 
 If NOTIFY is not being used, no changes are required in this

doc/arm/config-intro.inc.rst

@@ -79,7 +79,7 @@ as required by the user.
         };
 
 The :ref:`logging<logging_grammar>` and :ref:`options<options_grammar>` blocks
-and :ref:`category<the_category_phrase>`, :ref:`channel<channel>`,
+and :ref:`category<the_category_phrase>`, :any:`channel`,
 :ref:`directory<directory>`, :ref:`file<file>`, and :ref:`severity<severity>`
 statements are all described further in the appropriate sections of this ARM.
 

doc/arm/config-resolve.inc.rst

@@ -116,7 +116,7 @@ as the file ``named.root`` (normally found in /etc/namedb or
       Consult the appropriate distribution documentation for the actual file name.
 
 
-The hint zone file is referenced using the :ref:`type hint;<type>` statement and
+The hint zone file is referenced using the :any:`type hint` statement and
 a zone (domain) name of "." (the generally silent dot).
 
    .. Note:: The root server IP addresses have been stable for a number of
@@ -262,10 +262,10 @@ It is therefore a **closed** resolver and cannot be used in wider network attack
           notify no;
         };
 
-The :ref:`zone<zone_clause>` and :ref:`acl<acl_grammar>` blocks, and the
+The :any:`zone` and :any:`acl` blocks, and the
 :ref:`allow-query<allow-query>`, :ref:`empty-zones-enable<empty-zones-enable>`,
 :ref:`file<file>`, :ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and
-:ref:`type<type>` statements are described in detail in the appropriate
+:any:`type` statements are described in detail in the appropriate
 sections.
 
 As a reminder, the configuration of this resolver does **not** access the DNS
@@ -279,7 +279,7 @@ hierarchy (does not use the public network) for any recursive query for which:
 
 4. Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).
 
-5. Is a reverse-map query for any local IP (``empty-zones-enable``
+5. Is a reverse-map query for any local IP (:any:`empty-zones-enable`
    statement).
 
 All other recursive queries will result in access to the DNS hierarchy to
@@ -380,10 +380,10 @@ provided<selective_forward_sample>`.
           notify no;
         };
 
-The :ref:`zone<zone_clause>` and :ref:`acl<acl_grammar>` blocks, and the
+The :any:`zone` and :any:`acl` blocks, and the
 :ref:`allow-query<allow-query>`, :ref:`empty-zones-enable<empty-zones-enable>`,
 :ref:`file<file>`, :ref:`forward<forward>`, :ref:`forwarders<forwarders>`,
-:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :ref:`type<type>`
+:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :any:`type`
 statements are described in detail in the appropriate sections.
 
 As a reminder, the configuration of this forwarding resolver does **not**
@@ -397,7 +397,7 @@ forward any recursive query for which:
 
 4. Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).
 
-5. Is a reverse-map query for any local IP (``empty-zones-enable`` statement).
+5. Is a reverse-map query for any local IP (:any:`empty-zones-enable` statement).
 
 All other recursive queries will be forwarded to resolve the query.
 
@@ -507,10 +507,10 @@ those IPs from which it will accept recursive queries.
         };
 
 
-The :ref:`zone<zone_clause>` and :ref:`acl<acl_grammar>` blocks, and the
+The :any:`zone` and :any:`acl` blocks, and the
 :ref:`allow-query<allow-query>`, :ref:`empty-zones-enable<empty-zones-enable>`,
 :ref:`file<file>`, :ref:`forward<forward>`, :ref:`forwarders<forwarders>`,
-:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :ref:`type<type>`
+:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :any:`type`
 statements are described in detail in the appropriate sections.
 
 As a reminder, the configuration of this resolver does **not** access the DNS

doc/arm/dlz.inc.rst

@@ -34,7 +34,7 @@ Configuring DLZ
 ~~~~~~~~~~~~~~~
 .. namedconf:statement:: dlz
 
-A DLZ database is configured with a ``dlz`` statement in :iscman:`named.conf`:
+A DLZ database is configured with a :any:`dlz` statement in :iscman:`named.conf`:
 
 ::
 
@@ -46,19 +46,19 @@ A DLZ database is configured with a ``dlz`` statement in :iscman:`named.conf`:
 
 This specifies a DLZ module to search when answering queries; the module
 is implemented in ``driver.so`` and is loaded at runtime by the dlopen
-DLZ driver. Multiple ``dlz`` statements can be specified.
+DLZ driver. Multiple :any:`dlz` statements can be specified.
 
 
 .. namedconf:statement:: search
 
-When answering a query, all DLZ modules with ``search`` set to ``yes`` are
+When answering a query, all DLZ modules with :namedconf:ref:`search` set to ``yes`` are
 queried to see whether they contain an answer for the query name. The best
 available answer is returned to the client.
 
-The ``search`` option in the above example can be omitted, because
+The :namedconf:ref:`search` option in the above example can be omitted, because
 ``yes`` is the default value.
 
-If ``search`` is set to ``no``, this DLZ module is *not* searched
+If :namedconf:ref:`search` is set to ``no``, this DLZ module is *not* searched
 for the best match when a query is received. Instead, zones in this DLZ
 must be separately specified in a zone statement. This allows users to
 configure a zone normally using standard zone-option semantics, but
@@ -86,7 +86,7 @@ For guidance in the implementation of DLZ modules, the directory
 ``contrib/dlz/example`` contains a basic dynamically linkable DLZ
 module - i.e., one which can be loaded at runtime by the "dlopen" DLZ
 driver. The example sets up a single zone, whose name is passed to the
-module as an argument in the ``dlz`` statement:
+module as an argument in the :any:`dlz` statement:
 
 ::
 

doc/arm/dns-ops.inc.rst

@@ -110,51 +110,51 @@ server.
    described in :ref:`controls_statement_definition_and_usage`.
 
    The format of the configuration file is similar to that of
-   :iscman:`named.conf`, but is limited to only four statements: the ``options``,
+   :iscman:`named.conf`, but is limited to only three blocks: the :rndcconf:ref:`options`,
-   ``key``, ``server``, and ``include`` statements. These statements are
+   :rndcconf:ref:`key`, :rndcconf:ref:`server`, and the :ref:`include_grammar`. These blocks are
    what associate the secret keys to the servers with which they are
-   meant to be shared. The order of statements is not significant.
+   meant to be shared. The order of blocks is not significant.
 
 .. rndcconf:statement:: options
 
    .. rndcconf:statement:: default-server
 
-      ``default-server`` takes a
+      :any:`default-server` takes a
       host name or address argument and represents the server that is
       contacted if no :option:`-s <rndc -s>` option is provided on the command line.
 
    .. rndcconf:statement:: default-key
 
-      ``default-key`` takes the name of a key as its argument, as defined
+      :any:`default-key` takes the name of a key as its argument, as defined
-      by a ``key`` statement.
+      by a :rndcconf:ref:`key` block.
 
    .. rndcconf:statement:: default-port
 
-      ``default-port`` specifies the port to which
+      :any:`default-port` specifies the port to which
       :iscman:`rndc` should connect if no port is given on the command line or in
-      a ``server`` statement.
+      a :rndcconf:ref:`server` block.
 
    .. rndcconf:statement:: default-source-address
    .. rndcconf:statement:: default-source-address-v6
 
-      ``default-source-address`` and ``default-source-address-v6`` specify
+      :any:`default-source-address` and :any:`default-source-address-v6` specify
       the IPv4 and IPv6 source address used to communicate with the server
       if no address is given on the command line or in a
       :rndcconf:ref:`server` block.
 
 .. rndcconf:statement:: key
 
-   The ``key`` statement defines a key to be used by :iscman:`rndc` when
+   The :rndcconf:ref:`key` block defines a key to be used by :iscman:`rndc` when
-   authenticating with :iscman:`named`. Its syntax is identical to the ``key``
+   authenticating with :iscman:`named`. Its syntax is identical to the :namedconf:ref:`key`
-   statement in :iscman:`named.conf`. The keyword ``key`` is followed by a key
+   statement in :iscman:`named.conf`. The keyword :rndcconf:ref:`key` is followed by a key
    name, which must be a valid domain name, though it need not actually
    be hierarchical; thus, a string like ``rndc_key`` is a valid name.
-   The ``key`` statement has two clauses: ``algorithm`` and ``secret``.
+   The :rndcconf:ref:`key` block has two statements: :rndcconf:ref:`algorithm` and :rndcconf:ref:`secret`.
 
    .. rndcconf:statement:: algorithm
 
       While the configuration parser accepts any string as the argument
-      to ``algorithm``, currently only the strings ``hmac-md5``,
+      to :rndcconf:ref:`algorithm`, currently only the strings ``hmac-md5``,
       ``hmac-sha1``, ``hmac-sha224``, ``hmac-sha256``,
       ``hmac-sha384``, and ``hmac-sha512`` have any meaning.
 
@@ -165,7 +165,7 @@ server.
 
 .. rndcconf:statement:: server
 
-   The ``server`` statement specifies connection parameters for a given server.
+   The :rndcconf:ref:`server` block specifies connection parameters for a given server.
    The server can be specified as a host name or address.
 
    .. rndcconf:statement:: addresses
@@ -217,11 +217,11 @@ server.
               allow { localhost; } keys { rndc_key; };
       };
 
-   and it has an identical key statement for ``rndc_key``.
+   and it has an identical key block for ``rndc_key``.
 
    Running the :iscman:`rndc-confgen` program conveniently creates an
    :iscman:`rndc.conf` file, and also displays the corresponding
-   ``controls`` statement needed to add to :iscman:`named.conf`.
+   :any:`controls` statement needed to add to :iscman:`named.conf`.
    Alternatively, it is possible to run :option:`rndc-confgen -a` to set up an
    ``rndc.key`` file and not modify :iscman:`named.conf` at all.
 

doc/arm/dnssec.inc.rst

@@ -107,7 +107,7 @@ care of any DNSSEC maintenance for this zone, including replacing signatures
 that are about to expire and managing :ref:`key_rollovers`.
 
 .. note::
-   ``dnssec-policy`` needs write access to the zone. Please see
+   :any:`dnssec-policy` needs write access to the zone. Please see
    :ref:`dnssec_policy` for more details about implications for zone storage.
 
 The default policy creates one key that is used to sign the complete zone,
@@ -115,7 +115,7 @@ and uses ``NSEC`` to enable authenticated denial of existence (a secure way
 to tell which records do not exist in a zone). This policy is recommended
 and typically does not need to be changed.
 
-If needed, a custom policy can be defined by adding a ``dnssec-policy`` statement
+If needed, a custom policy can be defined by adding a :any:`dnssec-policy` statement
 into the configuration:
 
 .. code-block:: none
@@ -155,7 +155,7 @@ needs.
 Key Rollover
 ============
 
-When using a ``dnssec-policy``, a key lifetime can be set to trigger
+When using a :any:`dnssec-policy`, a key lifetime can be set to trigger
 key rollovers. ZSK rollovers are fully automatic, but for KSK and CSK rollovers
 a DS record needs to be submitted to the parent. See
 :ref:`secure_delegation` for possible ways to do so.
@@ -222,7 +222,7 @@ adjusts the zone's DNSSEC keys on a schedule according to the key timing
 metadata. However, keys still need to be generated separately, for
 example with :iscman:`dnssec-keygen`.
 
-Of course, dynamic zones can also use ``dnssec-policy`` to fully automate DNSSEC
+Of course, dynamic zones can also use :any:`dnssec-policy` to fully automate DNSSEC
 maintenance. The next sections assume that more key
 management control is needed, and describe how to use dynamic DNS update to perform
 various DNSSEC operations.
@@ -235,7 +235,7 @@ As an alternative to fully automated zone signing using :ref:`dnssec-policy
 <dnssec_kasp>`, a zone can be changed from insecure to secure using a dynamic
 DNS update. :iscman:`named` must be configured so that it can see the ``K*``
 files which contain the public and private parts of the `zone keys`_ that are
-used to sign the zone. Key files should be placed in the ``key-directory``, as
+used to sign the zone. Key files should be placed in the :any:`key-directory`, as
 specified in :iscman:`named.conf`:
 
 ::
@@ -273,7 +273,7 @@ To insert the keys via dynamic update:
        > send
 
 In order to sign with these keys, the corresponding key files should also be
-placed in the ``key-directory``.
+placed in the :any:`key-directory`.
 
 .. _dnssec_dynamic_zones_nsec3:
 
@@ -354,10 +354,10 @@ To convert a signed zone to unsigned using dynamic DNS, delete all the
 ``NSEC`` or ``NSEC3`` chains, and associated ``NSEC3PARAM`` records are removed
 automatically when the zone is supposed to be re-signed.
 
-This requires the ``dnssec-secure-to-insecure`` option to be set to ``yes`` in
+This requires the :any:`dnssec-secure-to-insecure` option to be set to ``yes`` in
 :iscman:`named.conf`.
 
-In addition, if the ``auto-dnssec maintain`` or a ``dnssec-policy`` is used, it
+In addition, if the ``auto-dnssec maintain`` or a :any:`dnssec-policy` is used, it
 should be removed or changed to ``allow`` instead; otherwise it will re-sign.
 
 .. _dnssec_tools:
@@ -471,7 +471,7 @@ This trust anchor is provided as part of BIND and is kept up-to-date using
 To validate answers, the resolver needs at least one trusted starting point,
 a "trust anchor." Essentially, trust anchors are copies of ``DNSKEY`` RRs for
 zones that are used to form the first link in the cryptographic chain of trust.
-Alternative trust anchors can be specified using :ref:`trust_anchors`, but
+Alternative trust anchors can be specified using :any:`trust-anchors`, but
 this setup is very unusual and is recommended only for expert use.
 For more information, see :ref:`trust_anchors_description` in the
 :doc:`dnssec-guide`.

doc/arm/dyndb.inc.rst

@@ -35,7 +35,7 @@ Configuring DynDB
 ~~~~~~~~~~~~~~~~~
 .. namedconf:statement:: dyndb
 
-A DynDB database is configured with a ``dyndb`` statement in
+A DynDB database is configured with a :any:`dyndb` statement in
 :iscman:`named.conf`:
 
 ::
@@ -46,7 +46,7 @@ A DynDB database is configured with a ``dyndb`` statement in
 
 
 The file ``driver.so`` is a DynDB module which implements the full DNS
-database API. Multiple ``dyndb`` statements can be specified, to load
+database API. Multiple :any:`dyndb` statements can be specified, to load
 different drivers or multiple instances of the same driver. Zones
 provided by a DynDB module are added to the view's zone table, and are
 treated as normal authoritative zones when BIND responds to
@@ -62,7 +62,7 @@ Sample DynDB Module
 For guidance in the implementation of DynDB modules, the directory
 ``bin/tests/system/dyndb/driver`` contains a basic DynDB module. The
 example sets up two zones, whose names are passed to the module as
-arguments in the ``dyndb`` statement:
+arguments in the :any:`dyndb` statement:
 
 ::
 

doc/arm/logging-categories.inc.rst

@@ -25,7 +25,7 @@
     Logging options for those categories where no specific configuration has been defined.
 
 ``delegation-only``
-    Queries that have been forced to NXDOMAIN as the result of a delegation-only zone or a ``delegation-only`` in a forward, hint, or stub zone declaration.
+    Queries that have been forced to NXDOMAIN as the result of a delegation-only zone or a :any:`delegation-only` in a forward, hint, or stub zone declaration.
 
 ``dispatch``
     Dispatching of incoming packets to the server modules where they are to be processed.
@@ -34,7 +34,7 @@
     DNSSEC and TSIG protocol processing.
 
 ``dnstap``
-    The "dnstap" DNS traffic capture system.
+    The :any:`dnstap` DNS traffic capture system.
 
 ``edns-disabled``
     Log queries that have been forced to use plain DNS due to timeouts. This is often due to the remote servers not being :rfc:`1034`-compliant (not always returning FORMERR or similar to EDNS queries and other extensions to the DNS when they are not understood). In other words, this is targeted at servers that fail to respond to DNS queries that they don't understand.
@@ -61,7 +61,7 @@
 ``queries``
     A location where queries should be logged.
     
-    At startup, specifying the category ``queries`` also enables query logging unless the ``querylog`` option has been specified.
+    At startup, specifying the category ``queries`` also enables query logging unless the :any:`querylog` option has been specified.
     
     The query log entry first reports a client object identifier in @0x<hexadecimal-number> format. Next, it reports the client's IP address and port number, and the query name, class, and type. Next, it reports whether the Recursion Desired flag was set (+ if set, - if not set), whether the query was signed (S), whether EDNS was in use along with the EDNS version number (E(#)), whether TCP was used (T), whether DO (DNSSEC Ok) was set (D), whether CD (Checking Disabled) was set (C), whether a valid DNS Server COOKIE was received (V), and whether a DNS COOKIE option without a valid Server COOKIE was present (K). After this, the destination address the query was sent to is reported. Finally, if any CLIENT-SUBNET option was present in the client query, it is included in square brackets in the format [ECS address/source/scope].
 
@@ -102,10 +102,10 @@
     TLS pre-master secrets (for debugging purposes).
 
 ``trust-anchor-telemetry``
-    Trust-anchor-telemetry requests received by :iscman:`named`.
+    :any:`trust-anchor-telemetry` requests received by :iscman:`named`.
 
 ``unmatched``
-    Messages that :iscman:`named` was unable to determine the class of, or for which there was no matching ``view``. A one-line summary is also logged to the ``client`` category. This category is best sent to a file or stderr; by default it is sent to the ``null`` channel.
+    Messages that :iscman:`named` was unable to determine the class of, or for which there was no matching :any:`view`. A one-line summary is also logged to the ``client`` category. This category is best sent to a file or stderr; by default it is sent to the :any:`null` channel.
 
 ``update``
     Dynamic updates.

doc/arm/managed-keys.inc.rst

@@ -23,9 +23,9 @@ Validating Resolver
 ^^^^^^^^^^^^^^^^^^^
 
 To configure a validating resolver to use :rfc:`5011` to maintain a trust
-anchor, configure the trust anchor using a ``trust-anchors`` statement and
+anchor, configure the trust anchor using a :any:`trust-anchors` statement and
 the ``initial-key`` keyword. Information about this can be found in
-:ref:`trust-anchors`.
+the :any:`trust-anchors` statement description.
 
 Authoritative Server
 ^^^^^^^^^^^^^^^^^^^^

doc/arm/plugins.inc.rst

@@ -36,7 +36,7 @@ Configuring Plugins
 ~~~~~~~~~~~~~~~~~~~
 .. namedconf:statement:: plugin
 
-A plugin is configured with the ``plugin`` statement in :iscman:`named.conf`:
+A plugin is configured with the :any:`plugin` statement in :iscman:`named.conf`:
 
 ::
 
@@ -48,7 +48,7 @@ A plugin is configured with the ``plugin`` statement in :iscman:`named.conf`:
 In this example, file ``library.so`` is the plugin library. ``query``
 indicates that this is a query plugin.
 
-Multiple ``plugin`` statements can be specified, to load different
+Multiple :any:`plugin` statements can be specified, to load different
 plugins or multiple instances of the same plugin.
 
 ``parameters`` are passed as an opaque string to the plugin's initialization

doc/arm/rpz.inc.rst

@@ -300,7 +300,7 @@ transfers possible.
 
 Administrators who edit or periodically regenerate a DNS RPZ rule set and
 whose primary name server uses BIND can enable the
-``ixfr-from-differences`` option, which tells the primary name server to
+:any:`ixfr-from-differences` option, which tells the primary name server to
 calculate the differences between each new zone and the preceding version,
 and to make these differences available as a stream of deltas for use in
 incremental zone transfers to the subscribing name servers. This will look
@@ -750,7 +750,7 @@ To accomplish this using RPZ:
   };
 
 3. Enable use of the Response Policy Zone for all incoming queries
-   by adding the ``response-policy`` directive into the ``options {}``
+   by adding the :any:`response-policy` directive into the ``options {}``
    section:
 
 .. code-block:: c

doc/arm/security.inc.rst

@@ -22,9 +22,9 @@ Access Control Lists
 --------------------
 
 Access Control Lists (ACLs) are address match lists that can be set up
-and nicknamed for future use in ``allow-notify``, ``allow-query``,
+and nicknamed for future use in :any:`allow-notify`, :any:`allow-query`,
-``allow-query-on``, ``allow-recursion``, ``blackhole``,
+:any:`allow-query-on`, :any:`allow-recursion`, :any:`blackhole`,
-``allow-transfer``, ``match-clients``, etc.
+:any:`allow-transfer`, :any:`match-clients`, etc.
 
 ACLs give users finer control over who can access the
 name server, without cluttering up configuration files with huge lists of
@@ -97,12 +97,12 @@ it is interpreted as the full name of the country.  Similarly, if
 standard two-letter state or province abbreviation; otherwise, it is treated as the
 full name of the state or province.
 
-The ``database`` field indicates which GeoIP database to search for a match. In
+The :any:`database` field indicates which GeoIP database to search for a match. In
 most cases this is unnecessary, because most search fields can only be found in
 a single database.  However, searches for ``continent`` or ``country`` can be
 answered from either the ``city`` or ``country`` databases, so for these search
-types, specifying a ``database`` forces the query to be answered from that
+types, specifying a :any:`database` forces the query to be answered from that
-database and no other. If a ``database`` is not specified, these queries
+database and no other. If a :any:`database` is not specified, these queries
 are first answered from the ``city`` database if it is installed, and then from the ``country``
 database if it is installed. Valid database names are ``country``,
 ``city``, ``asnum``, ``isp``, and ``domain``.
@@ -176,7 +176,7 @@ For a ``chroot`` environment to work properly in a particular
 directory (for example, ``/var/named``), the
 environment must include everything BIND needs to run. From BIND's
 point of view, ``/var/named`` is the root of the filesystem;
-the values of options like ``directory`` and ``pid-file``
+the values of options like :any:`directory` and :any:`pid-file`
 must be adjusted to account for this.
 
 Unlike with earlier versions of BIND, 
@@ -209,10 +209,10 @@ Dynamic Update Security
 Access to the dynamic update facility should be strictly limited. In
 earlier versions of BIND, the only way to do this was based on the IP
 address of the host requesting the update, by listing an IP address or
-network prefix in the ``allow-update`` zone option. This method is
+network prefix in the :any:`allow-update` zone option. This method is
 insecure, since the source address of the update UDP packet is easily
 forged. Also note that if the IP addresses allowed by the
-``allow-update`` option include the address of a secondary server which
+:any:`allow-update` option include the address of a secondary server which
 performs forwarding of dynamic updates, the primary can be trivially
 attacked by sending the update to the secondary, which forwards it to
 the primary with its own source IP address - causing the primary to approve
@@ -220,9 +220,9 @@ it without question.
 
 For these reasons, we strongly recommend that updates be
 cryptographically authenticated by means of transaction signatures
-(TSIG). That is, the ``allow-update`` option should list only TSIG key
+(TSIG). That is, the :any:`allow-update` option should list only TSIG key
 names, not IP addresses or network prefixes. Alternatively, the
-``update-policy`` option can be used.
+:any:`update-policy` option can be used.
 
 Some sites choose to keep all dynamically updated DNS data in a
 subdomain and delegate that subdomain to a separate zone. This way, the

doc/arm/troubleshooting.inc.rst

@@ -47,10 +47,10 @@ was implemented in BIND as of release 9.14.0.
 
 As a result, some domains may be non-resolvable without manual
 intervention. In these cases, resolution can be restored by adding
-``server`` clauses for the offending servers, or by specifying ``edns no`` or
+:namedconf:ref:`server` clauses for the offending servers, or by specifying ``edns no`` or
 ``send-cookie no``, depending on the specific noncompliance.
 
-To determine which ``server`` clause to use, run the following commands
+To determine which :namedconf:ref:`server` clause to use, run the following commands
 to send queries to the authoritative servers for the broken domain:
 
 ::
@@ -85,11 +85,11 @@ to make :iscman:`named` prepare such a file, set the ``SSLKEYLOGFILE``
 environment variable to either:
 
 - the string ``config`` (``SSLKEYLOGFILE=config``); this requires
-  defining a ``logging`` :ref:`channel <logging_grammar>` which will
+  defining a :any:`logging` :ref:`channel <logging_grammar>` which will
   handle messages belonging to the ``sslkeylog`` category,
 
 - the path to the key file to write (``SSLKEYLOGFILE=/path/to/file``);
-  this is equivalent to the following ``logging`` :ref:`stanza
+  this is equivalent to the following :any:`logging` :ref:`stanza
   <logging_grammar>`:
 
   ::
@@ -105,7 +105,7 @@ environment variable to either:
 .. note::
 
    When using ``SSLKEYLOGFILE=config``, augmenting the log channel
-   output using options like ``print-time`` or ``print-severity`` is
+   output using options like :any:`print-time` or :any:`print-severity` is
    strongly discouraged as it will likely make the key log file
    unusable.
 

doc/arm/tsig.inc.rst

@@ -96,14 +96,14 @@ Instructing the Server to Use a Key
 A server sending a request to another server must be told whether to use
 a key, and if so, which key to use.
 
-For example, a key may be specified for each server in the ``primaries``
+For example, a key may be specified for each server in the :any:`primaries`
 statement in the definition of a secondary zone; in this case, all SOA QUERY
 messages, NOTIFY messages, and zone transfer requests (AXFR or IXFR)
 are signed using the specified key. Keys may also be specified in
-the ``also-notify`` statement of a primary or secondary zone, causing NOTIFY
+the :any:`also-notify` statement of a primary or secondary zone, causing NOTIFY
 messages to be signed using the specified key.
 
-Keys can also be specified in a ``server`` directive. Adding the
+Keys can also be specified in a :namedconf:ref:`server` directive. Adding the
 following on ``host1``, if the IP address of ``host2`` is 10.1.2.3, would
 cause *all* requests from ``host1`` to ``host2``, including normal DNS
 queries, to be signed using the ``host1-host2.`` key:
@@ -114,7 +114,7 @@ queries, to be signed using the ``host1-host2.`` key:
        keys { host1-host2. ;};
    };
 
-Multiple keys may be present in the ``keys`` statement, but only the
+Multiple keys may be present in the :any:`keys` statement, but only the
 first one is used. As this directive does not contain secrets, it can be
 used in a world-readable file.
 
@@ -129,10 +129,10 @@ TSIG-Based Access Control
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 TSIG keys may be specified in ACL definitions and ACL directives such as
-``allow-query``, ``allow-transfer``, and ``allow-update``. The above key
+:any:`allow-query`, :any:`allow-transfer`, and :any:`allow-update`. The above key
 would be denoted in an ACL element as ``key host1-host2.``
 
-Here is an example of an ``allow-update`` directive using a TSIG key:
+Here is an example of an :any:`allow-update` directive using a TSIG key:
 
 ::
 
@@ -143,7 +143,7 @@ from an address in ``localnets``, *and* if it is signed using the
 ``host1-host2.`` key.
 
 See :ref:`dynamic_update_policies` for a
-discussion of the more flexible ``update-policy`` statement.
+discussion of the more flexible :any:`update-policy` statement.
 
 Errors
 ~~~~~~

doc/arm/zones.inc.rst

@@ -38,7 +38,7 @@ The components of a Resource Record are:
    owner name
       The domain name where the RR is found.
 
-   type
+   RR type
       An encoded 16-bit value that specifies the type of the resource record.
       For a list of *types* of valid RRs, including those that have been obsoleted, please refer to
       `https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4`.

doc/dnssec-guide/advanced-discussions.rst

@@ -342,7 +342,7 @@ In contrast, for a small zone the difference is operationally negligible
 and the drawbacks outweigh the benefits.
 
 If NSEC3 opt-out is truly essential for a zone, the following
-configuration can be added to ``dnssec-policy``; for example, to create an
+configuration can be added to :any:`dnssec-policy`; for example, to create an
 NSEC3 chain using the SHA-1 hash algorithm, with the opt-out flag,
 no additional iterations, and no extra salt, use:
 
@@ -883,7 +883,7 @@ roll over DNSKEYs to a new algorithm, e.g., from RSASHA1 (algorithm 5 or
 7) to RSASHA256 (algorithm 8). The algorithm rollover steps must be followed with
 care to avoid breaking DNSSEC validation.
 
-If you are managing DNSSEC by using the ``dnssec-policy`` configuration,
+If you are managing DNSSEC by using the :any:`dnssec-policy` configuration,
 :iscman:`named` handles the rollover for you. Simply change the algorithm
 for the relevant keys, and :iscman:`named` uses the new algorithm when the
 key is next rolled. It performs a smooth transition to the new
@@ -900,9 +900,9 @@ In any case, the first step is to put DNSKEYs in place using the new algorithm.
 You must generate the ``K*`` files for the new algorithm and put
 them in the zone's key directory, where :iscman:`named` can access them. Take
 care to set appropriate ownership and permissions on the keys. If the
-``auto-dnssec`` zone option is set to ``maintain``, :iscman:`named`
+:any:`auto-dnssec` zone option is set to ``maintain``, :iscman:`named`
 automatically signs the zone with the new keys, based on their timing
-metadata when the ``dnssec-loadkeys-interval`` elapses or when you issue the
+metadata when the :any:`dnssec-loadkeys-interval` elapses or when you issue the
 :option:`rndc loadkeys` command. Otherwise, for primary zones, you can use
 :iscman:`nsupdate` to add the new DNSKEYs to the zone; this causes :iscman:`named`
 to use them to sign the zone. For secondary zones, e.g., on a
@@ -924,7 +924,7 @@ so that the old DS records disappear from all resolver caches.
 The next step is to remove the DNSKEYs using the old algorithm from your
 zone. Again this can be accomplished using :iscman:`nsupdate` to delete the
 old DNSKEYs (for primary zones only) or by automatic key rollover when
-``auto-dnssec`` is set to ``maintain``. You can cause the automatic key
+:any:`auto-dnssec` is set to ``maintain``. You can cause the automatic key
 rollover to take place immediately by using the :iscman:`dnssec-settime`
 utility to set the *Delete* date on all keys to any time in the past.
 (See the :option:`dnssec-settime -D date/offset <dnssec-settime -D>` option.)

doc/dnssec-guide/commonly-asked-questions.rst

@@ -149,7 +149,7 @@ Can I use the same key for multiple zones?
    logins. First, categorize your zones: high-value zones (or zones that have
    specific key rollover requirements) get their own key pairs, while other,
    more "generic" zones can use a single key pair for easier management. Note that
-   at present (mid-2020), fully automatic signing (using the ``dnssec-policy``
+   at present (mid-2020), fully automatic signing (using the :any:`dnssec-policy`
    clause in your :iscman:`named` configuration file) does not support reuse of keys
    except when the same zone appears in multiple views (see next question).
    To use the same key for multiple zones, sign your
@@ -157,7 +157,7 @@ Can I use the same key for multiple zones?
    should point to the same key directory.
 
 How do I sign the different instances of a zone that appears in multiple views?
-   Add a ``dnssec-policy`` statement to each ``zone`` definition in the
+   Add a :any:`dnssec-policy` statement to each :any:`zone` definition in the
    configuration file. To avoid problems when a single computer accesses
    different instances of the zone while information is still in its cache
    (e.g., a laptop moving from your office to a customer site), you
@@ -167,6 +167,6 @@ How do I sign the different instances of a zone that appears in multiple views?
 
 Will there be any problems if I change the DNSSEC policy for a zone?
    If you are using fully automatic signing, no. Just change the parameters in the
-   ``dnssec-policy`` statement and reload the configuration file. :iscman:`named`
+   :any:`dnssec-policy` statement and reload the configuration file. :iscman:`named`
    makes a smooth transition to the new policy, ensuring that your zone
    remains valid at all times.

doc/dnssec-guide/recipes.rst

@@ -53,7 +53,7 @@ on them.
 
 Using the method described in
 :ref:`easy_start_guide_for_authoritative_servers`, we just need to
-add a ``dnssec-policy`` statement to the relevant zone clause. This is
+add a :any:`dnssec-policy` statement to the relevant zone clause. This is
 what the :iscman:`named.conf` zone statement looks like on the primary server, 192.168.1.1:
 
 ::
@@ -167,7 +167,7 @@ like this:
 Rollovers
 ~~~~~~~~~
 
-If you are signing your zone using a ``dnssec-policy`` statement, this
+If you are signing your zone using a :any:`dnssec-policy` statement, this
 section is not really relevant to you. In the policy statement, you set how long
 you want your keys to be valid for, the time
 taken for information to propagate through your zone, the time it takes
@@ -246,7 +246,7 @@ Make sure the successor keys are readable by :iscman:`named`.
 
 :iscman:`named`'s logging messages indicate when the next
 key checking event is scheduled to occur, the frequency of which can be
-controlled by ``dnssec-loadkeys-interval``. The log message looks like
+controlled by :any:`dnssec-loadkeys-interval`. The log message looks like
 this:
 
 ::
@@ -323,7 +323,7 @@ the new ZSK is in effect:
 
 These are all the manual tasks you need to perform for a ZSK rollover.
 If you have followed the configuration examples in this guide of using
-``inline-signing`` and ``auto-dnssec``, everything else is automated for
+:any:`inline-signing` and :any:`auto-dnssec`, everything else is automated for
 you by BIND.
 
 Day of ZSK Rollover
@@ -503,7 +503,7 @@ one to keep the output small and hopefully clearer.
 
 Make sure the successor keys are readable by :iscman:`named`.
 
-The ``syslog`` message indicates when the next key
+The :any:`syslog` message indicates when the next key
 checking event is. The log message looks like this:
 
 ::
@@ -793,7 +793,7 @@ according to the steps described in
    NSEC3 will fall back to treating the zone as unsecured (rather than
    "bogus"), as described in Section 2 of :rfc:`5155`.
 
-To enable NSEC3, update your ``dnssec-policy`` and add the desired NSEC3
+To enable NSEC3, update your :any:`dnssec-policy` and add the desired NSEC3
 parameters. The example below enables NSEC3 for zones with the ``standard``
 DNSSEC policy, using 0 additional iterations, no opt-out, and a zero-length salt:
 
@@ -836,8 +836,8 @@ parameters, please see :ref:`advanced_discussions_nsec3param`.
 Migrating from NSEC3 to NSEC
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Migrating from NSEC3 back to NSEC is easy; just remove the ``nsec3param``
+Migrating from NSEC3 back to NSEC is easy; just remove the :any:`nsec3param`
-configuration option from your ``dnssec-policy`` and reconfigure the name
+configuration option from your :any:`dnssec-policy` and reconfigure the name
 server. You can tell that it worked if you see these messages in the log:
 
 ::
@@ -997,7 +997,7 @@ Here is what :iscman:`named.conf` looks like when it is signed:
        dnssec-policy "default";
    };
 
-To indicate the reversion to unsigned, change the ``dnssec-policy`` line:
+To indicate the reversion to unsigned, change the :any:`dnssec-policy` line:
 
 .. code-block:: none
   :emphasize-lines: 4
@@ -1075,6 +1075,6 @@ After a while, the zone is reverted back to the traditional, insecure DNS
 format. This can be verified by checking that all DNSKEY and RRSIG records have been
 removed from the zone.
 
-The ``dnssec-policy`` line can then be removed from :iscman:`named.conf` and
+The :any:`dnssec-policy` line can then be removed from :iscman:`named.conf` and
 the zone reloaded. The zone will no longer be subject to any DNSSEC
 maintenance.

doc/dnssec-guide/signing.rst

@@ -53,7 +53,7 @@ Enabling Automated DNSSEC Zone Maintenance and Key Generation
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To sign a zone, add the following statement to its
-``zone`` clause in the BIND 9 configuration file:
+:any:`zone` clause in the BIND 9 configuration file:
 
 ::
 
@@ -69,7 +69,7 @@ To sign a zone, add the following statement to its
        ...
    };
 
-The ``dnssec-policy`` statement causes the zone to be signed and turns
+The :any:`dnssec-policy` statement causes the zone to be signed and turns
 on automatic maintenance for the zone. This includes re-signing the zone
 as signatures expire and replacing keys on a periodic basis. The value
 ``default`` selects the default policy, which contains values suitable
@@ -86,13 +86,13 @@ reload the configuration file by running :option:`rndc reconfig`:
 
 And that's it - BIND signs your zone.
 
-At this point, before you go away and merrily add ``dnssec-policy``
+At this point, before you go away and merrily add :any:`dnssec-policy`
 statements to all your zones, we should mention that, like a number of
 other BIND configuration options, its scope depends on where it is placed. In
-the example above, we placed it in a ``zone`` clause, so it applied only
+the example above, we placed it in a :any:`zone` clause, so it applied only
-to the zone in question. If we had placed it in a ``view`` clause, it
+to the zone in question. If we had placed it in a :any:`view` clause, it
 would have applied to all zones in the view; and if we had placed it in
-the ``options`` clause, it would have applied to all zones served by
+the :namedconf:ref:`options` clause, it would have applied to all zones served by
 this instance of BIND.
 
 .. _signing_verification:
@@ -143,8 +143,8 @@ simulate what a validating resolver will check, by telling
 :iscman:`delv` to use a specific trust anchor.
 
 First, we need to make a copy of the key created by BIND. This
-is in the directory you set with the ``directory`` statement in
+is in the directory you set with the :any:`directory` statement in
-your configuration file's ``options`` clause, and is named something
+your configuration file's :namedconf:ref:`options` clause, and is named something
 like ``Kexample.com.+013.10376.key``:
 
 ::
@@ -161,7 +161,7 @@ and comments omitted):
    ...
    example.com. 3600 IN DNSKEY 257 3 13 6saiq99qDB...dqp+o0dw==
 
-We want to edit the copy to be in the ``trust-anchors`` format, so that
+We want to edit the copy to be in the :any:`trust-anchors` format, so that
 it looks like this:
 
 ::
@@ -637,7 +637,7 @@ That is quite complex, and it is all handled in BIND 9 with the single
 setting up our own DNSSEC policy with customized parameters. However, in many
 cases the defaults are adequate.
 
-At the time of this writing (mid-2020), ``dnssec-policy`` is still a
+At the time of this writing (mid-2020), :any:`dnssec-policy` is still a
 relatively new feature in BIND. Although it is the preferred
 way to run DNSSEC in a zone, it is not yet able to automatically implement
 all the features that are available
@@ -729,7 +729,7 @@ you are not already familiar with DNSSEC, it may be worth reading that chapter
 first.
 
 Setting up your own DNSSEC policy means that you must include a
-``dnssec-policy`` clause in the zone file. This sets values for the
+:any:`dnssec-policy` clause in the zone file. This sets values for the
 various parameters that affect the signing of zones and the rolling of
 keys. The following is an example of such a clause:
 
@@ -759,7 +759,7 @@ The policy has multiple parts:
    done by giving each policy a name, such as ``standard`` in the above
    example.
 
--  The ``keys`` clause lists all keys that should be in the zone, along
+-  The :any:`keys` clause lists all keys that should be in the zone, along
    with their associated parameters. In this example, we are using the
    conventional KSK/ZSK split, with the KSK changed every year and the
    ZSK changed every two months (the ``default`` DNSSEC policy sets a
@@ -787,15 +787,15 @@ The policy has multiple parts:
 
 -  The parameters ending in ``-safety`` are there to give
    you a bit of leeway in case a key roll doesn't go to plan. When
-   introduced into the zone, the ``publish-safety`` time is the amount
+   introduced into the zone, the :any:`publish-safety` time is the amount
    of additional time, over and above that calculated from the other
    parameters, during which the new key is in the zone but before BIND starts
-   to sign records with it. Similarly, the ``retire-safety`` is the
+   to sign records with it. Similarly, the :any:`retire-safety` is the
    amount of additional time, over and above that calculated from the
    other parameters, during which the old key is retained in the zone before
    being removed.
 
--  Finally, the ``purge-keys`` option allows you to clean up key files
+-  Finally, the :any:`purge-keys` option allows you to clean up key files
    automatically after a period of time. If a key has been removed from the
    zone, this option will determine how long its key files will be retained
    on disk.
@@ -813,10 +813,10 @@ during the process.
 Having defined a new policy called "standard", we now need to tell
 :iscman:`named` to use it. We do this by adding a ``dnssec-policy standard;``
 statement to the configuration file. Like many other configuration
-statements, it can be placed in the ``options`` statement (thus applying
+statements, it can be placed in the :namedconf:ref:`options` statement (thus applying
-to all zones on the server), a ``view`` statement (applying to all zones
+to all zones on the server), a :any:`view` statement (applying to all zones
-in the view), or a ``zone`` statement (applying only to that zone). In
+in the view), or a :any:`zone` statement (applying only to that zone). In
-this example, we'll add it to the ``zone`` statement:
+this example, we'll add it to the :any:`zone` statement:
 
 ::
 
@@ -892,7 +892,7 @@ CDS and a CDNSKEY record for the key in question to the apex of the
 zone. If your parent zone supports polling for CDS/CDNSKEY records, they
 are uploaded and the DS record published in the parent - at least ideally.
 
-If BIND is configured with ``parental-agents``, it will check for the DS
+If BIND is configured with :any:`parental-agents`, it will check for the DS
 presence. Let's look at the following configuration excerpt:
 
 ::
@@ -943,10 +943,10 @@ to tell :iscman:`named` that the DS record has been published.
 Alternate Ways of Signing a Zone
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Although use of the automatic ``dnssec-policy`` is the preferred way to sign zones in
+Although use of the automatic :any:`dnssec-policy` is the preferred way to sign zones in
 BIND, there are occasions where a more manual approach may be
 needed, such as when external hardware is used to
-generate and sign the zone. ``dnssec-policy`` does not currently support
+generate and sign the zone. :any:`dnssec-policy` does not currently support
 the use of external hardware, so if your security policy requires it, you
 need to use one of the methods described here.
 
@@ -987,15 +987,15 @@ Manual
 
 Semi-Automatic
    The first step in DNSSEC automation came with BIND 9.7, when the
-   ``auto-dnssec`` option was added. This causes :iscman:`named` to
+   :any:`auto-dnssec` option was added. This causes :iscman:`named` to
    periodically search the directory holding the key files (see
    :ref:`generate_keys` for a description) and to
    use the information in them to both add and remove keys and sign the
    zone.
 
-   Use of ``auto-dnssec`` alone requires that the zone be dynamic,
+   Use of :any:`auto-dnssec` alone requires that the zone be dynamic,
    something not suitable for a number of situations, so BIND 9.9 added the
-   ``inline-signing`` option. With this, :iscman:`named` essentially keeps the
+   :any:`inline-signing` option. With this, :iscman:`named` essentially keeps the
    signed and unsigned copies of the zone separate. The signed zone is
    created from the unsigned one using the key information; when the
    unsigned zone is updated and the zone reloaded, :iscman:`named` detects the
@@ -1026,11 +1026,11 @@ Fully Automatic with ``dnssec-keymgr``
    determine when to add and remove keys, and when to sign with them.
 
    In BIND 9.17.0 and later, this method of handling DNSSEC
-   policies has been replaced by the ``dnssec-policy`` statement in the
+   policies has been replaced by the :any:`dnssec-policy` statement in the
    configuration file.
 
-Fully Automatic with ``dnssec-policy``
+Fully Automatic with :any:`dnssec-policy`
-   Introduced a BIND 9.16, ``dnssec-policy`` replaces ``dnssec-keymgr`` from BIND
+   Introduced a BIND 9.16, :any:`dnssec-policy` replaces ``dnssec-keymgr`` from BIND
    9.17 onwards and avoids the need to run a separate program. It also
    handles the creation of keys if a zone is added (``dnssec-keymgr``
    requires an initial key) and deletes old key files as they are
@@ -1040,7 +1040,7 @@ Fully Automatic with ``dnssec-policy``
 We now look at some of these methods in more detail. We cover
 semi-automatic signing first, as that contains a lot of useful
 information about keys and key timings. After that, we
-touch on fully automatic signing with ``dnssec-policy``. Since this has
+touch on fully automatic signing with :any:`dnssec-policy`. Since this has
 already been described in
 :ref:`easy_start_guide_for_authoritative_servers`, we will just
 mention a few additional points. Finally, we briefly describe manual signing.
@@ -1051,15 +1051,15 @@ Semi-Automatic Signing
 ^^^^^^^^^^^^^^^^^^^^^^
 
 As noted above, the term semi-automatic signing has been used in this
-document to indicate the mode of signing enabled by the ``auto-dnssec``
+document to indicate the mode of signing enabled by the :any:`auto-dnssec`
-and ``inline-signing`` keywords. :iscman:`named` signs the zone without any
+and :any:`inline-signing` keywords. :iscman:`named` signs the zone without any
 manual intervention, based purely on the timing information in the
 DNSSEC key files. The files, however, must be created manually.
 
 By appropriately setting the key parameters and the timing information
 in the key files, you can implement any DNSSEC policy you want for your
 zones. But why manipulate the key information yourself rather than rely
-on ``dnssec-policy`` to do it for you? The answer
+on :any:`dnssec-policy` to do it for you? The answer
 is that semi-automatic signing allows you to do things that, at the time of this writing
 (mid-2020), are currently not possible with one of the key managers: for
 example, the ability to use an HSM to store keys, or the ability to use
@@ -1347,19 +1347,19 @@ before a rollover depends on your organization's security policy.
 
 .. _advanced_discussions_automatic_dnssec-policy:
 
-Fully Automatic Signing With ``dnssec-policy``
+Fully Automatic Signing With :any:`dnssec-policy`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Since BIND 9.16, key management is fully integrated ingo :iscman:`named`.
 Managing the signing process and rolling of these keys has been described in
 :ref:`easy_start_guide_for_authoritative_servers` and is not
 repeated here. A few points are worth noting, though:
 
--  The ``dnssec-policy`` statement in the :iscman:`named` configuration file
+-  The :any:`dnssec-policy` statement in the :iscman:`named` configuration file
    describes all aspects of the DNSSEC policy, including the signing.
 
--  When using ``dnssec-policy``, there is no need to set the
+-  When using :any:`dnssec-policy`, there is no need to set the
-   ``auto-dnssec`` and ``inline-signing`` options for a zone. The zone's
+   :any:`auto-dnssec` and :any:`inline-signing` options for a zone. The zone's
    ``policy`` statement implicitly does this.
 
 .. _advanced_discussions_manual_key_management_and_signing:

doc/dnssec-guide/troubleshooting.rst

@@ -148,7 +148,7 @@ DNSSEC errors.
 Basic Logging
 ~~~~~~~~~~~~~
 
-DNSSEC validation error messages show up in ``syslog`` as a
+DNSSEC validation error messages show up in :any:`syslog` as a
 query error by default. Here is an example of what it may look like:
 
 ::
@@ -173,11 +173,11 @@ logging is thus not recommended for production servers.
 
 With that said, sometimes it may become necessary to temporarily enable
 BIND debug logging to see more details of how and whether DNSSEC is
-validating. DNSSEC-related messages are not recorded in ``syslog`` by default,
+validating. DNSSEC-related messages are not recorded in :any:`syslog` by default,
-even if query log is enabled; only DNSSEC errors show up in ``syslog``.
+even if query log is enabled; only DNSSEC errors show up in :any:`syslog`.
 
 The example below shows how to enable debug level 3 (to see full DNSSEC
-validation messages) in BIND 9 and have it sent to ``syslog``:
+validation messages) in BIND 9 and have it sent to :any:`syslog`:
 
 ::
 
@@ -205,7 +205,7 @@ The example below shows how to log DNSSEC messages to their own file
 
 After turning on debug logging and restarting BIND, a large
 number of log messages appear in
-``syslog``. The example below shows the log messages as a result of
+:any:`syslog`. The example below shows the log messages as a result of
 successfully looking up and validating the domain name ``ftp.isc.org``.
 
 ::
@@ -279,7 +279,7 @@ Below is an example attempting to resolve the A record for a test domain
 name ``www.example.net``. From the user's perspective, as described in
 :ref:`how_do_i_know_validation_problem`, only a SERVFAIL
 message is returned. On the validating resolver, we see the
-following messages in ``syslog``:
+following messages in :any:`syslog`:
 
 ::
 
@@ -404,7 +404,7 @@ Unable to Load Keys
 ^^^^^^^^^^^^^^^^^^^
 
 This is a simple yet common issue. If the key files are present but
-unreadable by :iscman:`named` for some reason, the ``syslog`` returns clear error
+unreadable by :iscman:`named` for some reason, the :any:`syslog` returns clear error
 messages, as shown below:
 
 ::
@@ -415,7 +415,7 @@ messages, as shown below:
    named[32447]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:04:36.521
 
 However, if no keys are found, the error is not as obvious. Below shows
-the ``syslog`` messages after executing ``rndc
+the :any:`syslog` messages after executing ``rndc
 reload`` with the key files missing from the key directory:
 
 ::
@@ -463,7 +463,7 @@ Invalid Trust Anchors
 
 In most cases, you never need to explicitly configure trust
 anchors. :iscman:`named` supplies the current root trust anchor and,
-with the default setting of ``dnssec-validation``, updates it on the
+with the default setting of :any:`dnssec-validation`, updates it on the
 infrequent occasions when it is changed.
 
 However, in some circumstances you may need to explicitly configure

doc/dnssec-guide/validation.rst

@@ -40,7 +40,7 @@ described in :ref:`how_to_test_recursive_server`.
 
 In earlier versions of BIND, including 9.11-ESV, DNSSEC
 validation must be explicitly enabled. To do this, you only need to
-add one line to the ``options`` section of your configuration file:
+add one line to the :namedconf:ref:`options` section of your configuration file:
 
 ::
 
@@ -280,7 +280,7 @@ name fails:
    ;; MSG SIZE  rcvd: 78
 
 On the other hand, if DNSSEC validation is disabled (by adding the
-statement ``dnssec-validation no;`` to the ``options`` clause in the
+statement ``dnssec-validation no;`` to the :namedconf:ref:`options` clause in the
 configuration file), the lookup succeeds:
 
 ::
@@ -372,8 +372,8 @@ take a closer look at what DNSSEC validation actually does, and some other optio
 
 .. _dnssec_validation_explained:
 
-``dnssec-validation``
+:any:`dnssec-validation`
-^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
@@ -382,9 +382,9 @@ take a closer look at what DNSSEC validation actually does, and some other optio
    };
 
 This “auto” line enables automatic DNSSEC trust anchor configuration
-using the ``managed-keys`` feature. In this case, no manual key
+using the :any:`managed-keys` feature. In this case, no manual key
 configuration is needed. There are three possible choices for the
-``dnssec-validation`` option:
+:any:`dnssec-validation` option:
 
 -  *yes*: DNSSEC validation is enabled, but a trust anchor must be
    manually configured. No validation actually takes place until
@@ -396,11 +396,11 @@ configuration is needed. There are three possible choices for the
 -  *auto*: DNSSEC validation is enabled, and a default trust anchor
    (included as part of BIND 9) for the DNS root zone is used. This is the
    default; BIND automatically does this if there is no
-   ``dnssec-validation`` line in the configuration file.
+   :any:`dnssec-validation` line in the configuration file.
 
 Let's discuss the difference between *yes* and *auto*. If set to
 *yes*, the trust anchor must be manually defined and maintained
-using the ``trust-anchors`` statement (with either the ``static-key`` or
+using the :any:`trust-anchors` statement (with either the ``static-key`` or
 ``static-ds`` modifier) in the configuration file; if set to
 *auto* (the default, and as shown in the example), then no further
 action should be required as BIND includes a copy [#]_ of the root key.
@@ -565,7 +565,7 @@ the client.
 .. [#]
    BIND technically includes two copies of the root key: one is in
    ``bind.keys.h`` and is built into the executable, and one is in
-   ``bind.keys`` as a ``trust-anchors`` statement. The two copies of the
+   ``bind.keys`` as a :any:`trust-anchors` statement. The two copies of the
    key are identical.
 
 .. _trust_anchors_description:
@@ -649,7 +649,7 @@ anchor) configured. How did it get here, and how do we maintain it?
 
 If you followed the recommendation in
 :ref:`easy_start_guide_for_recursive_servers`, by setting
-``dnssec-validation`` to *auto*, there is nothing left to do.
+:any:`dnssec-validation` to *auto*, there is nothing left to do.
 BIND already includes a copy of the root key (in the file
 ``bind.keys``), and automatically updates it when the root key
 changes. [#]_ It looks something like this:
@@ -668,7 +668,7 @@ changes. [#]_ It looks something like this:
    };
 
 You can, of course, decide to manage this key manually yourself.
-First, you need to make sure that ``dnssec-validation`` is set
+First, you need to make sure that :any:`dnssec-validation` is set
 to *yes* rather than *auto*:
 
 ::
@@ -679,7 +679,7 @@ to *yes* rather than *auto*:
 
 Then, download the root key manually from a trustworthy source, such as
 `<https://www.isc.org/bind-keys>`__. Finally, take the root key you
-manually downloaded and put it into a ``trust-anchors`` statement as
+manually downloaded and put it into a :any:`trust-anchors` statement as
 shown below:
 
 ::
@@ -695,7 +695,7 @@ shown below:
                    R1AkUTV74bU=";
    };
 
-While this ``trust-anchors`` statement and the one in the ``bind.keys``
+While this :any:`trust-anchors` statement and the one in the ``bind.keys``
 file appear similar, the definition of the key in ``bind.keys`` has the
 ``initial-key`` modifier, whereas in the statement in the configuration
 file, that is replaced by ``static-key``. There is an important

doc/man/nsupdate.1in

@@ -284,7 +284,7 @@ When using GSS\-TSIG, this command specifies the use of \fBrealm_name\fP rather
 in \fBkrb5.conf\fP\&. If no realm is specified, the saved realm is
 cleared.
 .TP
-.B \fBcheck\-names [yes_or_no]\fP
+.B \fBcheck\-names [boolean]\fP
 This command turns on or off check\-names processing on records to be added.
 Check\-names has no effect on prerequisites or records to be deleted.
 By default check\-names processing is on. If check\-names processing

doc/man/rndc.8in

@@ -32,7 +32,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 rndc \- name server control utility
 .SH SYNOPSIS
 .sp
-\fBrndc\fP [\fB\-b\fP source\-address] [\fB\-c\fP config\-file] [\fB\-k\fP key\-file] [\fB\-s\fP server] [\fB\-p\fP port] [\fB\-q\fP] [\fB\-r\fP] [\fB\-V\fP] [\fB\-y\fP key_id] [[\fB\-4\fP] | [\fB\-6\fP]] {command}
+\fBrndc\fP [\fB\-b\fP source\-address] [\fB\-c\fP config\-file] [\fB\-k\fP key\-file] [\fB\-s\fP server] [\fB\-p\fP port] [\fB\-q\fP] [\fB\-r\fP] [\fB\-V\fP] [\fB\-y\fP server_key] [[\fB\-4\fP] | [\fB\-6\fP]] {command}
 .SH DESCRIPTION
 .sp
 \fBrndc\fP controls the operation of a name server. If \fBrndc\fP is
@@ -47,7 +47,7 @@ algorithms are HMAC\-MD5 (for compatibility), HMAC\-SHA1, HMAC\-SHA224,
 HMAC\-SHA256 (default), HMAC\-SHA384, and HMAC\-SHA512. They use a shared
 secret on each end of the connection, which provides TSIG\-style
 authentication for the command request and the name server\(aqs response.
-All commands sent over the channel must be signed by a key_id known to
+All commands sent over the channel must be signed by a server_key known to
 the server.
 .sp
 \fBrndc\fP reads a configuration file to determine how to contact the name
@@ -119,9 +119,9 @@ This option enables verbose logging.
 .UNINDENT
 .INDENT 0.0
 .TP
-.B \-y key_id
+.B \-y server_key
-This option indicates use of the key \fBkey_id\fP from the configuration file. For control message validation to succeed, \fBkey_id\fP must be known
+This option indicates use of the key \fBserver_key\fP from the configuration file. For control message validation to succeed, \fBserver_key\fP must be known
-by \fI\%named\fP with the same algorithm and secret string. If no \fBkey_id\fP is specified,
+by \fI\%named\fP with the same algorithm and secret string. If no \fBserver_key\fP is specified,
 \fBrndc\fP first looks for a key clause in the server statement of
 the server being used, or if no server statement is present for that
 host, then in the default\-key clause of the options statement. Note that
@@ -706,7 +706,7 @@ zone. To specify a redirect zone, use the special zone name
 would specify a zone called "\-redirect".)
 .SH LIMITATIONS
 .sp
-There is currently no way to provide the shared secret for a \fBkey_id\fP
+There is currently no way to provide the shared secret for a \fBserver_key\fP
 without using the configuration file.
 .sp
 Several error messages could be clearer.

doc/notes/notes-9.19.1.rst

@@ -29,11 +29,11 @@ New Features
 - Catalog Zones schema version 2, as described in the
   "DNS Catalog Zones" IETF draft version 5 document, is now supported by
   :iscman:`named`. All of the previously supported BIND-specific catalog
-  zone custom properties (``primaries``, ``allow-query``, and
+  zone custom properties (:any:`primaries`, :any:`allow-query`, and
-  ``allow-transfer``), as well as the new Change of Ownership (``coo``)
+  :any:`allow-transfer`), as well as the new Change of Ownership (``coo``)
   property, are now implemented. Schema version 1 is still supported,
   with some additional validation rules applied from schema version 2:
-  for example, the ``version`` property is mandatory, and a member zone
+  for example, the :any:`version` property is mandatory, and a member zone
   PTR RRset must not contain more than one record. In the event of a
   validation error, a corresponding error message is logged to help with
   diagnosing the problem. :gl:`#3221` :gl:`#3222` :gl:`#3223`

doc/notes/notes-9.19.2.rst

@@ -15,14 +15,14 @@ Notes for BIND 9.19.2
 Feature Changes
 ~~~~~~~~~~~~~~~
 
-- New ``dnssec-policy`` configuration checks have been added to detect
+- New :any:`dnssec-policy` configuration checks have been added to detect
   unusual policies, such as missing KSK and/or ZSK and too-short key
   lifetimes and re-sign periods. :gl:`#1611`
 
 Bug Fixes
 ~~~~~~~~~
 
-- The ``fetches-per-server`` quota is designed to adjust itself downward
+- The :any:`fetches-per-server` quota is designed to adjust itself downward
   automatically when an authoritative server times out too frequently.
   Due to a coding error, that adjustment was applied incorrectly, so
   that the quota for a congested server was always set to 1. This has
@@ -31,7 +31,7 @@ Bug Fixes
 - DNSSEC-signed catalog zones were not being processed correctly. This
   has been fixed. :gl:`#3380`
 
-- Key files were updated every time the ``dnssec-policy`` key manager
+- Key files were updated every time the :any:`dnssec-policy` key manager
   ran, whether the metadata had changed or not. :iscman:`named` now
   checks whether changes were applied before writing out the key files.
   :gl:`#3302`