Authority and forwarding, but not recursion/iteration

Marki bind-users at
Wed Mar 10 09:23:47 UTC 2021

On 3/9/2021 10:21 PM, Tony Finch wrote:
> Marki <bind-users at> wrote:
>> I'm not sure about the flexibility of RPZ; it doesn't seem that I can
>> have rules like "client is allowed to look up but
>> client 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 is 
allowed to resolve" (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 and include an RPZ that allows to use But if you 
need granular filtering, that could become a lot of views...


More information about the bind-users mailing list