Merge branch 'each-doc-fixes-v9_11' into 'v9_11'

additional text edits to ARM

See merge request !3863

doc/arm/catz.xml

@@ -14,84 +14,84 @@
   <para>
     A "catalog zone" is a special DNS zone that contains a list of
     other zones to be served, along with their configuration parameters.
-    Zones listed in a catalog zone are called "member zones".
-    When a catalog zone is loaded or transferred to a slave server
-    which supports this functionality, the slave server will create
+    Zones listed in a catalog zone are called "member zones."
+    When a catalog zone is loaded or transferred to a secondary server
+    which supports this functionality, the secondary server creates
     the member zones automatically. When the catalog zone is updated
     (for example, to add or delete member zones, or change
-    their configuration parameters) those changes are immediately put
+    their configuration parameters), those changes are immediately put
     into effect. Because the catalog zone is a normal DNS zone, these
     configuration changes can be propagated using the standard AXFR/IXFR
     zone transfer mechanism.
   </para>
   <para>
-    Catalog zones' format and behavior are specified as an internet draft
-    for interoperability among DNS implementations.  As of this release, the
+    Catalog zones' format and behavior are specified as an Internet draft
+    for interoperability among DNS implementations.  The
     latest revision of the DNS catalog zones draft can be found here:
-    https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-catalog-zones/
+    https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/.
   </para>
 
   <section><info><title>Principle of Operation</title></info>
     <para>
-      Normally, if a zone is to be served by a slave server, the
+      Normally, if a zone is to be served by a secondary server, the
       <filename>named.conf</filename> file on the server must list the
       zone, or the zone must be added using <command>rndc addzone</command>.
-      In environments with a large number of slave servers and/or where
+      In environments with a large number of secondary servers, and/or where
       the zones being served are changing frequently, the overhead involved
-      in maintaining consistent zone configuration on all the slave
+      in maintaining consistent zone configuration on all the secondary
       servers can be significant.
     </para>
     <para>
-      A catalog zone is a way to ease this administrative burden.  It is a
-      DNS zone that lists member zones that should be served by slave servers.
-      When a slave server receives an update to the catalog zone, it adds,
+      A catalog zone is a way to ease this administrative burden: it is a
+      DNS zone that lists member zones that should be served by secondary servers.
+      When a secondary server receives an update to the catalog zone, it adds,
       removes, or reconfigures member zones based on the data received.
     </para>
     <para>
-      To use a catalog zone, it must first be set up as a normal zone on
-      the master and the on slave servers that will be configured to use
+      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 <option>catalog-zones</option> list
       in the <option>options</option> or <option>view</option> statement
-      in <filename>named.conf</filename>.  (This is comparable to the way
+      in <filename>named.conf</filename>.  This is comparable to the way
       a policy zone is configured as a normal zone and also listed in
-      a <option>response-policy</option> statement.)
+      a <option>response-policy</option> statement.
     </para>
     <para>
       To use the catalog zone feature to serve a new member zone:
       <itemizedlist>
         <listitem>
           <para>
-	    Set up the the member zone to be served on the master as normal.
-	    This could be done by editing <filename>named.conf</filename>,
+	    Set up the the member zone to be served on the primary as normal.
+	    This can be done by editing <filename>named.conf</filename>
 	    or by running <command>rndc addzone</command>.
           </para>
         </listitem>
         <listitem>
           <para>
             Add an entry to the catalog zone for the new member zone.
-	    This could be done by editing the catalog zone's master file
+	    This can be done by editing the catalog zone's zone file
 	    and running <command>rndc reload</command>, or by updating
 	    the zone using <command>nsupdate</command>.
           </para>
         </listitem>
       </itemizedlist>
-      The change to the catalog zone will be propagated from the master to all
-      slaves using the normal AXFR/IXFR mechanism.  When the slave receives the
-      update to the catalog zone, it will detect the entry for the new member
-      zone, create an instance of of that zone on the slave server, and point
+      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 <option>masters</option> specified in the catalog
-      zone data. The newly created member zone is a normal slave zone, so
-      BIND will immediately initiate a transfer of zone contents from the
-      master.  Once complete, the slave will start serving the member zone.
+      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.
     </para>
     <para>
