This is a discussion on Re: primary/secondary configuration - DNS ; Barbara Nowak wrote: > Hi, > > I need to configure 2 nameserver but it not easy. > Network looks like this: > > Public_IP1 ->Firewall/Router MZ -> 192.168.0.1 > Public_IP2 ->Firewall/Router MZ -> 192.168.0.100 > > now I have ...
Barbara Nowak wrote:
> I need to configure 2 nameserver but it not easy.
> Network looks like this:
> Public_IP1 ->Firewall/RouterMZ -> 192.168.0.1
> Public_IP2 ->Firewall/RouterMZ -> 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";
Master's local view: S2 in "match-clients" and "also-notify;
Slave's public view: M1 in "match-clients" and the "masters" clause;
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
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.