Home / server / Questions / 47087
Accepted
Brian
Asked: 2009-07-29 08:52:40 +0800 CST

Using .local for internal websites [duplicate]

  • 772

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

domain-name-system url internal-dns

13 Answers

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

    • 36

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

    • 16

  3. 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. corp.example.com)
    • Internal domain with a different TLD (ie example.net)

    IMO, either of the latter options are better ideas.

    • 13

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

    • 10

  5. 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 app.internal.mycompany.com would be appropriate and wouldn't collide with your public site.

    • 9

  6. .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 server.internal.yourcompany.com

    • 5

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

    • 2

  8. read http://cr.yp.to/djbdns/dot-local.html and then choose your local domain name. summary: do not invent your own, either buy a real domain or use .1 - .9

    • 2

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

    • 2

  10. 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 : https://www.rfc-editor.org/rfc/rfc6762#appendix-G

    • 0