Disabling RPZ for a few clients / views sharing zones

[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-ford at uiowa.edu, phone: 319-335-5555