Fix various typos in the documentation

Generally, the issues fixed here are missing articles, wrong articles
and double articles.  We especially like "the the".

doc/arm/advanced.rst

@@ -72,7 +72,7 @@ All changes made to a zone using dynamic update are stored in the zone's
 journal file. This file is automatically created by the server when the
 first dynamic update takes place. The name of the journal file is formed
 by appending the extension ``.jnl`` to the name of the corresponding
-zone file, unless specifically overridden. The journal file is in a
+zone file unless specifically overridden. The journal file is in a
 binary format and should not be edited manually.
 
 The server also occasionally writes ("dumps") the complete contents
@@ -613,7 +613,7 @@ recommended that zone keys use a cryptographic algorithm designated as
 RSASHA256 and ECDSAP256SHA256; ECDSAP256SHA256 is recommended for
 current and future deployments.
 
-The following command generates a ECDSAP256SHA256 key for the
+The following command generates an ECDSAP256SHA256 key for the
 ``child.example`` zone:
 
 ``dnssec-keygen -a ECDSAP256SHA256 -n ZONE child.example.``
@@ -835,7 +835,7 @@ Address-to-Name Lookups Using Nibble Format
 
 When looking up an address in nibble format, the address components are
 simply reversed, just as in IPv4, and ``ip6.arpa.`` is appended to the
-resulting name. For example, the following would provide reverse name
+resulting name. For example, the following commands produce a reverse name
 lookup for a host with address ``2001:db8::1``:
 
 ::

doc/arm/catz.rst

@@ -53,7 +53,7 @@ policy zone is configured as a normal zone and also listed in a
 
 To use the catalog zone feature to serve a new member zone:
 
--  Set up the the member zone to be served on the primary as normal. This
+-  Set up the member zone to be served on the primary as normal. This
    can be done by editing ``named.conf`` or by running
    ``rndc addzone``.
 
@@ -118,19 +118,18 @@ specified in any order.
    member zone name.
 
 ``zone-directory``
-   This option causes local copies of member zones'
+   This option causes local copies of member zones' zone files to be
-   zone files to be stored in
+   stored in the specified directory, if ``in-memory`` is not set to
-   the specified directory, if ``in-memory`` is not set to ``yes``. The default is to store zone files in the
+   ``yes``. The default is to store zone files in the server's working
-   server's working directory. A non-absolute pathname in
+   directory. A non-absolute pathname in ``zone-directory`` is assumed
-   ``zone-directory`` is assumed to be relative to the working directory.
+   to be relative to the working directory.
 
 ``min-update-interval``
-   This option sets the minimum interval between
+   This option sets the minimum interval between updates to catalog
-   processing of updates to catalog zones, in seconds. If an update to a
+   zones, in seconds. If an update to a catalog zone (for example, via
-   catalog zone (for example, via IXFR) happens less than
+   IXFR) happens less than ``min-update-interval`` seconds after the
-   ``min-update-interval`` seconds after the most recent update, the
+   most recent update, the changes are not carried out until this
-   changes are not carried out until this interval has elapsed. The
+   interval has elapsed. The default is 5 seconds.
-   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

doc/arm/dnssec.rst

@@ -194,7 +194,7 @@ option.
 Dynamic DNS Update Method
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To perform key rollovers via dynamic update, the ``K*``
+To perform key rollovers via a dynamic update, the ``K*``
 files for the new keys must be added so that ``named`` can find them.
 The new DNSKEY RRs can then be added via dynamic update. ``named`` then causes the
 zone to be signed with the new keys; when the signing is complete, the

doc/arm/general.rst

@@ -175,7 +175,7 @@ Clarification.* January 2006.
 
 :rfc:`4398` - S. Josefsson. *Storing Certificates in the Domain Name System (DNS).* March 2006.
 
-:rfc:`4470` - S. Weiler and J. Ihren. *Minimally Covering NSEC Records and
+:rfc:`4470` - S. Weiler and J. Ihren. *Minimally covering NSEC Records and
 DNSSEC On-line Signing.* April 2006. [5]
 
 :rfc:`4509` - W. Hardaker. *Use of SHA-256 in DNSSEC Delegation Signer
