Modules to become dynamically loadable modules?

[Yorgos Thessalonikefs]

Hi Petr!

Two separate things, building the library and modules.

For your specific case, couldn't you build Unbound two times?
One with all the configured modules you want and install the daemon from 
that build?

The other configured with --with-libunbound-only and install a probably 
vanilla, no extra configured modules only library to be used by other 
programs?

As for the modules, the modularity is there for the developer and user 
to be able to easily try new/extra features without polluting the main 
logic of other features/functionality. This is how it started.
Then the Python module made it possible to have your own Python logic 
attached into Unbound. And the dynlibmod came after that as providing 
the same black box functionality without having to rely on Python.

The main reason for not having runtime loadable modules is that it was 
not designed for that in the first place. It could be done but I believe 
yours is the first request that at least I know of.
People could argue that this behaviour does not sound secure and they 
would rather have the functionality compiled in the code.
I was told that there was such an argument way back for NSD.
I mean for core modules; dynlibmod for other stuff is something that you 
need to explicitly configure/consent so that's on the user to decide.

As for configuration of dynamically loaded modules, it can already 
happen if desired during initialization of the module (i.e., read your 
own configuration from a source) but not as part of Unbound's config file.

Best regards,
-- Yorgos

On 09/07/2024 13:02, Petr Menšík via Unbound-users wrote:
> Hello unbound users!
> 
> I have been digging around existing modules for unbound. There are some 
> quite nice, dnstap module for example. We package unbound for fedora and 
> rhel, but do not build alternative modules like redis, ipset or dnscrypt.
> 
> Main reason for it is dependencies dragged into libunbound.so. Because 
> our packaging would drag more unnecessary dependencies with each 
> depending application, gnutls-dane for example. The more we enable 
> during build, the more would get linked into libunbound. Which is quite 
> nice library for general DNS resolution and I would recommend it for 
> more complex resolution. But external module dependencies would make 
> every application using it require more packages.
> 
> I know most people does not need those modules. And they are made as 
> modules separate already, but not as loadable code. Of course problem is 
> they often have non-trivial configuration parts.
> 
> But unbound already supports dynlibmod, which kind of prepares loading 
> of external code. Could it be expanded a bit more to provide also 
> configuration snippets and known loadable modules?
> 
> Our unbound-libs package now depends on libprotobuf-c.so.1, among 
> others. Because we wanted dnstap. I think for general distributions, 
> this approach does not scale well. Ideally I would have unbound-dnstap 
> subpackage, which would only depend on protobuf-c. Another 
> unbound-redis, unbound-ipset, etc. But basic daemon would not link to 
> external libraries, only crypto libraries.
> 
> Is there specific reason, why loadable module cannot be dlopened only 
> when cachedb module is specified? Similar with any interesting features, 
> which are less common and have external library dependencies? dynlibmod 
> seems capable of such thing, but would make modules configuration look 
> weird. Especially when cachedb requires own section in configuration. 
> dynlibmod does not seem to support additional configuration processed in 
> module.
> 
> I expect those questions have already appeared. Were there any reasons 
> why modules are not (yet?) separate loadable code, but linked into main 
> library? Are there some blockers, why it should not be made such way?
> 
> Regards,
> Petr
>