Replication
-----------
-Please note that not all PowerDNS Server backends support master or slave support, see the :doc:`table of backends <../backends/index>`.
+Please note that not all PowerDNS Server backends support primary or secondary op[eration, see the :doc:`table of backends <../backends/index>`.
My PowerDNS Authoritative Server does not send NOTIFY messages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Don't forget to enable master-support by setting :ref:`setting-master` to ``yes`` in your configuration.
-In :ref:`master mode<master-operation>` PowerDNS Authoritative Server will send NOTIFYs to all nameservers that are listed as NS records in the zone by default.
+Don't forget to enable primary support by setting :ref:`setting-primary` to ``yes`` in your configuration.
+In :ref:`primary mode<primary-operation>` PowerDNS Authoritative Server will send NOTIFYs to all nameservers that are listed as NS records in the zone by default.
My PowerDNS Authoritative Server does not start AXFRs
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Don't forget to enable slave-support by setting :ref:`setting-slave` to ``yes`` in your configuration.
-In :ref:`slave mode<slave-operation>` PowerDNS Authoritative Server listens for NOTIFYs from the master IP for zones that are configured as slave zones.
-And will also periodically check for SOA serial number changes at the master.
+Don't forget to enable secondary-support by setting :ref:`setting-secondary` to ``yes`` in your configuration.
+In :ref:`secondary mode<secondary-operation>` PowerDNS Authoritative Server listens for NOTIFYs from the primary IP for zones that are configured as secondary zones,
+and will also periodically check for SOA serial number changes at the primary.
-Can PowerDNS Server act as Slave and Master at the same time?
+Can PowerDNS Server act as Secondary and Primary at the same time?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Yes totally, enable both by saying ``yes`` to :ref:`setting-master` and :ref:`setting-slave` in your configuration.
+Yes totally, enable both by saying ``yes`` to :ref:`setting-primary` and :ref:`setting-secondary` in your configuration.
How can I limit Zone Transfers (AXFR) per Domain?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
With the ALLOW-AXFR-FROM metadata, See :ref:`the documentation <metadata-allow-axfr-from>`.
-I have a working Supermaster/Superslave setup but when I remove Domains from the Master they still remain on the Slave. Am I doing something wrong?
+I have a working Autoprimary/Autosecondary setup but when I remove Domains from the Primary they still remain on the Secondary. Am I doing something wrong?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You're not doing anything wrong.
This is the perfectly normal and expected behavior because the AXFR (DNS Zonetransfer) Protocol does not provide for zone deletion.
-You need to remove the zones from the slave manually or via a custom script.
+You need to remove the zones from the secondary manually or via a custom script.
Operational
-----------
Invite such operators to look at :rfc:`section 6.2.1 of RFC 1034 <1034#section-6.2.1>`, which shows a correct authoritative answer without authority records.
In fact, none of the non-deprecated authoritative answers shown have authority records!
-Master or Slave support is not working, PowerDNS is not picking up changes
+Primary or Secondary support is not working, PowerDNS is not picking up changes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The Master/Slave apparatus is off by default.
-Turn it on by adding a :ref:`setting-slave` and/or :ref:`setting-master` statement to the configuration file.
-Also, check that the configured backend is master or slave capable and you entered exactly the same string to the Domains tables without the ending dot.
+The Primary/Secondary apparatus is off by default.
+Turn it on by adding a :ref:`setting-secondary` and/or :ref:`setting-primary` statement to the configuration file.
+Also, check that the configured backend is primary or secondary capable and you entered exactly the same string to the Domains tables without the ending dot.
-My masters won't allow PowerDNS to access zones as it is using the wrong local IP address
+My primaries won't allow PowerDNS to access zones as it is using the wrong local IP address
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By default, PowerDNS lets the kernel pick the source address.
To set an explicit source address, use the :ref:`setting-query-local-address` setting.
--------------------------------
Implementing a backend consists of inheriting from the DNSBackend class.
-For read-only backends, which do not support slave operation, only the
+For read-only backends, which do not support secondary operation, only the
following methods are relevant:
.. code-block:: cpp
.. cpp:member:: string SOAData::nameserver
- Name of the master nameserver of this zone
+ Name of the primary nameserver of this zone
.. cpp:member:: string SOAData::hostmaster
.. cpp:member:: DNSBackend* SOAData::db
- Pointer to the backend that feels authoritative for a domain and can act as a slave
+ Pointer to the backend that feels authoritative for a domain and can act as a secondary
Methods
~~~~~~~
.. _rw-slave:
+.. _rw-secondary:
-Read/write slave-capable backends
+Read/write secondary-capable backends
---------------------------------
The backends above are 'natively capable' in that they contain all data
enable storage of information, a backend must be able to do more.
Before diving into the details of the implementation some theory is in
-order. Slave domains are pulled from the master. PowerDNS needs to know
-for which domains it is to be a slave, and for each slave domain, what
-the IP address of the master is.
+order. Secondary domains are pulled from the primary. PowerDNS needs to know
+for which domains it is to be a secondary, and for each secondary domain, what
+the IP address of the primary is.
-A slave zone is pulled from a master, after which it is 'fresh', but
+A secondary zone is pulled from a primary, after which it is 'fresh', but
this is only temporary. In the SOA record of a zone there is a field
which specifies the 'refresh' interval. After that interval has elapsed,
-the slave nameserver needs to check at the master if the serial number
+the secondary nameserver needs to check at the primary if the serial number
there is higher than what is stored in the backend locally.
If this is the case, PowerDNS dubs the domain 'stale', and schedules a
.. cpp:member:: string DomainInfo::master
- IP address of the master of this domain, if any
+ IP address of the primary of this domain, if any
.. cpp:member:: uint32_t DomainInfo::serial
.. cpp:member:: uint32_t DomainInfo::notified_serial
- Last serial number of this zone that slaves have seen
+ Last serial number of this zone that secondaries have seen
.. cpp:member:: time_t DomainInfo::last_check
- Last time this zone was checked over at the master for changes
+ Last time this zone was checked over at the primary for changes
.. cpp:member:: enum DomainKind DomainInfo::kind
.. cpp:member:: DNSBackend* DomainInfo::backend
- Pointer to the backend that feels authoritative for a domain and can act as a slave
+ Pointer to the backend that feels authoritative for a domain and can act as a secondary
.. cpp:enum:: DomainKind
These functions all have a default implementation that returns false -
which explains that these methods can be omitted in simple backends.
-Furthermore, unlike with simple backends, a slave capable backend must
+Furthermore, unlike with simple backends, a secondary capable backend must
make sure that the 'DNSBackend \*db' field of the SOAData record is
filled out correctly - it is used to determine which backend will house
this zone.
.. cpp:function:: bool DomainInfo::isMaster(const string &name, const string &ip)
- If a backend considers itself a slave for the domain **name** and if the
- IP address in **ip** is indeed a master, it should return true. False
+ If a backend considers itself a secondary for the domain **name** and if the
+ IP address in **ip** is indeed a primary, it should return true. False
otherwise. This is a first line of checks to guard against reloading a
domain unnecessarily.
.. cpp:function:: void DomainInfo::getUnfreshSlaveInfos(vector\<DomainInfo\>* domains)
- When called, the backend should examine its list of slave domains and
+ When called, the backend should examine its list of secondary domains and
add any unfresh ones to the domains vector.
.. cpp:function:: bool DomainInfo::getDomainInfo(const string &name, DomainInfo & di)
db->setFresh(domain_id);
g_log<<Logger::Error<<"AXFR done for '"<<domain<<"'"<<endl;
-Supermaster/Superslave capability
+Autoprimary/autosecondary capability
---------------------------------
-A backend that wants to act as a 'superslave' for a master should
+A backend that wants to act as an 'autosecondary' (formerly 'superslave') for a primary should
implement the following method:
.. code-block:: cpp
};
This function gets called with the IP address of the potential
-supermaster, the domain it is sending a notification for and the set of
+autoprimary, the domain it is sending a notification for and the set of
NS records for this domain at that IP address.
Using the supplied data, the backend needs to determine if this is a
bonafide 'supernotification' which should be honoured. If it decides
that it should, the supplied pointer to 'account' needs to be filled
-with the configured name of the supermaster (if accounting is desired),
+with the configured name of the autoprimary (if accounting is desired),
and the db needs to be filled with a pointer to your backend.
-Supermaster/superslave is a complicated concept, if this is all unclear
-see the :ref:`Supermaster and Superslave <supermaster-operation>`
+Autoprimary/autosecondary is a complicated concept, if this is all unclear
+see the :ref:`autoprimary-operation`
documentation.
-Read/write master-capable backends
-----------------------------------
+Read/write primary-capable backends
+-----------------------------------
-In order to be a useful master for a domain, notifies must be sent out
+In order to be a useful primary for a domain, notifies must be sent out
whenever a domain is changed. Periodically, PowerDNS queries backends
-for domains that may have changed, and sends out notifications for slave
+for domains that may have changed, and sends out notifications to secondary
nameservers.
In order to do so, PowerDNS calls the ``getUpdatedMasters()`` method.
These functions all have a default implementation that returns false -
which explains that these methods can be omitted in simple backends.
-Furthermore, unlike with simple backends, a slave capable backend must
+Furthermore, unlike with simple backends, a secondary capable backend must
make sure that the 'DNSBackend \*db' field of the SOAData record is
filled out correctly - it is used to determine which backend will house
this zone.
------------------
To make your backend DNS update compatible, it needs to implement a
-number of new functions and functions already used for slave-operation.
+number of new functions and functions already used for secondary operation.
The new functions are not DNS update specific and might be used for
other update/remove functionality at a later stage.
Before migrating to PowerDNS a few things should be considered.
-PowerDNS does not operate as a :ref:`slave-operation` or
-:ref:`master-operation` server with all backends. The :doc:`Generic SQL <backends/generic-sql>` and
+PowerDNS does not operate as a :ref:`secondary <secondary-operation>` or
+:ref:`primary <primary-operation>` server with all backends. The :doc:`Generic SQL <backends/generic-sql>` and
:doc:`BIND <backends/bind>` backends have the ability to act as master or
slave. See the :doc:`table of backends <backends/index>`
which other backends support these modes.
managing records etc.
.. _master-operation:
+.. _primary-operation:
Master operation
----------------
happen in contrived configurations.
.. _slave-operation:
+.. _secondary-operation:
Slave operation
---------------
can not serve IXFR updates.
.. _supermaster-operation:
+.. _autoprimary-operation:
-Supermaster: automatic provisioning of slaves
----------------------------------------------
+Autoprimary: automatic provisioning of secondaries
+--------------------------------------------------
-PowerDNS can recognize so called 'supermasters'. A supermaster is a host
-which is master for domains and for which we are to be a slave. When a
-master (re)loads a domain, it sends out a notification to its slaves.
+.. versionchanged:: 4.5.0
+ Before version 4.5.0, this feature was called 'supermaster'
+
+PowerDNS can recognize so called 'autoprimaries'. An autoprimary is a host
+which is primary for domains and for which we are to be a secondary. When a
+primary (re)loads a domain, it sends out a notification to its secondaries.
Normally, such a notification is only accepted if PowerDNS already knows
-that it is a slave for a domain.
+that it is a secondary for a domain.
-However, a notification from a supermaster carries more persuasion. When
-PowerDNS determines that a notification comes from a supermaster and it
+However, a notification from an autoprimary carries more persuasion. When
+PowerDNS determines that a notification comes from a autoprimary and it
is bonafide, it can provision the domain automatically, and configure
-itself as a slave for that zone.
+itself as a secondary for that zone.
-Before a supermaster notification succeeds, the following conditions
+Before an autoprimary notification succeeds, the following conditions
must be met:
-
-- :ref:`setting-superslave` support must be enabled
-- The supermaster must carry a SOA record for the notified domain
-- The supermaster IP must be present in the 'supermasters' table in the database on the slave, along with any name that is in the NS set.
-- The set of NS records for the domain, as retrieved by the slave from the supermaster, must include the name that goes with the IP address in the supermasters table
-- If your master sends signed NOTIFY it will mark that TSIG key as the TSIG key used for retrieval as well
-- If you turn off :ref:`setting-allow-unsigned-supermaster`, then your supermaster(s) are required to sign their notifications.
+- :ref:`setting-autosecondary` support must be enabled
+- The autoprimary must carry a SOA record for the notified domain
+- The autoprimary IP must be present in the ``supermasters`` table in the database on the secondary, along with any name that is in the NS set.
+- The set of NS records for the domain, as retrieved by the secondary from the autoprimary, must include the name that goes with the IP address in the ``supermasters`` table
+- If your primary sends signed NOTIFY it will mark that TSIG key as the TSIG key used for retrieval as well
+- If you turn off :ref:`setting-allow-unsigned-autoprimary`, then your autoprimaries are required to sign their notifications.
.. warning::
- If you use another PowerDNS server as master and have
+ If you use another PowerDNS server as primary and have
DNSSEC enabled on that server please don't forget to rectify the domains
after every change. If you don't do this there is no SOA record
available and one requirement will fail.
So, to benefit from this feature, a backend needs to know about the IP
-address of the supermaster, and how PowerDNS will be listed in the set
-of NS records remotely, and the 'account' name of your supermaster.
+address of the autoprimary, and how PowerDNS will be listed in the set
+of NS records remotely, and the 'account' name of your autoprimary.
There is no need to fill the account name out but it does help keep
-track of where a domain comes from.
-Adding a supermaster can be done either directly in the database,
+track of where a domain comes from.
+Additionally, if a secondary selects multiple autoprimaries for a zone based on the name of the primary, it also checks that the ``account`` field is the same for all.
+Adding a autoprimary can be done either directly in the database,
or by using the 'pdnsutil add-supermaster' command.
.. note::
- Removal of zones provisioned using the supermaster must be
- done on the slaves themselves. As there is no way to signal this removal
- from the master to the slave.
+ Removal of zones provisioned using the autoprimary must be
+ done on the secondaries themselves, as there is no way to signal this removal
+ from the primary to the secondary.
.. _modes-of-operation-axfrfilter:
Static pre-shared authentication key for access to the REST API.
+.. _setting-autosecondary:
+
+``autosecondary``
+---------------
+
+.. versionchanged:: 4.5.0
+ This was called :ref:`setting-superslave` before 4.5.0.
+
+- Boolean
+- Default: no
+
+Turn on autosecondary support. See :ref:`autoprimary-operation`.
+
.. _setting-axfr-fetch-timeout:
``axfr-fetch-timeout``
``master``
----------
++.. deprecated:: 4.5.0
++ Renamed to :ref:`setting-primary`.
+
- Boolean
- Default: no
wrong and not notify a server that should be notified. In that case, set
prevent-self-notification to "no".
+.. _setting-primary:
+
+``primary``
+----------
+
+.. versionchanged:: 4.5.0
+ This was called :ref:`setting-master` before 4.5.0.
+
+- Boolean
+- Default: no
+
+Turn on operating as a primary. See :ref:`primary-operation`.
+
.. _setting-query-cache-ttl:
``query-cache-ttl``
.. note::
Not all choices are available on all systems.
+.. _setting-secondary:
+
+``secondary``
+-------------
+
+.. versionchanged:: 4.5.0
+ This was called :ref:`setting-slave` before 4.5.0.
+
+- Boolean
+- Default: no
+
+Turn on operationg as a secondary. See :ref:`secondary-operation`.
+
+.. _setting-secondary-do-renotify:
+
+``secondary-do-renotify``
+------------------
+
+.. versionchanged:: 4.5.0
+ This was called :ref:`setting-slave-renotify` before 4.5.0.
+
+- Boolean
+- Default: no
+
+This setting will make PowerDNS renotify the secondaries after an AXFR is
+*received* from a primary. This is useful, among other situations, when running a
+signing secondary.
+
+See :ref:`metadata-slave-renotify` to set this per-zone.
+
.. _setting-security-poll-suffix:
``security-poll-suffix``
``slave``
---------
-- Boolean
-- Default: no
-
-Turn on slave support. See :ref:`slave-operation`.
+.. deprecated:: 4.5.0
+ Renamed to :ref:`setting-secondary`.
.. _setting-slave-cycle-interval:
``slave-renotify``
------------------
+.. deprecated:: 4.5.0
+ Renamed to :ref:`setting-secondary-do-renotify`.
+
- Boolean
- Default: no
``superslave``
---------------
+.. deprecated:: 4.5.0
+ Renamed to :ref:`setting-autosecondary`.
+
- Boolean
- Default: no
projects / thirdparty / pdns.git / commitdiff
