From: Gert van Dijk Date: Sun, 31 Mar 2019 17:35:10 +0000 (+0200) Subject: docs: Consistent naming/casing of the BIND (backend) X-Git-Tag: rec-4.2.0-rc1~45^2~16 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=efdd3d7cefc4d87952040bd2c73ab233f50dcecc;p=thirdparty%2Fpdns.git docs: Consistent naming/casing of the BIND (backend) Skipped some occurrences where it refers to PR titles or commit messages. --- diff --git a/docs/appendices/backend-writers-guide.rst b/docs/appendices/backend-writers-guide.rst index d47a35dc18..9a8d9b8f6e 100644 --- a/docs/appendices/backend-writers-guide.rst +++ b/docs/appendices/backend-writers-guide.rst @@ -462,7 +462,7 @@ available. The exact definitions: 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 diff --git a/docs/backends/bind.rst b/docs/backends/bind.rst index b8b8c73eb1..c2e517fc3e 100644 --- a/docs/backends/bind.rst +++ b/docs/backends/bind.rst @@ -1,4 +1,4 @@ -Bind zone file backend +BIND zone file backend ====================== * Native: Yes @@ -13,11 +13,11 @@ Bind zone file backend * 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. @@ -41,9 +41,9 @@ Configuration Parameters ``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`` @@ -94,7 +94,7 @@ when loading zone files. 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 @@ -118,7 +118,7 @@ pdns\_control commands ``bind-add-zone `` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -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:: @@ -146,7 +146,7 @@ Reloads a zone from disk NOW, reporting back results. ``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. @@ -162,7 +162,7 @@ query for them. 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 @@ -175,7 +175,7 @@ Master ~~~~~~ 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. @@ -186,7 +186,7 @@ notifications however. 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. diff --git a/docs/backends/ldap.rst b/docs/backends/ldap.rst index 266be52bba..dfc43d7a5d 100644 --- a/docs/backends/ldap.rst +++ b/docs/backends/ldap.rst @@ -310,7 +310,7 @@ Wildcards ^^^^^^^^^ 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. @@ -471,15 +471,15 @@ instead all zones: 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 `__, 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 `__ which @@ -519,7 +519,7 @@ Other name server ^^^^^^^^^^^^^^^^^ 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 diff --git a/docs/dnssec/modes-of-operation.rst b/docs/dnssec/modes-of-operation.rst index aa917e15e7..9e6c2e5145 100644 --- a/docs/dnssec/modes-of-operation.rst +++ b/docs/dnssec/modes-of-operation.rst @@ -168,7 +168,7 @@ The signing and hashing algorithms are described in :ref:`dnssec-online-signing` 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. @@ -189,14 +189,14 @@ Hybrid BIND-mode operation -------------------------- 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>` diff --git a/docs/index.rst b/docs/index.rst index 7ad7ee8dac..f20a956684 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -8,7 +8,7 @@ zone files or be more dynamic in nature. 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 `, :doc:`PostgreSQL `, :doc:`Oracle `) -and :doc:`Bind-zonefiles ` to :doc:`co-processes ` and :doc:`JSON API's `. +and :doc:`BIND zone files ` to :doc:`co-processes ` and :doc:`JSON API's `. Multiple backends can be enabled in the configuration by using the :ref:`setting-launch` option. Each backend can be configured separately. diff --git a/docs/manpages/pdns_control.1.rst b/docs/manpages/pdns_control.1.rst index 0bac0c9492..737c663fab 100644 --- a/docs/manpages/pdns_control.1.rst +++ b/docs/manpages/pdns_control.1.rst @@ -30,25 +30,25 @@ Commands 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 ^^^^^^^ @@ -124,7 +124,7 @@ rediscover ^^^^^^^^^^ 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 ^^^^^^ diff --git a/docs/manpages/zone2json.1.rst b/docs/manpages/zone2json.1.rst index 8748435a18..b9c9d3ff1d 100644 --- a/docs/manpages/zone2json.1.rst +++ b/docs/manpages/zone2json.1.rst @@ -9,10 +9,10 @@ Synopsis 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 @@ -21,7 +21,7 @@ Options INPUT Options ------------- ---named-conf= Read *PATH* to get the bind configuration +--named-conf= Read *PATH* to get the BIND configuration --zone= Parse only the zone file at *PATH* Conflicts with ``--named-conf`` parameter. --zone-name= When parsing a single zone without $ORIGIN statement, set *ZONE* as the zone name. diff --git a/docs/manpages/zone2ldap.1.rst b/docs/manpages/zone2ldap.1.rst index 369ab8da8a..d827dd0e08 100644 --- a/docs/manpages/zone2ldap.1.rst +++ b/docs/manpages/zone2ldap.1.rst @@ -9,7 +9,7 @@ Synopsis 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 @@ -19,7 +19,7 @@ Options --basedn= Base DN to store objects below --dnsttl Add dnsttl attribute to every entry --layout= How to arrange entries in the directory ("simple" or "tree") ---named-conf= Path to a Bind named.conf to parse +--named-conf= Path to a BIND named.conf to parse --resume Continue after errors --verbose Verbose comments on operation --zone-file= Zone file to parse diff --git a/docs/manpages/zone2sql.1.rst b/docs/manpages/zone2sql.1.rst index cdd8cf06bf..0cb1972784 100644 --- a/docs/manpages/zone2sql.1.rst +++ b/docs/manpages/zone2sql.1.rst @@ -9,10 +9,10 @@ Synopsis 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 @@ -27,7 +27,7 @@ Options INPUT Options ------------- ---named-conf= Read *PATH* to get the bind configuration +--named-conf= Read *PATH* to get the BIND configuration --zone= Parse only the zone file at *PATH* Conflicts with **--named-conf** parameter. --zone-name= When parsing a single zone without $ORIGIN statement, set *ZONE* as the zone name. diff --git a/docs/migration.rst b/docs/migration.rst index 0a81af1d51..6c6dec24eb 100644 --- a/docs/migration.rst +++ b/docs/migration.rst @@ -86,10 +86,10 @@ From zonefiles to PowerDNS 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 ` +the ``zone`` statements. See the :doc:`BIND backend ` documentation for more information. To a Generic SQL backend @@ -104,7 +104,7 @@ Using ``zone2sql`` 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``. @@ -148,7 +148,7 @@ Syntax: ``pdnsutil b2b-migrate OLD NEW`` 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 diff --git a/docs/modes-of-operation.rst b/docs/modes-of-operation.rst index d8d79aef55..9025d275c3 100644 --- a/docs/modes-of-operation.rst +++ b/docs/modes-of-operation.rst @@ -132,7 +132,7 @@ updated and if so, retransfering it. 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. diff --git a/docs/settings.rst b/docs/settings.rst index ec2a930f51..5547221754 100644 --- a/docs/settings.rst +++ b/docs/settings.rst @@ -701,7 +701,7 @@ configuration item names change: e.g. ``gmysql-host`` is available to 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: