primary/secondary configuration

Kevin Darcy kcd at chrysler.com
Fri Oct 10 01:12:39 UTC 2008


Barbara Nowak wrote:
> Hi,
>
> I need to configure 2 nameserver but it not easy.
> Network looks like this:
>
> Public_IP1  ->Firewall/Router:DMZ -> 192.168.0.1
> Public_IP2  ->Firewall/Router:DMZ -> 192.168.0.100
>
> now I have domain DOMAIN.COM with registered Nameservers NS1 i NS2 with above Public_IP[1|2].
>
> Above Firewall/Router have 2 another networks connected to other ports: 192.168.1.x/24 and 192.168.2.x/24
>
> All networks are visible to others.
>
> Now I need configure primary nameserver. I've created 2 ZONE files for local and for public access. In named.conf simly use "views". Its seems to be easy. But how I sould configure slave nameverver to receive NOTIFY from primary for both zones (local and public) ??
> I newer did it before, so I dont know how to make above configuration on slave NS...
>   
The main challenge here is to differentiate views, so that when the 
slave gets a NOTIFY for the "local" zone it knows to do a refresh from 
the view that contains "local", and when it gets a NOTIFY for the 
"public" zone, it knows to do a refresh from the view that contains 
"public". Likewise, when a refresh is performed, the master needs to 
match the "local" refresh to the view containing "local" and the 
"public" refresh to the view containing "public".

There are two basic approaches to this.

1) You can differentiate views by TSIG key. This requires some up-front 
work in generating, installing and configuring the keys, and setting up 
the "server" statements in the respective views to enable signature 
generation and validation. Once you've invested that effort, though, it 
also enhances your security, so it's something you may wish to implement 
anyway. The big downside of this approach is that if you want to add 
*more* nameservers/resolvers to the mix, you might have to configure 
them all with TSIG keys as well, or come up with some confusing mixture 
of key- and source-address-based ACLs.

2) You can differentiate views by address. If your master and slave are 
not already configured with multiple network interfaces, you'd have to 
add more network interfaces to make this work. They can be "virtual" 
interfaces if you don't have multiple physical interfaces in each box, 
although this might complicate your network configuration. Once you have 
those interfaces, then you can use query-source, transfer-source and 
notify-source to differentiate views. E.g.

Master has addresses M1 and M2, Slave has addresses S1 and S2

Master's public view: S1 in "match-clients" and "also-notify"; 
notify-source=M1
Master's local view: S2 in "match-clients" and "also-notify; 
notify-source=M2
Slave's public view: M1 in "match-clients" and the "masters" clause; 
query-source=S1and transfer-source=S1
Slave's local view: M2 in "match-clients" and the "masters" clause; 
query-source=S2 and transfer-source=S2

Other variations of #2 are possible, e.g. using match-destinations 
instead of match-clients, etc. but I think the above formulation is the 
most straightforward.

Note that, with either solution, you'd need to set "also-notify"s to the 
private addresses if the public ones are unreachable, and, in that case, 
you'd also want to set "notify explicit" to prevent NOTIFYs from also 
being sent wastefully to those unreachable addresses.

                                                                         
                     - Kevin



More information about the bind-users mailing list