On 11/05/2015 04:32 PM, Mark Andrews wrote: > RPZ zones are hooked deeper into the view than just a single > attachment point. There is lots of auxillary data that needs to > be built and maintained at the view level with back references. > Sharing this is hard and has not been done.
So, I gather that this isn't on the roadmap for 9.11.x, either?
I know next-to-nothing about BIND internals, so the next several
paragraphs might describe things that are *obviously* unworkable and/or
silly. :(
Is a big chunk of the complexity wrapped up in the fact that you can
-IIRC- use the policy parameter for the zone statement in the
response-policy section in a view to alter the behavior of the RPZ zone?
If it *is*, would a reduced complexity version that allows in-view RPZ
zones (let's call these "back-references") with the following
constraints be easy to do?
* Updates for the RPZ zone that come in from a client in the view that
uses the back-reference are rejected. Updates may only happen from
clients that are come in from the view that contains the
forward-declared RPZ zone. (The more I think about it, the less sure I
am that this constraint is needed. I'm not at all sure how matching a
client to a view for dynamic updates works. From your third paragraph,
it sounds like update requests & etc. that come in through a view with a
back-reference are -effectively- passed through to the forward-declared
zone in the original view.)
* Views that contain back-references to an RPZ zone may *not* have a
response-policy section that references that RPZ zone (so that they
can't override RPZ policy for that zone). To use a forward-declared RPZ
zone, you treat it like any other zone:
zone "rpz" { in-view "zone-defs"; };
and you have to live with the policies configured for that zone in the
forward-declared view.
(As an aside, is saying "RPZ Zone" like saying "ATM Machine"? If it is,
I'm terribly sorry for breathing life into this horror.)
>> Unrelated to all that, remember how we can have RPZ master zones in
>> different views that share the same writeable file?
>
> No, they can't share the same writeable file. They can share a
> read only file.
Both named-checkconf and BIND *currently* allow master RPZ zones to
share a writable file. :-) However, this *doesn't* mean that it's *at
all* a good idea (or even intended behavior). I *expect* that dynamic
updates to the file will suffer from the same view propagation (and
potential corruption) problems that drove me to change my
nearly-identical (and equally incorrect) setup for *normal* zone sharing
between views to the one that I currently use that uses forward-declared
zones with back-references to the same.
For now, I'll just stop the server and hand-edit the RPZ zones on the
off-chance that they ever need updating.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
