Top level domain for private networks?

Question

On our office network we have an internal DNS and all the hostnames are whatever.lan. On my VMware VMs, on their host-only network I call them whatever.vm.

We now have a private IP space network in production for VMs to talk to each other and were thinking we'd want to extend the convention, but we can't come up with a good name. Any suggestions? (Given that *.vm and *.local and *.lan all have existing connotations.)

Answer 1

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 iamthebest.org and use it to name your devices.

Answer 2

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:
www.example.com
mail.example.com
dns1.example.com

Internal machines:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

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": client1.internal.example.com.

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.

Answer 3

Woah. Why would you even do that? I really don't understand. Inventing tld's is wrong on extremely many levels. You could just put all the computers in your company's domain (foo.yourcompany.org) or, if you are in a playful mood, use a special dubdomain like (foo.lan.yourcompany.org). Are you doing it because you think, that typing multiple subdomain is tiresome? Well, I don't think I had to type in a fqdn for a computer in our private network for a long, long time, - thats why search suffixes exist.

I can not believe, that so many people actually suggested the names instead of saying something, that is very very obvious - inventing TLDs is a no-no. I don't know just how worse it can get. I mean, what next - a question on "how to configure an open relay properly"?

Answer 4

Well, if it's a linked set of virtual servers, obviously it's .matrix.

Answer 5

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 "dev.example.com" => database server used: dbserv1.dev.example.com

On the QA server, you set the search suffix to "qa.example.com" => database server used: dbserv1.qa.example.com

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

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

Answer 6

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.

Answer 7

Don't use .local. Especially if you've got any Apple clients.

Answer 8

I wouldn't use a top level domain at all. I would rather use a subdomain like virtual.mycompany.lan. This makes more sense to me since the virtual machines are a subset of your network.

Answer 9

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.

Answer 10

I use _internal followed by my official domain name, in my case _internal.dcuktec.net, note that an underscore is an invalid hostname but it is allowed for network names.

Answer 11

I have a couple of home networks that I administer and use - I like having the hostname.local approach work for local machines on the LAN no matter the client. Rather than having my OpenWRT router serve its hosts via .local (which conflicts with mDNS that it also supports) I have the local DHCP hosts and the router itself in a local.mydomain.example domain - that way a search for hostname.local will use mDNS first, if that fails, it will use the mydomain.example search path and find hostname.local.mydomain.example

I don't have any data in the actual public DNS for local.mydomain.example - it is something that is only known by the local routers' DNS for DHCP registrations. This way, even systems that don't do mDNS but do provide a hostname for DHCP can be contacted at hostname.local

Answer 12

A TLD for a private network? How about .private ? Nice and generic and carries no assumptions about what devices might exist on it, other than that they won't be internet routable.

Answer 13

There are a number of pseudo-top-level domains that you can use for things like this:

http://en.wikipedia.org/wiki/Pseudo-top-level_domain

These "pseudo-TLDs" include .bitnet, .csnet, .exit, .i2p, .local, .onion, .oz, .freenet and .uucp. Although these pseudo-TLDs look like top-level domains, and serve the same syntactic function in creating names for network endpoints, they have no meaning in the global Domain Name System and are (or were) used only for specialist purposes; typically for addressing machines that were not reachable via the Internet Protocol for use in services such as E-mail and Usenet via UUCP.

These avoid the "What if ICANN registers it tomorrow" problem, as well as give you the option to avoid the potentially-troublesome .local TLD.

Answer 14

How about .virtual?

Answer 15

.prod-vm .pvm

Answer 16

I can recommend to use .lan for private networks. It's not registered, it's short and it's easy to remember - works for me since many years.

Answer 17

I think that all of your responses regarding not using a unique TLD for a private network are moronic. "What if its registered by ICANN tomarrow," is bullcrap. ICANN is not the defacto master root holder. Perhaps they are the most popular, a natural monopoly, but there are a handful of alternate roots available. On a second note, ICANN has no way to legally pursue action against someone who uses theyre own unique TLD within a private organization.

Regardless of conflicts, if I create a .myfoo domain, and it is registered with ICANN the next day, give me a scenario where the ICANN .myfoo is going to have any significant information I or my company may need to access. IF my domain name server is private, delegating only for specific parties within a network, someone on the other side of the globe is not going to have a conflict, the conflict only resides within the internal network, my answer? Tough.