From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Thu, 20 Feb 2025 16:44:09 +0000 (-0500) Subject: docs: Update to primary/secondary X-Git-Tag: dnsdist-2.0.0-alpha1~65^2~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=aada15d19a896058cec6524d5c410c1d9ecab2a7;p=thirdparty%2Fpdns.git docs: Update to primary/secondary Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- diff --git a/docs/appendices/types.rst b/docs/appendices/types.rst index d9ffd26cfb..b691b52f14 100644 --- a/docs/appendices/types.rst +++ b/docs/appendices/types.rst @@ -246,7 +246,7 @@ SOA --- The Start of Authority record is one of the most complex available. It -specifies a lot about a domain: the name of the master nameserver ('the +specifies a lot about a domain: the name of the primary nameserver ('the primary'), the hostmaster and a set of numbers indicating how the data in this domain expires and how often it needs to be checked. Further more, it contains a serial number which should rise on each change of diff --git a/docs/backends/bind.rst b/docs/backends/bind.rst index e4ab8a5779..eeff1f553d 100644 --- a/docs/backends/bind.rst +++ b/docs/backends/bind.rst @@ -73,7 +73,7 @@ See :ref:`bind-operation` section for more information. ~~~~~~~~~~~~~~~~~~ Filename to store and access our DNSSEC metadatabase, empty for none. To -slave DNSSEC-enabled domains (where the RRSIGS are in the AXFR), a +run secondary DNSSEC-enabled domains (where the RRSIGS are in the AXFR), a ``bind-dnssec-db`` is required. This is because the :ref:`metadata-presigned` domain metadata is set during the zonetransfer. @@ -176,8 +176,8 @@ zero, no checks will be performed until the ``pdns_control reload`` command is issued. Please note that also the :ref:`setting-xfr-cycle-interval` setting -controls how often a master would notify a slave about changes. -Especially in 'hidden master' configurations, where servers usually +controls how often a primary would notify a secondary about changes. +Especially in 'hidden primary' configurations, where servers usually don't receive regular queries, you may want to lower that setting to a value as low as :ref:`setting-bind-check-interval`. @@ -200,7 +200,7 @@ will be loaded at first request. Output an extended status of a domain or domains, containing much more information than the simple domain status, like the number of records currently loaded, whether pdns -is master or slave for the domain, the list of masters, various timers, etc +is primary or secondary for the domain, the list of primaries, various timers, etc ``bind-domain-status [domain ...]`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -246,11 +246,11 @@ benefit in using multiple CPUs for the packetcache, so a noticeable speedup can be attained by specifying ``distributor-threads=1`` in ``pdns.conf``. -Master/slave/native configuration ---------------------------------- +Primary/secondary/native configuration +-------------------------------------- -Master -~~~~~~ +Primary +~~~~~~~ Works as expected. At startup, no notification storm is performed as this is generally not useful. Perhaps in the future the BIND backend @@ -261,11 +261,11 @@ notifications were sent out. Changes which are discovered when reloading zones do lead to notifications however. -Slave -~~~~~ +Secondary +~~~~~~~~~ Also works as expected. The BIND backend expects to be able to write to -a directory where a slave domain lives. The incoming zone is stored as +a directory where a secondary domain lives. The incoming zone is stored as 'zonename.RANDOM' and atomically renamed if it is retrieved successfully, and parsed only then. @@ -277,10 +277,10 @@ Native PowerDNS has the concept of "native" zones that have the ``type native;`` in the BIND configuration file. These zones are neither -a master (no notifies are sent) nor a slave zone (it will never be +a primary (no notifies are sent) nor a secondary zone (it will never be AXFR'd in). This means that the replication mechanism for these zone is not AXFR but out of band, e.g. using ``rsync``. Changes to native zones -are picked up in the same way as master and slave zones, see +are picked up in the same way as primary and secondary zones, see :ref:`bind-operation`. Native zones in the BIND backend are supported since version 4.1.0 of diff --git a/docs/backends/generic-sql.rst b/docs/backends/generic-sql.rst index 95b7914a37..635147ae52 100644 --- a/docs/backends/generic-sql.rst +++ b/docs/backends/generic-sql.rst @@ -70,7 +70,7 @@ PowerDNS has support for multiple primaries per zone, and also port numbers for Autoprimary operation ^^^^^^^^^^^^^^^^^^^^^ -To configure a :ref:`autoprimary ` with IP address 203.0.113.53 which lists this +To configure a :ref:`autoprimary ` with IP address 203.0.113.53 which lists this installation as 'autosecondary.example.com', issue the following:: pdnsutil add-autoprimary 203.0.113.53 autosecondary.example.com internal diff --git a/docs/backends/ldap.rst b/docs/backends/ldap.rst index bc7616b538..16098d72ba 100644 --- a/docs/backends/ldap.rst +++ b/docs/backends/ldap.rst @@ -202,18 +202,18 @@ whose attribute "active" is set to "yes". e.g. (&(:target:)(active=yes)) for returning only entries whose attribute "active" is set to "yes". -Master Mode ------------ +Primary Mode +------------ Schema update ^^^^^^^^^^^^^ -First off adding master support to the LDAP backend needs a schema +First off adding primary support to the LDAP backend needs a schema update. This is required as some metadata must be stored by PowerDNS, such as the last successful transfer to slaves. The new schema is available in schema/pdns-domaininfo.schema. -Once the schema is loaded the zones for which you want to be a master +Once the schema is loaded the zones for which you want to be a primary must be modified. The dn of the SOA record *must* have the object class ``PdnsDomain``, and thus the ``PdnsDomainId`` attribute. This attribute is an integer that *must* be unique across all zones served by the @@ -223,7 +223,7 @@ backend. Furthermore the ``PdnsDomainType`` must be equal to 'master' Example ^^^^^^^ -Here is an example LDIF of a zone that's ready for master operation +Here is an example LDIF of a zone that's ready for primary operation (assuming the 'tree' style): :: @@ -242,7 +242,7 @@ Here is an example LDIF of a zone that's ready for master operation PdnsDomainType: master PdnsDomainMaster: 192.168.0.2 -You should have one attribute ``PdnsDomainMaster`` per master serving +You should have one attribute ``PdnsDomainMaster`` per primary serving this zone. Example diff --git a/docs/backends/lua2.rst b/docs/backends/lua2.rst index f0793318e6..d2c18c7c4b 100644 --- a/docs/backends/lua2.rst +++ b/docs/backends/lua2.rst @@ -92,8 +92,8 @@ OUTPUT: - string account - Associated account of this domain (default: ) - string kind - Domain kind (NATIVE,MASTER,SLAVE) (default: NATIVE) - int id - Associated domain ID (default: -1) - - int last_check - UNIX timestamp of last check from master (default: 0) - - table of strings masters - Master servers for this domain (default: ) + - int last_check - UNIX timestamp of last check from primary (default: 0) + - table of strings masters - Primary servers for this domain (default: ) - long notified_serial - Notified serial to slaves (default: 0) - long serial - Current domain serial @@ -101,7 +101,7 @@ NOTES: This function is **optional**. Defaults are used for omitted keys. ``last_check`` is for automatic serial. - ``masters``, ``account``, ``notified_serial`` are for master/slave interaction only. + ``masters``, ``account``, ``notified_serial`` are for primary/secondary interaction only. If this function is missing, it will revert into looking up SOA record for the given domain, and uses that, if found. @@ -114,7 +114,7 @@ OUTPUT: domaininfo. See :ref:`dns_get_domaininfo() `. NOTES: - This function is **optional**, except if you need master functionality. + This function is **optional**, except if you need primary functionality. ``dns_get_domain_metadata(domain, kind)`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -193,4 +193,4 @@ INPUT: - long serial - Notified serial NOTES: - This function is **optional**. However, not implementing this can cause problems with master functionality. + This function is **optional**. However, not implementing this can cause problems with primary functionality. diff --git a/docs/backends/remote.rst b/docs/backends/remote.rst index d2e6f62ed5..0d99a9ebc4 100644 --- a/docs/backends/remote.rst +++ b/docs/backends/remote.rst @@ -144,8 +144,8 @@ Methods Methods required for different features ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :Always required: ``initialize``, ``lookup`` -:Master operation: ``list``, ``getUpdatedMasters``, ``setNotified`` -:Slave operation: ``getUnfreshSlaveInfos``, ``startTransaction``, ``commitTransaction``, ``abortTransaction``, ``feedRecord``, ``setFresh`` +:Primary operation: ``list``, ``getUpdatedMasters``, ``setNotified`` +:Secondary operation: ``getUnfreshSlaveInfos``, ``startTransaction``, ``commitTransaction``, ``abortTransaction``, ``feedRecord``, ``setFresh`` :DNSSEC operation (live-signing): ``getDomainKeys``, ``getBeforeAndAfterNamesAbsolute`` :Filling the Zone Cache: ``getAllDomains`` @@ -945,7 +945,7 @@ Response: ``isMaster`` ~~~~~~~~~~~~ -Determines whether given IP is master for given domain name. +Determines whether given IP is primary for given domain name. - Mandatory: No - Parameters: name,ip @@ -987,7 +987,7 @@ Response: ``superMasterBackend`` ~~~~~~~~~~~~~~~~~~~~~~ -Creates new domain with given record(s) as master servers. IP address is +Creates new domain with given record(s) as primary servers. IP address is the address where notify is received from. nsset is array of NS resource records. @@ -1605,7 +1605,7 @@ Response: ``getUpdatedMasters`` ~~~~~~~~~~~~~~~~~~~~~ -Used to find out any updates to master domains. This is used to trigger notifications in master mode. +Used to find out any updates to primary domains. This is used to trigger notifications in primary mode. - Mandatory: no - Parameters: none @@ -1647,7 +1647,7 @@ Response: ``getUnfreshSlaveInfos`` ~~~~~~~~~~~~~~~~~~~~~~~~ -Used to find out if slave zones need checking of the master's SOA Serial. +Used to find out if primary zones need checking of the primary's SOA Serial. - Mandatory: no - Parameters: none @@ -1689,8 +1689,8 @@ Response: ``setFresh`` ~~~~~~~~~~~~ -Called when a slave freshness check succeeded. This does not indicate the -zone was updated on the master. +Called when a primary freshness check succeeded. This does not indicate the +zone was updated on the primary. - Mandatory: No - Parameters: id diff --git a/docs/backends/tinydns.rst b/docs/backends/tinydns.rst index 9ab90282e7..659ac6e790 100644 --- a/docs/backends/tinydns.rst +++ b/docs/backends/tinydns.rst @@ -56,7 +56,7 @@ The last update was on `January 1st, - Boolean - Default: no -Tell the TinyDNSBackend to notify all the slave nameservers on startup. +Tell the TinyDNSBackend to notify all the primary nameservers on startup. This might cause broadcast storms. .. _setting-tinydns-ignore-bogus-records: @@ -72,7 +72,7 @@ bad/corrupt RDATA. PowerDNS will crash when it tries to read that bad/corrupt data. This option (change to yes), allows you to ignore that bad RDATA to make PowerDNS operate when bad data is in your CDB file. Be aware that the records are then ignored, where tinydns would still send -out the bogus data. The option is primarily useful in master mode, as +out the bogus data. The option is primarily useful in primary mode, as that reads all the packets in the zone to find all the SOA records. .. _setting-tinydns-locations: @@ -101,15 +101,15 @@ record will expire once the cache is expired and the backend is queried again. Please note that :ref:`setting-cache-ttl` is a performance related setting. See :doc:`../performance`. Location support only exists for IPv4! -Master mode ------------ +Primary mode +------------ -The TinyDNSBackend supports master mode. This allows it to notify slave +The TinyDNSBackend supports primary mode. This allows it to notify secondary nameservers of updates to a zone. You simply need to rewrite the ``data.cdb`` file with an updated/increased serial and PowerDNS will -notify the slave nameservers of that domain. The :ref:`setting-tinydns-notify-on-startup` +notify the secondary nameservers of that domain. The :ref:`setting-tinydns-notify-on-startup` configuration setting tells the backend if it should notify all the -slave nameservers just after startup. +secondary nameservers just after startup. The CDB datafile does not allow PowerDNS to easily query for newly added domains or updated serial numbers. The CDB datafile requires us to do a diff --git a/docs/dnssec/operational.rst b/docs/dnssec/operational.rst index 34d597855a..2ba497be97 100644 --- a/docs/dnssec/operational.rst +++ b/docs/dnssec/operational.rst @@ -87,7 +87,7 @@ 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:`primary ` zones (where +For :ref:`primary ` 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 diff --git a/docs/dnsupdate.rst b/docs/dnsupdate.rst index de604c8b34..e474ccc074 100644 --- a/docs/dnsupdate.rst +++ b/docs/dnsupdate.rst @@ -58,8 +58,8 @@ unauthenticated agents operating from an allowed address range. ``forward-dnsupdate`` ~~~~~~~~~~~~~~~~~~~~~ -Tell PowerDNS to forward to the master server if the zone is configured -as slave. Masters are determined by the masters field in the domains +Tell PowerDNS to forward to the primary server if the zone is configured +as secondary. Primaries are determined by the masters field in the domains table. The default behaviour is enabled (yes), which means that it will try to forward. In the processing of the update packet, the ``allow-dnsupdate-from`` and ``TSIG-ALLOW-DNSUPDATE`` are processed @@ -184,7 +184,7 @@ per domain. NOTIFY-DNSUPDATE ~~~~~~~~~~~~~~~~ -Send a notification to all slave servers after every update. This will +Send a notification to all secondary servers after every update. This will speed up the propagation of changes and is very useful for acme verification:: @@ -305,7 +305,7 @@ This tells dhcpd to: For more information on this, consult the dhcpd.conf manual. Per subnet, you also have to tell **dhcpd** which (reverse-)domain it -should update and on which master domain server it is running. +should update and on which primary domain server it is running. :: @@ -409,12 +409,12 @@ PowerDNS. send. The TSIG-ALLOW-DNSUPDATE domainmetadata setting is used to find which key belongs to the domain. 7. The backends are queried to find the backend for the given domain. -8. If the domain is a slave domain, the **forward-dnsupdate** option - and domainmetadata settings are checked. If forwarding to a master - is enabled, the message is forward to the master. If that fails, the - next master is tried until all masters are tried. If all masters - fail, ServFail is returned. If a master succeeds, the result from - that master is returned. +8. If the domain is a secondary domain, the **forward-dnsupdate** option + and domainmetadata settings are checked. If forwarding to a primary + is enabled, the message is forward to the primary. If that fails, the + next primary is tried until all primaries are tried. If all primaries + fail, ServFail is returned. If a primary succeeds, the result from + that primary is returned. 9. A check is performed to make sure all updates/prerequisites are for the given zone. NotZone is returned if this is not the case. 10. The transaction with the backend is started. diff --git a/docs/domainmetadata.rst b/docs/domainmetadata.rst index 940770a922..5a54ba0962 100644 --- a/docs/domainmetadata.rst +++ b/docs/domainmetadata.rst @@ -102,7 +102,7 @@ number. e.g.: AXFR-MASTER-TSIG ---------------- -Use this named TSIG key to retrieve this zone from its master, see :ref:`tsig-provision-signed-notify-axfr`. +Use this named TSIG key to retrieve this zone from its primary, see :ref:`tsig-provision-signed-notify-axfr`. GSS-ALLOW-AXFR-PRINCIPAL ------------------------ @@ -194,7 +194,7 @@ SLAVE-RENOTIFY -------------- .. versionadded:: 4.3.0 -If set to 1, will make PowerDNS renotify the secondaries after an AXFR is received from a master. +If set to 1, will make PowerDNS renotify the secondaries after an AXFR is received from a primary. Any other value means that no renotifies are done. If not set at all, action will depend on the :ref:`setting-secondary-do-renotify` setting. diff --git a/docs/guides/alias.rst b/docs/guides/alias.rst index 48c74bd65c..0051cb0dda 100644 --- a/docs/guides/alias.rst +++ b/docs/guides/alias.rst @@ -71,4 +71,4 @@ ALIAS and DNSSEC Starting with the PowerDNS Authoritative Server 4.0.0, DNSSEC 'washing' of ALIAS records is supported on AXFR (**not** on live-signing). Set ``outgoing-axfr-expand-alias`` to 'yes' and enable DNSSEC for the zone -on the master. PowerDNS will sign the A/AAAA records during the AXFR. +on the primary. PowerDNS will sign the A/AAAA records during the AXFR. diff --git a/docs/http-api/zone.rst b/docs/http-api/zone.rst index 3adb26042a..850dd00cd4 100644 --- a/docs/http-api/zone.rst +++ b/docs/http-api/zone.rst @@ -42,7 +42,7 @@ When creating or updating a zone, the "api_rectify" field of the :json:object:`Z Backends might implement additional features (by coincidence or not). These things are not supported through the API. -When creating a slave zone, it is recommended to not set any of +When creating a secondary zone, it is recommended to not set any of ``nameservers``, ``rrsets`` or ``zone``. Examples diff --git a/docs/manpages/zone2sql.1.rst b/docs/manpages/zone2sql.1.rst index c177bae8de..15cbbbaa9f 100644 --- a/docs/manpages/zone2sql.1.rst +++ b/docs/manpages/zone2sql.1.rst @@ -15,8 +15,8 @@ on standard output, which can then be fed to your database. :program:`zone2sql` understands the BIND master file extension ``$GENERATE`` and will also honour ``$ORIGIN`` and ``$TTL``. -For backends supporting slave operation there is also an option to keep -slave zones as slaves, and not convert them to native operation. +For backends supporting secondary operation there is also an option to keep +secondary zones as secondaries, and not convert them to native operation. :program:`zone2sql` can generate SQL for the Generic MySQL, Generic PostgreSQL, Generic SQLite3 backend. @@ -67,7 +67,7 @@ OTHER Options --on-error-resume-next Ignore missing zone files during parsing. Dangerous. --secondary - Maintain slave status of zones listed in named.conf as being slaves. + Maintain secondary status of zones listed in named.conf as being slaves. The default behaviour is to convert all zones to native operation. --verbose Be verbose during conversion. diff --git a/docs/migration.rst b/docs/migration.rst index 737cec9061..f7bb8922b9 100644 --- a/docs/migration.rst +++ b/docs/migration.rst @@ -5,17 +5,17 @@ Before migrating to PowerDNS a few things should be considered. PowerDNS does not operate as a :ref:`secondary ` or :ref:`primary ` server with all backends. The :doc:`Generic SQL ` and -:doc:`BIND ` backends have the ability to act as master or -slave. See the :doc:`table of backends ` +:doc:`BIND ` backends have the ability to act as primary or +secondary. See the :doc:`table of backends ` which other backends support these modes. -Using AXFR to a Slave-Capable Backend -------------------------------------- +Using AXFR to a Secondary-Capable Backend +----------------------------------------- The easiest way to migrate all your zones from your old infrastructure -to PowerDNS is to add all your domains as a slave domain with your -current master as the master, wait for the zones to be transferred and -change the zones to master. Make sure :ref:`setting-secondary` is set to "yes" +to PowerDNS is to add all your domains as a secondary domain with your +current primary as the primary, wait for the zones to be transferred and +change the zones to primary. Make sure :ref:`setting-secondary` is set to "yes" in your pdns.conf. To A Generic SQL Backend @@ -25,15 +25,15 @@ To A Generic SQL Backend This assumes the schema provided with PowerDNS is in place. In order to migrate to a Generic SQL backend, add all your domains to -the 'domains' table with the IP of your current master. On your current -master, make sure that this master allows AXFRs to this new slave. +the 'domains' table with the IP of your current primary. On your current +primary, make sure that this primary allows AXFRs to this new secondary. .. code-block:: SQL INSERT INTO domains (name,type,master) VALUES ('example.net', 'SLAVE', '198.51.100.101'); Then start PowerDNS and wait for all the zones to be transferred. If -this server is the new :ref:`master `, change the type of +this server is the new :ref:`primary `, change the type of domain in the database: .. code-block:: SQL diff --git a/docs/running.rst b/docs/running.rst index e24bd70b53..1b5e5848be 100644 --- a/docs/running.rst +++ b/docs/running.rst @@ -99,7 +99,7 @@ To communicate with PowerDNS Authoritative Server over the controlsocket, the ``pdns_control`` command is used. The syntax is simple: ``pdns_control command arguments``. Currently this is most useful for telling backends to rediscover domains or to force the -transmission of notifications. See :ref:`master-operation`. +transmission of notifications. See :ref:`primary-operation`. For all supported ``pdns_control`` commands and options, see :doc:`the manpage <../manpages/pdns_control.1>` and the output of diff --git a/docs/settings.rst b/docs/settings.rst index 283ea3e2a1..82655b1505 100644 --- a/docs/settings.rst +++ b/docs/settings.rst @@ -77,7 +77,7 @@ will drop all incoming notifies. - Default: yes Turning this off requires all autoprimary notifications to be signed by -valid TSIG signature. It will accept any existing key on slave. +valid TSIG signature. It will accept any existing key on secondaries. .. _setting-allow-unsigned-notify: @@ -181,7 +181,7 @@ Maximum time in seconds for inbound AXFR to start or be idle after starting. - Boolean - Default: no -Also AXFR a zone from a master with a lower serial. +Also AXFR a zone from a primary with a lower serial. .. _setting-cache-ttl: @@ -828,7 +828,7 @@ ALIAS is not impacted by this setting. - Boolean - Default: no -Forward DNS updates sent to a slave to the master. +Forward DNS updates sent to a secondary to the primary. .. _setting-forward-notify: @@ -837,8 +837,8 @@ Forward DNS updates sent to a slave to the master. - IP addresses, separated by commas -IP addresses to forward received notifications to regardless of master -or slave settings. +IP addresses to forward received notifications to regardless of primary +or secondary settings. .. note:: The intended use is in anycast environments where it might be @@ -1182,7 +1182,7 @@ When combining the ``"`` delimited chunks of a LUA record, whether to insert whi - Boolean - Default: no -Turn on master support. See :ref:`master-operation`. +Turn on primary support. See :ref:`primary-operation`. .. _setting-max-cache-entries: @@ -1388,7 +1388,7 @@ this reason it is disabled by default. - IP Ranges, separated by commas or whitespace - Default: 0.0.0.0/0, ::/0 -For type=MASTER zones (or SLAVE zones with slave-renotify enabled) +For type=MASTER zones (or SLAVE zones with :ref:`setting-secondary-do-renotify` enabled) PowerDNS automatically sends NOTIFYs to the name servers specified in the NS records. By specifying networks/mask as whitelist, the targets can be limited. The default is to notify the world. To completely @@ -1414,11 +1414,11 @@ To notify all IP addresses apart from the 192.168.0.0/24 subnet use the followin :ref:`metadata-also-notify` zone metadata to avoid this potential bottleneck. .. note:: - If your slaves support an Internet Protocol version, which your master does not, + If your secondaries support an Internet Protocol version, which your primary does not, then set ``only-notify`` to include only supported protocol version. Otherwise there will be error trying to resolve address. - For example, slaves support both IPv4 and IPv6, but PowerDNS master have only IPv4, + For example, secondaries support both IPv4 and IPv6, but PowerDNS primary have only IPv4, so allow only IPv4 with ``only-notify``: .. code-block:: ini @@ -1471,7 +1471,7 @@ be dropped, and :ref:`stat-overload-drops` will be incremented. - Default: yes PowerDNS Authoritative Server attempts to not send out notifications to -itself in master mode. In very complicated situations we could guess +itself in primary mode. In very complicated situations we could guess wrong and not notify a server that should be notified. In that case, set prevent-self-notification to "no". @@ -1610,7 +1610,7 @@ Examples:: - Integer - Default: 2 -Number of AXFR slave threads to start. +Number of AXFR secondary threads to start. .. _setting-reuseport: @@ -1703,7 +1703,7 @@ this to an empty string disables secpoll. If yes, outgoing NOTIFYs will be signed if a TSIG key is configured for the zone. If there are multiple TSIG keys configured for a zone, PowerDNS will use the first one retrieved from the backend, which may not be the correct one for the -respective slave. Hence, in setups with multiple slaves with different TSIG keys +respective secondary. Hence, in setups with multiple slaves with different TSIG keys it may be required to send NOTIFYs unsigned. .. _setting-server-id: @@ -1775,9 +1775,9 @@ signing speed by changing this number. - Boolean - Default: no -This setting will make PowerDNS renotify the slaves after an AXFR is -*received* from a master. This is useful when running a -signing-slave. +This setting will make PowerDNS renotify the secondaries after an AXFR is +*received* from a primary. This is useful when running a +signing-secondary. See :ref:`metadata-slave-renotify` to set this per-zone. @@ -1860,7 +1860,7 @@ and :doc:`Virtual Hosting ` how this can differ. - Boolean - Default: no -Turn on supermaster support. See :ref:`supermaster-operation`. +Turn on supermaster support. See :ref:`autoprimary-operation`. .. _setting-svc-autohints: diff --git a/docs/tsig.rst b/docs/tsig.rst index 6335e96c2c..3f166b5f57 100644 --- a/docs/tsig.rst +++ b/docs/tsig.rst @@ -69,7 +69,7 @@ Provisioning signed notification and AXFR requests -------------------------------------------------- To configure PowerDNS to send out TSIG signed AXFR requests for a zone -to its master(s), set the ``AXFR-MASTER-TSIG`` metadata item for the +to its primaries, set the ``AXFR-MASTER-TSIG`` metadata item for the relevant domain to the key that must be used. The actual TSIG key must also be provisioned, as outlined in the @@ -113,7 +113,7 @@ quite) similar to the following BIND statements:: }; Except that in this case, TSIG will be used for all communications with -the master, not just those about AXFR requests. +the primary, not just those about AXFR requests. .. _tsig-gss-tsig: