Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.)

share|improve this question
    
.test is set aside for this reason: secure.wikimedia.org/wikipedia/en/wiki/.test –  CWSpear Jun 15 '12 at 4:34
    
@CWSpear That's not the actual reason .test is reserved, though it does make it a safe domain to use for test networks that won't be connected to the internet. –  voretaq7 Dec 1 '12 at 5:22
6  
@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 mydomain.com, delegate internal.mydomain.com 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 www.example.com and *.internal.example.com that are not allowed between www.example.com and *.example.net, 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 at 18:55

14 Answers 14

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.

share|improve this answer
43  
To be totally secure I would put everything on a subdomain of my company's domain name, like local.company.org, vm.company.org, and so on. –  drybjed Jun 2 '09 at 8:14
3  
+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
2  
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
1  
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
1  
@AveryPayne FWIW, .example, .test, and .invalid are reserved... but those are hardly good semantic choices, either. –  Joel Coel Mar 12 at 21:28

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.

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 "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.

share|improve this answer
2  
That is brilliant. –  Chris Magnuson Mar 14 '12 at 14:35
3  
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

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"?

share|improve this answer
    
It was never a /great/ idea, but for a while it probably seemed OK, because you could only have 3 letter terminations. Now that ICANN is selling TLDs to anyone with $10k, the schemes are in danger. I do know that as soon as my fake-made-up domain is available for purchase, I'm buying it. –  Matt Simmons Jun 2 '09 at 12:47
    
$100k, not $10k. And that's just the application and it is not open yet. –  bortzmeyer Jun 2 '09 at 13:12
    
Ah, thanks. Not that the extra difficulty will stop Murphy from making sure my private domain is first in line –  Matt Simmons Jun 2 '09 at 17:18
    
Sure, it does not change things in practice: using a non-standard TLD is dangerous, no matter the current ICANN policy is. For instance, if two companies merge and if both named their hosts under the same dummy TLD... –  bortzmeyer Jun 2 '09 at 19:31

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

share|improve this answer
    
There is an easy workaround for Apple devices not resolving .local domains from the configured DNS server, but I've had to apply it so infrequently that it's not something I've had to commit to memory. But just a heads-up, it's fixable. It's something to do with telling OS X not to resolve .local domains via MDNS. –  tomfanning Jun 2 '09 at 12:19
    
... MDNS is "multicast DNS" –  tomfanning Jun 2 '09 at 12:20
    
MDNS is a proprietary Apple protocol, specific to them. –  bortzmeyer Jun 2 '09 at 13:13
17  
mdns is not specific to apple. Linux uses it too within Avahi –  Mez Jun 11 '09 at 20:56
2  
mdns is a great steaming pile –  Joel Coel Sep 22 '11 at 15:54

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

share|improve this answer

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

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.

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 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.

share|improve this answer
1  
But what's the point? Since _ is illegal in host names, you won't be able to create mailserver._internal.dcuktec.net or similar. –  bortzmeyer Jun 2 '09 at 19:29
2  
It is perfectly legal in network names, so mail._internal.dcuktec.net works. If you are unsure about it just look how SRV records work. –  Martin P. Hellwig Jun 2 '09 at 20:21
5  
_ is legal in domain names not in host names so mail._internal.dcuktec.net is an illegal host name (you cannot use it as the left-hand side of a A or AAAA record, or as the right-hand side of a MX or NS record). SRV, as its name suggests, is for services, not for hosts. Too bad it is not possible to downvote a comment. –  bortzmeyer Jun 4 '09 at 6:41
4  
RFC 1123, section 2.1 - RFC 1035, section 3.3.9 –  bortzmeyer Jun 13 '09 at 10:04
2  
No, absolutely untrue. The difference between a host name and a domain name is that they follow different rules (RFC 1034-1035 for domain names and RFC 1123 for host names). Some contexts require a host name (for instance the right-hand side of a MX record, or the host part of an URL), some don't. –  bortzmeyer Apr 4 '10 at 15:13

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

share|improve this answer

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.

share|improve this answer
4  
The term of "pseudo-TLD" seems to be a Wikipedianism. I do not think anyone else used it. It has no formal meaning and, unlike what the Wikipedia page says, these TLD can be delegated as any others. –  bortzmeyer Jun 2 '09 at 19:28

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.

share|improve this answer
3  
What if the entire IT team get hit by a bus on the way to eating pancakes at the local snack house? Far more likely. –  Neobyte Jun 3 '09 at 1:06

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.

share|improve this answer
6  
The fact that it is not registered TODAY is irrelevant. What matters is "What if ICANN registers it tomorrow?" –  bortzmeyer Jun 2 '09 at 10:10
3  
Maybe there should be some names like .local and .private that are not allowed to be registered by ICANN. –  Bratch Jun 2 '09 at 14:37
3  
May be (I do not share this opinion). But currently, there is none. So, using a dummy TLD is quite risky. Even if ICANN does not create it, they make a merge between two companies very cumbersome, if they choosed the same (a problem similar to the one with RFC 1918 IPv4 addresses). –  bortzmeyer Jun 2 '09 at 19:26

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

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

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.