More On Split Horizon & Slaves
Tim Daneliuk
tundra at tundraware.com
Sat Aug 22 14:53:31 UTC 2015
I am still working through how to get this working but a little further
steering would be helpful.
I have a situation with a single domain "foo.com" That has both public
facing and NATed internal addresses. That is, regardless of whether the
host IP is visible in the outside world or not, its canonical
name is, host.foo.com
Split horizon is set up on the master so that there is a database
for each view:
db.foo.external - Defines SOA, nameservers, public hosts, SPF, MX and
so on for foo.com
db.foo.com.internal - This file begins with:
$INCLUDE master/db.foo.external
Following this are all the host assignments
for hosts on the non-routable (NATing)
network.
This works just fine and protects the internal namespace from the
public internet.
At the moment, there are two nameservers, each running as masters with
this configuration. What I want to do is convert them to a master and
slave instances, so only the master needs to be edited when changes are needed.
And ... that's where the wheels fall off. The slave setup does work,
but no matter how I configure it, when a lookup takes place on the slave,
it leaks host assignments from the private view. The relevant slave
configuration looks like this:
view "internal" {
match-clients { trustedhosts; };
zone "foo.com" { type slave; file "slave/db.foo.internal"; masters {1.2.3.4; }; };
zone "0.168.192.in-addr.arpa" { type slave; file "slave/db.192.168.0"; masters {1.2.3.4; }; };
};
view "external" {
match-clients { any; };
zone "foo.com" { type slave; file "slave/db.foo.external"; masters {1.2.3.4; }; };
};
My sense is that I need to split the internal and external host assignments on the master differently,
so that the slave knows which view is which, but I am not clear on how to do this when both views
are in the same namespace.
Any help would be appreciated ...
More information about the bind-users
mailing list