On 4/2/2013 2:00 AM, Doug Barton wrote:
On 04/01/2013 11:46 AM, Kevin Darcy wrote:
On 3/29/2013 12:09 AM, Doug Barton wrote:
On 03/28/2013 12:28 PM, Ben-Eliezer, Tal (ITS) wrote:
My organization is evaluating the use of split-view DNS in our
environment.
Simple ... don't do it. It's almost never the right answer, and as
you're learning carries with it more administrative overhead than the
problems it's designed to solve.
Much better to spend the time carefully considering what your goals
are, and finding other ways to reach them.
>
And your alternative is what? Run the external version of the namespace
on a completely separate infrastructure from the internal version?
No, my point was don't do 2 versions.
Somewhere in the last 10 years (roughly corresponding to the
popularity of NAT) it became baked in to a large segment of the DNS
operator community that having internal and external views of the same
zones was not only necessary, it was the only right way to do things.
In my experience the number of times that this is the right answer are
very few and far between. Looking at the actual problems that need
solving without the prejudice that multiple views are necessary (or
even correct) often leads to better solutions.
It's still not clear to me what you think is the "right" way to do it.
Completely different namespaces for internal versus external
(external-example.com versus internal-example.com)? Carve up the
namespace at some level of the hierarchy (internal.example.com versus
external.example.com)? My users, and management, simply don't find the
infrastructure benefits of such naming conventions compelling enough,
compared to the "image" or "aesthetic" problems from which those
conventions supposedly suffer.
NAT doesn't really have any bearing on this, by the way. I realize most
folks have gone hog-wild with NAT, but fortunately we've (mostly) been
able to avoid that pitfall.
- Kevin
_______________________________________________
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
