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 marka at isc.org
Fri Nov 6 00:32:43 UTC 2015


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.

Now if someone want's to spend the time to code the necessary support
to do this ...

For normal in-view named just grabs a reference to the zone in the
second view.  All the back references in the zone are to the original
view.  Notify's etc. are all processed in the context of the original
zone even if they come in via the second zone.

In message <563BEDA4.9000109 at gmail.com>, Kenneth Lakin writes:
>
> 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?

No, they can't share the same writeable file.  They can share a
read only 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?
>
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


More information about the bind-users mailing list