More On Split Horizon & Slaves

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

More On Split Horizon & Slaves

Tim Daneliuk
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 ...

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: More On Split Horizon & Slaves

/dev/rob0
On Sat, Aug 22, 2015 at 09:53:31AM -0500, Tim Daneliuk wrote:
[ Two views, one zone name, different zone contents,
  same master & slave: how to populate both views on the slave? ]

> 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.

https://kb.isc.org/article/AA-00296/0
https://kb.isc.org/article/AA-00851/0
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: More On Split Horizon & Slaves

Tim Daneliuk
On 08/22/2015 10:42 AM, /dev/rob0 wrote:

> On Sat, Aug 22, 2015 at 09:53:31AM -0500, Tim Daneliuk wrote:
> [ Two views, one zone name, different zone contents,
>   same master & slave: how to populate both views on the slave? ]
>
>> 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.
>
> https://kb.isc.org/article/AA-00296/0
> https://kb.isc.org/article/AA-00851/0
>


Aha!  The magic trick (also suggested in private email) was the use
of keys to determine which database each view used.

Many thanks - all working nicely now.

--
----------------------------------------------------------------------------
Tim Daneliuk     [hidden email]
PGP Key:         http://www.tundraware.com/PGP/

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users