When planning for a new Active Directory (AD) or upgrade AD, or merging AD one of the topics that will get on the table is planning DNS. DNS is the Domain Naming system, used to translate names into network (IP) addresses. Certainly this is the case if you need to plan for integration with an extranet, DMZ (demilitarized zone, typically between intranet and internet), or publishing website and applications
As it’s not a daily job to setup a new AD domain and internal DNS (from scratch…), so it might help to have some references to best practices.
It’s a pretty frequent topic on AD and network platforms. Plus, there are some strict technical guidelines that apply here, even for internal DNS configurations.
So the question is: what’s the best practice for DNS naming for internal domains and networks?
The short answer, as best practice:
- Microsoft strongly recommends that you register a public domain and use subdomains for the internal DNS.
- So, register a public DNS name, so you own it. Then create subdomains for internal use (like corp.example.org, dmz.example.org, extranet.example.org) and make sure you’ve got your DNS configuration setup correctly.
But first we need to clarify a few things…
The AD domain name is NOT the same as the DNS name, but they are linked. AD Domain names are mainly used within AD operations, mostly LDAP queries for AD functionality, while DNS is rather a network level solution for name resolution on IP level (to resolve the machines or application names to IP addresses). Essentially this difference allows you to use a ‘internal’, private AD domain name and use a public, registered DNS.
If you look into discussions and documentation on this topic, you’ll also see that the AD domain short name is referred as the NetBIOS Name (as in the AD logon name <DOMAIN>\<username>).
- AD Domain name: CORP
- DNS name: corp.example.org
See here for more explanation: https://technet.microsoft.com/en-gb/library/bb676377 You can also ‘unlink’ the AD domain name from the DNS name, then you get a disjoint namespace, as explained in previous link.
- AD Domain name: CORP
- DNS name: intranet.example.org
In the past, lots of people chose to use a dummy, unofficial TLD (top-level-domain) for their internal network, like domain.lan, domain.local of domain.internal (and also domain.internalhost)
But this can get you in serious trouble. Because these names are not supported by internet standards, the most important RFC on this is: RFC 2606 (http://tools.ietf.org/html/rfc2606 ) This RFC standard is very explicit on choosing domain names for private testing and documentation
But also for documentation some 2nd level domains are reserved
As you can see, these names are created for testing and not for production.
Plus, if the public naming standards change or additional names are released you might be using a name you don’t own and that can be routed to the internet, which conflicts with the initial use. Therefore, the technical conclusion is fairly straight forward: register a public DNS name and use it for your internal DNS resolution. So the use of <yourinternaldomain>.be is technically correct but it doesn’t stop there. There are some important consequences. Allow me to take the discussion a step further. You have to make a choice on the DNS zones:
- using a single DNS zone
- Using subdomains
- using different DNS zones
Some customers use the same DNS zone for internal and external usage. But there are some important disadvantages:
- mismatch between security zones (like intranet, extranet, DMZ and) and DNS naming
- when adding / merging domains the DNS is subject to redesign
- less flexible, less automated DNS operations
- conflict in authority with internal DNS and external DNS (managed by internet provider)
You might face some practical issues like:
- conflicts in DNS,
- instable operations and sub-optimal performance
- network issues
- complex configuration
- less or no automated DNS operations, more manual operations
- keeping DNS under control is less obvious
Plus, you’ll face some consequences regarding network security, by the lack of segregation of (DNS) duties.
So: Single DNS domain is absolutely not advised when you need to manage internal and external resources.
It’s completely the opposite of the previous approach. From DNS level, this is fairly simple setup, but you need to duplicate or multiply DNS configurations. And from a user perspective it might be complex or confusing, or not transparent, and inconsistent
This is a frequently used technique to use the same TLD (top level domain) and separate the zones by subdomain. E.g. “intranet”, “extranet”, “DMZ” for ‘internal’ zones and just plain <domain>.<tld> for public DNS. For example:
- intranet.example.org or corp.example.org (if your AD is named ‘CORP’)
- extranet.example.org for applications or partner facing websites
- DMZ.example.org for applications that need DMZ for data protection or publication,
- and master suffix .example.org for public websites (managed by your Internet Provider)
In fact, you have one DNS name space, but with forwarding spaces per zone. This is a bit more complicated setup as you need to make sure the DNS servers forward the requests to the applicable zones correctly. And it does require some planning and cooperation with your internet provider.
|The internal domain is a subdomain of the external domain. Microsoft strongly recommends this option. For more information, see Using an Internal Subdomain .||Easy to deploy and administer.||An organization with an external namespace contoso.com uses the internal namespace corp.contoso.com.|
|The internal and external domain names are different from each other. For more information, see Using Different Internal and External Domain Names .||
More complicated than previous option.
|An organization uses contoso.com for its external namespace, and corp.internal for its internal namespace.|
On top of that you need to be aware of a few rules regarding naming standards: https://support.microsoft.com/en-gb/kb/909264
Only use allowable ASCII characters when creating subdomains, A, CNAME and etc that conform to IETF standard.