in-view RPZ definitions

[Lannar Dean]

Thanks for the confirmation.

I'm going to continue to try to find alternate solutions to my problem.  I
considered trying to use a DLZ against a postgres database, which would
avoid the slow startup times, but that also would drastically reduce the
overall performance, as well as add complexity for getting this all going.
I'm also not sure if it would actually solve my problems, since I need to
provide different responses based on which view/user population the request
comes from, and it doesn't look like the client IP is made available to any
of the SQL queries that run when querying a DLZ (except for zone
transfers), so I can't easily vary the response.  I'd also entertain any
other ideas such as somehow chaining forwarders to run the request through
a few separate server processes, each of which is configured for a specific
subset of the RPZ.  I'm not sure if this approach will work, but at this
point I'm grasping at straws.

Thanks for your help

PS - sorry for the double post to the mailing list, I wasn't sure if my
last message in this thread went through.

On Sat, Nov 11, 2023 at 11:31 AM Evan Hunt <each at isc.org> wrote:

> On Fri, Nov 10, 2023 at 05:24:59PM -0500, Lannar Dean via bind-users wrote:
> > This is a continuation of a very old thread from this mailing list found
> > here:
> > https://groups.google.com/g/comp.protocols.dns.bind/c/nAHtXSDcDl4?pli=1
> >
> > It appears that what I'm attempting to do did not work at the time of
> this
> > thread 8 years ago, but I'm wondering if anything has changed by now.
>
> Many things have, but not this particular thing yet.
>
> To explain the problem, each view has an "RPZ summary database" which is
> an index of all the rules in the response-policy zones configured for that
> view. It makes it possible to determine quickly which policy zone or zones
> have matching rules for a query; that way we don't have to waste time
> trying the query against *all* of the policy zones.
>
> The summary database is populated by the policy zone when it's loaded.
> In your example, zone cf1 was in view1, so it sent its summary information
> to view1.  It doesn't know that it's also in view2.
>
> I've been thinking for a while about the best way to address this, and
> there might be some news coming in the not-too-distant future, but I don't
> have a good solution for you right now, sorry.
>
> --
> Evan Hunt -- each at isc.org
> Internet Systems Consortium, Inc.
>


-- 

<https://www.rgnets.com/>

*LANNAR DEAN*

Director of Product Engineering




<https://www.linkedin.com/company/rgnets> <https://twitter.com/rgnets>
<https://www.youtube.com/channel/UCY1FGrqtlcYQGiICvgRZ5VA>
<https://www.facebook.com/rg.nets.inc> <https://www.reddit.com/r/RGNets/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20231111/41b58d7b/attachment.htm>