What is dyndb and how is it better than DLZ?

Question:

What is dyndb?

Answer:

dyndb is a new plug-in interface for BIND for custom zone data providers.

Question:

Isn't there already DLZ for that?  Why should I port my provider from DLZ to dyndb?

Answer:

While both DLZ and dyndb allow for custom zone data providers, and are (or at least can be since BIND 9.8) linked into BIND as shared libraries loaded at runtime, that's about as far as the similarities go.

First, the DLZ API was designed with the assumption that all of the data providers would be databases; therefore, all of the data is passed through the API in text format to make it easier to use in SQL. This requires translating the question into text format before the DLZ call and then translating the answer out of text format to build the response to send to the client. This makes it pretty impossible to create a highly performant DLZ provider.

The dyndb API, on the other hand, is designed so that the custom provider connects into BIND using the same function interfaces that we use for our own internal databases, meaning that the API itself consumes the query data as it already exists within memory and doesn't impose any additional data translation. Similarly, the data returned by the dyndb API is already in the proper format for use in building the reply to the client (or for other internal use, as appropriate). Clearly this primarily benefits data providers that can work with those data structures directly, rather than having to translate things to and from text.

Second, the dyndb API includes additional setup calls when BIND is configuring itself. This allows the dyndb provider to, for example, pre-query the database for records and create a local in-memory cache of the data. If used properly, this can significantly improve performance immediately after starting BIND or configuring a new dyndb zone.

Finally, the limitations of the DLZ API prevented it from properly providing DNSSEC signed data, while the dyndb API has no such limitations.