-      Removing a member zone from a slave server requires nothing more than
-      deleting the member zone's entry in the catalog zone. The change to the
-      catalog zone is propagated to the slave server using the normal AXFR/IXFR
-      transfer mechanism.  The slave server, on processing the update, will
-      notice that the member zone has been removed.  It will stop serving the
-      zone and remove it from its list of configured zones.  (Removing the
-      member zone from the master server has to be done in the normal way,
+      Removing a member zone from a secondary server requires only
+      deleting the member zone's entry in the catalog zone; the change to the
+      catalog zone is propagated to the secondary server using the normal AXFR/IXFR
+      transfer mechanism.  The secondary server, on processing the update,
+      notices that the member zone has been removed, stops serving the
+      zone, and removes it from its list of configured zones. However, removing the
+      member zone from the primary server must be done
       by editing the configuration file or running
       <command>rndc delzone</command>.)
     </para>
@@ -116,31 +116,31 @@ catalog-zones {
       This statement specifies that the zone
       <literal>catalog.example</literal> is a catalog zone. This zone must be
       properly configured in the same view. In most configurations, it would
-      be a slave zone.
+      be a secondary zone.
     </para>
     <para>
       The options following the zone name are not required, and may be
       specified in any order:
     </para>
     <para>
-      The <option>default-masters</option> option defines the default masters
-      for member zones listed in a catalog zone. This can be overridden by
+      The <option>default-masters</option> option defines the default primaries
+      for member zones listed in a catalog zone, and can be overridden by
       options within a catalog zone. If no such options are included, then
-      member zones will transfer their contents from the servers listed in
+      member zones transfer their contents from the servers listed in
       this option.
     </para>
     <para>
       The <option>in-memory</option> option, if set to <literal>yes</literal>,
       causes member zones to be stored only in memory. This is functionally
-      equivalent to configuring a slave zone without a <option>file</option>.
+      equivalent to configuring a secondary zone without a <option>file</option>
       option.  The default is <literal>no</literal>; member zones' content
-      will be stored locally in a file whose name is automatically generated
+      is stored locally in a file whose name is automatically generated
       from the view name, catalog zone name, and member zone name.
     </para>
     <para>
       The <option>zone-directory</option> option causes local copies of
-      member zones' master files (if <option>in-memory</option> is not set
-      to <literal>yes</literal>) to be stored in the specified directory.
+      member zones' zone files to be stored in the specified directory,
+      if <option>in-memory</option> is not set to <literal>yes</literal>.
       The default is to store zone files in the server's working directory.
       A non-absolute pathname in <option>zone-directory</option> is
       assumed to be relative to the working directory.
