Choosing Your Domain Namespace

The first step in the actual design of the Active Directory structure is the decision on a common domain name system (DNS) namespace that Active Directory will occupy. Active Directory revolves around, and is inseparable from, DNS, and this decision is one of the most important ones to make. The namespace chosen can be as straightforward as microsoft.com, for example, or it can be more complex. Multiple factors must be considered, however, before this decision can be made. Is it better to register an AD namespace on the Internet and potentially expose it to intruders, or is it better to choose an unregistered internal namespace? Is it necessary to tie in multiple namespaces into the same forest? These and other questions must be answered before the design process can proceed.

External (Published) Namespace

The simplest method of implementing an Active Directory structure is through the use of a single, common DNS namespace that reflects the company's name and is registered on the Internet. Microsoft.com is an obvious example, and a myriad of other possibilities exist as well. Several advantages to a published namespace are that it is readily accessible from the Internet and there is less confusion on the end user's part in regards to the location on the network and on the Internet. For example, a user named Peter Pham working for the CompanyABC Corporation will be represented in the network through its user principal name (UPN) as [e-mail]. This name can be set up to exactly match his email address, limiting confusion for the end user.

The limitations to this type of namespace strategy are primarily security based. Publishing your Active Directory namespace leaves potential hackers with the name of your domain system and part of what is needed to compromise user accounts. Administering your firewall to block internal DNS queries also becomes less intuitive when the namespace is the same as the published Internet namespace for the organization. If the namespaces were separate, for example, a simple rule could be written to block any traffic to the internal domain structure. Another limitation would arise if an organization currently employs multiple namespaces to identify itself, and all those namespaces need to be joined into the same forest; in this case, a common namespace design is not an option. Mergers and acquisitions or even multiple business units within the same corporate parent can present these types of problems.

Internal Namespace

If desired or required by your organization, the namespace that the Active Directory structure inhabits can be internal, or not published to the Internet. Using internal namespaces adds a layer of complexity to your network because users' UPNs are different from their email addresses. However, the increase in security that is realized from this design is also a factor that leads organizations to choose this route. Another factor that may influence your decision to choose an Internet namespace is that you are no longer limited to the Internic standard namespaces of .com, .net, .biz, .info, and so on. For example, many organizations use the .internal namespace, or some other namespace that is not used on the Internet.

Keep in mind that it is important to secure an internal namespace from registration anywhere on the Internet other than in your own network. In other words, if an organization registers internalnetwork.net, and another organization on the Internet registers the same domain name for its network, there could be naming conflicts with applications and other systems that perform DNS lookups against your forest. For example, if an application on a laptop usually attempts to access an internal namespace but then tries to access it remotely through an ISP, the ISP's DNS will forward you to the registered DNS name on the Internet. In a nutshell, if you are going to design your domain with an unpublished namespace but use a standard such as .net or .org that someone else could theoretically register, it is best to register and reserve that domain but not point it anywhere. Another common tactic is to name your domain something that will never be published, such as a root with your company's stock ticker symbol (for example, network.msft), or by utilizing the .internal suffix, which has been specifically reserved for internal use only.