These are perfect answers, thank you very much Evan. > All supported versions of BIND are now multi-threaded. Single-threaded > support was removed in 9.14
Since BIND is now multi-threaded only, I will stick with that model. No need to cover a single-threaded model I suppose. > It does, actually, unless you run it with -g or -f. That's how it puts > itself in the background, the function is named_os_daemonize(). Regarding the child process(es), does named create one child process, or can it be multiple processes? I assume each process loads the shared objects for itself, so only one call to dns_dlzcreate per process? > In the DLZ module, there can be an arbitrary number of separate database > handles in use, and the query can pick one that isn't busy and use it to > send the query. Regarding handling the database connections, fortunately mongo-c-driver provides a thread-safe connection pool. It does the connection monitoring and handling very well. From the sounds of it, that would fit perfectly with the BIND model. I don't think I'm gonna need to be too creative on that front :) > If no local database does and recursion is enabled, then we try the cache, > and failing that, we recurse. Question about the cache mentioned here. Can cache be configured to pull from a DLZ? As far as I know, the DynDB API is not merged to BIND's codebase yet. In the absence of that, is caching from DLZ a possible configuration on a single BIND server? Regards Hamid Maadani August 23, 2022 6:49 PM, "Evan Hunt" <e...@isc.org> wrote: > On Tue, Aug 23, 2022 at 05:59:49PM +0000, Hamid Maadani wrote: > >> I'm working on a MongoDB DLZ for bind9, and have a few questions about >> the multi-threaded version of named: 1. Is there a pre-processor flag >> I can use to determine if thread support is enabled? Can't seem to >> find it in configure.ac > > All supported versions of BIND are now multi-threaded. Single-threaded > support was removed in 9.14, and everything older is now past end of > life. > > If you're building for an older version, though, the flag is PTHREADS. > >> 2. named does not fork itself, or create child processes, correct? > > It does, actually, unless you run it with -g or -f. That's how it puts > itself in the background, the function is named_os_daemonize(). > >> 3. when multi-threading is enabled, does named still call dlz_create >> only once when loading the shared object (dlopen)? > > I believe so. That happens in dns_dlzcreate() when setting up the view > configuration, if I recall correctly, so it should only occur once in the > main thread. > >> 4. when multi-threading is enabled, how is each request handled? are >> there multiple worker threads and requests passed to them? or would >> each request spin up a new thread? Trying to figure out how dlz_lookup >> is called in a multi-threaded version. > > In named, there are multiple worker threads that handle queries. > > The first step in query processing is to identify which local database, > if any, has data responsive to the query. If no local database does and > recursion is enabled, then we try the cache, and failing that, we recurse. > But if there *is* a local database that's authoritative for the name, then > we call dns_db_findext(), which is a front-end for the 'find' function in > the database implementation (whatever it may be). If the implementation > happens to be a DLZ, then it'll be calilng findext() in lib/dns/sdlz.c, > which in turn calls getnodedata(), which calls the DLZ's 'lookup' method. > > In the DLZ module, there can be an arbitrary number of separate database > handles in use, and the query can pick one that isn't busy and use it to > send the query. > > There are existing modules in the contrib tree (for example, > contrib/dlz/modules/ldap and contrib/dlz/modules/mysql) that have > examples of this you can use as a model. > > (Should you come up with a better way to do this, I'd be happy to > see it. It's always seemed pretty clunky to me but I've never had > the necessary combination of time and brains to improve it.) > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
