171

At our office, we have a local area network with a purely internal DNS setup, on which clients all named as whatever.lan. I also have a VMware environment, and on the virtual-machine-only network, I name the virtual machines whatever.vm.

Currently, this network for the virtual machines isn't reachable from our local area network, but we're setting up a production network to migrate these virtual machines to, which will be reachable from the LAN. As a result, we're trying to settle on a convention for the domain suffix/TLD we apply to the guests on this new network we're setting up, but we can't come up with a good one, given that .vm, .local and .lan all have existing connotations in our environment.

So, what's the best practice in this situation? Is there a list of TLDs or domain names somewhere that's safe to use for a purely internal network?

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Otto
  • 1,941
  • 3
  • 16
  • 11
  • 4
    .test is set aside for this reason: https://secure.wikimedia.org/wikipedia/en/wiki/.test – CWSpear Jun 15 '12 at 04:34
  • 2
    @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 01 '12 at 05:22
  • 13
    @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 01 '12 at 05:24
  • 18
    **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 '14 at 18:55
  • 9
    Don't use .local. Especially if you've got any Apple clients. – RainyRat Jun 02 '09 at 09:57
  • .local is officially reserved for MDNS on internal networks. See https://tools.ietf.org/html/rfc6762. So using it will be horribly slow, it will have to wait to timeout. – Erik Aronesty Aug 02 '18 at 13:53
  • Make it start with a letter. Someone I know used a TLD that starts with a number, then had trouble with several softwares that rejected it as invalid. – simlev Nov 16 '18 at 11:00
  • @simlev while technically it could work, the current regulations and specifically ICANN ones, forbid digits in TLDs, except for IDN TLDs which have the form `xn--something`. See my longer answer I just posted at https://stackoverflow.com/a/53875771/6368697 – Patrick Mevzek Dec 20 '18 at 20:44
  • 1
    What's wrong with using `-local`/`-lan` instead of `.local`/`.lan` though? Is it really important to have a dot in your hostname, other than Firefox's annoying behaviour of trying to resolve a google query as a DNS lookup finally have a true positive? – SOFe Feb 13 '20 at 06:07
  • 1
    Using an invented TLD has countless problems, and there's no reason for it. Use a subdomain of your main domain (corp.company.com) or your main domain (company.com). In some cases, I've even counseled organizations to buy a second domain for purely infrastructure, if they wanted to set up DNS for all internal hosts. They used example.com for all their external facing services and all their internal infrastructure had DNS records in the examplecorp.com. They didn't miss the $12 a year, and neither will you. – Ben Yanke Jun 25 '20 at 03:09
  • Please consider support by browser when write .local,.lan,..etc not show as search should shown as domain ,by testing both brave,firefox dev the supported was **.test**,**.example** that not gonna redirect it search engine – Zaman Oof Oct 16 '21 at 06:15

10 Answers10

112

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.