@@ -150,21 +150,21 @@ catalog-zones {
       interval between processing of updates to catalog zones, in seconds.
       If an update to a catalog zone (for example, via IXFR) happens less
       than <option>min-update-interval</option> seconds after the most
-      recent update, then the changes will not be carried out until this
+      recent update, the changes are not carried out until this
       interval has elapsed.  The default is <literal>5</literal> seconds.
     </para>
     <para>
       Catalog zones are defined on a per-view basis. Configuring a non-empty
-      <option>catalog-zones</option> statement in a view will automatically
-      turn on <option>allow-new-zones</option> for that view. (Note: this
-      means <command>rndc addzone</command> and <command>rndc delzone</command>
-      will also work in any view that supports catalog zones.)
+      <option>catalog-zones</option> statement in a view automatically
+      turns on <option>allow-new-zones</option> for that view. This
+      means that <command>rndc addzone</command> and <command>rndc delzone</command>
+      also work in any view that supports catalog zones.
     </para>
   </section>
 
-  <section><info><title>Catalog Zone format</title></info>
+  <section><info><title>Catalog Zone Format</title></info>
     <para>
-      A catalog zone is a regular DNS zone; therefore, it has to have a
+      A catalog zone is a regular DNS zone; therefore, it must have a
       single <literal>SOA</literal> and at least one <literal>NS</literal>
       record.
     </para>
@@ -180,14 +180,14 @@ version.catalog.example.    IN TXT "1"
 </screen>
     <para>
       Note that this record must have the domain name
-      version.<replaceable>catalog-zone-name</replaceable>.  This illustrates
-      how the meaning of data stored in a catalog zone is indicated by the
+      "version.<replaceable>catalog-zone-name</replaceable>".
+      The data stored in a catalog zone is indicated by the
       the domain name label immediately before the catalog zone domain.
     </para>
     <para>
       Catalog zone options can be set either globally for the whole catalog
       zone or for a single member zone. Global options override the settings
-      in the configuration file and member zone options override global
+      in the configuration file, and member zone options override global
       options.
     </para>
     <para>
@@ -204,8 +204,8 @@ version.catalog.example.    IN TXT "1"
 	 masters.catalog.example.    IN A 192.0.2.1
 	</screen>
 	<para>
-	  This option defines a master server for the member zones - it
-	  can be either an A or AAAA record. If multiple masters are set the
+	  This option defines a primary server for the member zones, which
+	  can be either an A or AAAA record. If multiple primaries are set, the
 	  order in which they are used is random.
 	</para>
       </listitem>
@@ -216,7 +216,7 @@ version.catalog.example.    IN TXT "1"
          label.masters.catalog.example.	    IN TXT "tsig_key_name"
         </screen>
         <para>
-         This option defines a master server for the member zone with a TSIG
+         This option defines a primary server for the member zone with a TSIG
          key set. The TSIG key must be configured in the configuration file.
          <option>label</option> can be any valid DNS label.
         </para>
@@ -232,9 +232,9 @@ version.catalog.example.    IN TXT "1"
           These options are the equivalents of <option>allow-query</option>
           and <option>allow-transfer</option> in a zone declaration in the
           <filename>named.conf</filename> configuration file. The ACL is
-          processed in order - if there's no match to any rule the default
-          policy is to deny access.  For the syntax of the APL RR see RFC
-          3123
+          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.
         </para>
       </listitem>
     </itemizedlist>
@@ -261,17 +261,17 @@ label.masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN
 allow-query.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN APL 1:10.0.0.0/24
 </screen>
     <para>
-      As would be expected, options defined for a specific zone override
+      Options defined for a specific zone override
       the global options defined in the catalog zone. These in turn override
       the global options defined in the <literal>catalog-zones</literal>
       statement in the configuration file.
     </para>
     <para>
-      (Note that none of the global records an option will be inherited if
+      Note that none of the global records for an option are inherited if
       any records are defined for that option for the specific zone.  For
       example, if the zone had a <literal>masters</literal> record of type
-      A but not AAAA, then it would <emphasis>not</emphasis> inherit the
-      type AAAA record from the global option.)
+      A but not AAAA, it would <emphasis>not</emphasis> inherit the
+      type AAAA record from the global option.
     </para>
   </section>
 </section>

doc/arm/dlz.xml

@@ -13,17 +13,17 @@
 <section xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="dlz-info"><info><title>DLZ (Dynamically Loadable Zones)</title></info>
 
   <para>
-    DLZ (Dynamically Loadable Zones) is an extension to BIND 9 that allows
+    Dynamically Loadable Zones (DLZ) are an extension to BIND 9 that allows
     zone data to be retrieved directly from an external database.  There is
     no required format or schema.  DLZ drivers exist for several different
-    database backends including PostgreSQL, MySQL, and LDAP and can be
+    database backends, including PostgreSQL, MySQL, and LDAP, and can be
     written for any other.
   </para>
   <para>
     Historically, DLZ drivers had to be statically linked with the <command>named</command>
     binary and were turned on via a configure option at compile time (for
-    example, <userinput>"configure --with-dlz-ldap"</userinput>).
-    Currently, the drivers provided in the BIND 9 tarball in
+    example, <userinput>configure --with-dlz-ldap</userinput>).
+    The drivers provided in the BIND 9 tarball in
     <filename>contrib/dlz/drivers</filename> are still linked this
     way.
   </para>
@@ -32,21 +32,21 @@
     dynamically at runtime, via the DLZ "dlopen" driver, which acts as a
     generic wrapper around a shared object implementing the DLZ API.  The
     "dlopen" driver is linked into <command>named</command> by default, so configure options
-    are no longer necessary when using these dynamically linkable drivers,
-    but are still needed for the older drivers in
+    are no longer necessary when using these dynamically linkable drivers;
+    they are still needed for the older drivers in
     <filename>contrib/dlz/drivers</filename>.
   </para>
 
   <para>
