Thread handling

[Hamid Maadani]

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" <each at 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 -- each at isc.org
> Internet Systems Consortium, Inc.