Project sponsored by



Project hosted on

SourceForge Logo



BIND DLZ > FAQ's
What databases does DLZ support?

DLZ currently supports postgreSQL, MySQL, Berkeley DB, ODBC, LDAP and a "file system" database.

Because of DLZ's support for ODBC and flexible schema support, virtually any modern relational database could be used with DLZ.

The "file system" database allows the hierarchal nature of a standard file system to be used as a database for DNS data. This driver is extremely simple to set up--it is also quite performant when used with a high performance file system, like the memory file system or ReiserFS.

What database schema does DLZ require?

DLZ does not have a "required" or pre-determined database schema for its SQL drivers. DLZ was built to be flexible and to easily integrate into your current database of DNS data. DLZ's SQL drivers should be able to support almost any database schema you design. DLZ gets the data it needs from your database using SQL queries that YOU create. So, as long as you can write a SQL query to get DNS data from your database, DLZ can use your database.

If you don't have an existing database of DNS data, you can either design your own to meet your needs, or use one of the sample schemas and configurations in the examples section of this site.

The file system & LDAP database drivers are slightly less flexible. The LDAP driver should be usable with a wide variety of schemas.

The Berkeley DB driver is the most strict about its database design. The tables it uses must be defined in the format it expects. However, you are free to add more tables to the same database and use those as you wish.

Are there any sample database schemas & configurations?

Yes! Take a look at the examples section of the site. Several database schemas and configuration samples for each DLZ driver are available there.

Why doesn't DLZ driver XXX have a cache?

Because it shouldn't. The entire purpose of DLZ is to publish dynamic DNS data. By implementing a cache, you are adding a delay between the updates to the database and the time those updates are visible in DNS.

Also, there are a variety of different ways to implement a cache. Who is to say the way I implement the cache supports the features & options you need? Attempting to develop a cache with a large number of options and settings would be difficult, bug prone, and hard for end users to setup. If you cannot get the performance you need from a DLZ driver, you are using the wrong driver.

You will never get the performance from one of the SQL drivers that you will from the Berkeley DB driver. Berkeley DB is a much simpler database system, with much lower overhead than SQL databases. Also, the Berkeley DB provides a very good built in cache which the DLZ driver takes full advantage of.

You can still use an SQL database to store and manipulate your DNS data, while also taking advantage of Berkeley DB and its performance. Infact, I recommend it! Take a look at the best practices section of the site to see how.