-    When the DLZ module provides data to <command>named</command>, it does so in text format.
-    The response is converted to DNS wire format by <command>named</command>.  This
+    The DLZ module provides data to <command>named</command> in text format,
+    which is then converted to DNS wire format by <command>named</command>.  This
     conversion, and the lack of any internal caching, places significant
     limits on the query performance of DLZ modules.  Consequently, DLZ is
     not recommended for use on high-volume servers.  However, it can be
-    used in a hidden master configuration, with slaves retrieving zone
-    updates via AXFR.  (Note, however, that DLZ has no built-in support for
-    DNS notify; slaves are not automatically informed of changes to the
-    zones in the database.)
+    used in a hidden primary configuration, with secondaries retrieving zone
+    updates via AXFR.  Note, however, that DLZ has no built-in support for
+    DNS notify; secondary servers are not automatically informed of changes to the
+    zones in the database.
   </para>
 
   <section><info><title>Configuring DLZ</title></info>
@@ -67,9 +67,9 @@
       loaded at runtime by the dlopen DLZ driver.  Multiple
       <command>dlz</command> statements can be specified; when
       answering a query, all DLZ modules with <option>search</option>
-      set to <literal>yes</literal> will be queried to find out if
-      they contain an answer for the query name; the best available
-      answer will be returned to the client.
+      set to <literal>yes</literal> are queried to see whether
+      they contain an answer for the query name. The best available
+      answer is returned to the client.
     </para>
     <para>
       The <option>search</option> option in the above example can be
@@ -79,11 +79,11 @@
       If <option>search</option> is set to <literal>no</literal>, then
       this DLZ module is <emphasis>not</emphasis> 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 you to
-      configure a zone normally using standard zone option semantics,
-      but specify a different database back-end for storage of the
+      separately specified in a zone statement.  This allows users to
+      configure a zone normally using standard zone-option semantics,
+      but specify a different database backend for storage of the
       zone's data.  For example, to implement NXDOMAIN redirection using
-      a DLZ module for back-end storage of redirection rules:
+      a DLZ module for backend storage of redirection rules:
     </para>
     <screen>
     dlz other {
@@ -100,9 +100,9 @@
   <section><info><title>Sample DLZ Driver</title></info>
 
     <para>
-      For guidance in implementation of DLZ modules, the directory
+      For guidance in the implementation of DLZ modules, the directory
       <filename>contrib/dlz/example</filename> contains a basic
-      dynamically-linkable DLZ module--i.e., one which can be
+      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 <command>dlz</command>
@@ -115,7 +115,7 @@
     </screen>
     <para>
       In the above example, the module is configured to create a zone
-      "example.nil", which can answer queries and AXFR requests, and
+      "example.nil", which can answer queries and AXFR requests and
       accept DDNS updates.  At runtime, prior to any updates, the zone
       contains an SOA, NS, and a single A record at the apex:
     </para>
@@ -127,13 +127,13 @@
  example.nil.  1800    IN      A       10.53.0.1
     </screen>
     <para>
-      The sample driver is capable of retrieving information about the
-      querying client, and altering its response on the basis of this
+      The sample driver can retrieve information about the
+      querying client and alter its response on the basis of this
       information.  To demonstrate this feature, the example driver
       responds to queries for "source-addr.<option>zonename</option>&gt;/TXT"
       with the source address of the query.  Note, however, that this
-      record will *not* be included in AXFR or ANY responses.  Normally,
-      this feature would be used to alter responses in some other fashion,
+      record will <emphasis>not</emphasis> be included in AXFR or ANY responses.  Normally,
+      this feature is used to alter responses in some other fashion,
       e.g., by providing different address records for a particular name
       depending on the network from which the query arrived.
     </para>
@@ -141,7 +141,7 @@
       Documentation of the DLZ module API can be found in
       <filename>contrib/dlz/example/README</filename>.  This directory also
       contains the header file <filename>dlz_minimal.h</filename>, which
-      defines the API and should be included by any dynamically-linkable
+      defines the API and should be included by any dynamically linkable
       DLZ module.
     </para>
   </section>

doc/arm/dnssec.xml

@@ -15,15 +15,15 @@
   <section><info><title>Converting from insecure to secure</title></info>
 
   </section>
-  <para>Changing a zone from insecure to secure can be done in two
-  ways: using a dynamic DNS update, or the
+  <para>A zone ca be changed from insecure to secure in two
+  ways: using a dynamic DNS update, or via the
   <command>auto-dnssec</command> zone option.</para>
-  <para>For either method, you need to configure
-  <command>named</command> so that it can see the
+  <para>For either method,
+  <command>named</command> must be configured so that it can see the
   <filename>K*</filename> files which contain the public and private
-  parts of the keys that will be used to sign the zone. These files
-  will have been generated by
-  <command>dnssec-keygen</command>. You can do this by placing them
+  parts of the keys that are used to sign the zone. These files
+  are generated by
+  <command>dnssec-keygen</command>, and they should be placed
   in the key-directory, as specified in
   <filename>named.conf</filename>:</para>
   <programlisting>
@@ -35,11 +35,11 @@
 	};
 </programlisting>
   <para>If one KSK and one ZSK DNSKEY key have been generated, this
