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:
>       1. Extract the domain from the query.
>       2. Call my categorization logic (via C function or subprocess).
>       3. 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

Reply via email to