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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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?


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users



--
José Alonso Hernández
CEO


       

  
+52 656 135 3846  [hidden email] 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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 reply to this post by Kenneth Lakin

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 <[hidden email]>, 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: [hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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.


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>, 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: [hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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!



_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (836 bytes) Download Attachment