DLZ modules

[Josef Moellers]

'morning Evan and the rest of the world,

On 21.01.22 00:06, Evan Hunt wrote:
> 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.

OK, understood so far.

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

I'm sorry, but I was unable to find anything wrt building the modules
Currently we have "--with-dlz-mysql" and "--with-dlz-ldap", so I would,
at the least, need "dlz_mysql_dynamic.so" and "dlz_ldap_dynamic.so" to
provide the same functionality as before. I have searched the configure
script but have found no way to select which dynamic module to build (or
build ALL modules, which would be fine with me) and the build log does
not show them to be built and on a test VM, where I run the tests prior
to releasing new versions, no "dlz_XXX_dynmic.so" file was found after
make-ing the binaries.

The README that you mention just shows how to set up the database and
the named.conf contains the directives to use the database but that
would be moot if the dynamic module wasn't build (and subsequently
packaged) in the first place.

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

As I wrote: I'm all in for dynamic extensions, so you have my full
support ;-) Therefore I do think that it would be A Good Thing (TM) to
enable this feature and build a set of driver modules if only I knew how.
NB And, no, I, too, don't know if anyone has ever used the database
drivers (mysql and ldap in our case).

Josef
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev