These DNS names and IP ranges are reserved (on the Internet) for use in specific situations, including examples, documentation and non-unique local assignment. As such, they are not available for unique assignment on the Internet and, with the exception of those reserved specifically for that purpose, should not be assigned on local networks that require proper Internet connectivity.

Because these DNS names and IP ranges are reserved, they can be used freely in anonymizing network assignments without risk of accidentally referring to some other real-world entity’s actual globally unique assignment either at the present time or in the future.

DNS names

Top-level domains for examples and documentation

RFC 2606 reserves four top-level domain names for use for examples and documentation:

  • test
  • example
  • invalid
  • localhost

Second-level domains for examples and documentation

RFC 2606 also reserves three second-level domain names for use for examples and documentation:

  • example.com
  • example.net
  • example.org

Second-level domain for residential homenets

RFC 8375 reserves a single, local-scope, second-level domain name for use for local name service in residential homenets:

  • home.arpa

If you aren’t sure what to enter when prompted for a domain name when setting up your home network or even an office network for which you don’t have a dedicated globally unique domain name or DNS zone, this (or some subdomain of it) is a good choice that is exceedingly unlikely to cause issues with host names used by others.

Top-level domain for multicast DNS

RFC 6762 reserves a single, restricted-scope, top-level domain name for use with multicast DNS (mDNS):

  • local

While this top-level domain is sometimes used outside of mDNS configurations, it should not be used where mDNS is not in use. Consider instead using home.arpa or a dedicated globally unique domain name.

Internationalized test top-level domains

ICANN Board Resolution 07.65 reserves an additional 11 variations of the top level domain “.test” as internationalized domain names (IDNs) in various languages and scripts:

The ordering in the list is as the TLDs are listed in 07.65.

Note that, in the copy of 07.65 available online, the Traditional Chinese and Greek IDNs are written as xn--g6w25ld and xn--jxa1pd1p respectively. Those are invalid Punycode. The list above uses the correct Punycode encoding as also given in the IANA’s summary of test IDN TLDs and indicated in the IANA DNS root database summary.

Other domain names reserved for special use

Several other domain names, including top-level domain names, are also reserved for various special uses. The IANA (Internet Assigned Numbers Authority) publishes a list of such special-use domain names.

Subdelegation reservations

Any names under any of these domains are, by consequence, available for use for the same purpose. For example, since “home.arpa” is reserved for local name service in residential homenets, to use “laptop.home.arpa” within such local name service is appropriate; similarly, since “example” as a top-level domain is reserved for examples, to use a name such as “oceania-web47-abc.example” as an example is appropriate.

Since these domain names are reserved for their purpose, no coordination with anyone else who might also be using them is required for such use. It is however worth noting that some such names might also resolve meaningfully on the global Internet; for example, “www.example.com” resolves to the IP address of a host that provides HTTP service and serves a web page briefly describing the purpose of the domain.

Country code-like TLDs

As a consequence of two different policies, some TLDs that look similar to country-code TLDs (ccTLDs) are also in effect reserved.

According to the IANA’s TLD eligibility criteria and the ICANN gTLD application process requirements (including ICANN Board Resolution 00.74), two-letter ASCII string (“alpha-2”) TLDs are not available for assignment except as provided for by ISO 3166-1.

ISO 3166-1 alpha-2 has several ranges of country codes with a status of “free for assignment at the disposal of users”. Specifically, those currently reserved for such use are:

  • AA
  • OO
  • QM through QZ inclusive
  • XA through XZ inclusive
  • ZZ

Consequently, using one of those for a top-level domain should in most cases not cause conflicts, although Wikipedia lists some ways in which some of those are used.

Since these TLDs would only be reserved as a consequence of other requirements, and the alpha-2 codes in question are in use in some places, great care should be taken when using them. It is likely a better idea to use one of the explicitly reserved alternatives instead of using any of these.

IPv4 networks

RFC 5737 reserves three IPv4 network address blocks out of the IPv4 globally routable unicast space for use for examples and documentation:

  • 192.0.2.0/24 (192.0.2.0 – 192.0.2.255) (originally by the now obsolete RFC 1166)
  • 198.51.100.0/24 (198.51.100.0 – 198.51.100.255)
  • 203.0.113.0/24 (203.0.113.0 – 203.0.113.255)

RFC 6676 additionally reserves an IPv4 network address block for documentation purposes specifically regarding multicast networks:

  • 233.252.0.0/24 (233.252.0.0 – 233.252.0.255)

RFC 2544 and RFC 6815 reserve an IPv4 network address block for private performance testning between subnets:

  • 198.18.0.0/15 (198.18.0.0 – 198.19.255.255)

