Special-Use Domain Names
Extracted elements (20)
Caching DNS servers are specified to generate immediate responses for private-address and test names (rather than forwarding upstream) in order to avoid unnecessary load on root name servers and other authoritative name servers.
Reserving a Special-Use Domain Name is appropriate only when special handling is required that cannot be achieved via existing DNS mechanisms or normal domain name registration processes. If declaring a given name special would result in no implementation change, reservation is likely inappropriate.
The IETF — not ICANN — has authority to define Special-Use Domain Names because the IETF is responsible for DNS protocol rules. ICANN manages allocation of names made possible by those rules, but the IETF can define higher-level protocol rules (e.g., always return NXDOMAIN) that apply on all networks independent of ICANN allocation.
Application software and name resolution libraries SHOULD NOT treat private-address reverse-mapping names, 'test.' names, or example domain names differently from ordinary names; special treatment at these layers is reserved for 'localhost.' and 'invalid.' which have protocol-guaranteed resolution behavior.
Special-use domain name behavior must apply universally on all networks — not only on the public Internet — because ICANN has no jurisdiction over private DNS servers on private networks. Special names are worthless unless they are defined to behave consistently by protocol across all installations.
An IETF 'Standards Action' or 'IESG Approval' specification MUST be published before reserving any Special-Use Domain Name. The specification MUST state how implementations determine that special handling is required for any given name.
Any specification reserving a Special-Use Domain Name MUST address all seven 'Domain Name Reservation Considerations' categories: Users, Application Software, Name Resolution APIs and Libraries, Caching DNS Servers, Authoritative DNS Servers, DNS Server Operators, and DNS Registries/Registrars.
Authoritative DNS servers SHOULD recognize private-address reverse-mapping names as special and SHOULD, by default, generate immediate negative responses unless explicitly configured by the administrator to give positive answers.
Caching DNS servers SHOULD NOT recognize example names as special and SHOULD resolve them normally. Authoritative DNS servers SHOULD NOT recognize example names as special. Application software SHOULD NOT recognize example names as special.
Caching DNS servers SHOULD recognize 'invalid.' names as special and SHOULD generate immediate NXDOMAIN responses for all such queries, without querying authoritative DNS servers.
Caching DNS servers SHOULD recognize 'localhost.' names as special and SHOULD NOT attempt to resolve them via authoritative servers; instead they SHOULD generate an immediate positive response with the IP loopback address for address queries, and immediate negative responses for all other query types.
Caching DNS servers SHOULD recognize private-address reverse-mapping names as special and SHOULD NOT, by default, query authoritative DNS servers for them; instead they SHOULD generate immediate responses. A configuration option (disabled by default) to enable upstream resolution SHOULD be offered.
DNS Registries/Registrars MUST NOT grant requests to register example domain names ('example.', 'example.com.', 'example.net.', 'example.org.'). All example names are registered in perpetuity to IANA.
DNS server operators SHOULD be aware that the effective RDATA for 'localhost.' and 'invalid.' names is defined by protocol specification and cannot be modified by local configuration.
Name resolution APIs and libraries SHOULD recognize 'invalid.' names as special and SHOULD always return immediate negative responses. They SHOULD NOT send queries for 'invalid.' names to configured caching DNS servers.
Name resolution APIs and libraries SHOULD recognize 'localhost.' names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. They SHOULD NOT send queries for localhost names to configured caching DNS servers.
The 'Domain Name Reservation Considerations' framework defines seven stakeholder categories that every special-use domain specification must address: (1) Users, (2) Application Software, (3) Name Resolution APIs/Libraries, (4) Caching DNS Servers, (5) Authoritative DNS Servers, (6) DNS Server Operators, and (7) DNS Registries/Registrars.
IANA created a new 'Special-Use Domain Names' registry, initially seeded with private-address reverse-mapping domains (from RFC 1918) and the Reserved Top Level DNS Names from RFC 2606. New entries require an IETF Standards Action or IESG Approval document with a 'Domain Name Reservation Considerations' section.
The private-address reverse-mapping domains are designated Special-Use Domain Names: 10.in-addr.arpa., 168.192.in-addr.arpa., and the 16 domains under 172.in-addr.arpa. (16 through 31). Any names falling within these domains are also special.
Any IETF document requesting reservation of a Special-Use Domain Name must contain an appropriate 'Security Considerations' section describing security issues relevant to that special use. This document itself does not define specific security properties of individual special-use names.