This is a Canonical Question about Active Directory domain naming.

After experimenting with Windows domains and domain controllers in a virtual environment, I've realized that having an active directory domain named identically to a DNS domain is bad idea (Meaning that having example.com as an Active Directory name is no good when we have the example.com domain name registered for use as our website).

This related question seems to support that conclusion, but I'm still not sure about what other rules there are around naming Active Directory domains.

Are there any best practices on what an Active Directory name should or shouldn't be?


6 Answers 6


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.

  • 2
    But then NetBIOS name of the domain is not... well, pretty :) corp is not as descriptive as foo. Commented Oct 21, 2009 at 13:26
  • 36
    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. Commented Oct 21, 2009 at 13:32
  • 5
    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
    Commented Oct 21, 2009 at 15:12
  • 2
    I am not aware of any email server product that requires you to use the AD domain name as the users' email address suffix. Exchange has never required any kind of correlation between the AD domain name and email address suffixes. Commented Jul 4, 2015 at 19:46
  • 3
    Office365 only requires that your users logon with their UPN with a suffix matching your tenant domain. Since the default Exchange mailbox address policy can be defined to be anything, as can your UPN suffix, it is trivial. We have EXAMPLE.COM as our company name (and tenant in Office365), EXAMPLE.NET (also registered) as the forest, CORP.EXAMPLE.NET as the primary account domain (with other regional sub-domains, e.g. EU.EXAMPLE.NET) with EXAMPLE as the NetBIOS name, all users in the forest Exchange org use [email protected] for UPN and for email. Office365 is perfectly happy with this. Commented Sep 9, 2015 at 23:16

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.

  • 2
    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
    Commented Jan 29, 2013 at 17:21
  • 9
    This is true, but all of that is sloppy and unnecessary.
    – MDMarra
    Commented Jan 29, 2013 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... Commented Aug 26, 2013 at 20:49
  • May I just note that .local is not "made up" it is in fact reserved; just not for this type of use: en.wikipedia.org/wiki/.local Commented Mar 11, 2015 at 14:25
  • At the time this was written, it was not reserved.
    – MDMarra
    Commented Mar 11, 2015 at 19:47

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: Deployment and operation of Active Directory domains that are configured by using single-label DNS names | Microsoft Support

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


I disagree with using:

  • example.com - for reasons already stated in other answers

I could accept using:

  • ad.example.com - - for reasons already stated in other answers

But I wouldn't do it myself or recommend it. During company takeover, rebranding all hell breaks loose especially when management at that point wants things to change right away. Renaming migrations, changes are very hard or expensive.

Best way I would recommend is to buy domain that's irrelevant to company name and also irrelevant to company's brand. SIMPLE.CLOUD or similar should do just fine as long as you can own it.

I've seen big companies with 150k users using AD that's still referencing old company they bought years ago, or companies that changed names and even though it doesn't matter in the long run that you are using \login (if you can't use UPN) it's still looks bad in front of management who doesn't understand why it's not trivial to change it.


Example.com is a DNS host alias that serves the domain zone of the same name. Using it for other purposes, such as https://example.com, is incorrect: the web host must have a suitable name, such as www.example.com, just like any other resource other than a DNS host. Imagine you need to move the site https://example.com to a different host than the DNS service host. The only option is to run the web service on the DNS host with redirection (regardless of whether there is AD or not), which is what many people do to catch bad web requests. CONCLUSIONS. Services other than DNS should not use the zone name as their own name. Regarding the AD service. AD services are built on top of a DNS server, and their name literally means the NAME of the DOMAIN ZONE in which AD objects will be registered, and it does not matter whether it is a main zone or a child zone. If all resources of a domain zone have their own names, then there is no need to allocate a child zone for DNS AD (AD itself creates several child zones where necessary). If AD (with the name of the main domain zone) is located on the local network, then the “problem” of DNS zone stratification arises; This isn't really a problem - it's a mechanism to ensure that the same names (but different IP addresses) are used on both the LAN and WAN. This mechanism will result in additional annoying work for the administrator. The alternative, a child zone, relieves the administrator of this burden, but at the same time creates tedious work for users and developers, since the full names of the same resources are different on the local and global networks.


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.

  • 8
    FWIW, .local queries hammer on the root L-server -- ~800/sec when I looked.
    – jscott
    Commented Sep 23, 2010 at 20:11
  • 2
    dot.Local, AKA dot.Fail
    – PnP
    Commented Apr 13, 2015 at 8:23
  • 3
    Using an invalid TLD (or an unregistered domain) isn't a best practice, it's a worst practice, for all the reasons mentioned above. I'll admit that I have used .local, but that was before I knew better.
    – Jonathan J
    Commented Sep 9, 2016 at 20:05

You must log in to answer this question.

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