On Wed, Apr 28, 2010 at 10:22 AM, Joseph Heaton <[email protected]> wrote:
> ... my thinking, and the other Windows admins, is that having the
> same FQDN internally would be ok.

  I recommend strongly against creating disjoint namespaces in DNS.
Sure, it's possible, but it can create a number of IT management
headaches (see below).  Why people are so dead-set on making more work
for themselves, I have no idea.  DNS is *not* designed to work this
way.  Don't do it.

  I recommend using a subdomain of your registered domain name, like
<ad.dfg.ca.gov> or <win.dfg.ca.gov> or something.  This also has
benefits if you ever want your internal namespace to be visible to the
outside world.

  You can invent a bogus top-level domain like <dfg.ca.local>, but if
you've already got a registered domain name, I don't see the point.
It was an appropriate strategy when most SOHOs didn't have domain
names, but these days, one guy working out of a truck still registers
a 2LD.

  *  *  *

  My commentary on split DNS, from way back:

  My objection to split DNS is simple: It is one more thing to go
wrong. If I can eliminate a place for something to go wrong, I will.
And when you are claiming authority for a DNS zone you are not
delegated for (which is what split DNS is all about), there is the
potential for things to get out of sync. Sure, if you do it right,
nothing will, but *WHY* even open up the possibility, if it does not
get you *any* advantage?

At the same time, I think using a separate DNS domain name has several
advantages:

* It keeps DNS names globally unique.
* It clearly identifies internal vs external resources in their name.
* You don't have to worry about keeping two different DNS zones in sync.
* Should you decide you want to expose your private DNS to the public
for any reason, you can still do so.
* Roaming systems which are sometimes outside the private network will
never get confused over which DNS zone is currently visible.

In short, it keeps separate things separate.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to