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
.test
is reserved, though it does make it a safe domain to use for test networks that won't be connected to the internet.mydomain.com
, delegateinternal.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.www.example.com
and*.internal.example.com
that are not allowed betweenwww.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.