In message <563c015c.1020...@gmail.com>, Kenneth Lakin writes:
>
> 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?
Not at the moment.
> 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?
> >=20
> > 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.
[rock:~/git/bind9] marka% /usr/local/sbin/named-checkconf xxx.conf
xxx.conf:2: writeable file 'x': already in use: xxx.conf:1
[rock:~/git/bind9] marka% cat xxx.conf
view a { zone example { type master; file "x"; allow-update { any; }; }; };
view b { zone example { type master; file "x"; allow-update { any; }; }; };
[rock:~/git/bind9] marka%
If you remove the "allow-update { any; };" named doesn't treat the
file as writeable. It's not file permissions. It's whether named
will potentially update the file itself or not.
> For now, I'll just stop the server and hand-edit the RPZ zones on the
> off-chance that they ever need updating.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
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
