You've come to this page because you've abused a domain name that you do not own, for private or internal use. This is the Frequently Given Answer to such abuse.
You do not own
TLD
names such as
local.,
lan.,
dev.,
corp., or
private..
They are not yours, and you thus may not use them for even private or internal purposes.
You may not use subdomains of those TLDs as Active Directory domain names or forest root names, for example.
Use a domain name that you actually own, or subdomains thereof. Learn from history. Making up one's own private-use TLDs, 3 letter or otherwise, is a bad idea whose results have annoyed people and caused technical difficulties for years. Don't adopt it. The only place that one has any business making up domain names is under the domain name(s) that one actually owns.
The Domain Name System as a standard function of the system gives you a means of having arbitrary many domain names to play with.
You register a domain name in the public DNS database, such as example.org., and that gives you the right to create any (protocol legal) names that you want beneath it, such as internal.example.org. or silly-walks.gb.geo.example.org..
That is how you should reserve a portion of the DNS namespace for your private or internal use.
It gets you an entire subtree to play in.
So if you want to create Active Directory domain and forest names, and have registered example.com., then you can place them all under a subdomain such as ad.example.com..
(You could even place them directly under example.com., using example.com. itself as your AD domain name, although this has not been best practice for many years.)
If you have your Active Directory LAN set up properly, none of your domain controllers will be providing DNS service to the world outwith your LAN borders, and you'll already have "split horizon" DNS service with the prune-and-graft point for the DNS namespace tree at ad.example.com. or some such.
There are two reasons for this, which basically boil down to "Think! What if other people did the same thing as you?":
This has already happened twice. On two occasions, over the decades, we've already seen this go wrong for people. People thought that an "unused" TLD was a whizz-o idea to steal for their own purposes, only to find that they weren't the only people in the world who thought that it was a good idea for a domain name, and that those others had adopted it for a different use:
People thought that corp. was a good idea for an "internal", "private", domain name.
Then along came AlterNIC, who also thought it a good idea, and promptly created a corp. top-level domain name.
People thought that local. was a good idea for an "internal", "private", domain name.
Then along came no fewer than two separate groups of people who also thought it a good name but used it for different purposes: ZeroConf/Bonjour/Avahi and HTTP Cookies (RFC2965).
The conflict between Bonjour and system/network administrators who want to steal local. for their own purposes has been well-known for the past almost two decades.
One of the earliest commentaries on it on the WWW is a MacWorld article dated 2002, and there have been tens if not hundreds of articles on the WWW explaining that if one attempts to abuse local. for one's own purposes things will break.
Yet system/network administrators are still not learning from history all of these years later.
Companies and organizations merge and split.
Two companies whose separate network infrastructures both steal lan., or some other TLD that the companies don't own, are a nightmare to merge.
They also set up VPN links. Again, two or more companies that abuse domain names that they don't own are a nightmare to create VPN links between, when their system/network administrators have both had the same whizz-o idea of abusing the same domain names. One might think that it wouldn't be that much trouble, as long as the names were different amongst the various organizations. Of course, since everybody has this same unoriginal idea it's actually the usual case for the domain names being abused to conflict, because everyone has the same unoriginal choices for TLD too.
Note that the domain names reserved for examples, invalid names, and tests by RFC2606 are not reserved for private use as actual domain names. Don't be confused on this point. Use in documentation is not use as an actual domain name. RFC2606 does not set aside any TLDs or SLDs for private use.
Every so often, people propose that domain names such as local. and pri. be reserved for private use.
There have been several such proposals in the past couple of decades, some even made to the IETF.
They've all foundered, for one simple reason:
They aren't actually necessary and would in fact be worse than the existing mechanisms.
The DNS already provides a mechanism for any company or organization to grab an entire subtree of the DNS namespace for itself.
And it's a mechanism that is immune to the aforementioned problems of corporate mergers, splits, and VPNs that would plague a single reserved top-level domain name set aside for such a purpose.
Registration in the public DNS avoids conflicting subtree roots.
This is why the DNS has a hierarchical namespace in the first place, after all.
local. domain and DNS issues.
macworld
local. or pvt. top-level domain names as part of an Active Directory tree name?
ID 44818.
Windows IT Pro.
local. hostnames via both Bonjour and standard DNS.
local..
HoffmanLabs.
local. hostnames via both Bonjour and standard DNS.