Using DLZ in BIND

What is DLZ?

DLZ (Dynamically Loadable Zones) is a contributed extension to BIND 9 that allows zone data to be retrieved directly from an external database. There is no required format or schema. DLZ drivers exist for several different database backends including PostgreSQL, MySQL, and LDAP and can be written for any other.

As of BIND 9.8, it is also possible to link some DLZ modules dynamically at runtime via the DLZ "dlopen" driver, which acts as a generic wrapper around a shared object that implements the DLZ API. The "dlopen" driver is linked into named by default, so configure options are no longer necessary unless using older DLZ drivers.

DLZ is not recommended for use on high-query-volume servers

When the DLZ module provides data to named, it does so in text format. The response is converted to DNS wire format by named. This conversion, and the lack of any internal caching, places significant limits on the query performance of DLZ modules. Consequently, DLZ is not recommended for use on high-volume servers. However, it can be used in a hidden master configuration, with slaves retrieving zone updates via AXFR. (Note, however, that DLZ has no built-in support for DNS notify; slaves are not automatically informed of changes to the zones in the database.)

For more information on using DLZ and on creating your own drivers, please see the file ./contrib/dlz/example/README in the BIND9 tarball.

Basic DLZ Configuration

A DLZ database is configured with a dlz statement in named.conf. The example below is using dynamic linking via dlopen:

dlz example {
     database "dlopen driver.so <args>";
     search yes;
};

This specifies a DLZ module to search when answering queries; the module is implemented as driver.so and is loaded at runtime by the dlopen DLZ driver.

When answering a query, all DLZ modules with the "search" option set to "yes" will be checked for an answer, and the best available answer will be returned to the client. (The "search" option in this example can be omitted, as "yes" is the default value.) Please note, however, that multiple "dlz" statements is not available in all versions of BIND.

Using the DLZ API

Sometimes conventional zone semantics are desired, but at the same time you wish to use a different back-end storage mechanism than the standard zone database.

In that case, you would set the search to "no" so that this DLZ module is not searched for best-match when a query is received. Instead, zones in this DLZ would be separately specified in a zone statement that references the dlz rather than a traditional source such as a file.

The example below defines a DLZ named "example" that is referenced by the zone statement for example.com:

dlz example {
     database "dlopen driver.so <args>";
     search no;
};

zone "example.com" {
     type master;
     dlz example;
};

Multiple DLZ definitions

Multiple DLZ definitions was added to BIND 9.9 Subscription Version and BIND 9.10 in order to support NXDOMAIN redirection using DLZ API. For more information, see: NXDOMAIN Redirection Using DLZ in BIND 9.10.