Merge branch '1940-removing-more-references-to-master-and-slave-in-bind-arm' into 'main'

Resolve "Removing more references to "master" and "slave" in BIND ARM"

Closes #1940

See merge request isc-projects/bind9!3692

bin/check/named-checkconf.rst

@@ -56,7 +56,7 @@ Options
 
 **-l**
    List all the configured zones. Each line of output contains the zone
-   name, class (e.g. IN), view, and type (e.g. master or slave).
+   name, class (e.g. IN), view, and type (e.g. primary or secondary).
 
 **-c**
    Check "core" configuration only. This suppresses the loading of
@@ -82,12 +82,12 @@ Options
    When printing the configuration files in canonical form, obscure
    shared secrets by replacing them with strings of question marks
    ('?'). This allows the contents of ``named.conf`` and related files
-   to be shared MDASH for example, when submitting bug reports MDASH
+   to be shared - for example, when submitting bug reports -
    without compromising private data. This option cannot be used without
    ``-p``.
 
 **-z**
-   Perform a test load of all master zones found in ``named.conf``.
+   Perform a test load of all zones of type ``primary`` found in ``named.conf``.
 
 filename
    The name of the configuration file to be checked. If not specified,

bin/nsupdate/nsupdate.rst

@@ -46,7 +46,7 @@ updates and cause data to be lost.
 
 The resource records that are dynamically added or removed with
 ``nsupdate`` have to be in the same zone. Requests are sent to the
-zone's master server. This is identified by the MNAME field of the
+zone's primary server. This is identified by the MNAME field of the
 zone's SOA record.
 
 Transaction signatures can be used to authenticate the Dynamic DNS
@@ -105,7 +105,7 @@ Options
    (disabling the ``server`` so that the server address cannot be
    overridden). Connections to the local server will use a TSIG key
    found in ``/var/run/named/session.key``, which is automatically
-   generated by ``named`` if any local master zone has set
+   generated by ``named`` if any local ``primary`` zone has set
    ``update-policy`` to ``local``. The location of this key file can be
    overridden with the ``-k`` option.
 
@@ -190,8 +190,8 @@ The command formats and their meaning are as follows:
 ``server`` servername port
    Sends all dynamic update requests to the name server ``servername``.
    When no server statement is provided, ``nsupdate`` will send updates
-   to the master server of the correct zone. The MNAME field of that
+   to the primary server of the correct zone. The MNAME field of that
-   zone's SOA record will identify the master server for that zone.
+   zone's SOA record will identify the primary server for that zone.
    ``port`` is the port number on ``servername`` where the dynamic
    update requests get sent. If no port number is specified, the default
    DNS port number of 53 is used.
@@ -306,7 +306,7 @@ Examples
 The examples below show how ``nsupdate`` could be used to insert and
 delete resource records from the ``example.com`` zone. Notice that the
 input in each example contains a trailing blank line so that a group of
-commands are sent as one dynamic update request to the master name
+commands are sent as one dynamic update request to the primary name
 server for ``example.com``.
 
 ::

bin/rndc/rndc.rst

@@ -150,7 +150,7 @@ Currently supported commands are:
    If the ``-clean`` argument is specified, the zone's master file (and
    journal file, if any) will be deleted along with the zone. Without
    the ``-clean`` option, zone files must be cleaned up by hand. (If the
-   zone is of type "slave" or "stub", the files needing to be cleaned up
+   zone is of type ``secondary`` or ``stub``, the files needing to be cleaned up
    will be reported in the output of the ``rndc delzone`` command.)
 
    If the zone was originally added via ``rndc addzone``, then it will
@@ -372,7 +372,7 @@ Currently supported commands are:
    Reload the given zone.
 
 ``retransfer`` *zone* [*class* [*view*]]
-   Retransfer the given slave zone from the master server.
+   Retransfer 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
@@ -459,7 +459,7 @@ Currently supported commands are:
 
    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 you wish to set the opt-out bit in the NSEC3
+   depending on whether the opt-out bit should be set in the NSEC3
    chain. ``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
@@ -562,7 +562,7 @@ Currently supported commands are:
 ``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 slaved copies of the root
+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".)

bin/tools/named-journalprint.rst

@@ -46,7 +46,7 @@ appending the extension ``.jnl`` to the name of the corresponding zone
 file.
 
 ``named-journalprint`` converts the contents of a given journal file
-into a human-readable text format. Each line begins with "add" or "del",
+into a human-readable text format. Each line begins with ``add`` or ``del``,
 to indicate whether the record was added or deleted, and continues with
 the resource record in master-file format.
 

doc/arm/introduction.rst

@@ -152,7 +152,7 @@ and we suggest reading :rfc:`1033`, :rfc:`1034`, and :rfc:`1035` to gain a compl
 understanding of this difficult and subtle topic.
 
 Though BIND 9 is called a "domain name server," it deals primarily in
-terms of zones. The primary and secondary declarations in the ``named.conf``
+terms of zones. The ``primary`` and ``secondary`` declarations in the ``named.conf``
 file specify zones, not domains. When BIND asks some other site if it is
 willing to be a secondary server for a *domain*, it is actually asking
 for secondary service for some collection of *zones*.
@@ -186,7 +186,7 @@ file which is edited by humans. This file is called the *zone file* or
 In some cases, however, the master file may not be edited by humans at
 all, but may instead be the result of *dynamic update* operations.
 
-.. _slave_server:
+.. _secondary_server:
 
 Secondary Servers
 ^^^^^^^^^^^^^^^^^

doc/arm/reference.rst

@@ -6067,11 +6067,11 @@ records if the machine has more than one name. For example, in the
 Other Zone File Directives
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The Master File Format was initially defined in :rfc:`1035` and has
+The DNS "master file" format was initially defined in :rfc:`1035` and has
-subsequently been extended. While the Master File Format itself is
+subsequently been extended. While the format itself is class-independent,
-class-independent, all records in a master file must be of the same class.
+all records in a zone file must be of the same class.
 
-Master File Directives include ``$ORIGIN``, ``$INCLUDE``, and ``$TTL.``
+Master file directives include ``$ORIGIN``, ``$INCLUDE``, and ``$TTL.``
 
 .. _atsign:
 

doc/arm/troubleshooting.rst

@@ -70,7 +70,7 @@ them to upgrade their broken DNS servers.
 Incrementing and Changing the Serial Number
 -------------------------------------------
 
-Zone serial numbers are just numbers — they are not date related. However, many
+Zone serial numbers are just numbers — they are not date-related. However, many
 people set them to a number that represents a date, usually of the
 form YYYYMMDDRR. Occasionally they will make a mistake and set the serial number to a
 date in the future, then try to correct it by setting it to the