RFC 6761
For implications on Internet governance, see Special-Use Domain Name.
RFC 6761, Special-Use Domain Names, is an IETF standards-track RFC that defines what it means for a domain name to be reserved for "special use", when such reservation is appropriate, and how it is recorded in an IANA registry.[1][2] The RFC both documents existing reserved names and creates the Special-Use Domain Names registry at IANA.
Background[edit | edit source]
The IETF had previously reserved a small set of top-level and second-level domain names for documentation and testing, notably in RFC 2606, which introduced .test, .example, .invalid, .localhost and the "example.com/net/org" domains.[3] At the same time, other protocols made implicit or explicit assumptions about names that should not be delegated in the public DNS (for example, reverse-mapping domains for private IPv4 space in RFC 1918).[4]
As conventions accumulated, the lack of a central registry made it difficult to track which names had special handling and how implementations should treat them. RFC 6761 responds to this by defining a common framework and consolidating them into a single IANA-managed registry.[1][5]
Definition and Scope[edit | edit source]
RFC 6761 defines a Special-Use Domain Name as a domain name that is reserved by an IETF specification for a specific purpose and that may require handling different from ordinary names looked up via the global DNS root.[1] It distinguishes two aspects: designating the name as special-use in an IETF document; and registering that special use in the IANA Special-Use Domain Names registry, with a reference to the defining document.[6]
These are not limited to top-level domains. They can appear at other points in the namespace, including reverse-mapping domains under .arpa. RFC 6761 also makes clear that some special-use names are still resolved via the DNS protocol, while others signal that resolution should occur by other means or should not occur at all.[6]
Section 5 of the RFC requires authors who propose a new special-use name to analyse its impact on users, applications, APIs, recursive resolvers, authoritative servers, and IANA registries, so that implementers understand where special handling is expected.[1][6]
IANA Registry and Initial Entries[edit | edit source]
The registry at IANA was initially seeded with entries drawn from earlier specifications and operational practice.[1][7] The initial contents were:
- Documentation names from RFC 2606: .example, .invalid, .localhost, .test, plus second-level domains example.com, example.net, and example.org.
- Reverse-mapping domains for private IPv4 space: 10.in-addr.arpa, 16–31.172.in-addr.arpa and 168.192.in-addr.arpa.
- Infrastructure names such as in-addr.arpa itself.[1][7]
These entries indicate that the listed names are reserved, document the intended use, and give guidance on whether they should be resolved via the global DNS, handled locally, or treated as always non-existent.[5]
Since RFC 6761 was published, additional special-use names such as .local, .onion, home.arpa and .alt have been added to the registry by later RFCs, following the same general pattern.[7][8]
Subsequent Discussion and Problem Statement[edit | edit source]
Experience with RFC 6761 revealed tensions between the IETF-managed list of special-use names and the public DNS root administered through ICANN processes. Within ICANN, SSAC advisories such as SAC090 and SAC094 discussed the role of RFC 6761 names in broader considerations around name collisions and reserved names in the root zone.[9][10] The ICANN Name Collision Analysis Project (NCAP) Study 1 also cites RFC 6761 in its survey of reserved and collision-prone strings.[11]
Within the IETF, the policy defined in RFC 6761 for populating the registry was criticised as difficult to apply consistently. RFC 8244 documents these concerns in detail and reviews the history and implications of special-use names, recommending that any further work start from a clear problem statement.[6] The IAB also issued a statement noting controversy around the use of RFC 6761 mechanisms for names in .arpa and asking DNSOP to clarify the overlap between the special-use registry and the public DNS root.[12]
As of 2025, an Internet-Draft sometimes called rfc6761bis proposes to obsolete RFC 6761 while keeping the IANA registry and its contents, and to simplify the policy for adding new entries by placing responsibility with the IESG.[13] The registry itself remains active and continues to be referenced by new protocol work and by ICANN community discussions.
See Also[edit | edit source]
References[edit | edit source]
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 S. Cheshire, M. Krochmal, "Special-Use Domain Names", RFC 6761, IETF, February 2013.
- ↑ RFC Editor, "Information on RFC 6761" (accessed 2025-11-27).
- ↑ RFC 2606, "Reserved Top Level DNS Names", IETF, June 1999.
- ↑ RFC 1918, "Address Allocation for Private Internets", IETF, February 1996.
- ↑ 5.0 5.1 IANA, "IANA-managed Reserved Domains" (accessed 2025-11-27).
- ↑ 6.0 6.1 6.2 6.3 T. Lemon et al., "Special-Use Domain Names Problem Statement", RFC 8244, IETF, October 2017.
- ↑ 7.0 7.1 7.2 IANA, "Special-Use Domain Names" registry (accessed 2025-11-27).
- ↑ "Special-use domain name", Wikipedia (accessed 2025-11-27).
- ↑ ICANN SSAC, "SAC090: SSAC Advisory on the Stability of the Domain Name System Root", 22 December 2016.
- ↑ ICANN SSAC, "SAC094: SSAC Response to the New gTLD Subsequent Procedures PDP", 22 May 2017.
- ↑ ICANN, "NCAP Study 1: Managing the Risks of Top-Level Domain Name Collisions", 19 June 2020.
- ↑ IAB, "Internet Architecture Board statement on the registration of special use names in the ARPA domain", 30 March 2017.
- ↑ P. Hoffman, "Special-Use Domain Names Registry", Internet-Draft, 2022.
ICANNWiki resources: Special Pages | Content Guide | Documentation | Development || Maintenance: Articles needing attention | Candidates for deletion || Projects: Internet & Digital Governance Library