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.
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.
0