Clients Matching Multiple Views

[Jason Brandt]

I faced a similar situation when setting up my servers.  The way I handled
it (correctly or not) was to built the zones in the internal view as
master, and then the external view slaved to the internal master.  That way
you can simply update your internals, and the external side automatically
populates.

The end result, is that you still have to define the zones in both views,
and that you still end up with multiple data files for the same zone.  But
you still only have to manage 1 set of those files, and not make the same
changes in multiple places.

This setup uses TSIG keys to do the transfers, which is handy as you need
to use TSIG keys to transfer different views to slave servers.


On Wed, Apr 9, 2014 at 9:30 AM, Steven Carr <sjcarr at gmail.com> wrote:

> On 9 April 2014 13:09, Mike Meredith <mike.meredith at port.ac.uk> wrote:
> > What I did in testing (and not very much at that) was to define the
> > zones twice with different file names. Seemed to work fine ... at least
> > the zone files and the journal files were created for both file names.
>
> BIND will allow you to configure it like that but remember clients can
> only update a _single_ view, so if you have the same zone in multiple
> views then they will quickly get out of step if they are accepting
> dynamic updates as some updates will be made in one view, others in
> the other view.
>
> So the easiest way to settle that is to have a _single_ authoritative
> source for the dynamic zone that both internal/external clients can
> update, then that zone is slaved to both the views needing to serve
> it, AKA hidden master.
>
> DNS & BIND (ISBN:9780596100575) is your friend :)
>
> Steve
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
Jason K. Brandt
Systems Administrator
Bradley University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140409/884132f9/attachment.html>