bortzmeyer
  • 3,903
  • 1
  • 20
  • 24
  • 63
    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 02 '09 at 08:14
  • 4
    +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 02 '09 at 11:53
  • This is good advice. We ran a few different made up domains, then switched to a unified int.abbrev, but with some of ICANN's rules, that could theoretically become a viable domain, which could really screw us if we needed to communicate with it. It's not a country code, otherwise I would have bought it already. – Matt Simmons Jun 02 '09 at 12:45
  • In the rare case that ICANN delegates our TLD, and the even more rare case that we could not register the domain under that TLD, then we would simply follow the ICANN's UDRP procedures to protect our trademark. Additionally, since this is internal only it would not affect us in anyway if the domain was publicly registered other than not being able to access this public domain through our internal DNS servers. This assumes that you are not simply using host.TLD, but instead host.domain.TLD where "domain" is a registered trademark. – Doug Luxem Jun 02 '09 at 18:19
  • 3
    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 02 '09 at 19:34
  • 21
    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
  • 18
    Agree with @Joel Coel, you are a renter, and nothing more. There should be two reserved TLD names *for internal use only* that should be considered invalid in public and not reachable by public networks. One name would be for internal home use, the second name would be for internal business use. Both would be considered "private TLDs" in the same sense that we have "private subnets" that are non-routable (192.168.x.x and ilk). This allows home users to do something besides being forced into .local and mDNS. Ditto for small businesses running an internal LAN behind a NAT with no domain. – Avery Payne Mar 12 '14 at 18:20
  • 1
    @AveryPayne FWIW, `.example`, `.test`, and `.invalid` are reserved... but those are hardly good semantic choices, either. – Joel Coel Mar 12 '14 at 21:28
  • 2
    From The Register - [Do you use .home and .mail on your network? ICANN mulls .corp, .mail, .home dot-word domains](https://www.theregister.co.uk/2017/03/13/icann_gtlds_corp_home_mail/) *'High risk' gTLDs pondered by money-loving DNS overseer* – Nick T Mar 14 '17 at 20:02
  • 2
    `home.arpa.` from [RFC8375](https://tools.ietf.org/html/rfc8375) is now reserved on [IANA](https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml). So you can use it (or a subdomain of it) on your private network. – Carlos Beppler Feb 20 '20 at 14:32
  • given how this value proliferates, and often directly for human entry, I have a strong preference towards something short, memorable, and hard-to mis-enter – ThorSummoner Mar 27 '20 at 03:57
  • 4
    It's a ridiculous notion that the use of domain names is exclusively limit to those with funds to maintain a registered domain. While most registrars aren't that expensive, it's becoming increasingly difficult to not end up with "my-new-project-idea.com" which is absolutely lovely to type. Frankly the level of domain squating and limited value beyond the initial public gold rush is much worse that the ipv4 situation – Andre Helberg Apr 27 '20 at 21:54
  • 1
    My Indonesian friend has just reported that test.lan is resolves by her ISP :)) – badbishop Jul 04 '20 at 12:53
  • I need to short-term test some web apps locally on my network by myself and a couple others. I assume the .test TLD is fine for this. – Arrow_Raider Mar 03 '21 at 16:40
82

Since the previous answers to this question were written, there have been a couple of RFCs that alter the guidance somewhat. RFC 6761 discusses special-use domain names without providing specific guidance for private networks. RFC 6762 still recommends not using unregistered TLDs, but also acknowledges that there are cases where it will be done anyway. Since the commonly used .local conflicts with Multicast DNS (the main topic of the RFC), Appendix G. Private DNS Namespaces recommends the following TLDs:

  • intranet
  • internal
  • private
  • corp
  • home
  • lan

IANA appears to recognize both RFCs but does not (currently) incorporate the names listed in Appendix G.

In other words: you shouldn't do it. But when you decide to do it anyway, use one of the above names.

Community
  • 1
blihp
  • 961
  • 6
  • 5
  • 3
    The Appendix G has before the list you quote: "We do not recommend use of unregistered top-level domains at all". This is more the key point. The names given are not "recommended" to use, they are just observed names seen that will work better than `.local` which is kind of reserved for MulticastDNS, which is the discussion in Appendix G. – Patrick Mevzek Dec 20 '18 at 17:51
  • 21
    I would disagree. The key point is the absurdity of the advice: 'don't do it... but when you do...' The expectation that home/small business/non-publicly facing networks should register a TLD is not realistic. People **are** going to use unregistered TLDs so far better to help everyone out and say 'OK, here's a list of unregistered TLDs you can use internally' rather than pretending everyone is going to follow the hard line advice. – blihp Dec 21 '18 at 02:54
  • 2
    We will remain in disagreement then. The fact that some people used TLD like they are internal (for example `.MAIL` found in many documentations) is exactly the reason why these TLDs were not possible to delegate and are now indefinitely dead. Hence continuing to recommend to people to use TLDs in that way is a disservice to the global Internet community. The advice says that since some TLDs are already abused like that, if people have to abuse they should reuse those one instead of abusing new ones. RFC2606 is clear for the TLDs to use internally that will work: `.EXAMPLE` `.TEST` `.INVALID` – Patrick Mevzek Dec 21 '18 at 14:03
  • 10
    `home.arpa.` from [RFC8375](https://tools.ietf.org/html/rfc8375) is now reserved on [IANA](https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml). – Carlos Beppler Feb 20 '20 at 14:31
  • Somehow I had missed this response, I feel like this is the most useful overall. I get that folks shouldn't do it (I haven't been since I asked the question, originally) but now there's an RFC I can point at that explains why but also happens to set aside some that aren't likely to be reserved by a different RFC. – Otto Jul 15 '21 at 15:18