RFC 1918 reserves three IPv4 network address blocks for private assignments, typically but not exclusively local area networks:

  • 10.0.0.0/8 (10.0.0.0 – 10.255.255.255)
  • 172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
  • 192.168.0.0/16 (192.168.0.0 – 192.168.255.255)

RFC 6598 additionally reserves an IPv4 network address block for carrier-grade network address translation, which with very few exceptions should not be used on equipment outside of a service provider’s network but may be seen on the Internet (WAN) side of customer equipment:

  • 100.64.0.0/10 (100.64.0.0 – 100.127.255.255)

Additional reserved IPv4 network address blocks, including historically reserved blocks, are listed listed in the Internet Assigned Numbers Authority’s list of IPv4 special-purpose allocations and in Wikipedia’s article on reserved IPv4 addresses.

For a local network that requires Internet connectivity, it is generally preferable to use some portion of the RFC 1918 address space behind a network address translation (NAT) device. However, when circumstances so require, specifically obtained globally routable addresses can also be used. Never pick an IP address at random for local use.

IPv6 networks

RFC 3849 reserves a single IPv6 network address block out of the IPv6 globally routable unicast space for use for examples and documentation:

  • 2001:DB8::/32

RFC 5180 reserves an IPv6 network address block for private performance testning between subnets:

  • 2001:200::/48

Additional reserved IPv6 network address blocks, including historically reserved blocks, are listed the Internet Assigned Numbers Authority’s list of IPv6 special-purpose allocations and in Wikipedia’s article on reserved IPv6 addresses.

For a local network that requires Internet connectivity, it is generally preferable to use globally routable addresses assigned from an upstream provider. Alternatively, a netblock assigned as described in RFC 4193 sections 3.1 and 3.2.2 using FC00::/7 space can be used. Never pick an IP address at random for local use.

EUI-48 and EUI-64 MAC addresses

Note that MAC addresses are normally not routed outside of the local subnet, but they can be used to generate particularly IPv6 addresses and as such may be exposed directly or indirectly on a larger network.

For examples of the latter, RFC 2464 defines stateless IPv6 address autoconfiguration for link-local addresses based on the EUI-64 address of a network interface, and RFC 4193 uses an EUI-64 identifier in the process of generating a unique local IPv6 unicast address prefix. Particularly in cases where the EUI-48 or EUI-64 identifier is used directly, such as in RFC 2464, addresses generated based on the ranges reserved for use in documentation should also be safe to use in documentation and examples.

As discussed in for example RFC 4941, RFC 7217 and RFC 7721 section 3, for several reasons, use of the EUI-48 or EUI-64 identifier directly should be avoided on actual networks.

When using these to generate example IPv6 addresses (for example for SLAAC), care should be taken to ensure that the network prefix used for the example is also reserved. Using these EUI addresses reduces the risk that the part generated based on the EUI address will collide with a real-world case; other parts of the full IPv6 address need similar care.

RFC 7042 reserves two EUI-48 ranges for use in documentation:

  • 00-00-5E-00-53-00 through 00-00-5E-00-53-FF for unicast
  • 01-00-5E-90-10-00 through 01-00-5E-90-10-FF for multicast

RFC 7042 also reserves several unicast EUI-64 ranges for use in documentation:

  • 00-00-5E-EF-10-00-00-00 through 00-00-5E-EF-10-00-00-FF
  • 00-00-5E-FE-C0-00-02-00 through 00-00-5E-FE-C0-00-02-FF
  • 00-00-5E-FE-C6-33-64-00 through 00-00-5E-FE-C6-33-64-FF
  • 00-00-5E-FE-CB-00-71-00 through 00-00-5E-FE-CB-00-71-FF
  • 00-00-5E-FF-FE-00-53-00 through 00-00-5E-FF-FE-00-53-FF
  • 00-00-5E-FE-EA-C0-00-02 (specific EUI-64 address)
  • 00-00-5E-FE-EA-C6-33-64 (specific EUI-64 address)
  • 00-00-5E-FE-EA-CB-00-71 (specific EUI-64 address)

RFC 7042 also reserves several multicast EUI-64 ranges for use in documentation:

  • 01-00-5E-EF-10-00-00-00 through 01-00-5E-EF-10-00-00-FF
  • 01-00-5E-FE-C0-00-02-00 through 01-00-5E-FE-C0-00-02-FF
  • 01-00-5E-FE-C6-33-64-00 through 01-00-5E-FE-C6-33-64-FF
  • 01-00-5E-FE-CB-00-71-00 through 01-00-5E-FE-CB-00-71-FF
  • 01-00-5E-FE-EA-C0-00-02 (specific EUI-64 address)
  • 01-00-5E-FE-EA-C6-33-64 (specific EUI-64 address)
  • 01-00-5E-FE-EA-CB-00-71 (specific EUI-64 address)