Skipped some occurrences where it refers to PR titles or commit messages.
Returns the numerical value of a parameter. Uses ``atoi()`` internally
- Sample usage from the BindBackend: getting the 'check-interval' setting:
+ Sample usage from the BIND backend: getting the 'check-interval' setting:
.. code-block:: cpp
-Bind zone file backend
+BIND zone file backend
======================
* Native: Yes
* Module name: bind
* Launch: ``bind``
-The BindBackend started life as a demonstration of the versatility of
+The BIND backend started life as a demonstration of the versatility of
PowerDNS but quickly gained in importance when there appeared to be
-demand for a Bind 'work-alike'.
+demand for a BIND 'work-alike'.
-The BindBackend parses a Bind-style ``named.conf`` and extracts
+The BIND backend parses a BIND-style ``named.conf`` and extracts
information about zones from it. It makes no attempt to honour other
configuration flags, which you should configure (when available) using
the PowerDNS native configuration.
``bind-config``
~~~~~~~~~~~~~~~
-Location of the Bind configuration file to parse.
+Location of the BIND configuration file to parse.
-PowerDNS does not support every directive supported by Bind.
+PowerDNS does not support every directive supported by BIND.
It supports the following blocks and directives:
* ``options``
Operation
---------
-On launch, the BindBackend first parses the ``named.conf`` to determine
+On launch, the BIND backend first parses the ``named.conf`` to determine
which zones need to be loaded. These will then be parsed and made
available for serving, as they are parsed. So a ``named.conf`` with
100.000 zones may take 20 seconds to load, but after 10 seconds, 50.000
``bind-add-zone <domain> <filename>``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add zone ``domain`` from ``filename`` to PowerDNS's bind backend. Zone
+Add zone ``domain`` from ``filename`` to PowerDNS's BIND backend. Zone
will be loaded at first request.
.. note::
``rediscover``
~~~~~~~~~~~~~~
-Reread the bind configuration file (``named.conf``). If parsing fails,
+Reread the BIND configuration file (``named.conf``). If parsing fails,
the old configuration remains in force and ``pdns_control`` reports the
error. Any newly discovered domains are read, discarded domains are
removed from memory.
Performance
-----------
-The BindBackend does not benefit from the packet cache as it is fast
+The BIND backend does not benefit from the packet cache as it is fast
enough on its own. Furthermore, on most systems, there will be no
benefit in using multiple CPUs for the packetcache, so a noticeable
speedup can be attained by specifying
~~~~~~
Works as expected. At startup, no notification storm is performed as
-this is generally not useful. Perhaps in the future the Bind Backend
+this is generally not useful. Perhaps in the future the BIND backend
will attempt to store zone metadata in the zone, allowing it to
determine if a zone has changed its serial since the last time
notifications were sent out.
Slave
~~~~~
-Also works as expected. The Bind backend expects to be able to write to
+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
'zonename.RANDOM' and atomically renamed if it is retrieved
successfully, and parsed only then.
^^^^^^^^^
Wild-card domains are possible by using the asterisk in the
-``associatedDomain`` value like it is used in the bind zone files. The
+``associatedDomain`` value like it is used in the BIND zone files. The
"dc" attribute can be set to any value in simple or strict mode - this
doesn't matter.
See :doc:`its manpage <../manpages/zone2ldap.1>` for a complete list of
options.
-Bind LDAP backend
+BIND LDAP backend
^^^^^^^^^^^^^^^^^
-When coming from the `Bind LDAP sdb
+When coming from the `BIND LDAP sdb
backend <http://bind9-ldap.bayour.com/>`__, the records can be kept in
the LDAP tree also for the PowerDNS LDAP backend. The schemas both
backends utilize is almost the same except for one important thing:
Domains for PowerDNS are stored in the attribute "associatedDomain"
-whereas Bind stores them split in "relativeDomainName" and "zoneName".
+whereas BIND stores them split in "relativeDomainName" and "zoneName".
There is a `migration
script <http://www.linuxnetworks.de/pdnsldap/bind2pdns-ldap>`__ which
^^^^^^^^^^^^^^^^^
The easiest way for migrating DNS records is to use the output of a zone
-transfer (AXFR). Save the output of the ``dig`` program provided by bind
+transfer (AXFR). Save the output of the ``dig`` program provided by BIND
into a file and call ``zone2ldap`` with the file name as option to the
``--zone-file`` parameter. This will generate the appropriate ldif file,
which can be imported into the LDAP tree. The bash script except below
BIND-mode operation
-------------------
-The :doc:`bindbackend <../backends/bind>` can manage keys and other
+The :doc:`BIND backend <../backends/bind>` can manage keys and other
DNSSEC-related :doc:`domain metadata <../domainmetadata>` in an SQLite3
database without launching a separate gsqlite3 backend.
--------------------------
PowerDNS can also operate based on 'BIND'-style zone & configuration
-files. This 'bindbackend' has full knowledge of DNSSEC but has no
+files. This 'BIND backend' has full knowledge of DNSSEC but has no
native way of storing keying material.
However, since PowerDNS supports operation with multiple simultaneous
backends, this is not a problem.
In hybrid mode, keying material and zone records are stored in different
-backends. This allows for 'bindbackend' operation in full DNSSEC mode.
+backends. This allows for 'BIND backend' operation in full DNSSEC mode.
To benefit from this mode, include at least one database-based backend
in the :ref:`setting-launch` statement. See the :doc:`backend specific documentation <../backends/index>`
PowerDNS has the concepts of 'backends'. A backend is a datastore that
the server will consult that contains DNS records (and some metadata).
The backends range from database backends (:doc:`MySQL <backends/generic-mysql>`, :doc:`PostgreSQL <backends/generic-postgresql>`, :doc:`Oracle <backends/oracle>`)
-and :doc:`Bind-zonefiles <backends/bind>` to :doc:`co-processes <backends/pipe>` and :doc:`JSON API's <backends/remote>`.
+and :doc:`BIND zone files <backends/bind>` to :doc:`co-processes <backends/pipe>` and :doc:`JSON API's <backends/remote>`.
Multiple backends can be enabled in the configuration by using the
:ref:`setting-launch` option. Each backend can be configured separately.
bind-add-zone *DOMAIN* *FILENAME*
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-When using the bindbackend, add a zone. This zone is added in-memory
+When using the BIND backend, add a zone. This zone is added in-memory
and served immediately. Note that this does not add the zone to the
bind-config file. *FILENAME* must be an absolute path.
bind-domain-status [*DOMAIN*...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-When using the bindbackend, list status of all domains. Optionally,
+When using the BIND backend, list status of all domains. Optionally,
append *DOMAIN*\ s to get the status of specific zones.
bind-list-rejects
^^^^^^^^^^^^^^^^^
-When using the bindbackend, get a list of all rejected domains.
+When using the BIND backend, get a list of all rejected domains.
bind-reload-now *DOMAIN* [*DOMAIN*...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-When using the bindbackend, immediately reload *DOMAIN* from disk.
+When using the BIND backend, immediately reload *DOMAIN* from disk.
ccounts
^^^^^^^
^^^^^^^^^^
Instructs backends that new domains may have appeared in the
-database, or, in the case of the Bind backend, in named.conf.
+database, or, in the case of the BIND backend, in named.conf.
reload
^^^^^^
Description
-----------
-:program:`zone2json` parses Bind named.conf files and zonefiles and outputs
+:program:`zone2json` parses BIND named.conf files and zonefiles and outputs
JSON on standard out, which can then be fed to the PowerDNS API.
-:program:`zone2json` understands the Bind master file extension ``$GENERATE``
+:program:`zone2json` understands the BIND master file extension ``$GENERATE``
and will also honour ``$ORIGIN`` and ``$TTL``.
Options
INPUT Options
-------------
---named-conf=<PATH> Read *PATH* to get the bind configuration
+--named-conf=<PATH> Read *PATH* to get the BIND configuration
--zone=<PATH> Parse only the zone file at *PATH* Conflicts with ``--named-conf`` parameter.
--zone-name=<NAME> When parsing a single zone without $ORIGIN statement, set *ZONE* as the zone name.
Description
-----------
-:program:`zone2ldap` is a program that converts bind zonefiles to ldif format
+:program:`zone2ldap` is a program that converts BIND zonefiles to ldif format
which can inserted to an LDAP server.
Options
--basedn=<DN> Base DN to store objects below
--dnsttl Add dnsttl attribute to every entry
--layout=<layout> How to arrange entries in the directory ("simple" or "tree")
---named-conf=<PATH> Path to a Bind named.conf to parse
+--named-conf=<PATH> Path to a BIND named.conf to parse
--resume Continue after errors
--verbose Verbose comments on operation
--zone-file=<PATH> Zone file to parse
Description
-----------
-:program:`zone2sql` parses Bind named.conf files and zonefiles and outputs SQL
+:program:`zone2sql` parses BIND named.conf files and zonefiles and outputs SQL
on standard out, which can then be fed to your database.
-:program:`zone2sql` understands the Bind master file extension ``$GENERATE``
+: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
INPUT Options
-------------
---named-conf=<PATH> Read *PATH* to get the bind configuration
+--named-conf=<PATH> Read *PATH* to get the BIND configuration
--zone=<PATH> Parse only the zone file at *PATH* Conflicts with **--named-conf** parameter.
--zone-name=<NAME> When parsing a single zone without $ORIGIN statement, set *ZONE* as
the zone name.
Using the BIND backend
~~~~~~~~~~~~~~~~~~~~~~
-To use the bind backend, set ``launch=bind`` and
+To use the BIND backend, set ``launch=bind`` and
``bind-config=/path/to/named.conf`` in your ``pdns.conf``. Note that
PowerDNS will not honor any options from named.conf, it will only use
-the ``zone`` statements. See the :doc:`Bind backend <backends/bind>`
+the ``zone`` statements. See the :doc:`BIND backend <backends/bind>`
documentation for more information.
To a Generic SQL backend
To migrate, the ``zone2sql`` tool is provided. This tool parses a BIND
``named.conf`` file and zone files and outputs SQL on standard out,
-which can then be fed to your database. It understands the Bind master
+which can then be fed to your database. It understands the BIND master
file extension ``$GENERATE`` and will also honour ``$ORIGIN`` and
``$TTL``.
This tool lets you migrate data from one backend to another, it moves
all data, including zones, metadata and crypto keys (if present). Some
-example use cases are moving from Bind style zonefiles to SQL based, or
+example use cases are moving from BIND-style zonefiles to SQL based, or
other way around, or moving from MyDNS to gMySQL.
Prerequisites
All backends which implement this feature must make sure that they can
handle transactions so as to not leave the zone in a half updated state.
MySQL configured with either BerkeleyDB or InnoDB meets this
-requirement, as do PostgreSQL and Oracle. The Bindbackend implements
+requirement, as do PostgreSQL and Oracle. The BIND backend implements
transaction semantics by renaming files if and only if they have been
retrieved completely and parsed correctly.
configure the ``host`` setting of the first or main instance, and
``gmysql-server2-host`` for the second one.
-Running multiple instances of the bind backend is not allowed.
+Running multiple instances of the BIND backend is not allowed.
.. _setting-load-modules:
projects / thirdparty / pdns.git / commitdiff
