1 .. Copyright (C) Internet Systems Consortium, Inc. ("ISC") 2 .. 3 .. SPDX-License-Identifier: MPL-2.0 4 .. 5 .. This Source Code Form is subject to the terms of the Mozilla Public 6 .. License, v. 2.0. If a copy of the MPL was not distributed with this 7 .. file, you can obtain one at https://mozilla.org/MPL/2.0/. 8 .. 9 .. See the COPYRIGHT file distributed with this work for additional 10 .. information regarding copyright ownership. 11 12 .. _dyndb-info: 13 14 Dynamic Database (DynDB) 15 ------------------------ 16 17 Dynamic Database, or DynDB, is an extension to BIND 9 which, like DLZ (see 18 :ref:`dlz-info`), allows zone data to be retrieved from an external 19 database. Unlike DLZ, a DynDB module provides a full-featured BIND zone 20 database interface. Where DLZ translates DNS queries into real-time 21 database lookups, resulting in relatively poor query performance, and is 22 unable to handle DNSSEC-signed data due to its limited API, a DynDB 23 module can pre-load an in-memory database from the external data source, 24 providing the same performance and functionality as zones served 25 natively by BIND. 26 27 A DynDB module supporting LDAP has been created by Red Hat and is 28 available from https://pagure.io/bind-dyndb-ldap. 29 30 A sample DynDB module for testing and developer guidance is included 31 with the BIND source code, in the directory 32 ``bin/tests/system/dyndb/driver``. 33 34 Configuring DynDB 35 ~~~~~~~~~~~~~~~~~ 36 .. namedconf:statement:: dyndb 37 :tags: zone 38 :short: Configures a DynDB database in :iscman:`named.conf`. 39 40 A DynDB database is configured with a :any:`dyndb` statement in 41 :iscman:`named.conf`: 42 43 :: 44 45 dyndb example "driver.so" { 46 parameters 47 }; 48 49 50 The file ``driver.so`` is a DynDB module which implements the full DNS 51 database API. Multiple :any:`dyndb` statements can be specified, to load 52 different drivers or multiple instances of the same driver. Zones 53 provided by a DynDB module are added to the view's zone table, and are 54 treated as normal authoritative zones when BIND responds to 55 queries. Zone configuration is handled internally by the DynDB module. 56 57 The parameters are passed as an opaque string to the DynDB module's 58 initialization routine. Configuration syntax differs depending on 59 the driver. 60 61 Sample DynDB Module 62 ~~~~~~~~~~~~~~~~~~~ 63 64 For guidance in the implementation of DynDB modules, the directory 65 ``bin/tests/system/dyndb/driver`` contains a basic DynDB module. The 66 example sets up two zones, whose names are passed to the module as 67 arguments in the :any:`dyndb` statement: 68 69 :: 70 71 dyndb sample "sample.so" { example.nil. arpa. }; 72 73 74 In the above example, the module is configured to create a zone, 75 "example.nil", which can answer queries and AXFR requests and accept 76 DDNS updates. At runtime, prior to any updates, the zone contains an 77 SOA, NS, and a single A record at the apex: 78 79 :: 80 81 example.nil. 86400 IN SOA example.nil. example.nil. ( 82 0 28800 7200 604800 86400 83 ) 84 example.nil. 86400 IN NS example.nil. 85 example.nil. 86400 IN A 127.0.0.1 86 87 88 When the zone is updated dynamically, the DynDB module determines 89 whether the updated RR is an address (i.e., type A or AAAA); if so, 90 it automatically updates the corresponding PTR record in a reverse 91 zone. Note that updates are not stored permanently; all updates are lost when the 92 server is restarted. 93
Indexes created Tue Mar 03 05:31:39 UTC 2026