If you look at Microsoft Best Practices for setting up a new Forest/Domain they make some recommendations that conflict with other recommendations online and are not followed by any of the companies with which I have ever worked.

For example, best practices specify to use DNS names registered with an Internet authority in the Active Directory namespace because they are globally unique. Then they recommend to add a prefix to the registered DNS name to create a new subordinate name. For example, if the DNS root name is contoso.com then you should create an Active Directory forest root domain name such as concorp.contoso.com ...

In very many places I see recommendations against using the Internet Registered names because of routing of internal network traffic to the external IP and problems with DFS shares. I also rarely see companies use the "corp.company.com" naming scheme for the domain. They typically use something like "company.com" or "company.local".

Lastly, the best practices recommend leaving the root domain empty for the management of the domain and creating a single global child domain. Following this practice would result in domain names like "domain.corp.company.com" which I have never seen implemented.

Are there reasons the best practices aren't followed or are they being followed and I'm just not looking at it right to see the structure?

4 Answers 4


Too bad I wasn't awake for the party, eh? I'll take a crack anyway.

I taught MCSE classes for several years, and Microsoft's recommendations were always fairly consistent between their various training materials.

  • Don't use a domain name you don't own for your Active Directory domain name (i.e. microsoft.com).

  • Don't use an FQDN for the domain that other DNS servers are already authoritative for (i.e. company.com)

  • Do use an FQDN for the domain that is globally unique (i.e. ad.company.com, corp.company.com).

I believe the ".local" TLD "recommendation" started about the time of Windows Small Business Server 2003. The ".local" TLD is not reserved by ICANN though it's doubtful, at this point, that it would ever be used "for real" on the Internet (the Zeroconf protocol has dependencies on the ".local" TLD, too, I believe).

I've been in too many environments where "company.com" got used for the AD Domain name, necessitating stupid ugly hacks involving manually copying DNS records from the Internet DNS servers into the DNS servers supporting AD. I've answered a boatload of questions on this site that came down to this poor domain name choice causing hacks to have to be implemented (having to run web servers to do redirects to the "real" "company.com" web site on every AD domain controller, etc).

I don't know why companies persist in doing the "company.com" naming scheme for AD domains. It only creates problems. There isn't any good argument why you should do it, and it "goes against" the basic tenet of DNS that only one set of DNS servers in the world should be authoritative for a given DNS domain name. (I often hear the "UPN suffix" argument. If you want users to have a UPN suffix of "@company.com", for example, you can do that w/o actually naming the domain "company.com". All your users can have "@whitehouse.gov" UPN suffixes if you want, regardles of the domain's name...)

I've always been partial to "ad.company.com", myself.

The "empty root" domain idea is purely a political construct. Originally (W2K timeframe) Microsoft touted "empty root" as a way to have isolation of security concerns between parts of an organization while still having a single AD infrastructure. Fortunately, they've let up on this attitude (though they haven't necessarily gone back and corrected all the documents that were erroneous) since it's been demonstrated that any member of "Domain Admins" in any domain of the AD forest can, fairly easily, make themselves into members of the "Enterprise Admins" group.

So, today "empty root" is only ever really used for political purposes. I would argue that there's no place for it at all because it adds needless complexity (never, ever have a multi-domain environmnet where a single domain environment will do) and offers no real advantages.

If you want security isolation between concerns in your organization you must use a multi-forest deployment (which is absolutely the least fun kind of environment and to be avoided at all costs).


What you're describing is straight out of the MCSE classes.

One thing to keep in mind about their best practices is they're talking about experiences drawn from massive implementations of Active Directory.

I don't want to assume too much but based on your question, I'm guessing you're in the SMB segment? Not all of these best practices necessarily apply in that space due to matters of scale.

Regarding the DNS domain name, the suggestion of picking a "real" domain is probably based on an AD forest also hosting Exchange. Such a config makes both easier to manage. A better method is to register the real domain and then change the TLD to .local for AD. Your AD DNS domain name would be contoso.local and the "real" name contoso.com. You then configure an alternate SPN suffix for the real name for Exchange. Sounds like a hassle but it's worth the trouble not to deal with split-brain DNS, etc.

As far as how to handle the forest root domain, their suggestion is based on more strictly delineating security for managing objects within the forest. You might have organizational boundaries that require certain departments/business units, etc. to have a domain administrator for their domain. There are other benefits but that's probably the most common one.


I'll give you the principles that I go by...

  1. For a domain environment, always use a non-internet domain suffix, i.e. .lan or .local - This can become a really big deal really quickly due to DNS. Say you have your web site hosted somewhere else with a few subdomains, and your web site is company.com, and your AD domain is also company.com. Your workstations look for www.company.com to go to your web site, but your AD DNS responds with a "not found" because it thinks it's the authority for company.com, and you have no machine on the network named "www". The reverse scenario is true when you have VPN users; your VPN'd users can try to access myserver.company.com, but the DNS lookup goes to your web site DNS server instead of the AD server.... you get the drift. The .lan suffix mitigates this.
  2. If you know you'll eventually have branch offices to support, then the root domain being blank makes sense. If not, there's no reason to add the additional complexity and additional domain controller.
  • 1
    You can find several discussion about the TLD you should choose. The use of non-standart (or inexistant) TLD is against RFC. You can't predict if this TLd will become "real" in the future, particularly with the new TLD offers. You should really consider using a sub-domain and/or views for this kind of thing.
    – Benoit
    Jul 30, 2009 at 9:55

The so-called "root placeholder domain" (empty forest root) can be actually useful in large organizations, where merge/split scenarios are more likely; if you ever find yourself in need of creating other domains in the forest and move to a more decentralized administration model, it's good to have a place of its own to hold forest-wide administrative accounts and FSMO roles. You can't move or rename the forest root domain, so if you ever think you could need a distinct one for this purpose, you have to create it from the beginning.

That's of course completely useless for small organizations, and it also has the added cost of requiring at least two additional servers to act as DCs for the second domain.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .