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

[Lannar Dean via bind-users]

I know this is an incredibly old thread, but I was wondering if there has been 
any progress on this topic within the last 8 years. 

I am attempting to use views to offer different configurations of RPZ filtering 
to different subsets of the user population.  My original approach was having 
multiple named processes running on different ports, with PF redirecting port 
53 to the appropriate port based on the user's source IP. 

Some of my RPZ zones are quite large, and if the same zone records exist for 
multiple configurations, this means loading a lot of the same data into 
multiple processes, resulting in long startup times and very high memory 
utilization.  So I wanted to use views to reduce named to a single process, and 
define RPZ zones that can be shared among multiple views using the "in-view" 
config.

I'm using a config like the following:

view Child {
  match-clients { Child; };
  allow-recursion { any; };
  response-policy { zone "cf1"; zone "cf2"; };
  zone "cf1" {
  type master;
  file "cf1";
  };
  zone "cf2" {
  type master;
  file "cf2";
  };
};

view Teen {
  match-clients { Teen; };
  allow-recursion { any; };
  response-policy { zone "cf1"; };
  zone "cf1" {
in-view Child;
  };
};

Since the rpz for cf1 is large, I want to only have to load/keep a single copy 
of it in memory and reference it from both the Child and Teen views.  However 
the above configuration gives me the error:
response-policy zone 'cf1' for view B is not a master or slave zone

If I add "type master;" to the cf1 zone in view B, I get
zone 'cf1': 'in-view' used with incompatible zone options

So it appears my goal is still not achievable, unless I'm missing something.  
Is there some other mechanism to achieve this end result (sharing zones between 
different user populations without loading multiple copies of the zone into 
memory)?

I am currently running BIND 9.16.44 by the way.

Thanks for any advice!
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Jose Alonso Hernandez]

Hi Kenneth

I'm also struggling with the in-view clause and RPZ zones at this moment,
documentation says that the in-view clause can't be used in policy zones,
and I really don't know why is that programmed that way, it shouldn't
matter if it t's a regular zone or a rpz zone.

I'm using the 9.10.3 version, which it's the latest version, maybe can
anyone give us a hint on how to change this directly on source code ?

Regards


On Thu, Nov 5, 2015 at 5:00 PM, Kenneth Lakin 
wrote:

> 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?
>
>
> ___
> 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
>



-- 
*José Alonso Hernández*
*CEO*


  



*+52 656 135 3846 **| * jah@ignis.software |  Ciudad Juárez, Chihuahua,
México |

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Company Name is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
___
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

Re: 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]

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.9000...@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: 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

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?



signature.asc
Description: OpenPGP digital signature
___
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

Re: 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 05:56 PM, Mark Andrews wrote:
> 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.

Oh! Thanks for the clarification!




signature.asc
Description: OpenPGP digital signature
___
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

Re: 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.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

Re: 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.



signature.asc
Description: OpenPGP digital signature
___
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