DLZ modules
Evan Hunt
each at isc.org
Thu Jan 20 23:06:58 UTC 2022
On Thu, Jan 20, 2022 at 05:26:02PM +0100, Josef Moellers wrote:
> I just updated our bind sources to 9.16.25 and stumbled across the
> deprecation warning wrt "DLZ drivers". Being a huge fan of the
> flexibility that dlopen() offers, I immediately wanted to enable the
> "DLZ modules". While I still have to find out how eaxtly I configure the
> build process to build the "dlz_*_dynamic.so", I am also slightly
> worried about this section in the ARM:
>
> <quote>
> The DLZ module provides data to ``named`` in text format, which is then
> 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 primary
> configuration, with secondaries retrieving zone updates via AXFR. Note,
> however, that DLZ has no built-in support for DNS notify; secondary
> servers are not automatically informed of changes to the zones in the
> database.
> </quote>
>
> The question is: Why are the "DLZ drivers" deprecated in favor of "DLZ
> modules" which will degrade named performance?
Drivers worked the same way and had the same performance impact. Converting
data from text to wire format takes time, and if you have to do that on
every query, it's going to slow down the server. That applies to any DLZ
back-end, not just modules.
The only difference between a DLZ "driver" and "module" is that the drivers
have to be linked to named at compile time, while modules can be built
separately and loaded at runtime.
For information and examples of how to build and use DLZ modules,
look in the 'testing' directories under the DLZ modules; for example,
contrib/dlz/modules/mysql/testing/README and /named.conf.
To answer the question of why drivers are being deprecated - we've
been planning to for years and years, so we wouldn't have to maintain
two different methods for doing the same thing. The only reasons we
hadn't gotten around to it were inertia, and one or two databases for
which drivers had been written but no one had written a module. (And
I'm not sure how many people were using those drivers, anyway.)
--
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.
More information about the bind-workers
mailing list