Adding upstream version 1:9.16.44.upstream/1%9.16.44

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 608 insertions, 0 deletions

diff --git a/bin/rndc/rndc.rst b/bin/rndc/rndc.rst
new file mode 100644
index 0000000..b2ec0e8
--- /dev/null
+++ b/bin/rndc/rndc.rst
@@ -0,0 +1,608 @@
+.. Copyright (C) Internet Systems Consortium, Inc. ("ISC")
+..
+.. SPDX-License-Identifier: MPL-2.0
+..
+.. This Source Code Form is subject to the terms of the Mozilla Public
+.. License, v. 2.0.  If a copy of the MPL was not distributed with this
+.. file, you can obtain one at https://mozilla.org/MPL/2.0/.
+..
+.. See the COPYRIGHT file distributed with this work for additional
+.. information regarding copyright ownership.
+
+.. highlight: console
+
+.. _man_rndc:
+
+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}
+
+Description
+~~~~~~~~~~~
+
+``rndc`` controls the operation of a name server; it supersedes the
+``ndc`` utility. If ``rndc`` is
+invoked with no command line options or arguments, it prints a short
+summary of the supported commands and the available options and their
+arguments.
+
+``rndc`` communicates with the name server over a TCP connection,
+sending commands authenticated with digital signatures. In the current
+versions of ``rndc`` and ``named``, the only supported authentication
+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
+the server.
+
+``rndc`` reads a configuration file to determine how to contact the name
+server and decide what algorithm and key it should use.
+
+Options
+~~~~~~~
+
+``-4``
+   This option indicates use of IPv4 only.
+
+``-6``
+   This option indicates use of IPv6 only.
+
+``-b source-address``
+   This option indicates ``source-address`` as the source address for the connection to the
+   server. Multiple instances are permitted, to allow setting of both the
+   IPv4 and IPv6 source addresses.
+
+``-c config-file``
+   This option indicates ``config-file`` as the configuration file instead of the default,
+   ``/etc/rndc.conf``.
+
+``-k key-file``
+   This option indicates ``key-file`` as the key file instead of the default,
+   ``/etc/rndc.key``. The key in ``/etc/rndc.key`` is used to
+   authenticate commands sent to the server if the config-file does not
+   exist.
+
+``-s server``
+   ``server`` is the name or address of the server which matches a server
+   statement in the configuration file for ``rndc``. If no server is
+   supplied on the command line, the host named by the default-server
+   clause in the options statement of the ``rndc`` configuration file
+   is used.
+
+``-p port``
+   This option instructs BIND 9 to send commands to TCP port ``port`` instead of its default control
+   channel port, 953.
+
+``-q``
+   This option sets quiet mode, where message text returned by the server is not printed
+   unless there is an error.
+
+``-r``
+   This option instructs ``rndc`` to print the result code returned by ``named``
+   after executing the requested command (e.g., ISC_R_SUCCESS,
+   ISC_R_FAILURE, etc.).
+
+``-V``
+   This option enables verbose logging.
+
+``-y key_id``
+   This option indicates use of the key ``key_id`` from the configuration file. For control message validation to succeed, ``key_id`` must be known
+   by ``named`` with the same algorithm and secret string. If no ``key_id`` is specified,
+   ``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
+   the configuration file contains shared secrets which are used to send
+   authenticated control commands to name servers, and should therefore
+   not have general read or write access.
+
+Commands
+~~~~~~~~
+
+A list of commands supported by ``rndc`` can be seen by running ``rndc``
+without arguments.
+
+Currently supported commands are:
+
+``addzone`` *zone* [*class* [*view*]] *configuration*
+   This command adds a zone while the server is running. This command requires the
+   ``allow-new-zones`` option to be set to ``yes``. The configuration
+   string specified on the command line is the zone configuration text
+   that would ordinarily be placed in ``named.conf``.
+
+   The configuration is saved in a file called ``viewname.nzf`` (or, if
+   ``named`` is compiled with liblmdb, an LMDB database file called
+   ``viewname.nzd``). ``viewname`` is the name of the view, unless the view
+   name contains characters that are incompatible with use as a file
+   name, in which case a cryptographic hash of the view name is used
+   instead. When ``named`` is restarted, the file is loaded into
+   the view configuration so that zones that were added can persist
+   after a restart.
+
+   This sample ``addzone`` command adds the zone ``example.com`` to
+   the default view:
+
+   ``rndc addzone example.com '{ type master; file "example.com.db"; };'``
+
+   (Note the brackets around and semi-colon after the zone configuration
+   text.)
+
+   See also ``rndc delzone`` and ``rndc modzone``.
+
+``delzone`` [**-clean**] *zone* [*class* [*view*]]
+   This command deletes a zone while the server is running.
+
+   If the ``-clean`` argument is specified, the zone's master file (and
+   journal file, if any) are deleted along with the zone. Without
+   the ``-clean`` option, zone files must be deleted manually. (If the
+   zone is of type ``secondary`` or ``stub``, the files needing to be removed
+   are reported in the output of the ``rndc delzone`` command.)
+
+   If the zone was originally added via ``rndc addzone``, then it is
+   removed permanently. However, if it was originally configured in
+   ``named.conf``, then that original configuration remains in place;
+   when the server is restarted or reconfigured, the zone is
+   recreated. To remove it permanently, it must also be removed from
+   ``named.conf``.
+
+   See also ``rndc addzone`` and ``rndc modzone``.
+
+``dnssec`` ( **-status** | **-rollover** **-key** id [**-alg** *algorithm*] [**-when** *time*] | **-checkds** [**-key** *id* [**-alg** *algorithm*]] [**-when** *time*] ( *published* | *withdrawn* )) *zone* [*class* [*view*]]
+   This command allows you to interact with the "dnssec-policy" of a given
+   zone.
+
+   ``rndc dnssec -status`` show the DNSSEC signing state for the specified
+   zone.
+
+   ``rndc dnssec -rollover`` allows you to schedule key rollover for a
+   specific key (overriding the original key lifetime).
+
+   ``rndc dnssec -checkds`` informs :iscman:`named` that the DS for
+   a specified zone's key-signing key has been confirmed to be published
+   in, or withdrawn from, the parent zone. This is required in order to
+   complete a KSK rollover.  The ``-key id`` and ``-alg algorithm`` arguments
+   can be used to specify a particular KSK, if necessary; if there is only
+   one key acting as a KSK for the zone, these arguments can be omitted.
+   The time of publication or withdrawal for the DS is set to the current
+   time by default, but can be overridden to a specific time with the
+   argument ``-when time``, where ``time`` is expressed in YYYYMMDDHHMMSS
+   notation.
+
+``dnstap`` ( **-reopen** | **-roll** [*number*] )
+   This command closes and re-opens DNSTAP output files.
+
+   ``rndc dnstap -reopen`` allows
+   the output file to be renamed externally, so that ``named`` can
+   truncate and re-open it.
+
+   ``rndc dnstap -roll`` causes the output file
+   to be rolled automatically, similar to log files. The most recent
+   output file has ".0" appended to its name; the previous most recent
+   output file is moved to ".1", and so on. If ``number`` is specified, then
+   the number of backup log files is limited to that number.
+
+``dumpdb`` [**-all** | **-cache** | **-zones** | **-adb** | **-bad** | **-expired** | **-fail**] [*view ...*]
+   This command dumps the server's caches (default) and/or zones to the dump file for
+   the specified views. If no view is specified, all views are dumped.
+   (See the ``dump-file`` option in the BIND 9 Administrator Reference
+   Manual.)
+
+``flush``
+   This command flushes the server's cache.
+
+``flushname`` *name* [*view*]
+   This command flushes the given name from the view's DNS cache and, if applicable,
+   from the view's nameserver address database, bad server cache, and
+   SERVFAIL cache.
+
+``flushtree`` *name* [*view*]
+   This command flushes the given name, and all of its subdomains, from the view's
+   DNS cache, address database, bad server cache, and SERVFAIL cache.
+
+``freeze`` [*zone* [*class* [*view*]]]
+   This command suspends updates to a dynamic zone. If no zone is specified, then all
+   zones are suspended. This allows manual edits to be made to a zone
+   normally updated by dynamic update, and causes changes in the
+   journal file to be synced into the master file. All dynamic update
+   attempts are refused while the zone is frozen.
+
+   See also ``rndc thaw``.
+
+``halt`` [**-p**]
+   This command stops the server immediately. Recent changes made through dynamic
+   update or IXFR are not saved to the master files, but are rolled
+   forward from the journal files when the server is restarted. If
+   ``-p`` is specified, ``named``'s process ID is returned. This allows
+   an external process to determine when ``named`` has completed
+   halting.
+
+   See also ``rndc stop``.
+
+``loadkeys`` [*zone* [*class* [*view*]]]
+   This command fetches all DNSSEC keys for the given zone from the key directory. If
+   they are within their publication period, they are merged into the
+   zone's DNSKEY RRset. Unlike ``rndc sign``, however, the zone is not
+   immediately re-signed by the new keys, but is allowed to
+   incrementally re-sign over time.
+
+   This command requires that the zone be configured with a ``dnssec-policy``, or
+   that the ``auto-dnssec`` zone option be set to ``maintain``, and also requires the
+   zone to be configured to allow dynamic DNS. (See "Dynamic Update Policies" in
+   the Administrator Reference Manual for more details.)
+
+``managed-keys`` (*status* | *refresh* | *sync* | *destroy*) [*class* [*view*]]
+   This command inspects and controls the "managed-keys" database which handles
+   :rfc:`5011` DNSSEC trust anchor maintenance. If a view is specified, these
+   commands are applied to that view; otherwise, they are applied to all
+   views.
+
+   -  When run with the ``status`` keyword, this prints the current status of
+      the managed-keys database.
+
+   -  When run with the ``refresh`` keyword, this forces an immediate refresh
+      query to be sent for all the managed keys, updating the
+      managed-keys database if any new keys are found, without waiting
+      the normal refresh interval.
+
+   -  When run with the ``sync`` keyword, this forces an immediate dump of
+      the managed-keys database to disk (in the file
+      ``managed-keys.bind`` or (``viewname.mkeys``). This synchronizes
+      the database with its journal file, so that the database's current
+      contents can be inspected visually.
+
+   -  When run with the ``destroy`` keyword, the managed-keys database
+      is shut down and deleted, and all key maintenance is terminated.
+      This command should be used only with extreme caution.
+
+      Existing keys that are already trusted are not deleted from
+      memory; DNSSEC validation can continue after this command is used.
+      However, key maintenance operations cease until ``named`` is
+      restarted or reconfigured, and all existing key maintenance states
+      are deleted.
+
+      Running ``rndc reconfig`` or restarting ``named`` immediately
+      after this command causes key maintenance to be reinitialized
+      from scratch, just as if the server were being started for the
+      first time. This is primarily intended for testing, but it may
+      also be used, for example, to jumpstart the acquisition of new
+      keys in the event of a trust anchor rollover, or as a brute-force
+      repair for key maintenance problems.
+
+``modzone`` *zone* [*class* [*view*]] *configuration*
+   This command modifies the configuration of a zone while the server is running. This
+   command requires the ``allow-new-zones`` option to be set to ``yes``.
+   As with ``addzone``, the configuration string specified on the
+   command line is the zone configuration text that would ordinarily be
+   placed in ``named.conf``.
+
+   If the zone was originally added via ``rndc addzone``, the
+   configuration changes are recorded permanently and are still
+   in effect after the server is restarted or reconfigured. However, if
+   it was originally configured in ``named.conf``, then that original
+   configuration remains in place; when the server is restarted or
+   reconfigured, the zone reverts to its original configuration. To
+   make the changes permanent, it must also be modified in
+   ``named.conf``.
+
+   See also ``rndc addzone`` and ``rndc delzone``.
+
+``notify`` *zone* [*class* [*view*]]
+   This command resends NOTIFY messages for the zone.
+
+``notrace``
+   This command sets the server's debugging level to 0.
+
+   See also ``rndc trace``.
+
+``nta`` [( **-class** *class* | **-dump** | **-force** | **-remove** | **-lifetime** *duration*)] *domain* [*view*]
+   This command sets a DNSSEC negative trust anchor (NTA) for ``domain``, with a
+   lifetime of ``duration``. The default lifetime is configured in
+   ``named.conf`` via the ``nta-lifetime`` option, and defaults to one
+   hour. The lifetime cannot exceed one week.
+
+   A negative trust anchor selectively disables DNSSEC validation for
+   zones that are known to be failing because of misconfiguration rather
+   than an attack. When data to be validated is at or below an active
+   NTA (and above any other configured trust anchors), ``named``
+   aborts the DNSSEC validation process and treats the data as insecure
+   rather than bogus. This continues until the NTA's lifetime has
+   elapsed.
+
+   NTAs persist across restarts of the ``named`` server. The NTAs for a
+   view are saved in a file called ``name.nta``, where ``name`` is the name
+   of the view; if it contains characters that are incompatible with
+   use as a file name, a cryptographic hash is generated from the name of
+   the view.
+
+   An existing NTA can be removed by using the ``-remove`` option.
+
+   An NTA's lifetime can be specified with the ``-lifetime`` option.
+   TTL-style suffixes can be used to specify the lifetime in seconds,
+   minutes, or hours. If the specified NTA already exists, its lifetime
+   is updated to the new value. Setting ``lifetime`` to zero is
+   equivalent to ``-remove``.
+
+   If ``-dump`` is used, any other arguments are ignored and a list
+   of existing NTAs is printed. Note that this may include NTAs that are
+   expired but have not yet been cleaned up.
+
+   Normally, ``named`` periodically tests to see whether data below
+   an NTA can now be validated (see the ``nta-recheck`` option in the
+   Administrator Reference Manual for details). If data can be
+   validated, then the NTA is regarded as no longer necessary and is
+   allowed to expire early. The ``-force`` parameter overrides this behavior
+   and forces an NTA to persist for its entire lifetime, regardless of
+   whether data could be validated if the NTA were not present.
+
+   The view class can be specified with ``-class``. The default is class
+   ``IN``, which is the only class for which DNSSEC is currently
+   supported.
+
+   All of these options can be shortened, i.e., to ``-l``, ``-r``,
+   ``-d``, ``-f``, and ``-c``.
+
+   Unrecognized options are treated as errors. To refer to a domain or
+   view name that begins with a hyphen, use a double-hyphen (--) on the
+   command line to indicate the end of options.
+
+``querylog`` [(*on* | *off*)]
+   This command enables or disables query logging. For backward compatibility, this
+   command can also be used without an argument to toggle query logging
+   on and off.
+
+   Query logging can also be enabled by explicitly directing the
+   ``queries`` ``category`` to a ``channel`` in the ``logging`` section
+   of ``named.conf``, or by specifying ``querylog yes;`` in the
+   ``options`` section of ``named.conf``.
+
+``reconfig``
+   This command reloads the configuration file and loads new zones, but does not reload
+   existing zone files even if they have changed. This is faster than a
+   full ``reload`` when there is a large number of zones, because it
+   avoids the need to examine the modification times of the zone files.
+
+``recursing``
+   This command dumps the list of queries ``named`` is currently
+   recursing on, and the list of domains to which iterative queries
+   are currently being sent.
+
+   The first list includes all unique clients that are waiting for
+   recursion to complete, including the query that is awaiting a
+   response and the timestamp (seconds since the Unix epoch) of
+   when named started processing this client query.
+
+   The second list comprises of domains for which there are active
+   (or recently active) fetches in progress.  It reports the number
+   of active fetches for each domain and the number of queries that
+   have been passed (allowed) or dropped (spilled) as a result of
+   the ``fetches-per-zone`` limit.  (Note: these counters are not
+   cumulative over time; whenever the number of active fetches for
+   a domain drops to zero, the counter for that domain is deleted,
+   and the next time a fetch is sent to that domain, it is recreated
+   with the counters set to zero).
+
+``refresh`` *zone* [*class* [*view*]]
+   This command schedules zone maintenance for the given zone.
+
+``reload``
+   This command reloads the configuration file and zones.
+
+``reload`` *zone* [*class* [*view*]]
+   This command reloads the given zone.
+
+``retransfer`` *zone* [*class* [*view*]]
+   This command retransfers the given secondary zone from the primary server.
+
+   If the zone is configured to use ``inline-signing``, the signed
+   version of the zone is discarded; after the retransfer of the
+   unsigned version is complete, the signed version is regenerated
+   with new signatures.
+
+``scan``
+   This command scans the list of available network interfaces for changes, without
+   performing a full ``reconfig`` or waiting for the
+   ``interface-interval`` timer.
+
+``secroots`` [**-**] [*view* ...]
+   This command dumps the security roots (i.e., trust anchors configured via
+   ``trust-anchors``, or the ``managed-keys`` or ``trusted-keys`` statements
+   [both deprecated], or ``dnssec-validation auto``) and negative trust anchors
+   for the specified views. If no view is specified, all views are
+   dumped. Security roots indicate whether they are configured as trusted
+   keys, managed keys, or initializing managed keys (managed keys that have not
+   yet been updated by a successful key refresh query).
+
+   If the first argument is ``-``, then the output is returned via the
+   ``rndc`` response channel and printed to the standard output.
+   Otherwise, it is written to the secroots dump file, which defaults to
+   ``named.secroots``, but can be overridden via the ``secroots-file``
+   option in ``named.conf``.
+
+   See also ``rndc managed-keys``.
+
+``serve-stale`` (**on** | **off** | **reset** | **status**) [*class* [*view*]]
+   This command enables, disables, resets, or reports the current status of the serving
+   of stale answers as configured in ``named.conf``.
+
+   If serving of stale answers is disabled by ``rndc-serve-stale off``,
+   then it remains disabled even if ``named`` is reloaded or
+   reconfigured. ``rndc serve-stale reset`` restores the setting as
+   configured in ``named.conf``.
+
+   ``rndc serve-stale status`` reports whether serving of stale
+   answers is currently enabled, disabled by the configuration, or
+   disabled by ``rndc``. It also reports the values of
+   ``stale-answer-ttl`` and ``max-stale-ttl``.
+
+``showzone`` *zone* [*class* [*view*]]
+   This command prints the configuration of a running zone.
+
+   See also ``rndc zonestatus``.
+
+``sign`` *zone* [*class* [*view*]]
+   This command fetches all DNSSEC keys for the given zone from the key directory (see
+   the ``key-directory`` option in the BIND 9 Administrator Reference
+   Manual). If they are within their publication period, they are merged into
+   the zone's DNSKEY RRset. If the DNSKEY RRset is changed, then the
+   zone is automatically re-signed with the new key set.
+
+   This command requires that the zone be configured with a ``dnssec-policy``, or
+   that the ``auto-dnssec`` zone option be set to ``allow`` or ``maintain``,
+   and also requires the zone to be configured to allow dynamic DNS. (See
+   "Dynamic Update Policies" in the BIND 9 Administrator Reference Manual for more
+   details.)
+
+   See also ``rndc loadkeys``.
+
+``signing`` [(**-list** | **-clear** *keyid/algorithm* | **-clear** *all* | **-nsec3param** ( *parameters* | none ) | **-serial** *value* ) *zone* [*class* [*view*]]
+   This command lists, edits, or removes the DNSSEC signing-state records for the
+   specified zone. The status of ongoing DNSSEC operations, such as
+   signing or generating NSEC3 chains, is stored in the zone in the form
+   of DNS resource records of type ``sig-signing-type``.
+   ``rndc signing -list`` converts these records into a human-readable
+   form, indicating which keys are currently signing or have finished
+   signing the zone, and which NSEC3 chains are being created or
+   removed.
+
+   ``rndc signing -clear`` can remove a single key (specified in the
+   same format that ``rndc signing -list`` uses to display it), or all
+   keys. In either case, only completed keys are removed; any record
+   indicating that a key has not yet finished signing the zone is
+   retained.
+
+   ``rndc signing -nsec3param`` sets the NSEC3 parameters for a zone.
+   This is the only supported mechanism for using NSEC3 with
+   ``inline-signing`` zones. Parameters are specified in the same format
+   as an NSEC3PARAM resource record: ``hash algorithm``, ``flags``, ``iterations``,
+   and ``salt``, in that order.
+
+   Currently, the only defined value for ``hash algorithm`` is ``1``,
+   representing SHA-1. The ``flags`` may be set to ``0`` or ``1``,
+   depending on whether the opt-out bit in the NSEC3
+   chain should be set. ``iterations`` defines the number of additional times to apply
+   the algorithm when generating an NSEC3 hash. The ``salt`` is a string
+   of data expressed in hexadecimal, a hyphen (``-``) if no salt is to be
+   used, or the keyword ``auto``, which causes ``named`` to generate a
+   random 64-bit salt.
+
+   The only recommended configuration is ``rndc signing -nsec3param 1 0 0 - zone``,
+   i.e. no salt, no additional iterations, no opt-out.
+
+   .. warning::
+      Do not use extra iterations, salt, or opt-out unless all their implications
+      are fully understood. A higher number of iterations causes interoperability
+      problems and opens servers to CPU-exhausting DoS attacks.
+
+   ``rndc signing -nsec3param none`` removes an existing NSEC3 chain and
+   replaces it with NSEC.
+
+   ``rndc signing -serial value`` sets the serial number of the zone to
+   ``value``. If the value would cause the serial number to go backwards, it
+   is rejected. The primary use of this parameter is to set the serial number on inline
+   signed zones.
+
+``stats``
+   This command writes server statistics to the statistics file. (See the
+   ``statistics-file`` option in the BIND 9 Administrator Reference
+   Manual.)
+
+``status``
+   This command displays the status of the server. Note that the number of zones includes
+   the internal ``bind/CH`` zone and the default ``./IN`` hint zone, if
+   there is no explicit root zone configured.
+
+``stop`` **-p**
+   This command stops the server, making sure any recent changes made through dynamic
+   update or IXFR are first saved to the master files of the updated
+   zones. If ``-p`` is specified, ``named(8)`'s process ID is returned.
+   This allows an external process to determine when ``named`` has
+   completed stopping.
+
+   See also ``rndc halt``.
+
+``sync`` **-clean** [*zone* [*class* [*view*]]]
+   This command syncs changes in the journal file for a dynamic zone to the master
+   file. If the "-clean" option is specified, the journal file is also
+   removed. If no zone is specified, then all zones are synced.
+
+``tcp-timeouts`` [*initial* *idle* *keepalive* *advertised*]
+   When called without arguments, this command displays the current values of the
+   ``tcp-initial-timeout``, ``tcp-idle-timeout``,
+   ``tcp-keepalive-timeout``, and ``tcp-advertised-timeout`` options.
+   When called with arguments, these values are updated. This allows an
+   administrator to make rapid adjustments when under a
+   denial-of-service (DoS) attack. See the descriptions of these options in the BIND 9
+   Administrator Reference Manual for details of their use.
+
+``thaw`` [*zone* [*class* [*view*]]]
+   This command enables updates to a frozen dynamic zone. If no zone is specified,
+   then all frozen zones are enabled. This causes the server to reload
+   the zone from disk, and re-enables dynamic updates after the load has
+   completed. After a zone is thawed, dynamic updates are no longer
+   refused. If the zone has changed and the ``ixfr-from-differences``
+   option is in use, the journal file is updated to reflect
+   changes in the zone. Otherwise, if the zone has changed, any existing
+   journal file is removed.
+
+   See also ``rndc freeze``.
+
+``trace``
+   This command increments the server's debugging level by one.
+
+``trace`` *level*
+   This command sets the server's debugging level to an explicit value.
+
+   See also ``rndc notrace``.
+
+``tsig-delete`` *keyname* [*view*]
+   This command deletes a given TKEY-negotiated key from the server. This does not
+   apply to statically configured TSIG keys.
+
+``tsig-list``
+   This command lists the names of all TSIG keys currently configured for use by
+   ``named`` in each view. The list includes both statically configured keys and
+   dynamic TKEY-negotiated keys.
+
+``validation`` (**on** | **off** | **status**) [*view* ...]``
+   This command enables, disables, or checks the current status of DNSSEC validation. By
+   default, validation is enabled.
+
+   The cache is flushed when validation is turned on or off to avoid using data
+   that might differ between states.
+
+``zonestatus`` *zone* [*class* [*view*]]
+   This command displays the current status of the given zone, including the master
+   file name and any include files from which it was loaded, when it was
+   most recently loaded, the current serial number, the number of nodes,
+   whether the zone supports dynamic updates, whether the zone is DNSSEC
+   signed, whether it uses automatic DNSSEC key management or inline
+   signing, and the scheduled refresh or expiry times for the zone.
+
+   See also ``rndc showzone``.
+
+``rndc`` commands that specify zone names, such as ``reload``,
+``retransfer``, or ``zonestatus``, can be ambiguous when applied to zones
+of type ``redirect``. Redirect zones are always called ``.``, and can be
+confused with zones of type ``hint`` or with secondary copies of the root
+zone. To specify a redirect zone, use the special zone name
+``-redirect``, without a trailing period. (With a trailing period, this
+would specify a zone called "-redirect".)
+
+Limitations
+~~~~~~~~~~~
+
+There is currently no way to provide the shared secret for a ``key_id``
+without using the configuration file.
+
+Several error messages could be clearer.
+
+See Also
+~~~~~~~~
+
+:manpage:`rndc.conf(5)`, :manpage:`rndc-confgen(8)`,
+:manpage:`named(8)`, :manpage:`named.conf(5)`, :manpage:`ndc(8)`, BIND 9 Administrator
+Reference Manual.