bind9/doc/arm/dyndb.xml

<!--
 - Copyright (C) Internet Systems Consortium, Inc. ("ISC")
 -
 - This Source Code Form is subject to the terms of the Mozilla Public
 - License, v. 2.0. If a copy of the MPL was not distributed with this
 - file, you can obtain one at https://mozilla.org/MPL/2.0/.
 -
 - See the COPYRIGHT file distributed with this work for additional
 - information regarding copyright ownership.
-->

<!-- Converted by db4-upgrade version 1.0 -->
<section xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="dyndb-info"><info><title>Dynamic Database (DynDB)</title></info>

  <para>
    Dynamic Database, or 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://pagure.io/bind-dyndb-ldap">https://pagure.io/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
    <filename>bin/tests/system/dyndb/driver</filename>.
  </para>

  <section><info><title>Configuring DynDB</title></info>

    <para>
      A DynDB database is configured with a <command>dyndb</command>
      statement in <filename>named.conf</filename>:
    </para>
    <screen>
    dyndb example "driver.so" {
        <replaceable>parameters</replaceable>
    };
    </screen>
    <para>
      The file <filename>driver.so</filename> is a DynDB module which
      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
      responds 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 differs depending on the driver.
    </para>
  </section>
  <section><info><title>Sample DynDB Module</title></info>

    <para>
      For guidance in the implementation of DynDB modules, the directory
      <filename>bin/tests/system/dyndb/driver</filename>
      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>
 example.nil.  86400    IN      SOA     example.nil. example.nil. (
                                               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 determines
      whether the updated RR is an address (i.e., type A or AAAA); if
      so, it automatically updates the corresponding PTR record in a
      reverse zone.  Note that updates are not stored permanently; all updates are
      lost when the server is restarted.
    </para>
  </section>
</section>