In the beginning, life was easy. We had a very limited set of top-level domains: .com, .edu, .gov, ..int, org, .mil, .net, .org, .edu. In addition, we had .arpa for infrastructure use and various two letter country level domains.
But that initial set of TLDs was insufficient as the internet grew, and we had several additions:
And I am only considering ICANN-sanctioned TLDs. We also have a couple of alternate roots.
ICANN is consistently expanding the gTLDs. But yesterday, I noticed some news about a new interesting TLD that you may want to consider adopting: .internal.
Until now, there has been no "official" TLD for internal use. ".local" is reserved for multicast DNS, and using it internally can lead to odd conflicts if your unicast and multicast DNS processes overlap. Companies have run into issues with "adopting" unused top-level domains if they become official and used. For example, the European router manufacturer AVM used "fritz.box" for the internal admin interface of its popular "FRITZ!Box" line of routers.
First, many of these issues disappear if you use a properly registered domain name. You may, for example, register "example-internal.com" for internal use. For external users, you can configure a wildcard entry directing users to a static placeholder page. It will also be easy to get proper TLS certificates for hosts within the domain, should you need them.
But if you do not want to register a "proper" domain for internal use, or if you feel like you need a TLD, you can now use ".internal" without being afraid that the TLD will be used publicly elsewhere.
What are the risks of using ".internal"?
Other networks may use it, too. If you later need to merge your network with another organization, let's say, a partner, or as part of a merge, you may have overlapping names. This issue is similar to the one you will have when using RFC1918 IP addresses.
The biggest security threat comes from users who are only connected to your network part of the time. They may attempt to resolve the internal hostnames while connected to external networks. In a non-malicious network, they may accidentally connect to ".internal" hosts defined at the external network. For a malicious network, there is no big difference. An attacker may intercept DNS requests no matter if they are directed at .internal or another TLD. However, an official domain may make it easier to configure proper TLS certificates. ".internal" TLS certificates will only work with an internal certificate authority. TLS remains one of the main defenses against DNS spoofing, particularly if you use a malicious resolver.
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|