Project sponsored by

Project hosted on

SourceForge Logo


Performance testing results released!


See which driver is the fastest and how DLZ's performance compares with an unmodified Bind. It's all here.

New high performance driver released!


DLZ's new driver provides the best performance yet. Check out the new driver's documentation for more information.

Updated DLZ performance testing tools released!


The Performance tools have been updated to include a writer for the new BDBHPT driver.

Updated DLZ docs download available!


The DLZ documentation has been updated for the new DLZ release. DLZ documentation is now a completely separate download.

DLZ performance testing tools released!


DLZ Perf Tools provide easy to use utilities for generating large sets of randomized data - essential when evaluating the performance of your DNS server. The tool kit also provides capabilities for testing DNS server latency and DNS update latency (RFC2136 or DLZ style updates). Click here for more info.

DLZ performance testing standard data set released!


A "standard" set of DNS records for performance testing DNS servers. By providing a "standard" data set, performance results for different machines and configurations can be collected and compared. This data file can be read by the DLZ Perf Tools and output in a variety of formats.

The standard data set is available in the downloads section.

Why is DLZ needed?

The defacto standard DNS server is BIND. Despite being around for many years now and going through several revisions, BIND's basic functionality has remained the same. Unfortunately, so have some of its unfavorable attributes:

  • BIND reads DNS data from text files. It is very easy to make a mistake when editing a file causing it to be mis-read or made un-readable by BIND.
  • BIND stores all DNS data in RAM. If your DNS server is authoritative for a large number of zones, you may have to rebuild the kernel on your machine in order to support BIND's memory needs.
  • BIND parses all of its zone files at startup. For a large number of zones this can be time-consuming.
  • If you change any information in those zone files, you must reload or restart BIND before those changes take effect. Do this often enough and BIND could spend more time reloading data than answering queries.

Other DNS servers have been built over the years. Many of them are efforts to mate a DNS server with a database in order to reduce memory usage and get away from using cryptic zone files and restarting BIND. Some of these DNS servers don't seem to be available anymore, and most don't support all the resource records and capabilities of BIND. At best, these DNS servers support basic features and usually only have the ability to use one database server with a pre-defined database schema.

Another common means of maintaining zone files is to use scripts. The DNS data is stored in a database, and every so often a script is run to create the zone files. BIND is then reloaded or restarted. This solution abstracts the user away from zone files, but BIND still may require large amounts of RAM and have long reload / restart times.

You'd think with the "instant everything" world of the Internet, where everything advances at a rapid pace, this situation for DNS management wouldn't exist today. And now, with DLZ, it doesn't have to.

What is DLZ?

DLZ (Dynamically Loadable Zones) is a patch for BIND version 9 that simplifies BIND administration and reduces memory usage and startup time. DLZ allows you to store your zone data in a database. Unlike using scripts, the changes in your database are immediately reflected in BIND's response to DNS queries, so there is no need to reload or restart BIND. You see, BIND "dynamically loads" the "zone" data it needs to answer a query from the database.

DLZ is unique:

First of all, DLZ is not a DNS server. We are not reinventing the wheel here. BIND is the standard by which all other DNS servers are judged - why not improve that standard and automatically gain all of the advantages of BIND? When a feature is added to BIND, there is no need to re-implement that feature in another proprietary DNS server. DLZ becomes part of BIND and can take advantage of new features added to it. The result: no more incompatibilities between BIND and a custom DNS server created just to avoid zone files.

Flexibility was a goal from day one with DLZ. It's more than a little annoying to find a cool piece of software that can't be used without modification because it doesn't support your preferred database or your database schema. So, unlike most DNS servers, DLZ supports a wide variety of databases: PostgreSQL, MySQL, Berkeley DB, ODBC (thus Firebird, DB2, Oracle, Sybase, SAPDB) and LDAP. It can also use the hierarchal nature of a standard file system as a database. Here is the best part though: DLZ does not impose a pre-defined database schema with most databases. This means that if you already have your DNS data in a database, you should be able to get DLZ up and running with your data in your database in about an hour. DLZ also supplies an API to allow custom drivers to be developed if the existing drivers do not meet your needs.

Furthermore, DLZ does not remove or hinder any existing capabilities of BIND. You can continue to use standard zone files for some of your DNS zones and use DLZ for the others if you wish. In fact, this is required if you have a DHCP server which updates DNS.

DLZ should not be confused with dynamic DNS update, as they are not the same. The name DLZ (Dynamically Loadable Zones) was chosen because when using it, BIND does not need to load zones at startup as it normally does. Instead, BIND will ask a driver for zone and record information when needed to answer a DNS query. Thus, the zone data is "dynamically loaded" from the database as needed.