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

[Kenneth Lakin]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151105/03a41003/attachment.bin>