Top level domain/domain suffix for private network?

Question

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?

Answer 1

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.

Update 1/2024: We're getting closer to having some definitive guidance on this. IANA has made a provisional determination that ICANN has opened up for public comment (the recommendation is to use .internal)

Update 8/2024: ICANN has officially reserved .INTERNAL (note: all caps) for private use.

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

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

This is a useful question and the answers here are really helpful. I've gathered the main considerations as I see them:

• It's not a good idea to use subdomains of a publicly facing domain.
• Amazon.com and Google use .internal.
• RFC 6762 Appendix G says that a lot of people use .internal, saying (paraphrased), "don't use a custom TLD, but if you do, we've seen a few in use, including .internal".
• SAC113: SSAC Advisory on Private-Use TLDs says ICANN should really come up with a TLD for private networks. It uses .internal as a hypothetical example (while protesting that it is not actually recommending .internal). In the graph of real-world queries it shows .internal as one of the most popular, and SAC113 singles it out (along with .home and .lan) as examples.

Understanding that the best practice would seem to be to purchase a separate domain, but taking the above items into consideration, as of 2023 I have decided to go with .internal. I have not read any realistic possible scenarios that would cause problems in practice.

Answer 9

As of late January 2024, ICANN is officially proposing .INTERNAL:

Proposed Top-Level Domain String for Private Use

The Internet Assigned Numbers Authority (IANA) has made a provisional determination that “.INTERNAL” should be reserved for private-use and internal network applications. Prior to review and approval of this reservation by the ICANN Board, we are seeking feedback on whether the selection complies with the specified procedure from SAC113, and any other observations that this string would be an inappropriate selection for this purpose.

On July 29, 2024, the ICANN board made it official:

Resolved (2024.07.29.06), the Board reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications. The Board recommends that efforts be undertaken to raise awareness of its reservation for this purpose through the organization's technical outreach.

Answer 10

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

• aaaaaa.aaaaaaaaaa.aa
• gg.qq
• tired.zz
• windows.xp

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!

Answer 11

Regarding RFC 8375 - Special-Use Domain 'home.arpa.', below is a hosts file showcasing a simple residential/office network setup. Up to line 23, it is exactly the same as Windows 11. home.arpa. is excluded from the Global DNS System and is therefore the safest option for those not renting a domain name.

Comments include relevant portions of:

RFC952 - DOD INTERNET HOST TABLE SPECIFICATION

RFC1123 - Requirements for Internet Hosts - Application and Support

RFC6762 - Multicast DNS

RFC8375 - Special-Use Domain home.arpa.

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.lan          # source server
#       38.25.63.10     x.acme.lan              # x client host
localhost name resolution is handled within DNS itself.
127.0.0.1       localhost
::1             localhost
--------------------------------------------------------------------------
RFC 952 and RFC 1123 Hosts File
https://www.rfc-editor.org/rfc/rfc952
https://www.rfc-editor.org/rfc/rfc1123

This file contains hostname to IP address mappings for TCP/IP networks.

RFC 952 and RFC 1123 are standards that define the rules for hostnames in
the Internet. According to these standards, a compliant hostname must
meet the following criteria:

It can contain letters (A-Z, a-z), digits (0-9), hyphens (-), and periods (.).
It must start with an alphanumeric character (letter or digit) and end
with an alphanumeric character.
Hyphens (-) can be used as a separator but must not be at the beginning
or end of a label (part of the hostname separated by periods).
Periods (.) are used to separate labels, which usually represent
different levels of the domain hierarchy.
Hostnames are case-insensitive.

RFC 1123 updated the original hostname requirements in RFC 952 to allow
hostnames to start with digits. However, it did not change the maximum
hostname length. The maximum length of a fully qualified domain name (FQDN)
is 253 characters (excluding the trailing dot). This limit is based on the
maximum size of a DNS message, which is 512 bytes, and the requirement to
accommodate other data fields within the DNS message, such as the query
type and class.

