Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

At our office, we have a local area network with a purely internal DNS setup, on which clients all named as whatever.lan. I also have a VMware environment, and on the virtual-machine-only network, I name the virtual machines whatever.vm.

Currently, this network for the virtual machines isn't reachable from our local area network, but we're setting up a production network to migrate these virtual machines to, which will be reachable from the LAN. As a result, we're trying to settle on a convention for the domain suffix/TLD we apply to the guests on this new network we're setting up, but we can't come up with a good one, given that .vm, .local and .lan all have existing connotations in our environment.

So, what's the best practice in this situation? Is there a list of TLDs or domain names somewhere that's safe to use for a purely internal network?

share|improve this question
Well, if it's a linked set of virtual servers, obviously it's .matrix. – chaos Jun 1 '09 at 21:49
Don't use .local. Especially if you've got any Apple clients. – RainyRat Jun 2 '09 at 9:57
.test is set aside for this reason: – CWSpear Jun 15 '12 at 4:34
@Otto best practices would dictate that you acquire a "real" domain name (under an ICANN-recognized TLD) and create a subdomain of that for your local stuff (e.g. register, delegate to an internal NS, and properly configure split horizon DNS ("views" in BIND) so you don't leak internal names/addresses to the internet. It's not as pretty as a TLD/pseudo-TLD, but it's less prone to breakage as it's under your control. – voretaq7 Dec 1 '12 at 5:24
However: don't use a real domain name that you have already used for public-facing production services. There are various interactions that are allowed between and * that are not allowed between and *, most notably cross-site cookie setting. Running internal and external services on the same domain increases the risk that a compromise of a public service will give some ingress to the internal services, and conversely that an insecure internal service could provoke internal misuse of an external service. – bobince Nov 24 '14 at 18:55

Do not use an invented TLD. If ICANN were to delegate it, you would be in big trouble. Same thing if you merge with another organization which happens to use the same dummy TLD. That's why globally unique domain names are preferred.

The standard, RFC 2606 reserves names for examples, documentation, testing, but nothing for general use, and for good reasons: today, it is so easy and cheap to get a real and unique domain name that there is no good reason to use a dummy one.

So, buy and use it to name your devices.

share|improve this answer
To be totally secure I would put everything on a subdomain of my company's domain name, like,, and so on. – drybjed Jun 2 '09 at 8:14
+1 this. Presumably your company already has a domain. Just create a sub-domain from this. It doesn't have to be visible/resolvable outside of your LAN. – Dan Carley Jun 2 '09 at 11:53
Well, even with very good lawyers, you will have trouble claiming ".lan" or ".local" by invoking a trademark. And the argument "it is internal only" is extremely weak: organizations merge, set up virtual private networks with partner organizations and simply make mistakes such that "private" names leak. – bortzmeyer Jun 2 '09 at 19:34
My only beef with this is that you can't really "buy" a domain: you can only rent one. Some bozo forgets to pay a bill (and this has happened in a few high-profile cases) and a core part of your configuration goes to some random squatter. So you use your company's domain? Execs decide to rebrand or get bought out, and you're stuck with an old name. .local used to work well enough, but it's now been preempted by a certain company in ways that refuse to play nice. I'd really like so see something like .lan or .internal formally reserved for this purpose, but until then this is the best option. – Joel Coel Apr 25 '13 at 20:36
Agree with @Joel Coel, you are a renter, and nothing more. There should be two reserved TLD names for internal use only that should be considered invalid in public and not reachable by public networks. One name would be for internal home use, the second name would be for internal business use. Both would be considered "private TLDs" in the same sense that we have "private subnets" that are non-routable (192.168.x.x and ilk). This allows home users to do something besides being forced into .local and mDNS. Ditto for small businesses running an internal LAN behind a NAT with no domain. – Avery Payne Mar 12 '14 at 18:20

Use a subdomain of your company's registered domain for internal machines whose names you do not want available on the Internet. (Then, of course, only host those names on your internal DNS servers.) Here are some examples for the fictitious Example Corporation.

Internet-facing servers:

Internal machines:

I used "corp" to signify that this subdomain described machines on the internal corporate network, but you could use anything you want here, such as "internal":

Remember, too, that DNS zones and subdomains do not have to align with your network numbering scheme. My company, for example, has 37 locations, each with its own subnet, but all locations use the same (internal) domain name. Conversely, you could have only one or a few subnets, but many peer internal domains or levels of subdomains to help you organize your machines.

share|improve this answer

There's another advantage of using an internal subdomain: cleverly using search suffixes and only hostnames instead of FQDN, you can build configuration files that work both in development, QA and production.

For example, you always use "database = dbserv1" in your configuration file.

On the development server, you set the search suffix to "" => database server used:

On the QA server, you set the search suffix to "" => database server used:

And on the production server, you set the search suffix to "" => database server used:

That way, you can use the same settings in every environment.

share|improve this answer
That is brilliant. – Chris Magnuson Mar 14 '12 at 14:35
Until someone mis-configs their workstation with the production search suffix to test an issue, and later inadvertently updates a bunch of production records. – Joel Coel Apr 25 '13 at 20:43
That is pretty crude, SRV records are very simple to parse and can be placed within any zone, such that the same db server serves several zones. In this case some bit of code would be filling in the value within your config files. And you can use the name of the database as the SRV key and the value of course pointing to the hostname. I'd never rely on search suffixes. You can also get quite creative with TXT records, and can stuff them with aes-256 encrypted (then base64 encoded) values, if they're secrets. You can use TXT records for all sorts of things. – Tim Kelley Oct 12 '15 at 1:12
see, but what I want is,, and example.stg. The last 2 are only on a private network, can I setup a local DNS server for zero config access? Still using a similar config here for all sites, just moving changes up to tld. Easy for .dev with a hosts file, but zero config... – DigitalDesignDj Jan 2 at 18:21

We tend to consider no difference in the virtual naming of hosts from the physical - in fact, we've taken to abstracting the host configuration (software) from the physical layer.

So we purchase Hardware Items, and create Host Items on top of them (and use a simple relationship to show that in our documentation).

The purpose is that when a host exists, DNS shouldn't be the determining factor - as we've have machines move from one space to the next - for instance a low-performing webapp has no need to consume expensive CPU cycles - virtualize it, and it retains its naming scheme, everything continues to work.

share|improve this answer

As already said, you should not use an unregistered TLD for your private network. Especially now that ICANN allows almost anybody to register new TLDs. You should then use a real domain name

On the other side, the RFC 1918 is clear:

Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. So your name server should also use views to prevent the private records to be transmitted on the Internet.

share|improve this answer

I'm not sure this will help you, but for internal DNS inside my AWS account, I use .aws as the tld, and it seems to work perfectly fine.

I know there are some TLDs you should just flat out not use, but other than those, I don't think it's too strict.

I worked at a few larger companies, where they would use the authentication source as the TLD, meaning if it was a MS/Windows server, using Active Directory as the auth source, it would be .ad, and some others would be .ldap (Why they weren't just using the same source? or servers replicating from the same directory service? I don't know, it was like that when I got there)

Good luck

share|improve this answer
Amazon has now registered .aws as a TLD so you might start seeing problems eventually: – mmckinst Apr 7 at 1:09
For information, the .aws is registered recently "25 March 2016" => – Bruno Adelé May 9 at 9:00

protected by Chris S Sep 28 '11 at 14:23

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.