-  configuration will cause all records in the zone to be signed
-  with the ZSK, and the DNSKEY RRset to be signed with the KSK as
-  well. An NSEC chain will be generated as part of the initial
+  configuration causes all records in the zone to be signed
+  with the ZSK, and the DNSKEY RRset to be signed with the KSK.
+  An NSEC chain is generated as part of the initial
   signing process.</para>
-  <section><info><title>Dynamic DNS update method</title></info>
+  <section><info><title>Dynamic DNS Update Method</title></info>
 
   </section>
   <para>To insert the keys via dynamic update:</para>
@@ -50,15 +50,15 @@
 	&gt; update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
 	&gt; send
 </screen>
-  <para>While the update request will complete almost immediately,
-  the zone will not be completely signed until
-  <command>named</command> has had time to walk the zone and
+  <para>While the update request completes almost immediately,
+  the zone is not completely signed until
+  <command>named</command> has had time to "walk" the zone and
   generate the NSEC and RRSIG records. The NSEC record at the apex
-  will be added last, to signal that there is a complete NSEC
+  is added last, to signal that there is a complete NSEC
   chain.</para>
-  <para>If you wish to sign using NSEC3 instead of NSEC, you should
-  add an NSEC3PARAM record to the initial update request. If you
-  wish the NSEC3 chain to have the OPTOUT bit set, set it in the
+  <para>To sign using NSEC3 instead of NSEC,
+  add an NSEC3PARAM record to the initial update request.
+  The OPTOUT bit in the NSEC3 chain can be set in the
   flags field of the NSEC3PARAM record.</para>
   <screen>
 	% nsupdate
@@ -68,15 +68,15 @@
 	&gt; update add example.net NSEC3PARAM 1 1 100 1234567890
 	&gt; send
 </screen>
-  <para>Again, this update request will complete almost
-  immediately; however, the record won't show up until
+  <para>Again, this update request completes almost
+  immediately; however, the record does not show up until
   <command>named</command> has had a chance to build/remove the
-  relevant chain. A private type record will be created to record
-  the state of the operation (see below for more details), and will
-  be removed once the operation completes.</para>
+  relevant chain. A private type record is created to record
+  the state of the operation (see below for more details), and is
+  removed once the operation completes.</para>
   <para>While the initial signing and NSEC/NSEC3 chain generation
   is happening, other updates are possible as well.</para>
-  <section><info><title>Fully automatic zone signing</title></info>
+  <section><info><title>Fully Automatic Zone Signing</title></info>
 
   </section>
   <para>To enable automatic signing, add the
@@ -89,69 +89,69 @@
   <command>auto-dnssec allow</command>,
   <command>named</command> can search the key directory for keys
   matching the zone, insert them into the zone, and use them to
-  sign the zone. It will do so only when it receives an
+  sign the zone. It does so only when it receives an
   <command>rndc sign &lt;zonename&gt;</command>.</para>
   <para>
   <!-- TODO: this is repeated in the ARM -->
   <command>auto-dnssec maintain</command> includes the above
-  functionality, but will also automatically adjust the zone's
-  DNSKEY records on schedule according to the keys' timing metadata.
+  functionality, but also automatically adjusts the zone's
+  DNSKEY records on a schedule according to the keys' timing metadata.
   (See <xref linkend="man.dnssec-keygen"/> and
   <xref linkend="man.dnssec-settime"/> for more information.)
   </para>
   <para>