The format for entries in a hosts file is <IP-address> <hostname> <alias(es)>

RFC 6762 - Multicast DNS
https://www.rfc-editor.org/rfc/rfc6762
https://serverfault.com/a/1041148

Appendix G. Private DNS Namespaces

The special treatment of names ending in ".local." has been
implemented in Macintosh computers since the days of Mac OS 9, and
continues today in Mac OS X and iOS. There are also implementations
for Microsoft Windows [B4W], Linux, and other platforms.

Some network operators setting up private internal networks
("intranets") have used unregistered top-level domains, and some may
have used the ".local" top-level domain. Using ".local" as a private
top-level domain conflicts with Multicast DNS and may cause problems
for users. Clients can be configured to send both Multicast and
Unicast DNS queries in parallel for these names, and this does allow
names to be looked up both ways, but this results in additional
network traffic and additional delays in name resolution, as well as
potentially creating user confusion when it is not clear whether any
given result was received via link-local multicast from a peer on the
same link, or from the configured unicast name server. Because of
this, we recommend against using ".local" as a private Unicast DNS
top-level domain. We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
this purpose:

.intranet.
.internal. (Google, Amazon) virtual intranets
.private.
.corp.
.home.
.lan.

RFC 8375 - Special-Use Domain 'home.arpa.'
https://www.rfc-editor.org/rfc/rfc8375

3.  General Guidance

The domain name 'home.arpa.' is to be used for naming within
residential homenets. Names ending with '.home.arpa.' reference a
zone that is served locally, the contents of which are unique only to
a particular homenet and are not globally unique. Such names refer
to nodes and/or services that are located within a homenet (e.g., a
printer or a toaster).

DNS queries for names ending with '.home.arpa.' are resolved using
local resolvers on the homenet. Such queries MUST NOT be recursively
forwarded to servers outside the logical boundaries of the homenet.

Some service discovery user interfaces that are expected to be used
on homenets conceal information such as domain names from end users.
However, in some cases, it is still expected that users will need to
see, remember, and even type names ending with '.home.arpa.'. The
Homenet Working Group hopes that this name will in some way indicate
to as many readers as possible that such domain names are referring
to devices in the home, but we recognize that it is an imperfect
solution.

--------------------------------------------------------------------------
loopback address
127.0.0.1       localhost
::1             localhost
RFC 952-compliant host entries using RFC 8375 Special-Use Domain 'home.arpa.'
[IPv4]        DNS server                [Alias(es)]
10.0.0.2        dnsserver1.home.arpa      dns.home.arpa
[IPv4]        DHCP server               [Alias(es)]
10.0.0.3        dhcpserver1.home.arpa     dhcp.home.arpa
[IPv4]        Proxy server              [Alias(es)]
10.0.0.4        proxyserver1.home.arpa    proxy.home.arpa
[IPv4]        Web server                [Alias(es)]
10.0.0.5        webserver1.home.arpa      www.home.arpa
[IPv4]        File server               [Alias(es)]
10.0.0.6        fileserver1.home.arpa     files.home.arpa sftp.home.arpa
[IPv4]        Application server        [Alias(es)]
10.0.0.7        appserver1.home.arpa      app.home.arpa api.home.arpa
[IPv4]        Database server           [Alias(es)]
10.0.0.8        dbserver1.home.arpa       db.home.arpa
[IPv4]        Mail server               [Alias(es)]
10.0.0.9        mailserver1.home.arpa     smtp.home.arpa imap.home.arpa
[IPv4]        Print server              [Alias(es)]
10.0.0.10       printer1.home.arpa        printer.home.arpa
[IPv4]        Backup server             [Alias(es)]
10.0.0.11       backupserver1.home.arpa   backup.home.arpa
[IPv4]        Remote Desktop Services   [Alias(es)]
10.0.0.12       rds1.home.arpa            rds.home.arpa
end of file

Answer 12

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.

Answer 13

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