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]

Why doesn't BIND accept the in-view option for RPZ zone definitions?
named-checkconf has no problem with it, but BIND chokes on startup.

I'm running BIND 9.10.2-P4 from Gentoo Linux's net-dns/bind-9.10.2_p4
package. Has this been fixed in a later version? Am I doing something
really silly?

Details follow:

Consider the following partial config file:

acl "v1" { 10.0.0.0/24; };
acl "v2" { 10.0.1.0/24; };
acl "slave" { 192.168.1.1; };
masters "slave" { slave; };

#Forward definitions
view "zone-defs" IN {
  match-clients { slave; };
  zone "example.com" IN {
    type master;
    file "pri/example.com.zone";
    notify yes;
    also-notify { slave; };
    allow-transfer { slave; };
  };
};

view "v1" IN {
  match-clients { v1; };
  zone "example.com" IN { in-view "zone-defs"; };
};

view "v2" IN {
  match-clients { v2; };
  zone "example.com" IN { in-view "zone-defs"; };
};

Clients in views v1 and v2 can each query example.com data, and updates
to the zone work as expected.

If I add

  response-policy { zone "rpz"; };
  zone "rpz" IN {
    type master;
    file "pri/rpz.zone";
    notify yes;
    also-notify { slave; };
    allow-transfer { slave; };
  };

to view v1, RPZ works as it should. If I add the same statements to view
v2 (Notice that we now have master zones in *two* views sharing the same
writeable file! I'll come back to this in a minute.), RPZ still works as
expected. named-checkconf is happy, and BIND loads and uses the config
without issue.

So, if I attempt to forward-declare the RPZ zone by moving the "rpz"
zone definition into the "zone-defs" view, then change the "rpz" zone in
v1 and v2 like so:

  zone "rpz" IN { in-view "zone-defs"; };

I can *reload* the configuration without problem and RPZ *seems* to work
as expected. named-checkconf is *also* totally okay with the config
file. However, if I *restart* BIND, BIND fails to start and emits the
following error:

/etc/bind/named.conf:$LINE: 'rpz' is not a master or slave zone

If I leave the zone definition that now contains "in-view" in v1 and v2,
but remove the response-policy block from v1 and v2 and move it into
zone-defs, named-checkconf and BIND both accept the config file, but
-naturally- RPZ does not work for the v1 and v2 views.

Unrelated to all that, remember how we can have RPZ master zones in
different views that share the same writeable file? You *can't* do that
with RPZ slave zones. named-checkconf complains that the "writeable file
... [is] already in use". (*PLEASE*(!!!) don't fix this until we can
forward-define RPZ zones, just like we can for regular zones.)

Anyway. As I asked above: Is this fixed in a later version, or am I
-perhaps- doing something rather silly?

-------------- 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/51190c24/attachment.bin>