62

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.

Jay Michaud
  • 3,947
  • 4
  • 21
  • 36
36

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.

geewiz
  • 590
  • 3
  • 4
  • 2
    That is brilliant. – Chris Magnuson Mar 14 '12 at 14:35
  • 31
    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
  • 3
    That is pretty crude, SRV records are very simple to parse and can be placed within any zone, such that the same db server serves several zones. In this case some bit of code would be filling in the value within your config files. And you can use the name of the database as the SRV key and the value of course pointing to the hostname. I'd never rely on search suffixes. You can also get quite creative with TXT records, and can stuff them with aes-256 encrypted (then base64 encoded) values, if they're secrets. You can use TXT records for all sorts of things. – figtrap Oct 12 '15 at 01:12
  • see, but what I want is example.com, example.dev, and example.stg. The last 2 are only on a private network, can I setup a local DNS server for zero config access? Still using a similar config here for all sites, just moving changes up to tld. Easy for .dev with a hosts file, but zero config... – DigitalDesignDj Jan 02 '16 at 18:21
  • formatting/populating a config file should _not_ be the bottleneck for promoting code – ThorSummoner Mar 27 '20 at 03:53
  • @JoelCoel I would certainly hope your dev, QA, and prod databases have different credentials. – ndm13 Jan 05 '21 at 21:54
  • @ndm13 Certificate auth, where the someone in question has both certificates available – Joel Coel Jan 05 '21 at 22:12
  • 2
    Please never do this. It is one of those "smart" things you realize you *can* do after the first time you read the "BIND & DNS" O'Reilly book. But the **pain** of troubleshooting / tracking down the handful of systems that happens to use some hardcoded FQDN hostname *or* are manually misconfigured using the wrong (i.e. prod instead of qa) such search suffix is going to outweigh **all** the convenience gained. – conny Jul 30 '21 at 09:24
27

As always there are de jure and de facto standards.

While "nonprofit" ICANN plays in politics and money we, common people, suffer. IETF once introduced .home (RFC 7788) for personal home intranets but they don't have power over only-for-pofit IANA players and reintroduced domain under .home.arpa (RFC 8375) as IETF controls only .arpa.

Appendix G of https://www.rfc-editor.org/rfc/rfc6762 mentions:

.intranet .internal .private .corp .home .lan

for use if you really want internal TLD.

Big players (Google, Amazon) use .internal for virtual intranets:

  • https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html - A private (internal) DNS hostname resolves to the private IPv4 address of the instance. The private DNS hostname takes the form ip-private-ipv4-address.ec2.internal for the us-east-1 Region, and ip-private-ipv4-address.region.compute.internal for other Regions (where private-ipv4-address is the reverse lookup IP address).
  • https://cloud.google.com/compute/docs/internal-dns Zonal DNS [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal for all organizations or standalone projects that have enabled the Compute Engine API after September 06, 2018.

Those companies can buy the Internet. So it is de facto safe to use .internal TLD internally ))

Community
  • 1
