There are only two correct answers to this question.
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
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
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
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.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.