Choosing a Future-Proof Internal DNS Domain Name: Mission Impossible?

Choosing a domain name that will only be visible from an internal network may look simple. Unfortunately, it is not. The basic problem: How to avoid collisions between the internal namespace and the internet?

I ran into this question when I recently installed a domain controller for a new test domain. Up till then I had used “.local” as top level domain (TLD), but I had not been sure whether “.local” was actually reserved on the internet or not. This time I wanted to be sure to take the “official” route. I first took stock of my setup and requirements:

• The test network is connected to the internet (via NAT).
• The test network has its own DNS server.
• The test network’s DNS server must be able to resolve both internal names (from its own database) and external internet names (by forwarding them to the provider’s DNS server).

Authoritative DNS servers will answer any query about their “own” domains. Only queries for other domains will be forwarded. The internal domain effectively masks out any external domain of the same name.

Consider this example: The internal domain is called “home.local”. A year later, the IETF adds the “.local” TLD to the list of officially supported TLDs and some large company decides to host a very popular site on that domain. If you then try to access the popular internet site from within the internal network, the browser will send a name resolution request for “www.home.local” to the internal network’s DNS server. Since that server is authoritative for “home.local” it will either return the IP address of the internal web server (instead of the external internet web server) or it will answer that the desired address cannot not be found. In either case, the server www.home.local on the internet cannot be accessed.

Looking for a Reserved Namespace

Taking the masking effect into account it is essential to choose an internal domain name that cannot and will not be used on the internet. Where do we find such a domain? We need to start at the root, i.e. the top level domain. Any second level domain below a reserved top level domain would suit our purposes fine. In the past, many have used “.internal” or “.local” as internal top level domains, but there is no RFC that actually marks those names as reserved. In theory they could be put to use just like “.info”, “.name” and so on.

RFC 2606 contains the solution to our problem. It defines the following four TLDs as reserved for private testing:

• .test
• .example
• .invalid
• .localhost

Additionally, the following second level domains are reserved:

• example.com
• example.net
• example.org

From those reserved names I picked the TLD “.test” for my new domain. The word “test” describes the domain’s purpose well. But there is a catch here – what if you need a name not for a test but a production domain? Somehow I cannot see Microsoft using “microsoft.test” as their internal Active Directory domain.

Creating Your Own Reserved Namespace

If you need a future-proof internal DNS name for production use you are limited to the following options:

• Use an internet domain name you reserved solely for the purpose of blocking it from being used by anyone else.
• Use a subdomain of your company’s existing internet domain.

Side note: Never ever should the same DNS domain name be used both internally and externally unless the network is fully routed and official IP addresses are used internally as was common in the early days of the internet before the widespread adoption of proxies and NAT.