Single-label DNS domain names consist of a single word or label like .global or .lan and often look like top-level domain names (albeit illegal ones). One of the biggest problems with single-label DNS names is that they cannot be registered with an Internet registrar.
A good article that covers configuring Active Directory domains by using single-label DNS names can be found here, with a general summary of:
Active Directory domain names should consist of two or more labels for the current and the future operating system and for application experience and reliability.
An article for general DNS Namespace planning can be found here that also advocates similar best practices.
In general, Microsoft does not recommend using single-label DNS names as discussed in the above articles.
However the term single-label is also, confusingly, used with the UAG DirectAccess TechNet documentation to refer to a different scenario. Within the UAG DirectAccess documentation the term single-label actually refers to unqualified, single-label names that are sometimes used for intranet servers so that you can specify a single name, such as http://intranet. This is an unfortunate overlapping of terms for two very different UAG DirectAccess concepts and is the first thing I wanted to highlight as part of this post. Those looking at the UAG DirectAccess documentation who may have come across the single-label DNS domain name term before when talking about an environment (one that a DNS domain name like .global for example) may consequently become quite confused. From this point on I will use the term single-label in this more traditional context and will abbreviate it to SLDNS.
The subject of SLDNS and UAG DirectAccess has come up a few times now, so I thought it would be useful to write a quick blog post with my views on the subject.
The first area of consideration for SLDNS is when defining Client Domains within Step 1: Clients and GPOs Configuration of the UAG DirectAccess wizard.
With the advent of Forefront UAG Service Pack 1, it appears that UAG DirectAccess no longer accepts the use of SLDNS and you will receive a An error occurred while loading the configuration. Please configure DirectAccess again error when attempting to Activate the UAG configuration after running the UAG DirectAccess wizard. I don’t believe UAG DirectAccess has ever supported this particular scenario, but I cannot find any documentation to confirm or dispute this statement at this time.
The second area of consideration for SLDNS is when defining DNS Suffixes within Step 3: Infrastructure Server Configuration of the UAG DirectAccess wizard.
This section of the wizard essentially allow you to define the Network Policy Routing Table (NRPT) which is used by DirectAccess clients for name resolution decisions. If you attempt to define a new DNS suffix and enter a SLDNS domain name, you will receive a The DNS suffix cannot be a DNS label error as shown below:
The final area of consideration for SLDNS is when defining Authentication Domains within Step 3: Infrastructure Server Configuration of the UAG DirectAccess wizard.
Again, in a similar way to when defining Client Domains within Step 1: Clients and GPOs Configuration of the UAG DirectAccess wizard, choosing an SLDNS for the Authentication Domains section will result in receiving a ‘An error occurred while loading the configuration. Please configure DirectAccess again’ error when attempting to Activate the UAG configuration after running the UAG DirectAccess wizard.
So, if you are running Active Directory DNS namespaces that use SLDNS domain names, or you have SLDNS namespaces in use somewhere within your organisation that need to be reached by DA clients, bear in mind that this will seriously impact your ability to deploy UAG DirectAccess without making some significant changes to your existing environment. Consequently, you would probably (unfortunately) do best to choose an alternate remote access solution, until you can “fix” your inherent DNS namespace design problem