gavenkoa
  • 712
  • 8
  • 12
  • 5
    This is a good answer because it covers both what is technically best according to specifications and what is safe from a practical standpoint. – Danation Jan 19 '21 at 01:01
  • 2
    Thank you for this great answer. I think "those companies can buy the Internet. So it is de facto safe to use .internal TLD internally" is the key insight. Google and Amazon would refactor the Internet if that meant they can avoid hitting a minor snag in their own infrastructure. They are all-powerful. – gd1 Mar 11 '21 at 15:13
  • the fact that .local is used by both Apple and Microsoft makes it just unlikely that ICANN would delegate .local as .internal, imo – Erik Aronesty Jun 23 '22 at 16:09
  • 1
    This is a real answer. The rest of the "don't do it" advice make wild assumptions about your use cases. No, I don't want to rent the name of my internal domain from icann who can hand it to a squatter or someone with deeper lawsuit pockets and a clever lawyer. No thanks. – Erik Aronesty Jun 23 '22 at 16:15
13

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.

Jaime Hablutzel
  • 416
  • 4
  • 10
Benoit
  • 3,499
  • 1
  • 18
  • 17
  • Registering your own TLD is typically not an option for anyone except rather large organisations because of the price. Definitely not for home users. – Göran Uddeborg Jan 14 '20 at 08:58
  • 2
    @GöranUddeborg: You misunderstand the answer. The answer does not recommend that you should register your own TLD, it just warns that new TLDs _could be created_ which might conflict with the TLD you chose. The advice is to just register your own domain name (which is cheap). – sleske Apr 02 '20 at 12:22
  • 1
    .internal and .local are both defacto locked-up by companies for internal use. – Erik Aronesty Jun 23 '22 at 16:10
11

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.

Mike Fiedler
  • 2,152
  • 1
  • 17
  • 33
0

An expired Internet Draft entitled Top-level Domains for Private Internets would have sanctioned the use of the 42 two-letter "user assigned code elements" as TLDs for private use.

  • AA
  • QM to QZ
  • XA to XZ
  • ZZ

So we could have used

and so on.

While this draft has expired, and therefore won't become a proposed standard, at IETF-111 the dnsop group had an update on the proposal: minutes video slides1 slides2

The update ends with (emphasis my own):

Change the approach of the draft as follows:

  • Recognize that User Assigned 3166 code elements are used in various ways, including private networks
  • Recognize that these elements have not been delegated and are known to be used by some people to anchor private namespaces
  • Do not recommend anything, do not reserve anything, no registries
  • Do not promote any particular interpretation of the current standards
  • Document potential future pitfalls for using these codes for private namespaces
  • Empower readers to make their own decisions

So, reading between the lines, and in the spirit of permissionless innovation...

But seriously, watch the video or at least read the minutes before using any of these!

Sam Morris
  • 345
  • 1
  • 10
-1

The real answer according to the IETF spec is:

.localhost
.test
.example
.invalid

I'm surprised at all the aggro answers, when real specific guidance has been there since 1999.

I cannot say if this will always bypass HSTS. That may still be an open issue.

New Alexandria
  • 159
  • 3
  • 9
-4

I'm not sure this will help you, but for internal DNS inside my AWS account, I use .aws as the tld, and it seems to work perfectly fine.

I know there are some TLDs you should just flat out not use, but other than those, I don't think it's too strict.

I worked at a few larger companies, where they would use the authentication source as the TLD, meaning if it was a MS/Windows server, using Active Directory as the auth source, it would be .ad, and some others would be .ldap (Why they weren't just using the same source? or servers replicating from the same directory service? I don't know, it was like that when I got there)

Good luck

Justin
  • 137
  • 2
  • 9
  • 4
    Amazon has now registered `.aws` as a TLD so you might start seeing problems eventually: http://nic.aws/ – Mark McKinstry Apr 07 '16 at 01:09
  • 1
    For information, the .aws is registered recently "25 March 2016" => http://newgtlds.icann.org/en/program-status/delegated-strings – Bruno Adelé May 09 '16 at 09:00
  • 1
    While I don't think using a phony TLD is that big of a deal, at least not if the whole system is closed off and uses a proxy to communicate with the internet at large, ".aws" is a really bad choice unless you're NOT in AWS! There's way too many conceivable scenarios where you won't be able to communicate with AWS anymore. – figtrap Oct 28 '16 at 19:55