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.
Top-level domains for examples and documentation
Second-level domains for examples and documentation
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:
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.
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:
- xn--kgbechtv (Arabic: إختبار)
- xn--hgbk6aj7f53bba (Persian: آزمایشی)
- xn--0zwm56d (Simplified Chinese/Han: 测试)
- xn--g6w251d (Traditional Chinese/Han: 測試)
- xn--80akhbyknj4f (Russian: испытание)
- xn--11b5bs3a9aj6g (Hindi: परीक्षा)
- xn--jxalpdlp (Greek: δοκιμή)
- xn--9t4b11yi5a (Korean: 테스트)
- xn--deba0ad (Yiddish: טעסט)
- xn--zckzah (Japanese/Katakana: テスト)
- xn--hlcj6aya9esc7a (Tamil: பரிட்சை)
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.
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:
- QM through QZ inclusive
- XA through XZ inclusive
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.
- 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 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)
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.
For a local network that requires Internet connectivity, use either globally routable addresses or a netblock assigned as described in RFC 4193 sections 3.1 and 3.2.2 using FC00::/7 space. 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.
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)