Forward First on Master Zone (bypass SOA)

Kevin Darcy kcd at chrysler.com
Thu Apr 4 00:30:01 UTC 2013


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



More information about the bind-users mailing list