Internal (AD) vs. external (Internet) DNS namespace

[Guest]

I am planning a migration from NT 4.0 to Active Directory, and the first step
is to design the DNS namespace. There are four options. If the company has
the registered Internet domain mycompany.com, for AD you can use:

1. The same namespace as the company's registered domain, i.e mycompany.com.

2. A subdomain, e.g. corp.mycompany.com, internal.mycompany.com,
ad.mycompany.com.

3. A different registered domain, e.g. mycomp.com.

4. A fake TLD, e.g. mycompany.local, mycompany.internal


Since this is a question that anyone designing AD needs to answer before
beginning, I would have expected to find a wealth of information about it.
To my surprise and frustration, I have had a remarkably hard time finding any
good, detailed, specific analysis about the relative merits and demerits of
each option. To be sure, the topic comes up frequently in articles about AD
design and technical forums, but it seems that it is always treated very
superficially. Even Microsoft's own deployment guide doesn't go into the
topic in any depth. Most discussions either just state what the options are,
without saying a whole lot about the reasons to use or avoid each one, or
will simply say "The best practice is X" and "Y is not recommended", without
going into detail about why (and different articles/discussions contradict
each other). Whenever reasons are given, they are always very generic and
vague. I've also tried asking around, but unfortunately I've only been able
to get answers saying "Here's how I suggest that you do it" or "Here's
another possibility" or "There's more than one way to do it, you have to
choose from your options" (thanks, but that was the setup for my question,
not an answer to it). Sometimes people will answer by discussing one
particular advantage or disadvantage to one particular option, or two if I'm
lucky.

There has got to be some better information or discussion out there about
such a commonly faced topic. Can anyone provide or point me toward a source
of specific, detailed, in-depth analysis about the pros, cons, and caveats of
the different options for internal AD DNS namespace with respect to external
namespace?

 

[Herb Martin]

You really such Crosspost a single message rather than
multi-posting separate ones.

Then everyone who offers help can see the other answers,
correct and learn from them, and you will only have one
place to check for all the answers together.

 

[Guest]

You really such Crosspost a single message rather than
multi-posting separate ones.

Then everyone who offers help can see the other answers,
correct and learn from them, and you will only have one
place to check for all the answers together.

I would, if I could find a way to crosspost using Microsoft's web-based news
reader. As far as I can tell, it's not possible.

 

[Herb Martin]

I would, if I could find a way to crosspost using Microsoft's web-based news
reader. As far as I can tell, it's not possible.

That's a pretty ridiculous limitation -- excessive crossposting
is a bad thing; intelligent crossposting is a best practice.

Use Outlook Express, Google, or something like Agent.

 

[Enkidu]

I am planning a migration from NT 4.0 to Active Directory, and the first step
is to design the DNS namespace. There are four options. If the company has
the registered Internet domain mycompany.com, for AD you can use:

1. The same namespace as the company's registered domain, i.e mycompany.com.

2. A subdomain, e.g. corp.mycompany.com, internal.mycompany.com,
ad.mycompany.com.

3. A different registered domain, e.g. mycomp.com.

4. A fake TLD, e.g. mycompany.local, mycompany.internal


Since this is a question that anyone designing AD needs to answer before
beginning, I would have expected to find a wealth of information about it.
To my surprise and frustration, I have had a remarkably hard time finding any
good, detailed, specific analysis about the relative merits and demerits of
each option. To be sure, the topic comes up frequently in articles about AD
design and technical forums, but it seems that it is always treated very
superficially. Even Microsoft's own deployment guide doesn't go into the
topic in any depth. Most discussions either just state what the options are,
without saying a whole lot about the reasons to use or avoid each one, or
will simply say "The best practice is X" and "Y is not recommended", without
going into detail about why (and different articles/discussions contradict
each other). Whenever reasons are given, they are always very generic and
vague. I've also tried asking around, but unfortunately I've only been able
to get answers saying "Here's how I suggest that you do it" or "Here's
another possibility" or "There's more than one way to do it, you have to
choose from your options" (thanks, but that was the setup for my question,
not an answer to it). Sometimes people will answer by discussing one
particular advantage or disadvantage to one particular option, or two if I'm
lucky.

There has got to be some better information or discussion out there about
such a commonly faced topic. Can anyone provide or point me toward a source
of specific, detailed, in-depth analysis about the pros, cons, and caveats of
the different options for internal AD DNS namespace with respect to external
namespace?

There is no essential reason for preferring one approach
over the others, and I've used all three at various times.

Your option number 3 I discount - your internal Domain
information should *NEVER* make it to the Internet, so there
is no reason to spend the money registering a separate
Domain name for your internal network.

All the methods are better than the others in some minor way
or other. Here's some pros and cons though:

1) Same Domain name (registered) internally and externally.
The main disadvantage of this method is that if you wish
your internal clients to see an external system with your
Domain Name as part of its name (eg a Web server named
"www.mycompany.com") you will have to manually add it to the
internal DNS. The main advantage is that your non-computer
savvy staff don't have to remember two Domain Names, one
internal and one external. That *can* be a problem, and I
speak from experience!

