Change to primary/secondary wording and mention RFC9077.

docs/dnssec/advice.rst

@@ -15,9 +15,9 @@ to the keying defaults of ``pdnsutil secure-zone``.
 It is possible to operate a zone with different keying algorithms
 simultaneously, but it has also been observed that this is not reliable.
 
-Depending on your master/slave setup, you may need to tinker with the
-:ref:`SOA-EDIT <metadata-soa-edit>` metadata on your master.
-This is described in the :ref:`soa-edit-ensure-signature-freshness-on-slaves` section.
+Depending on your primary/secondary setup, you may need to tinker with the
+:ref:`SOA-EDIT <metadata-soa-edit>` metadata on your primary.
+This is described in the :ref:`soa-edit-ensure-signature-freshness-on-secondaries` section.
 
 Packet sizes, fragments, TCP/IP service
 ---------------------------------------

docs/dnssec/migration.rst

@@ -29,7 +29,7 @@ To deliver a correctly signed zone with the :ref:`dnssec-pdnsutil-dnssec-default
     pdnsutil secure-zone ZONE
 
 To view the DS records for this zone (to transfer to the parent zone),
-run
+run:
 
 .. code-block:: shell
 

docs/dnssec/modes-of-operation.rst

@@ -138,8 +138,8 @@ Pre-signed records
 ------------------
 
 In this mode, PowerDNS serves zones that already contain DNSSEC records.
-Such zones can either be slaved from a remote master in online signing
-mode, or can be pre-signed using tools like OpenDNSSEC, ldns-signzone,
+Such zones can either be served as secondary from a remote primary in online
+signing mode, or can be pre-signed using tools like OpenDNSSEC, ldns-signzone,
 and dnssec-signzone.
 
 Even in this mode, PowerDNS will synthesize NSEC(3) records itself
@@ -150,10 +150,10 @@ Front-signing
 -------------
 
 As a special feature, PowerDNS can operate as a signing server which
-operates as a slave to an unsigned master.
+operates as a secondary to an unsigned primary.
 
 In this way, if keying material is available for an unsigned zone that
-is retrieved from a master server, this keying material will be used
+is retrieved from a primary server, this keying material will be used
 when serving data from this zone.
 
 As part of the zone retrieval, the equivalent of
@@ -163,10 +163,10 @@ fields are set correctly in the backend.
 Signed AXFR
 -----------
 
-An outgoing zone transfer from a signing master contains all information
+An outgoing zone transfer from a signing primary contains all information
 required for the receiving party to rectify the zone without knowing the
 keys, such as signed NSEC3 records for empty non-terminals. The zone is
-not required to be rectified on the master.
+not required to be rectified on the primary.
 
 The signing and hashing algorithms are described in :ref:`dnssec-online-signing`.
 

docs/dnssec/operational.rst

@@ -47,7 +47,7 @@ e.g.
     pdnsutil set-nsec3 example.net '1 0 0 -'
 
 The quoted part is the content of the NSEC3PARAM records, as defined in
-:rfc:`5155 <5155#section-4>`, in order:
+:rfc:`RFC 5155 <5155#section-4>`, in order:
 
 -  Hash algorithm, should always be ``1`` (SHA1)
 -  Flags, set to ``1`` for :rfc:`NSEC3 Opt-out <5155#section-6>`, this best
@@ -71,30 +71,30 @@ To convert a zone from NSEC3 to NSEC operations, run:
   for zones with algorithm 5 (RSASHA1), 6 (DSA-NSEC3-SHA1) or 7
   (RSASHA1-NSEC3-SHA1).
 
-.. _soa-edit-ensure-signature-freshness-on-slaves:
+.. _soa-edit-ensure-signature-freshness-on-secondaries:
 
-SOA-EDIT: ensure signature freshness on slaves
-----------------------------------------------
+SOA-EDIT: ensure signature freshness on secondaries
+---------------------------------------------------
 