-  <command>named</command> will periodically search the key directory
-  for keys matching the zone, and if the keys' metadata indicates
-  that any change should be made the zone, such as adding, removing,
-  or revoking a key, then that action will be carried out.  By default,
+  <command>named</command> periodically searches the key directory
+  for keys matching the zone; if the keys' metadata indicates
+  that any change should be made to the zone - such as adding, removing,
+  or revoking a key - then that action is carried out.  By default,
   the key directory is checked for changes every 60 minutes; this period
-  can be adjusted with the <option>dnssec-loadkeys-interval</option>, up
+  can be adjusted with <option>dnssec-loadkeys-interval</option>, up
   to a maximum of 24 hours.  The <command>rndc loadkeys</command> forces
   <command>named</command> to check for key updates immediately.
   </para>
   <para>
   If keys are present in the key directory the first time the zone
-  is loaded, the zone will be signed immediately, without waiting for an
+  is loaded, the zone is signed immediately, without waiting for an
   <command>rndc sign</command> or <command>rndc loadkeys</command>
-  command. (Those commands can still be used when there are unscheduled
-  key changes, however.)
+  command. Those commands can still be used when there are unscheduled
+  key changes.
   </para>
   <para>
   When new keys are added to a zone, the TTL is set to match that
   of any existing DNSKEY RRset. If there is no existing DNSKEY RRset,
-  then the TTL will be set to the TTL specified when the key was
+  the TTL is set to the TTL specified when the key was
   created (using the <command>dnssec-keygen -L</command> option), if
   any, or to the SOA TTL.
   </para>
   <para>
-  If you wish the zone to be signed using NSEC3 instead of NSEC,
+  To sign the zone using NSEC3 instead of NSEC,
   submit an NSEC3PARAM record via dynamic update prior to the
-  scheduled publication and activation of the keys.  If you wish the
-  NSEC3 chain to have the OPTOUT bit set, set it in the flags field
-  of the NSEC3PARAM record.  The NSEC3PARAM record will not appear in
-  the zone immediately, but it will be stored for later reference.  When
+  scheduled publication and activation of the keys.
+  The OPTOUT bit for the NSEC3 chain can be set in the flags field
+  of the NSEC3PARAM record.  The NSEC3PARAM record does not appear in
+  the zone immediately, but it is stored for later reference.  When
   the zone is signed and the NSEC3 chain is completed, the NSEC3PARAM
-  record will appear in the zone.
+  record appears in the zone.
   </para>
   <para>Using the
   <command>auto-dnssec</command> option requires the zone to be
   configured to allow dynamic updates, by adding an
   <command>allow-update</command> or
   <command>update-policy</command> statement to the zone
-  configuration. If this has not been done, the configuration will
-  fail.</para>
-  <section><info><title>Private-type records</title></info>
+  configuration. If this has not been done, the configuration
+  fails.</para>
+  <section><info><title>Private Type Records</title></info>
 
   </section>
   <para>The state of the signing process is signaled by
-  private-type records (with a default type value of 65534). When
-  signing is complete, these records will have a nonzero value for
-  the final octet (for those records which have a nonzero initial
-  octet).</para>
-  <para>The private type record format: If the first octet is
-  non-zero then the record indicates that the zone needs to be
+  private type records (with a default type value of 65534). When
+  signing is complete, these records with a non-zero initial octet
+  have a non-zero value for the final octet.</para>
+  <para>If the first octet of a private type record is
+  non-zero, the record indicates either that the zone needs to be
   signed with the key matching the record, or that all signatures
-  that match the record should be removed.</para>
+  that match the record should be removed. Here are the meanings
+  of the different values of the first octet:</para>
   <para>
     <literallayout>
 <!-- TODO: how to format this? -->
@@ -162,13 +162,13 @@
 </literallayout>
   </para>
   <para>Only records flagged as "complete" can be removed via
-  dynamic update. Attempts to remove other private type records
-  will be silently ignored.</para>
+  dynamic update; attempts to remove other private type records
+  are silently ignored.</para>
   <para>If the first octet is zero (this is a reserved algorithm
-  number that should never appear in a DNSKEY record) then the
-  record indicates changes to the NSEC3 chains are in progress. The
-  rest of the record contains an NSEC3PARAM record. The flag field
-  tells what operation to perform based on the flag bits.</para>
+  number that should never appear in a DNSKEY record), the
+  record indicates that changes to the NSEC3 chains are in progress. The
+  rest of the record contains an NSEC3PARAM record, while the flag field
+  tells what operation to perform based on the flag bits:</para>
   <para>
     <literallayout>
 <!-- TODO: how to format this? -->
