Choosing local versus public domain name for Active Directory [duplicate]
What are the pros and cons of choosing a local domain name such as mycompany.local versus a publicly registered domain name such as mycompany.com (assuming that your org has registered the public name)? When would you choose one over the other?
UPDATE
Thanks to Zoredache and Jay for pointing me to this question, which had the most useful responses. That also led me to find this Microsoft Technet article, which states:
It is best to use DNS names that are 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 cannot interact with one another.
Note
Using single label names or unregistered suffixes, such as .local, is not recommended.
Combining this with mrdenny's advice, I think the right approach is to use either:
- Registered domain name that will never be used publicly (e.g. mycompany.org, mycompany.info, etc).
- Subdomain of an existing public domain name which will never be used publicly (e.g. corp.mycompany.com).
The "never used publicly" part is a business decision so its probably best to get sign off from those in the company authorized to reserve domain names and subdomains. E.g. you don't want to use a registered name or subdomain that the marketing dept later wants to use for some public marketing campaign.
Below is an excerpt from my answer to a similar question found at: Top level domain/domain suffix for private network?.
Microsoft has recommended either
a dedicated, registered domain name that is not available on the Internet
a subdomain of your public domain name for use as the Active Directory forest root domain name
ever since they released Active Directory in Windows 2000 Server. To me, the main benefit of using a subdomain of your public domain name is a consistency of namespace, resulting in one less thing that you, other administrators, and users have to remember.
Use a subdomain of your company's registered domain for internal machines whose names you do not want available on the Internet. (Then, of course, only host those names on your internal DNS servers.) Here are some examples for the fictitious Example Corporation.
Internet-facing servers:
www.example.com
mail.example.com
dns1.example.com
Internal machines:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com
I used "corp" to signify that this subdomain described machines on the internal corporate network, but you could use anything you want here, such as "internal": client1.internal.example.com.
Using the same domain will make things difficult.
Unfortunately using .local also can cause problems. In particularly .local is used for for Bonjour/Zeroconf. If you use a .local tld you will need to adjust the settings on any OSX machine or Linux host running avahi.
In the somewhat related question 'Top level domain for private networks'. There is lots of advice about what you should not use, but there isn't really any consensus about what TLD should be used for private networks.
Unless I am mistaken, and please correct me if I am, but I don't believe there is anything from the IETF, IANA, or anyone of the other standards bodies permits usage of .local for anything.
- http://en.wikipedia.org/wiki/Bonjour_%28software%29
- http://www.zeroconf.org/
- Top level domain/domain suffix for private network?
- Using .local for internal websites
You shouldn't really ever use a public domain name for your AD name.
-
The first problem you'll find is accessing your own public website. Your public site's name matches your internal sites name. So when you do an
nslookup
formycompany.com
you get back your internal AD server's IP addresses, and not the public IP for the companie's sites. If you setup an FTP name for your public site, you won't be able to find that name either.The work around for some of this is to put the public names and IPs into your internal DNS so that you can hit them from inside the firewall, but this means you now have to manage two DNS farms when ever anything on the public side changes.
Another reason to keep them separate is so that an attacker doesn't know your internal domain name. Not knowing the domain name is just one more piece of the puzzle that an attacker would need to figure out.
If you don't want to use your external namespace, either of your thoughts (something like corp.mycompany.com or mycompany.net) works well and is common. I tend to prefer the .net option over the subdomain personally but I've done both many times.