-As RRSIGs can expire, slave servers need to know when to re-transfer the
+As RRSIGs can expire, secondary servers need to know when to re-transfer the
 zone. In most implementations (BIND, NSD), this is done by re-signing
 the full zone outside of the nameserver, increasing the SOA serial and
-serving the new zone on the master.
+serving the new zone on the primary.
 
 With PowerDNS in Live-signing mode, the SOA serial is not increased by
 default when the RRSIG dates are rolled.
 
 For zones that use :ref:`native-operation`
 replication PowerDNS will serve valid RRSIGs on all servers.
 
-For :ref:`master <master-operation>` zones (where
-replication happens by means of AXFR), PowerDNS slaves will
+For :ref:`primary <master-operation>` zones (where
+replication happens by means of AXFR), PowerDNS secondaries will
 automatically re-transfer the zone when it notices the RRSIGs have
 changed, even when the SOA serial is not increased. This ensures the
 zone never serves old signatures.
 
-If your DNS setup uses non-PowerDNS slaves, the slaves need to know when
-the signatures have been updated. This can be accomplished by setting
+If your DNS setup uses non-PowerDNS secondaries, the secondaries need to know
+when the signatures have been updated. This can be accomplished by setting
 the :ref:`metadata-soa-edit` metadata for DNSSEC signed
 zones. This value controls how the value of the SOA serial is modified
 by PowerDNS.
@@ -159,10 +159,10 @@ EPOCH
 Sets the SOA serial to the number of seconds since the epoch.
 
 .. warning::
-  Don't combine this with AXFR - the slaves would keep
+  Don't combine this with AXFR - the secondaries would keep
   refreshing all the time. If you need fast updates, sync the backend
   databases directly with incremental updates (or use the same database
-  server on the slaves)
+  server on the secondaries)
 
 NONE
 ^^^^
@@ -183,10 +183,10 @@ In some settings, having such (private) keying material available online
 is considered undesirable. In this case, consider running in pre-signed
 mode.
 
-A slightly more complex approach is running a *hidden* master in simple
+A slightly more complex approach is running a *hidden* primary in simple
 online signing mode, but on a highly secured system unreachable for the
-public. Internet-connected slaves can then transfer the zones pre-signed
-from this master over a secure private network. This topology offers
+public. Internet-connected secondaries can then transfer the zones pre-signed
+from this primary over a secure private network. This topology offers
 substantial security benefits with regards to key material while
 maintaining ease of daily operation by PowerDNS's features in online
 mode.
@@ -220,5 +220,7 @@ Note that the NSEC/NSEC3 records proving those negatives will get the high TTL i
   This behaviour was changed in version 4.3.0.
   We believe the language in RFC 4034 and 5155 about the NSEC(3) TTL is a mistake, and we have chosen to honour its spirit instead of its words.
 
+  This unfortunate wording was eventually corrected in :rfc:`RFC 9077 <9077#section-3>`.
+
   NSEC(3) records now get the negative TTL (which is the lowest of the SOA TTL and the SOA minimum), which means their TTL matches that of an error such as NXDOMAIN.
-  The warning about RFC8198 no longer applies.
+  This conforms to RFC9077.

docs/dnssec/pkcs11.rst

@@ -174,4 +174,4 @@ Smart Card token on Ubuntu 14.04.
     pdnsutil show-zone zone
 
 - Note that the physical token is pretty slow, so you have to use it as
-  hidden master. It has been observed to produce about 1.5 signatures/second.
+  hidden primary. It has been observed to produce about 1.5 signatures/second.

docs/domainmetadata.rst

@@ -206,7 +206,7 @@ SOA-EDIT
 When serving this zone, modify the SOA serial number in one of several
 ways. Mostly useful to get slaves to re-transfer a zone regularly to get
 fresh RRSIGs. See the :ref:`DNSSEC
-documentation <soa-edit-ensure-signature-freshness-on-slaves>`
+documentation <soa-edit-ensure-signature-freshness-on-secondaries>`
 for more information.
 
 .. _metadata-soa-edit-api: