Greg, not really, but unless the querying is blazingly fast, it needs to use asynchronous processing, and we don't have that now. It is not impossible to write something like this, but with no async-await mechanism in C, it might get complicated very soon. So, I would cross that bridge only if you need to - starting with blazingly fast classification would be a better option.
Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 21. 3. 2025, at 18:11, Greg Choules via bind-users > <bind-users@lists.isc.org> wrote: > > My take on this is that DNS resolver code is written to (try and) be as fast > and efficient as possible and work pretty much entirely in RAM because that's > the quickest storage available. > > Anything that interrupts that and tries to access some external database, > however it's done, is bound to slow down query processing. Think of why > resolvers cache and how much delay is introduced when they need to recurse. > > I think the data needs to be in the resolver, not external to it. Off the top > of my head, use a special zone, perhaps (in a similar way to RPZ) that is > updated dynamically by the external source of truth. That is, keep the engine > that is gathering, sorting, processing and ultimately maintaining the > database that *is* the source of truth separate from the thing that is > handling queries in real time. > > /soapbox. > Cheers, Greg > > On Fri, 21 Mar 2025 at 07:32, Mónika Kiss <kozmamonik...@gmail.com> wrote: > Hi, > Thank you again for your time. > I wanted to provide some additional context and clarify a few key aspects of > my use case: > • I already maintain a large, pre-existing file containing comprehensive > domain categorization data. > • This file is updated externally and serves as the sole source of truth > for categorization decisions. > • As such, I do not wish to store any additional data within the plugin, > memory, or any BIND-internal structures. > • Instead, I want the plugin to dynamically query this data by calling my > existing C program or SDK, which reads and evaluates domains in real time. > Desired Behavior > • On each DNS query, the plugin should: > • Extract the domain from the query. > • Call my categorization logic (via C function or subprocess). > • Based on the result: > • If High Risk: Immediately stop further resolution and return a > custom response (e.g., a custom IP address). > • Otherwise: Allow the query to continue to upstream resolvers as > normal. > • The plugin will be handling a very high volume of DNS queries, so > performance is critical. > > Best regards, > Monika > > On Thu, Mar 20, 2025 at 10:25 PM Grant Taylor via bind-users > <bind-users@lists.isc.org> wrote: > On 3/19/25 10:02 AM, Ondřej Surý wrote: > > Thinking aloud - perhaps, we can extend the plugin API (and RPZ) in a > > way to add the classification to the message processing and then the RPZ > > processing could read the classification and take an action? > > This sounds like my understanding of what the Response Policy Service > (RPS) is supposed to achieve. > > "The DNS Response Policy Service (DNSRPS) API, is a mechanism to allow > named to use an external response policy provider. This allows the same > type of policy filtering as standard RPZ, but can reduce the workload > for named, particularly when using large and frequently updated policy > zones. It also enables named to share response policy providers with > other DNS implementations such as Unbound. Thanks to Vernon Schryver > and Farsight Security for the contribution." > > Link - BIND 9.12 development is getting closer to completion! > - https://www.isc.org/blogs/bind-9-12-almost-ready/ > > I have long considered RPS for DNS to be like the milter API for email. > > > > -- > Grant. . . . > unix || die > > -- > 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 > -- > 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 > -- > 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
signature.asc
Description: Message signed with OpenPGP
-- 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
