On 3/9/2021 10:21 PM, Tony Finch wrote:
Marki <bind-us...@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
_______________________________________________
Please 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
