---
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
~~~~~~~~~~~~~~~~~~
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.
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`.
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 ...]``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
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.
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
Autoprimary operation
^^^^^^^^^^^^^^^^^^^^^
-To configure a :ref:`autoprimary <supermaster-operation>` with IP address 203.0.113.53 which lists this
+To configure a :ref:`autoprimary <autoprimary-operation>` 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
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
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):
::
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
- string account - Associated account of this domain (default: <empty>)
- 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: <empty>)
+ - int last_check - UNIX timestamp of last check from primary (default: 0)
+ - table of strings masters - Primary servers for this domain (default: <empty>)
- long notified_serial - Notified serial to slaves (default: 0)
- long serial - Current domain serial
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.
domaininfo. See :ref:`dns_get_domaininfo() <backends_lua2_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)``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- 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.
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``
``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
``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.
``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
``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
``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
- 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:
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:
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
For zones that use :ref:`native-operation`
replication PowerDNS will serve valid RRSIGs on all servers.
-For :ref:`primary <master-operation>` zones (where
+For :ref:`primary <primary-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
``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
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::
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.
::
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.
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
------------------------
--------------
.. 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.
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.
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
: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.
--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.
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>`
+:doc:`BIND <backends/bind>` backends have the ability to act as primary or
+secondary. See the :doc:`table of backends <backends/index>`
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
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 <master-operation>`, change the type of
+this server is the new :ref:`primary <primary-operation>`, change the type of
domain in the database:
.. code-block:: SQL
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
- 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:
- 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:
- 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:
- 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
- Boolean
- Default: no
-Turn on master support. See :ref:`master-operation`.
+Turn on primary support. See :ref:`primary-operation`.
.. _setting-max-cache-entries:
- 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
: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
- 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".
- Integer
- Default: 2
-Number of AXFR slave threads to start.
+Number of AXFR secondary threads to start.
.. _setting-reuseport:
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:
- 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.
- Boolean
- Default: no
-Turn on supermaster support. See :ref:`supermaster-operation`.
+Turn on supermaster support. See :ref:`autoprimary-operation`.
.. _setting-svc-autohints:
--------------------------------------------------
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
};
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:
projects / thirdparty / pdns.git / commitdiff
