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

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 example.com) and they buy company B that also uses .local (or example.com). Not a lot of fun bringing the two namespaces together.

We have (e.g.) server.ourcompany.com and otherserver.ourcompany.local; not much chance of a collision unless company B is also called "ourcompany". We should probably use (e.g.) otherserver.corp.ourcompany.com, but the decision was made a while back.
–
Roger LipscombeOct 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 iamthebest.org and use it to name your devices. Other solution: local.yourdomain.org.

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.
–
AlbicJul 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 GadsdenFeb 2 '12 at 18:15

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.

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

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 some-app.beta.internal.mycompany.com, but as internal.mycompany.com 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.)

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.