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-f...@uiowa.edu, phone: 319-335-5555
_______________________________________________
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
