24

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:

  1. Registered domain name that will never be used publicly (e.g. mycompany.org, mycompany.info, etc).
  2. 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.

Community
  • 1
DSO
  • 553
  • 2
  • 6
  • 11
  • 2
    DSO: if their answers helped, you should mark the best one as "accepted" so later visitors can know what the right answer is. – Bill Weiss May 16 '12 at 16:57

6 Answers6

13

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

  1. a dedicated, registered domain name that is not available on the Internet

  2. 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.

Community
  • 1
Jay Michaud
  • 3,947
  • 4
  • 21
  • 36
  • It would be really nice if you could provide a link to a document where Microsoft makes this recommendation. – Zoredache Oct 04 '09 at 05:50
  • 2
    @Zoredache I updated my question with a link to the MS Technet article making the recommendation to use registered domain names. – DSO Oct 04 '09 at 07:02
7

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.

Community
  • 1
Zoredache
  • 128,755
  • 40
  • 271
  • 413
3

You shouldn't really ever use a public domain name for your AD name.

  1. 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 for mycompany.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.

  2. 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.

Diamond
  • 8,791
  • 3
  • 22
  • 37
mrdenny
  • 27,074
  • 4
  • 40
  • 68
  • +1 - I've actually seen silly things like IIS installed on every DC in an organization running a single web site to redirect HTTP requests to "domain-name.com" to "www.domain-name.com". Unbelievable but true. Personally, I go for "ad.domain-name.com" for the Active Directory domain name, but it really can be anything (other than the public name!). Your users' UPN suffix can still be "@domain-name.com" such that their account names can match their email addresses, because UPN suffixes have no connection to DNS whatsoever. – Evan Anderson Oct 03 '09 at 22:27
  • Hi- While it may be convenient or perceivably less work to use seperate namespaces, using the same one internally and externally is EXTREMELY common and there is really nothing wrong with it. The argument about an "attacker" is moot if the so called "attacker" knows anything. This little piece of information is quite easy to get if you want it. – Brian Desmond Oct 04 '09 at 16:54
  • I'd agree that the whole "attacker" bit is silly. Trying to minimize future DNS upkeep labor isn't, though. "Extremely common" doesn't mean "good for future management efficiency", or "a good choice", either. Boneheaded decisions seem to abound in IT, and large organizations seem to make poor choices just as well (if not better) than smaller ones. – Evan Anderson Oct 05 '09 at 15:55
1

The TechNet article referred above is older than this;

In here, Microsoft consistently suggests to use a private namespace for Active Directory Domain Name. You will also find bulleted details about disadvantages and problems of using a publicly registered domain name.

Diamond
  • 8,791
  • 3
  • 22
  • 37
Asad Hamdani
  • 11
  • 1
1

Back in 2000, there was an IETF Internet-Draft entitled DNS Top Level Domain For Private Networks that recommended using .pri:

A reserved top level domain name, ".pri", would allow a private domain name to be chosen safely with no risk of conflict with current or future registered domain names.

A private DNS server is configured as authoritative for the ".pri" domain, and delegates the private subdomains as appropriate.

Not sure what became of it, but it was a swell idea.
(Update: IETF Tracker says: draft never went further.)

Community
  • 1
Miles Wolbe
  • 151
  • 5
1

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.

Brian Desmond
  • 870
  • 4
  • 7
  • 4
    I wouldn't use "mycompany.net" unless you also own "mycompany.net", too. Otherwise, your internal DNS servers won't be able to resolve names in the "real" "mycompany.net" domain. – Evan Anderson Oct 05 '09 at 15:57