Hi,
For the first question about being practical, I took a stab at enabling
dynlib support in the existing build (diff attached in
unbound-dynlib.debdiff). Because of the split unbound library and
unbound daemon build, and because building dynlib modules requires more
header files (and symbols) than just what is exported, the packaging
gets a bit messy.
The shared library can't be used (without some renaming taking place)
because it doesn't expose all of the necessary symbols; if
`--enable-allsymbols` is used for the build, then that effectively
breaks the library-only and library+daemon build, because they are
currently built with different features, which means the libraries will
have different code compiled in. This leaves using a static library.
However, the static library build from the daemon build must be used,
because otherwise one of the structures has a difference in the number
of fields (because of the different featuresets), and this would either
result in unexpected behavior or a segfault. Also, PIC would need to be
enabled for the static build.
In addition to the above, more header files from unbound would need to
be packaged. In the debdiff, I've included the header files from 3
directories that might be used for dynlib modules.
As for an example module, unbound does have an example module at
https://github.com/NLnetLabs/unbound/blob/master/dynlibmod/examples/helloworld.c.
I've attached a slightly modified version here where the include paths
are corrected. This can be compiled with `gcc -I /usr/include/unbound
-shared -Wall -Werror -fPIC -o libhelloworld.so helloworld.c -fPIC
-l:libunbound.a` after installing the build with the debdiff along with
the private-dev package.
I personally am looking at writing a Rust library (with bindgen
generating the C <-> Rust translation code) to log DNS requests into a
DB. It appears to be able to do the basics (get loaded by unbound, parse
a DNS query), so it seems to be partially working at least.