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

This question already has an answer here:

Is it okay to use app.mycoolname.local for URLs that are private / internal?

We have several applications that are web based, but they are private apps and are not exposed to the public.

We have been using ".net" for some of these, which doesn't make sense since they could collied with a real URL on the internet. That hasn't been a problem yet.

But now I have a new group of applications and I want to name them using a "popular" name that will definatly collide with a URL on the internet.

Should I use app.mycoolname.local? I have it set up this way right now, and it seems to be working. I have read a few places where it was encouraged, but then I saw a few places where it wasn't working (some problem on Mac, but we don't have those, so NBD).

share|improve this question

marked as duplicate by 84104, Ward, squillman, Jenny D, Rex Oct 30 '13 at 16:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

13 Answers 13

up vote -4 down vote accepted

It's perfectly acceptable to use a .local zone. We have one for our internal network, mainly used for development sites, but it works well.

share|improve this answer
Cool, thanks. I just wanted to be sure I wasn't doing something dumb. – Brian Jul 28 '09 at 19:09
Bad idea for the reasons explained in… – bortzmeyer Jul 28 '09 at 19:44
See the article at While it's not a guarantee, .local will, in all likelihood, be just fine. – palehorse Jul 28 '09 at 20:21
no, no, no. .local is not reserved, do not use it. – goo Jul 28 '09 at 20:24
@palehorse, "The implementation of both approaches on the same network can be problematic, however, so resolving such names via “unicast” DNS servers has fallen into disfavor as [devices] supporting zero-configuration networking (zeroconf) have become increasingly common." — – toolbear74 Aug 25 '14 at 12:02

Do not use .local. Do not use .anythingyoujustmadeup either. Don't even use the reserved TLDs. Use a real domain or sub domain and just don't allow it to be visible to the outside world. The main reason for this is when you work for company A that uses .local (or and they buy company B that also uses .local (or Not a lot of fun bringing the two namespaces together.

share|improve this answer
We have (e.g.) and otherserver.ourcompany.local; not much chance of a collision unless company B is also called "ourcompany". We should probably use (e.g.), but the decision was made a while back. – Roger Lipscombe Oct 16 '09 at 8:19

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. Other solution:

share|improve this answer
Everything to the right of the dot is now fair game: – Mark Johnson Dec 26 '12 at 18:37
After reading this question, I decided on "" and I've been pleased. "in" being short for "internal" of course. Even makes for great ssh aliases: "ssh" and let the ~/.ssh/config file sort the rest out. – freb Apr 16 '15 at 4:15
@ScottChamberlain Fine, put an 'Almost' in front of my previous comment. I still wouldn't recommend using any of those reserved names for an invented TLD. Or any invented TLD at all. – Mark Johnson Apr 21 '15 at 20:56
@MarkJohnson Oh, I agree. you should be using a domain you own. I just did not want to perpetuate "Everything to the right of the dot..." – Scott Chamberlain Apr 21 '15 at 21:29

I wouldn't use .local unless you understand how zeroconf works, as it will become a bigger deal when you start to see IPv6 move into the mainstream.

In the past, I've used:

  • Made up TLD (not a good practice for a variety of reasons)
  • Internal subdomain (ie.
  • Internal domain with a different TLD (ie

IMO, either of the latter options are better ideas.

share|improve this answer

Technically you shouldn't use it. It's used by multicast DNS / zero configuration networking for link-local addresses. In practice it doesn't seem to matter much. I've been using a Mac laptop (which uses zeroconf) on an internal network with a .local suffix for the past couple of years without any issues.

share|improve this answer

As Gerald Combs pointed out .local is a reserved domain and should not be used other than intended.

As Gerald Combs pointed out the .local domain is used by a lot of Apple (and others) software and therefore using it in another way could cause problems with this software.

Why not use a subdomain of your public site? Something like would be appropriate and wouldn't collide with your public site.

share|improve this answer
That's a pretty good idea - I hadn't thought of that. It would make for a slightly longer URL, though. – Brian Jul 28 '09 at 19:08
No, .local is NOT reserved. And that is precisely the reason why it should not be used. Otherwise, I fully agree. – bortzmeyer Jul 28 '09 at 19:45
-1 for saying .local is reserved – goo Jul 28 '09 at 20:33
You're right, "reserved" might not be the right word. Anyway .local is used by a lot of Apple software and therefore using it in another way could cause problems with this software. – Albic Jul 28 '09 at 20:49
@Brian Set up a domain search path on your computers (you can do this by Group Policy in the Microsoft world; I'm sure there are equivalents for Mac / Linux) and then all you need in the URL is http://app/ – Richard Gadsden Feb 2 '12 at 18:15

.local is used by Microsoft's Small Business Server and by MDNS on Macs (ie Bonjour). I think the fact that it's used by both Apple and Microsoft makes it unlikely that ICANN would delegate it, but it's not reserved and it does remain theoretically possible that they might.

I'd use something like

share|improve this answer
Yeah, I'm surprised ICANN still hasn't reserved .local, especially considering that anyone with enough money can now register their desired TLD. – Martijn Heemels Nov 9 '11 at 20:14

If you were after some more information on .local and why it may or may not be an issue for you to use it. There don't actually seem to be any reserved zones for internal use

share|improve this answer

A nice compromise solution is to use an internal subdomain in conjunction with a DNS search path.

As a real-life example, an app I'm working on might be addressed in full as, but as is in the DNS search path for workstations as returned by the DHCP server, I can access it as some-app.beta. There's still a possibility of collision if these names are chosen poorly, but in that event a collision can be resolved using an FQDN. (Or, if you want to protect yourself, by always using FQDNs for the important stuff -- although the final dot in DNS names is sadly neglected.)

share|improve this answer

read and then choose your local domain name. summary: do not invent your own, either buy a real domain or use .1 - .9

share|improve this answer
Any entity with sufficient cash can now purchase .1 - .9 from ICANN. – Mark Johnson Dec 26 '12 at 18:42

As pointed out by many; in general a bad idea to use an unregistered TLD for intranets. However [0] states that there are some commonly used nanmes (although not approved for intranet use only). [0] still discourages to use the mentioned TLD for local nets, and local. should not be used in any other situation than a multicast DNS.

[0] RFC6762, appendix G :

share|improve this answer

I've always been a big fan of the internal .lan TLD, myself.

share|improve this answer
As bad as .local and for the same reason… – bortzmeyer Jul 28 '09 at 19:54

We use .local all the time with both macs and pcs. Enjoy

share|improve this answer