Take the 2-minute tour ×

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 SF question reassured me in my conclusions.

What are your recommendations on naming AD domains?

share|improve this question
add comment

5 Answers

up vote 37 down vote accepted

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.

share|improve this answer
But then NetBIOS name of the domain is not... well, pretty :) corp is not as descriptive as foo. –  Anton Gogolev Oct 21 '09 at 13:26
You can assign whatever NetBIOS name you want, though. Many of my Customers have names like "ad.example.com", but the NetBIOS name is "EXAMPLE". DCPROMO will prompt you for what you'd like the NetBIOS name to be during creation of the domain. –  Evan Anderson Oct 21 '09 at 13:32
if you do this watch out for problems with domains that have wildcards. When you have *.foo.com, host.internal.foo.com will match it in some situations –  JamesRyan Oct 21 '09 at 15:12
add comment

There are only two correct answers to this question.

  1. An unused sub-domain of a domain that you use publicly. For example, if your public web presence is example.com your internal AD might be named something like ad.example.com or internal.example.com.

  2. An unused second-level domain that you own and don't use anywhere else. For example, if your public web presence is example.com your AD might be named example.net as long as you have registered example.net and don't use it anywhere else!

These are your only two choices. If you do something else, you're leaving yourself open to a lot of pain and suffering.

But everyone uses .local!
Doesn't matter. You shouldn't. I've blogged about the use of .local and other made up TLDs like .lan and .corp. Under no circumstances should you ever do this.

It's not more secure. It's not "best practices" like some people claim. And it doesn't have any benefit over the two choices that I've proposed.

But I want to name it the same as my public website's URL so that my users are example\user instead of ad\user
This is a valid, but misguided concern. When you promote the first DC in a domain, you can set the NetBIOS name of the domain to whatever you want it to be. If you follow my advice and set up your domain to be ad.example.com, you can configure the domain's NetBIOS name to be example so that your users will log on as example\user.

In Active Directory Forests and Trusts, you can create additional UPN suffixes as well. There's nothing stopping you from creating and setting @example.com as the primary UPN suffix for all accounts in your domain. When you combine this with the previous NetBIOS recommendation, no end user will ever see that your domain's FQDN is ad.example.com. Everything that they see will be example\ or @example.com. The only people that will need to work with the FQDN are the systems admins that work with Active Directory.

Also, assume that you use a split-horizon DNS namespace, meaning that your AD name is the same as your public-facing website. Now, your users can't get to example.com internally unless you have them prefix www. in their browser or you run IIS on all of your domain controllers (this is bad). You also have to curate two non-identical DNS zones that share a disjoint namespace. It's really more hassle than it's worth. Now imagine that you have a partnership with another company and they also have a split-horizon DNS configuration with their AD and their external presence. You have a private fiber link between the two and you need to create a trust. Now, all of your traffic to any of their public sites has to traverse the private link instead of just going out over the Internet. It also creates all kinds of headaches for the network admins on both sides. Avoid this. Trust me.

But but but...
Seriously, there's no reason not to use one of the two things that I've suggested. Any other way has pitfalls. I'm not telling you to rush to change your domain name if it's functioning and in place, but if you're creating a new AD, do one of the two things that I've recommended above.

share|improve this answer
A small point - one can use something much smaller, faster and secure than IIS to serve the redirect. Even haproxy or nginx are probably overkill - let alone a full-featured server like apache2. –  OrangeDog Jan 29 '13 at 17:21
This is true, but all of that is sloppy and unnecessary. –  MDMarra Jan 29 '13 at 18:08
Uuuuw yeah, it was so painful when someone suddenly registered the domain local.net and all the printers who silently got NXDOMAIN before that date suddenly did not answer anymore. That was some funny investigation... –  JoBo Aug 26 '13 at 20:49
add comment

To assist MDMarra's answer:

You should NEVER use a single-label DNS name for your domain name either. This was/is available prior to Windows 2008 R2. Reasons/explanations can be found here: http://support.microsoft.com/kb/300684/en-us

Don't forget to NOT use reserved words (a table is included in the "Naming Conventions" link at the bottom of this post), such as SYSTEM or WORLD or RESTRICTED.

I also agree with Microsoft in that you should follow two additional rules (that aren't set in stone, but still):

  1. You should NOT name your domain based on something that will change or become outdated. Examples include naming your domain after a product line, operating system, or anything else that is likely to change over time. Stick with something either geographical or concrete enough to make sense 5 or even 10 years down the road.
  2. Stick with short names of 15 characters or less, this will allow for the NETBIOS name to easily be the same as the domain name.

Finally, I would recommend that you think long term as much as possible. Companies do go through mergers and acquisitions, even small companies. Also think in terms of getting outside help/consultation. Use domain names, AD structure, etc. that will be explainable to consultants or people here on SF without much effort.

Knowledge links:




Microsoft's current (W2k12) recommendation page for the root forest domain name

share|improve this answer
add comment

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.

share|improve this answer
Any what happens when someone else purchases mycompanyCORP.com? –  MDMarra Aug 7 '10 at 21:18
Yes, you have to purchase it first. –  James Risto Aug 8 '10 at 13:18
add comment

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.

share|improve this answer
FWIW, .local queries hammer on the root L-server -- ~800/sec when I looked. –  jscott Sep 23 '10 at 20:11
add comment

Your Answer


