Authority and forwarding, but not recursion/iteration

[Marki]

On 3/9/2021 10:21 PM, Tony Finch wrote:
> Marki <bind-users at lists.roth.lu> wrote:
>> I'm not sure about the flexibility of RPZ; it doesn't seem that I can
>> have rules like "client 1.2.3.4 is allowed to look up example.com but
>> client 1.2.3.5 is not".
> You can have multiple response-policy zones, which are matched in the
> order they are listed in the configuration. You could perhaps have a zone
> listed early that uses RPZ-CLIENT-IP triggers and a PASSTHRU policy for
> non-sandboxed clients, then have a zone containing QNAME triggers (with
> liberal use of wildcards) and PASSTHRU policy (again) for just the
> permitted internal names, and finally a catch-all zone (wildcard to match
> any qname) with an NXDOMAIN policy to deny external names for sandboxed
> clients. (You can equally well combine the first two into a single zone,
> depending on whether you want more single-purpose RPZs or fewer
> multi-purpose ones.)

Probably the setup would be more straightforward if there was a view for 
sandboxed clients and one or more views for those that are not.

Concerning the non-sandboxed (or less-sandboxed view), I still fail to 
see how RPZ would allow me to define conditionals like "Host 1.2.3.4 is 
allowed to resolve example.com" (and nothing else). AFAICS you can 
either trigger on the client ip and allow (or deny) all names, or 
trigger on the name to be resolved and allow (or deny) for all clients, 
but not a combination thereof. You could create a view that matches 
1.2.3.4 and include an RPZ that allows to use example.com. But if you 
need granular filtering, that could become a lot of views...

Marki