**-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
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,
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
(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.
``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.
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``.
::
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
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
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
``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".)
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.
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*.
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
^^^^^^^^^^^^^^^^^
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:
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
projects / thirdparty / bind9.git / commitdiff
