Windows AD Domain naming recommendations

Question

After experimenting with domains and domain controllers in a virtual environment I realized that having an AD domain named identically to a... well, DNS domain is bad idea (I mean, we have foo.com as our website, so foo.com as a AD domain name is no good). This has only reassured me in my conclusions.

What are your recommendations on naming AD domains?

Answer 1

This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.

I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.

So, if you own foo.com, use ad.foo.com or some such.

The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com into their browser would be redirected to www.foo.com by these IIS installations. Utter silliness!

Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)

Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)

I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.

Answer 2

EDIT (1/29/13): I should preclude the below with "I have learned from my mistakes." I no longer do this and would downvote myself for this answer. As such, I'm editing my post and will simply say for archival purposes that using split-DNS and same external and internal domains should be avoided if possible.

If you use the same domain name internally as I do externally and implement split-DNS it is a piece of cake.

Here's an article (albeit for ISA but it still applies) that explains split DNS:

http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html

Basically, as long as you statically create records internally that point to www or ftp or similar "externally hosted" hosts on your domain then you'll be just fine.

For example, let's say you have "mail.foo.com" as your Exchange server. You can have internal clients on your LAN resolve to mail.foo.com with the internal IP. You can have external clients resolve to it (for SMTP or OWA, etc.) using the external record and then your firewall will redirect the traffic accordingly (after proper setup).

My main reason for doing it this way? I've found it so much simpler to explain to end user's their email addresses, login IDs, sip ID's for Office Communicator, etc. by saying "it's the same as your email address".

Answer 3

Another option we are using is mycompanyCORP.com so you are not in the mycompany.com space yet not incurring the confusion of a 3-layer name.

Answer 4

I always do mydomain.local.

local is not a valid TLD, so it never competes with an actual public DNS entry.

For example, I like being able to know that web1.mydomain.local will resolve to the internal IP of a web server, while web1.mydomain.com will resolve to the external IP.