Dynamically Loadable Zones in BIND v9
BIND 9 Dynamically Loadable Zones implementation
Despite the advances of the Internet, management of DNS servers is still very rudimentary. DNS data continues to be stored in cryptic zone files. To make modifications to DNS data or add zones, administrators must edit the configuration files and then interrupt BIND's operation by issuing a restart, reload, or reconfig control message or command. If BIND requires many rapid zone or data modifications, it cannot perform its main function of serving DNS data because of constant interruption. This problem is exacerbated when BIND has a large amount of DNS data. Because BIND reads this data into memory, it can require huge amounts of ram, special kernel modifications, and long start or reload times.
To solve these problems, several attempts have been made to mate DNS servers with more advanced backends to provide easier management of DNS data, especially if that data is dynamic in nature. Some attempts have resulted in new implementations of DNS servers. Other attempts have led to unsupported patches to existing DNS servers. Most of these efforts have ended in proprietary, unsupported, or unstable code. This forces those who desire to mate a DNS server with another backend to start again and develop a new proprietary system.
BIND version 9 made efforts towards solving this problem by providing a database API. The idea behind this was that different database backends could be substituted for BIND's default in memory database. Additional efforts on this front yielded the SDB (Simple Database) API. This extended upon BIND's database API and converted all data into and out of BIND to ASCII text. This made the job of developing database drivers much easier because DNS data could be manipulated as text.
However, BIND 9 misses the mark and falls short in two areas. First, the supplied drivers are not production grade and should not be used in any critical system. Second, and more importantly, the current interface does not allow zone lookup. Zones must still be specified in the named.conf file, forcing the administrator to restart, reload, or reconfig the server for the changes to take effect.
BIND DLZ makes an effort to eliminate these problems and hopefully simplify DNS data management. BIND DLZ (Dynamically Loadable Zones) is built upon BIND's database API. Actually, DLZ wraps BIND's database API inside of a new API. The new API allows BIND to ask (via a DLZ driver) if a zone is contained within the database. This allows zones and the records within a zone to both be stored in a single database. When combined with a true database such as PostgreSQL or MySQL, this change has a dramatic effect on how BIND operates and how DNS data is managed.
Because all zone and zone records are stored in a database system, cryptic zone files are no longer needed. Adding or removing zones from BIND does not require interrupting its operation; just add or remove a row in the database. BIND's memory requirements are minimized, as is the time required to for it to start.
Unfortunately, DLZ is not a panacea for DNS data management. Because of BIND's internal design, DLZ has some serious limitations. At this time, BIND DLZ can support standard name resolution queries and zone transfers (AXFR). It cannot support incremental zone transfer (IXFR) or dynamic DNS updates as specified in RFC 2136. However, DLZ does not impede any of BIND's original functionality when using "standard" zone files. Standard zone files can be used for zones requiring incremental transfers or RFC 2136 dynamic updates alongside zones using DLZ. DLZ operates in a similar manner to BIND's existing interface. It has functions to load and unload itself and provides the new functions findzone() and allowzonexfr(). These new functions are responsible for querying the external database driver about the zones that it supports. Drivers that implement the DLZ interface must also implement BIND's existing database interface so that findzone() and allowzonexfr() can return a pointer to it.
For basic queries, BIND uses findzone(). This function returns false to indicate that a zone is not contained in the database. If the zone is found in the database, findzone() returns true and passes back a database pointer. From that point on, BIND operates as normal. For zone transfers, BIND uses allowzonexfr(). This also returns false to indicate that a zone is not contained in the database. It returns true and a database pointer if the zone is found and the client requesting the zone transfer is authorized to perform the operation. If the zone is found but the client is not authorized, it returns an error indicating permission is denied.
The diagram below shows BIND (Named) with the DLZ API. Connected to it is the SDLZ API. The SDLZ is similar in purpose to BIND's SDB API. It acts as a "driver filter" and converts all data to and from ASCII text for use by the "real" drivers. The SDLZ also implements a BIND database driver. This is the database driver returned by the DLZ when BIND needs to communicate with an SDLZ driver. Below that are the individual drivers for different types of databases. Each of these drivers makes use of the SDLZ API for communication with BIND. Everything inside of the large "BIND 9 (Named)" box is compiled into BIND as one executable.
enlarges to 52kB
A wide variety of database drivers could be developed. A production grade PostgreSQL driver had been developed. Other drivers for MySQL, LDAP, ODBC and Berkeley DB may be developed soon. Be sure to check the BIND DLZ website (http://bind-dlz.sourceforge.net") for the latest information and drivers.
In order to avoid the fate of becoming another proprietary or unsupported patch, DLZ has been developed while attempting to adhere to the BIND development standard. Ideally, DLZ and its drivers will be incorporated into BIND's standard release, making them available immediately without additional effort. Members of the ISC responsible for BIND have already been contacted about this project.
This project has been made possible through the kind sponsorship of Stichting NLnet. For more information on NLnet, visit http://www.nlnet.nl. If you would like to use or try BIND DLZ, it can be found at http://bind-dlz.sourceforge.net. BIND 9 can be obtained from the ISC (Internet Software Consortium) at http://www.isc.org/products/BIND.
About the author
Rob works as an application developer at a large health care company in the United States. His focus there is primarily on J2EE web applications and minor *nix administration. Previously, Rob has contributed the NT Backhand Broadcaster to the Backhand project. The Backhand project facilitates the distribution of web requests to a cluster of web servers based upon the current load of each server. More information can be found about the backhand project at http://www.backhand.org