On 2016-02-18 14:06, Mark Andrews wrote:
For some reason people are afraid to slave internal zones. Back when I was working for CSIRO I used to slave all the internal zones for all of the sites the division had. Each site administered its own zones but all sites slaved all of them. That way local and inter site lookups always succeeded even when the external links were down.
While I avidly prefer slaving internal zones, it becomes one more thing to maintain, monitor and support, and for every failure point they eliminate, the zone transfers themselves become a failure point and maintenance task.
I've had issues with Microsoft DNS in particular (when fully integrated with Active Directory) periodically losing the list of IPs allowed to request zone transfers, although I think it was Server 2008 (pre R2) when this last happened. Similarly, if you frequently add and remove zones, you've now created an extra task to add the zone to all internal resolvers, rather than just using NS records and letting DNS do what it does best and recursively resolve. This too can be automated, obviously.
The tipping point for me is that by slaving my internal zones, I can effectively do instant DNS updates during normal operations rather than having internal resolvers maintain their own cache -- This alone makes it worthwhile to slave all of my zones everywhere possible.
Still, if you're not big enough to automate everything, I can see the advantage in having your resolvers be as ignorant about internal infrastructure as possible.
-- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
