diff options
Diffstat (limited to 'doc/arm/dyndb.inc.rst')
-rw-r--r-- | doc/arm/dyndb.inc.rst | 92 |
1 files changed, 92 insertions, 0 deletions
diff --git a/doc/arm/dyndb.inc.rst b/doc/arm/dyndb.inc.rst new file mode 100644 index 0000000..59ceb66 --- /dev/null +++ b/doc/arm/dyndb.inc.rst @@ -0,0 +1,92 @@ +.. Copyright (C) Internet Systems Consortium, Inc. ("ISC") +.. +.. SPDX-License-Identifier: MPL-2.0 +.. +.. 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. + +.. _dyndb-info: + +Dynamic Database (DynDB) +------------------------ + +Dynamic Database, or DynDB, is an extension to BIND 9 which, like DLZ (see +:ref:`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. + +A DynDB module supporting LDAP has been created by Red Hat and is +available from https://pagure.io/bind-dyndb-ldap. + +A sample DynDB module for testing and developer guidance is included +with the BIND source code, in the directory +``bin/tests/system/dyndb/driver``. + +Configuring DynDB +~~~~~~~~~~~~~~~~~ +.. namedconf:statement:: dyndb + :tags: zone + :short: Configures a DynDB database in :iscman:`named.conf`. + +A DynDB database is configured with a :any:`dyndb` statement in +:iscman:`named.conf`: + +:: + + dyndb example "driver.so" { + parameters + }; + + +The file ``driver.so`` is a DynDB module which implements the full DNS +database API. Multiple :any:`dyndb` 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. + +The parameters are passed as an opaque string to the DynDB module's +initialization routine. Configuration syntax differs depending on +the driver. + +Sample DynDB Module +~~~~~~~~~~~~~~~~~~~ + +For guidance in the implementation of DynDB modules, the directory +``bin/tests/system/dyndb/driver`` contains a basic DynDB module. The +example sets up two zones, whose names are passed to the module as +arguments in the :any:`dyndb` statement: + +:: + + dyndb sample "sample.so" { example.nil. arpa. }; + + +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: + +:: + + 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 + + +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. |