Hi Steve,<div><br></div><div>Many thanks for the answer. Just one question, when the master sends the notification, does the slave checks all views and see if the tsig matches?</div><div><br>Br,</div><div>Ls</div><div><br>

<div class="gmail_quote">On Tue, May 10, 2011 at 8:15 PM, Steve Arntzen <span dir="ltr"><<a href="mailto:isc@arntzen.us">isc@arntzen.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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