Mailing list questions (DMARC, ARC, more?)
Hi all and list admins, I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? In that case, do they get non-munged messages? Are there other advantages that ARC brings about? Otherwise, RFC9057 introduced the Author: header field. Using it to save the original From: would allow trusting receivers to de-munge the message at a later stage. I'm trying to elaborate a draft[*] to formalize such method. Would this list be interested in experimenting that? Best Ale -- [*] https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ -- 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
Re: Mailing list questions (DMARC, ARC, more?)
Hi there, On Tue, 23 Aug 2022, Alessandro Vesely wrote: I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? When it comes to email, I don't trust *anything*. :) Generally speaking I think these technological fixes are very much over-engineered as compared with, say, inspecting the headers. :/ We check the ARC seal and I would be alerted to a failure. That's all. There have been two failures since ISC implemented ARC - the first two ARC-signed messages we received, on 25th April - all after that passed: Date: Mon, 22 Aug 2022 12:00:00 + X-ARCverify: pass (All ARC Seals and the most recent ARC Signature passed verification) There were a few DKIM failures in the early days too, I don't remember if I investigated any of the failures. In that case, do they get non-munged messages? Nope. I'm on the digest list anyway. Are there other advantages that ARC brings about? It's a comfort to know that it's all working as designed, but I can't get excited about munged addresses. I've experienced no issues on the BIND list to which I've thought ARC might be relevant. Unfortunately that's by no means the case for some of the other lists to which I am (or have in the past been) subscribed. Otherwise, RFC9057 introduced the Author: header field. Using it to save the original From: would allow trusting receivers to de-munge the message at a later stage. I'm trying to elaborate a draft[*] to formalize such method. Would this list be interested in experimenting that? I'm happy to use cut'n'paste for replies, but I can offer to help you with your testing. The milters here can do more or less anything. :) PS: Please don't be offended if mail sent directly to me is rejected. We can get around it. PPS: [Page 18] s/Content-Tyep:/Content-Type:/; -- 73, Ged. -- 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
Thread handling
Good day all, 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 2. named does not fork itself, or create child processes, correct? 3. when multi-threading is enabled, does named still call dlz_create only once when loading the shared object (dlopen)? 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. Would appreciate if someone can answer these, or point me in the right direction if this is not the appropriate forum to ask. Regards Hamid Maadani -- 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
Re: Thread handling
On Tue, Aug 23, 2022 at 05:59:49PM +, 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
Re: Thread handling
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" wrote: > On Tue, Aug 23, 2022 at 05:59:49PM +, 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
Re: Thread handling
> 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? I'm pretty sure it's called only once on startup, after daemonizing, and again whenever you reconfigure the server. (I haven't checked, but I think that's the case.) > Question about the cache mentioned here. Can cache be configured to > pull from a DLZ? No. > As far as I know, the DynDB API is not merged to BIND's codebase yet. BIND does have dyndb support, since 9.11. As far as I know, though, the only two dyndb modules in existence are the bind-dyndb-ldap modiule that was written by Red Hat as part of FreeIPA, and a toy module used for testing. If you were interested in writing your MongoDB module for dyndb instead of DLZ, I'd be quite excited about that, I've long hoped the API would get more use. > In the absence of that, is caching from DLZ a possible configuration > on a single BIND server? Not DLZ, no. And I'm not sure dyndb can be used for the cache database, either; do you know something about it that I don't? It would definitely be easier to *make* dyndb work for the cache; it has all the necessary API calls, and DLZ doesn't. But I don't know a way to configure it to take the place of the cache currently. If you do, please educate me. -- 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
