BIND-9.10.2-P4: Cannot use in-view to refer to RPZ zone definitions: "'$RPZ_ZONE' is not a master or slave zone"

[Mark Andrews]

In message <563C015C.1020102 at 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: marka at isc.org