Disabling RPZ for a few clients / views sharing zones

[Chuck Anderson]

What is the best way to disable RPZ for a few clients (without forcing
those clients to use different DNS server IPs)? I think I could
create a new view that has all the same zones and zone contents except
for the RPZ one. If I go this route, is it still required to set up
per-view IP aliases on the master and slaves so that NOTIFY and
transfers work properly? All of my client-facing DNS servers are
secondaries with a shadow master. I was kinda hoping that newer
versions of BIND could share zones (with identical zone contents)
between views without requiring the messy multiple IP alias setup.

Thanks.

[Doug Barton]

On 02/06/2014 06:27 AM, Chuck Anderson wrote:
> I was kinda hoping that newer
> versions of BIND could share zones (with identical zone contents)
> between views without requiring the messy multiple IP alias setup.

You have always been able to do this with include files.

hth,

Doug

[Chuck Anderson]

I'm not sure how this helps. If you do this:

named.conf:

view "no-rpz" {
match-clients { 192.168.1.1; };

zone "example.com" {
type slave;
file "/var/named/slaves/example.com.zone";
masters { 10.0.0.1; };
};
};

view "global" {
match-clients { any; };
response-policy { zone "rpzip.example.com"; };

zone "rpzip.example.com" {
type slave;
file "/var/named/slaves/rpzip.example.com.zone";
masters { 10.0.0.2; };
};

zone "example.com" {
type slave;
file "/var/named/slaves/example.com.zone";
masters { 10.0.0.1; };
};
};

Then the "global" view sees updates to example.com quickly, as soon as
NOTIFY is sent by the master and the zone is transferred. However,
the "no-rpz" view doesn't see changes to example.com in a timely
manner. I've had to wait awhile (SOA refresh) for new records to
appear and old records to disappear from the "no-rpz" view's
example.com zone.

I don't see how changing it to use includes helps the matter any:

named.conf.example.com:

zone "example.com" {
type slave;
file "/var/named/slaves/example.com.zone";
masters { 10.0.0.1; };
};


named.conf:

view "no-rpz" {
match-clients { 192.168.1.1; };

include "named.conf.example.com";
};

view "global" {
match-clients { any; };
response-policy { zone "rpzip.example.com"; };

zone "rpzip.example.com" {
type slave;
file "/var/named/slaves/rpzip.example.com.zone";
masters { 10.0.0.2; };
};

include "named.conf.example.com";
};

Maybe I'm missing something.

[Evan Hunt]

On Thu, Feb 06, 2014 at 03:10:03PM -0500, Chuck Anderson wrote:
> > You have always been able to do this with include files.
>
> I'm not sure how this helps. If you do this:
>

> Then the "global" view sees updates to example.com quickly, as soon as
> NOTIFY is sent by the master and the zone is transferred. However,
> the "no-rpz" view doesn't see changes to example.com in a timely
> manner. I've had to wait awhile (SOA refresh) for new records to
> appear and old records to disappear from the "no-rpz" view's
> example.com zone.

You can have one view send a NOTIFY to the other view using
TSIG; there's a recipe for this in the bind9 FAQ.

Also, in the upcoming BIND 9.10, a single zone object can be
shared between two views:

view us {
match-clients { localnets; };
zone "example.com" {
type slave;
masters { ... };
};
};

view them {
zone "example.com" {
in-view us;
};
};

--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.

[Jay Ford]

On Thu, 6 Feb 2014, Chuck Anderson wrote:
> On Thu, Feb 06, 2014 at 09:50:26AM -0800, Doug Barton wrote:
>> On 02/06/2014 06:27 AM, Chuck Anderson wrote:
>>> I was kinda hoping that newer
>>> versions of BIND could share zones (with identical zone contents)
>>> between views without requiring the messy multiple IP alias setup.

Evan Hunt just replied, but I already this typed so....

I think that's coming in 9.10, which is in alpha now.

>> You have always been able to do this with include files.
>
> I'm not sure how this helps. If you do this:
>

> named.conf:
>
> view "no-rpz" {
> match-clients { 192.168.1.1; };
>
> zone "example.com" {
> type slave;
> file "/var/named/slaves/example.com.zone";
> masters { 10.0.0.1; };
> };
> };
>
> view "global" {
> match-clients { any; };
> response-policy { zone "rpzip.example.com"; };
>
> zone "rpzip.example.com" {
> type slave;
> file "/var/named/slaves/rpzip.example.com.zone";
> masters { 10.0.0.2; };
> };
>
> zone "example.com" {
> type slave;
> file "/var/named/slaves/example.com.zone";
> masters { 10.0.0.1; };
> };
> };
>

> Then the "global" view sees updates to example.com quickly, as soon as
> NOTIFY is sent by the master and the zone is transferred. However,
> the "no-rpz" view doesn't see changes to example.com in a timely
> manner. I've had to wait awhile (SOA refresh) for new records to
> appear and old records to disappear from the "no-rpz" view's
> example.com zone.

I like the "trick" of having view A pull the zone from the real master &
notify view B, while view B pulls the zone locally from view A, using TSIG
keys to indicate the "other" view for the notify & transfer.

Adapting your config, using IPv6 loopback addresses, something like this
might work for you:

key be-internal.keys.example.com. {
algorithm hmac-md5;
secret "...secret stuff...";
};

view "no-rpz" {
match-clients {
192.168.1.1;
key "be-internal.keys.example.com.";

};

zone "example.com" {
type slave;
file "/var/named/slaves/example.com.zone";

masters { ::1; };
allow-notify { "localhost"; };
};
};

view "global" {
match-clients { any; };

// define self as server using "be-internal" key to allow
// external->internal notify for common zones mastered by
// servers unaware of our view games
server ::1 { keys "intra-dns-be-internal.keys.uiowa.edu."; };

response-policy { zone "rpzip.example.com"; };

zone "rpzip.example.com" {
type slave;
file "/var/named/slaves/rpzip.example.com.zone";
masters { 10.0.0.2; };
};

zone "example.com" {
type slave;
file "/var/named/slaves/example.com.zone";
masters { 10.0.0.1; };

also-notify { ::1; }; // internal->external trickery
};
};

The relatively new ability to specify a key in a "masters" statement can
also be useful, but isn't required for the above example.

Evaluate it for use in your context. I don't know how/if this interacts with
RPZ. It also assumes you don't do anything else with DNS via loopback
addresses. ...

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-...@uiowa.edu, phone: 319-335-5555

[Chuck Anderson]

On Thu, Feb 06, 2014 at 02:49:03PM -0600, Jay Ford wrote:
> I like the "trick" of having view A pull the zone from the real master &
> notify view B, while view B pulls the zone locally from view A, using TSIG
> keys to indicate the "other" view for the notify & transfer.
>
> Adapting your config, using IPv6 loopback addresses, something like this
> might work for you:

Neat. Is there any problem with using the exact same zone file in
both views? I worry that one view might fight with the file from the
other view...

Thanks!

[Jay Ford]

On Thu, 6 Feb 2014, Chuck Anderson wrote:

> Neat. Is there any problem with using the exact same zone file in
> both views? I worry that one view might fight with the file from the
> other view...

Oh yeah, sorry, I left that bit out. The slave files do need to be unique or
they will over-write each other. I use a directory per view to keep things
tidy.

Jay