dyndb.xml revision 14a656f94b1fd0ababd84a772228dfa52276ba15
<!--
- Copyright (C) 2015 Internet Systems Consortium, Inc. ("ISC")
-
- purpose with or without fee is hereby granted, provided that the above
- copyright notice and this permission notice appear in all copies.
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- Converted by db4-upgrade version 1.0 -->
<section xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="dyndb-info"><info><title>DynDB (Dynamic Database)</title></info>
<para>
DynDB is an extension to BIND 9 which, like DLZ
(see <xref linkend="dlz-info"/>), allows zone data to be
retrieved from an external database. Unlike DLZ, a DynDB module
provides a full-featured BIND zone database interface. Where
DLZ translates DNS queries into real-time database lookups,
resulting in relatively poor query performance, and is unable
to handle DNSSEC-signed data due to its limited API, a DynDB
module can pre-load an in-memory database from the external
data source, providing the same performance and functionality
as zones served natively by BIND.
</para>
<para>
A DynDB module supporting LDAP has been created by Red Hat
and is available from
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://fedorahosted.org/bind-dyndb-ldap/">https://fedorahosted.org/bind-dyndb-ldap/</link>.
</para>
<para>
A sample DynDB module for testing and developer guidance
is included with the BIND source code, in the directory
</para>
<section><info><title>Configuring DynDB</title></info>
<para>
A DynDB database is configured with a <command>dyndb</command>
</para>
<screen>
dyndb example "driver.so" {
<replaceable>parameters</replaceable>
};
</screen>
<para>
implements the full DNS database API. Multiple
<command>dyndb</command> statements can be specified, to load
different drivers or multiple instances of the same driver.
Zones provided by a DynDB module are added to the view's zone
table, and are treated as normal authoritative zones when BIND
is responding to queries. Zone configuration is handled internally
by the DynDB module.
</para>
<para>
The <replaceable>parameters</replaceable> are passed as an opaque
string to the DynDB module's initialization routine. Configuration
syntax will differ depending on the driver.
</para>
</section>
<section><info><title>Sample DynDB Module</title></info>
<para>
For guidance in implementation of DynDB modules, the directory
contains a basic DynDB module.
The example sets up two zones, whose names are passed
to the module as arguments in the <command>dyndb</command>
statement:
</para>
<screen>
dyndb sample "sample.so" { example.nil. arpa. };
</screen>
<para>
In the above example, the module is configured to create a zone
"example.nil", which can answer queries and AXFR requests, and
accept DDNS updates. At runtime, prior to any updates, the zone
contains an SOA, NS, and a single A record at the apex:
</para>
<screen>
0 28800 7200 604800 86400
)
example.nil. 86400 IN NS example.nil.
example.nil. 86400 IN A 127.0.0.1
</screen>
<para>
When the zone is updated dynamically, the DynDB module will determine
whether the updated RR is an address (i.e., type A or AAAA) and if
so, it will automatically update the corresponding PTR record in a
reverse zone. (Updates are not stored permanently; all updates are
lost when the server is restarted.)
</para>
</section>
</section>