2) Sub-Domain of registered external Domain Name. This is a
pretty good solution since you don't have to manually update
your internal Domain Name every time one of your external
hosts changes. However the internal Domain Names can get
pretty long (eg mailserver.internal.mycompany.com) and some
people don't like that.

3) Bogus Domain Name. This is also a pretty good solution.
However some people don't like bogus names. Also the name
may not *remain* bogus. What if you had called your internal
Domain "mycompany.biz" years ago? There is these days a
possibility of a conflict between your internal Domain Name
and a genuine external Domain, now that .biz is a valid suffix.

As I said above there is little operational difference
between the options. If one were *significantly* better than
the others, it would be recommended by most people. As it
is, there is no consensus, so no clearly preferable option.
Go with what seems best to you.

Cheers,

Cliff

 

[Guest]

The main thing is to make it flexible.

I would not recommend a bogus name because it could place restrictions on
using AD for future internet facing apps. Use an IANA registered namespace.

I would not recommend using yourcompanyname.com , if yourcompanyname changes
it can be a problem, if only a political one.

Where is yourcompanyname DNS hosted now ?
Your DNS will have to be able to except Dynamic Updates from AD. Unless it's
on AD, it cannot do Secure DDNS, therefore there is risk. You may want to
consider using AD DNS for AD. Create a new namespace, make ADDNS
authoritative for this zone. Forward workstations querys from the DNS that is
authoritative for yourcompanyname.com to ADDNS. Point AD servers at ADDNS.

You have to have a pretty good understanding of DNS to make these decisions.
Each decision should come with a justification. Finding people that really
understand DNS is not always easy, remember, justify each decision.

 

[Guest]

The main thing is to make it flexible.

I would not recommend a bogus name because it could place restrictions on
using AD for future internet facing apps. Use an IANA registered namespace.

How would it place restrictions? For Internet facing apps, external clients
would use the Internet domain name, mycompany.com, which would resolve an IP
address assigned to the firewall's external interface, and the firewall would
forward the traffic to the right internal server. If certificates are
needed, they can bear the external names, so that clients will see a
certificate for the hostname that they are using. (If internal users also
access the app and have to dismiss a warning saying that the certificate is
valid but the hostname is different, that's not a big deal.)

Besides, would using a bogus TLD be any different in this respect than a
subdomain? For example, if external clients access a server using the name
appserver.mycompany.com, would it make a difference whether the internal name
is appserver.mycompany.local or appserver.corp.mycompany.com? In both cases,
the internal name is different from the one used by external users.

Is there some issue I'm overlooking?

Where is yourcompanyname DNS hosted now ?
Your DNS will have to be able to except Dynamic Updates from AD. Unless it's
on AD, it cannot do Secure DDNS, therefore there is risk. You may want to
consider using AD DNS for AD. Create a new namespace, make ADDNS
authoritative for this zone. Forward workstations querys from the DNS that is
authoritative for yourcompanyname.com to ADDNS. Point AD servers at ADDNS.

Currently, the external domain, mycompany.com, is hosted on two Win2k DNS
servers in the DMZ. The internal domains, corp.mycompany.com and
corp.oldcompanyname.com, are hosted on DNS servers on the internal LAN, also
running Win2k. The internal DNS servers forward to the DNS servers in the
DMZ, and the servers in the DMZ use root hint. Since the internal servers
are Win2k, they do support DDNS and SRV records. However, my goal after the
migration is complete is to have a single internal domain name, hosted on the
domain controllers as an ADI zone.

You have to have a pretty good understanding of DNS to make these decisions.
Each decision should come with a justification. Finding people that really
understand DNS is not always easy, remember, justify each decision.

I'd say I have a pretty good understanding of DNS. However, I'm trying to
gather information about the specific advantages and disadvantages of the
different options for the AD domain name, because it's a decision that can't
be reversed and has to be made before setting up the first DC.

Another question that I have is, does the NetBIOS name necessarily have to
be the same as the lowest level of the AD domain name? For example, if I
choose internal.mycompany.com for AD, and I don't plan on creating any child
domains, is there a reason why the NetBIOS name would need to be INTERNAL, or
would MYCOMPANY work just as well?

 

[Guest]

Okay, it sounds like you're saying that on the whole each method works just
as well as the next, with the exception of a few minor issues, and that
choosing one method over another isn't really that much of a trade-off, is
that correct?

2) Sub-Domain of registered external Domain Name. This is a
pretty good solution since you don't have to manually update
your internal Domain Name every time one of your external
hosts changes. However the internal Domain Names can get
pretty long (eg mailserver.internal.mycompany.com) and some
people don't like that.

If I go with this method, supposing I want the users to see the company name
in the drop-down list when they log on, is there any problem with using
MYCOMPANY as the NetBIOS name if the DNS name is internal.mycompany.com, as
long as I'm not planning on adding any child domains to the AD tree, or is
there some reason why the NetBIOS name would necessarily have to be INTERNAL,
to match the lowest level of the AD domain name?