@@ -178,97 +178,95 @@
   0x20 NONSEC
 </literallayout>
   </para>
-  <section><info><title>DNSKEY rollovers</title></info>
+  <section><info><title>DNSKEY Rollovers</title></info>
 
   </section>
-  <para>As with insecure-to-secure conversions, rolling DNSSEC
-  keys can be done in two ways: using a dynamic DNS update, or the
+  <para>As with insecure-to-secure conversions, DNSSEC keyrolls
+  can be done in two ways: using a dynamic DNS update, or via the
   <command>auto-dnssec</command> zone option.</para>
-  <section><info><title>Dynamic DNS update method</title></info>
+  <section><info><title>Dynamic DNS Update Method</title></info>
 
   </section>
-  <para> To perform key rollovers via dynamic update, you need to add
-  the <filename>K*</filename> files for the new keys so that
-  <command>named</command> can find them. You can then add the new
-  DNSKEY RRs via dynamic update.
-  <command>named</command> will then cause the zone to be signed
-  with the new keys. When the signing is complete the private type
-  records will be updated so that the last octet is non
-  zero.</para>
-  <para>If this is for a KSK you need to inform the parent and any
-  trust anchor repositories of the new KSK.</para>
-  <para>You should then wait for the maximum TTL in the zone before
+  <para> To perform key rollovers via dynamic update,
+  the <filename>K*</filename> files for the new keys must be added so that
+  <command>named</command> can find them. The new
+  DNSKEY RRs can then be added via dynamic update.
+  <command>named</command> then causes the zone to be signed
+  with the new keys; when the signing is complete, the private type
+  records are updated so that the last octet is non-zero.</para>
+  <para>If this is for a KSK, the parent and any
+  trust anchor repositories of the new KSK must be informed.</para>
+  <para>The maximum TTL in the zone must expire before
   removing the old DNSKEY. If it is a KSK that is being updated,
-  you also need to wait for the DS RRset in the parent to be
-  updated and its TTL to expire. This ensures that all clients will
-  be able to verify at least one signature when you remove the old
-  DNSKEY.</para>
-  <para>The old DNSKEY can be removed via UPDATE. Take care to
+  the DS RRset in the parent must also be
+  updated its TTL allowed to expire. This ensures that all clients
+  are able to verify at least one signature when the old DNSKEY is removed.</para>
+  <para>The old DNSKEY can be removed via UPDATE, taking care to
   specify the correct key.
-  <command>named</command> will clean out any signatures generated
+  <command>named</command> cleans out any signatures generated
   by the old key after the update completes.</para>
-  <section><info><title>Automatic key rollovers</title></info>
+  <section><info><title>Automatic Key Rollovers</title></info>
 
   </section>
   <para>When a new key reaches its activation date (as set by
   <command>dnssec-keygen</command> or <command>dnssec-settime</command>),
-  if the <command>auto-dnssec</command> zone option is set to
-  <constant>maintain</constant>, <command>named</command> will
-  automatically carry out the key rollover.  If the key's algorithm
-  has not previously been used to sign the zone, then the zone will
-  be fully signed as quickly as possible.  However, if the new key
-  is replacing an existing key of the same algorithm, then the
-  zone will be re-signed incrementally, with signatures from the
-  old key being replaced with signatures from the new key as their
+  and if the <command>auto-dnssec</command> zone option is set to
+  <constant>maintain</constant>, <command>named</command>
+  automatically carries out the key rollover.  If the key's algorithm
+  has not previously been used to sign the zone, then the zone is
+  fully signed as quickly as possible.  However, if the new key
+  replaces an existing key of the same algorithm, the
+  zone is re-signed incrementally, with signatures from the
+  old key replaced with signatures from the new key as their
   signature validity periods expire.  By default, this rollover
-  completes in 30 days, after which it will be safe to remove the
+  completes in 30 days, after which it is safe to remove the
   old key from the DNSKEY RRset.</para>
-  <section><info><title>NSEC3PARAM rollovers via UPDATE</title></info>
+  <section><info><title>NSEC3PARAM Rollovers via UPDATE</title></info>
 
   </section>