Commit 42386f3d authored by Suzanne Goldlust's avatar Suzanne Goldlust Committed by Ondřej Surý
Browse files

Updates to .rst files to remove more references to "master" and "slave"

parent c4fcafe0
......@@ -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,
......
......@@ -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
zone's SOA record will identify the master server for that zone.
to the primary server of the correct zone. The MNAME field of that
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``.
::
......
......@@ -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".)
......
......@@ -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.
......
......@@ -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
^^^^^^^^^^^^^^^^^
......
......@@ -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
subsequently been extended. While the Master File Format itself is
class-independent, all records in a master file must be of the same class.
The DNS "master file" format was initially defined in :rfc:`1035` and has
subsequently been extended. While the format itself is class-independent,
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:
......
......@@ -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
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment