I've been using multiple views and servers successfully for a while now.
I hope the following helps...
To transfer zones to and from specific views, you can use keys,
"match-clients" and "server" declarations to control access and
transfers.
Setup keys for each view.
Disallow clients (and servers) without those keys in the inappropriate
views.
Allow clients (and servers) with those keys in the appropriate view.
Remember, the views are hit in top, down order. By default, your slaves
will all hit the first view. Whoever you don't want in the upper views,
you must specifically block from those views and allow them later in a
other view.
Increasing log levels and viewing logs will tell you what's going on.
Good luck,
Steve.
Assuming 192.168.100.5 is your master and 192.168.100.10 and
192.168.100.20 are your slaves:
--------------------------------------------------
On the master:
view "VIEW1" {
match-clients {
!key VIEW2; // Block VIEW2 from slave to this view
!key VIEW3; // Block VIEW3 from slave to this view
"any"; // Allow anyone else in this view
};
allow-transfer { 192.168.100.10; 192.168.100.20; };
server 192.168.100.10 {keys VIEW1; }; // first slave
server 192.168.100.20 {keys VIEW1; }; // second slave
...rest of view...
};
view "VIEW2" {
match-clients {
!key VIEW1; // Block VIEW1 from slave to this view
!key VIEW3; // Block VIEW3 from slave to this view
};
allow-transfer { 192.168.100.10; 192.168.100.20; };
server 192.168.100.10 {keys VIEW2; }; // first slave
server 192.168.100.20 {keys VIEW2; }; // second slave
...rest of view...
};
view "VIEW3" {
match-clients {
!key VIEW1; // Block VIEW1 from slave to this view
!key VIEW2; // Block VIEW2 from slave to this view
};
allow-transfer { 192.168.100.10; 192.168.100.20; };
server 192.168.100.10 {keys VIEW3; }; // first slave
server 192.168.100.20 {keys VIEW3; }; // second slave
...rest of view...
};
----------------------------------------------------------
On the slave(s):
view "VIEW1" {
match-clients {
192.168.100.0/24; // IPs you want to access this view
// Note: you must include the IP of
// the master to receive notifications.
};
server 192.168.100.5 {keys VIEW1; }; // master
...rest of view...
};
view "VIEW2" {
match-clients {
192.168.200.0/24; // IPs you want to access this view
192.168.100.5; // IP of master for notifications
};
server 192.168.100.5 {keys VIEW2; }; // master
...rest of view...
};
Etc.
---------------------------------------------------
On Tue, 2011-05-10 at 17:03 +0200, Matus UHLAR - fantomas wrote:
> > On Tue, May 10, 2011 at 2:50 PM, Luis Silva <luisfilsi...@gmail.com> wrote:
> > > Many thanks for the answer. Btw, If I want to notify the slaves that a
> > > zone
> > > is updated, which parameter (ip:port) needs to be configured in the slave
> > > to
> > > differenciate the view? Is the "transfer-source" also used for listening
> > > for
> > > the notify requests?
>
> On 10.05.11 15:39, Luis Silva wrote:
> > Let me refrase my question. How can I notify a slave that suports different
> > views for the zone? How can the master distinguish?
>
> master can not distinguish the slaves when sending notify. It can only send
> the notify to slaves... If you have multiple views on the slave containing
> the same zone, you must either give them different IP and send notify to
> both IPs or you can configure one view to fetch the zone from master and
> notify the second view, which will fetch the zone from master or the first
> view.
>
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
