------------------
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
-------------
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
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`.
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
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.
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
^^^^
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.
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.
projects / thirdparty / pdns.git / commitdiff
