Don't use .local for your AD domain name

"Why you shouldn't use .local in your Active Directory domain name.

This post was updated on 14 November 2013

There are an awful lot of .local, .corp, and .lan Active Directory domains out there for many reasons. Sometimes, there is no easy way to change this due to things like Exchange, custom apps that integrate tightly with AD, or just the massive amount of testing that a domain rename requires. I can understand if you walk into a situation like this that you did not create, but please don't ever do this on a new domain.

The correct way to name an Active Directory domain is to create a subdomain that is the delegation of a parent domain that you have registered and have control over. As an example, if I ever started a consulting business and used the Internet-facing website mdmarra.com as my company's site, I should name my Active Directory domain ad.mdmarra.com or internal.mdmarra.com, or something similar. You want to avoid making up a TLD like .local and you also want to avoid the headache of using mdmarra.com for the Internet-facing zone and the internal zone.


I hear a lot of different reasons why people might want to use .local, some a bit crazier than others. A select few are:

"Since .local isn't a valid TLD, it's more secure since my AD can't be attacked from the Internet."

I actually heard this on an Active Directory certification training video today and I was shocked. It's just plain silly. You shouldn't be exposing your Domain Controllers to the Internet, period. They should be behind a firewall on the trusted side of your LAN. If you do expose them to the Internet, having a made-up TLD isn't going to help you much. This is a false sense of security that has no root in reality.

"Small Business Server defaults to using a .local TLD during the setup wizard."

Trust me when I say that SBS is not a product that you want to model your organization around. It is meant to be an out-of-the-box solution that can be managed by users with minimal knowledge of Active Directory or Windows Server. Microsoft is betting that people that install SBS either won't already own a valid Internet domain or won't understand what it means to use a third level domain name. SBS also has Active Directory, SQL Server, Exchange, and SharePoint all on the same server. Like I said, not something you want to model your environment after.

"I want my users to see Company\User as the login name. I don't want something ugly like AD\User or Corp\User!"

These two things aren't really related. You can set the NetBIOS name of the domain (the part before the backslash) to whatever you want during domain creation. You can also set the UPN (@whatever.domain.com) to anything that you want as well. This will allow you to have your AD's FQDN be something like internal.company.com, while your users will log in with Company\User or user@company.com. The FQDN of the domain has little to do with the format of a user's login name other than it picks a reasonable default during domain creation. You are free to change this default if you want to make it prettier.

If I haven't made up your mind about this yet, you should read Best Practice Active Directory Design for Managing Windows Networks on TechNet. It's a Windows 2000 era document, but this best practice hasn't changed. The relevant passage is as follows (The bolding is mine for emphasis):

As a best practice use DNS names registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name, or if your organization merges with, acquires, or is acquired by other company that uses the same DNS names then the two infrastructures can never interact with one another. 

Add a prefix that is not currently in use to the registered DNS name to create a new subordinate name. For example, if your DNS root name were contoso.com then you should create an Active Directory forest root domain name such as concorp.contoso.com, where the namespace concorp.contoso.com is not already in use on the network

Another reason, albeit a much smaller one, is that mDNS, otherwise known as Bonjour, uses .local to identify nodes on the local subnet without using a DNS lookup. According to Apple, this should only happen when there is a single label in front of .local, like server1.local. If your AD is called company.local – guess what – that's a single name in front of a .local. Not a good situation to be in. There are certainly workarounds for this, but I've worked in mixed environments with both .local and proper AD FQDNs and it's a lot less painful when you aren't using .local.

Really, there are zero good reasons to use .local in a new installation of Active Directory and there are plenty of reasons not to, so make it easier on yourself and your successors and put a little bit of planning into the naming of your forest root domain.

Update: Since this post was written, there has been a major new development with fabricated TLDs. The CA/Browser forum, which is a consortium of web browser vendors and public CAs has released a document titled:  Internal Server Names and IP Address Requirements for SSL: Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses provided by the CA/Browser Forum. It can be found here (warning: direct link to PDF).

This document states that no major certificate vendor will issue an SSL certificate for an address with a made up TLD in it, such as .local, .lan, .corp, etc. This echos the best practices that have been published for years, but now has real tangible consequences attached to it."

http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html