@@ -542,7 +542,7 @@ retrieve unknown keys.
 [4] Compliance is with loading and serving of A6 records only. A6 records were moved
 to the experimental category by :rfc:`3363`.
 
-[5] Minimally covering NSEC records are accepted but not generated.
+[5] Minimally Covering NSEC records are accepted but not generated.
 
 [6] BIND 9 interoperates with correctly designed experiments.
 

doc/arm/introduction.rst

@@ -218,13 +218,13 @@ zone expires and no longer responds to queries.
 Stealth Servers
 ^^^^^^^^^^^^^^^
 
-Usually, all of the zone's authoritative servers are listed in NS records
+Usually, all of the zone's authoritative servers are listed in NS
-in the parent zone. These NS records constitute a *delegation* of the
+records in the parent zone. These NS records constitute a *delegation*
-zone from the parent. The authoritative servers are also listed in the
+of the zone from the parent. The authoritative servers are also listed
-zone file itself, at the *top level* or *apex* of the zone.
+in the zone file itself, at the *top level* or *apex* of the zone.
-Servers that are not in the parent's
+Servers that are not in the parent's NS delegation can be listed in the
-NS delegation can be listed in the zone's top-level NS records, but servers that are not present at the zone's top level
+zone's top-level NS records, but servers that are not present at the
-cannot be listed in the parent's delegation.
+zone's top level cannot be listed in the parent's delegation.
 
 A *stealth server* is a server that is authoritative for a zone but is
 not listed in that zone's NS records. Stealth servers can be used for

doc/arm/logging-categories.rst

@@ -43,7 +43,7 @@
     Note: eventually ``named`` will have to stop treating such timeouts as due to :rfc:`1034` non-compliance and start treating it as plain packet loss. Falsely classifying packet loss as due to :rfc:`1034` non-compliance impacts DNSSEC validation, which requires EDNS for the DNSSEC records to be returned.
 
 ``general``
-    Catch-all for many things that still are not classified into categories.
+    A catch-all for many things that still are not classified into categories.
 
 ``lame-servers``
     Misconfigurations in remote servers, discovered by BIND 9 when trying to query those servers during resolution.
@@ -58,7 +58,7 @@
     NSID options received from upstream servers.
 
 ``queries``
-    Location where queries should be logged.
+    A location where queries should be logged.
     
     At startup, specifying the category ``queries`` also enables query logging unless the ``querylog`` option has been specified.
     

doc/arm/pkcs11.rst

@@ -79,7 +79,7 @@ SoftHSMv2, the latest development version of SoftHSM, is available from
 https://github.com/opendnssec/SoftHSMv2. It is a software library
 developed by the OpenDNSSEC project (https://www.opendnssec.org) which
 provides a PKCS#11 interface to a virtual HSM, implemented in the form
-of a SQLite3 database on the local filesystem. It provides less security
+of an SQLite3 database on the local filesystem. It provides less security
 than a true HSM, but it allows users to experiment with native PKCS#11
 when an HSM is not available. SoftHSMv2 can be configured to use either
 OpenSSL or the Botan library to perform cryptographic functions, but

doc/arm/requirements.rst

@@ -60,7 +60,7 @@ Name Server-Intensive Environment Issues
 
 For name server-intensive environments, there are two
 configurations that may be used. The first is one where clients and any
-second-level internal name servers query a main name server, which has
+second-level internal name servers query the main name server, which has
 enough memory to build a large cache; this approach minimizes the
 bandwidth used by external name lookups. The second alternative is to
 set up second-level internal name servers to make queries independently.

doc/arm/security.rst

@@ -138,7 +138,7 @@ signed with a particular key, use:
    allow-query { !{ !10/8; any; }; key example; };
 
 Within the nested ACL, any address that is *not* in the 10/8 network
-prefix is rejected, which terminates processing of the ACL.
+prefix is rejected, which terminates the processing of the ACL.
 Any address that *is* in the 10/8 network prefix is accepted, but
 this causes a negative match of the nested ACL, so the containing ACL
 continues processing. The query is accepted if it is signed by