Jump to content

Special-Use Domain Name

For the technical specification, see RFC 6761.

Special-Use Domain Names are those that Internet protocols treat in a non-standard way, often outside the normal public DNS resolution path. They are recorded in a dedicated IANA registry created by RFC 6761 and are used to avoid ambiguity between the global DNS root and names that are meant for documentation, local networking, privacy-preserving overlays, or alternative naming systems.[1][2][3]

From an Internet Governance perspective, these names sit at the intersection of protocol design, DNS operations, and naming policy. They have implications for name collisions, the scope of the ICANN community’s authority over the DNS root, and the relationship between the IETF, IANA, and ICANN.

Concept and Rationale edit

In RFC 6761, appropriate reservation of a name for “special use” is defined, as well as how the IETF can request such a registration in the IANA Special-Use Domain Names registry.[1] The RFC consolidates pre-existing conventions such as documentation and test names like example.com, .example, .test and .invalid; and infrastructure labels such as reverse-mapping zones for private address space (for example, 10.in-addr.arpa and the RFC 1918 ranges).[3]

Later specifications added names that signal particular resolution mechanisms or namespaces, including:

Governance Significance edit

Special-use domain names raise questions about who decides what strings can or cannot appear in the DNS root and how to coordinate between the IETF’s protocol work and ICANN’s naming policies.

RFC 8244 collected the problems that emerged when RFC 6761 was applied in practice. Issues include the lack of a formal coordination mechanism between the IETF and ICANN, uncertainties about what kinds of names should be reserved this way, and confusion among implementers about the obligations that registration in the special-use registry implies.[10] The document notes that the policy defined in RFC 6761 “has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written”, and explicitly references ICANN’s SSAC work on name collisions and stability.[10]

In parallel, the SSAC has treated special-use names as part of a broader problem: overlapping use of the domain namespace by public DNS, private namespaces, and alternative naming systems. SAC090 (SSAC Advisory on the Stability of the Domain Namespace) examines ambiguities created when the same label is used in different contexts, and recommends collaborative processes among “various interested parties” to coordinate activities related to the domain namespace.[11][12]

APNIC commentary on IETF work has highlighted “confusion over the IETF’s role as the custodian of the RFC 6761 Special Use names registry and ICANN’s role as the name policy community for generic TLDs”, especially when proposals such as .alt or .internal touch topics that the ICANN community also sees as its remit.[13]

Within ICANN’s policy processes, special-use names appear in discussions about reserved names and in the context of the New gTLD Program. SAC094, in its response to the New gTLD Subsequent Procedures PDP, explicitly asks whether special-use names should be added to the Applicant Guidebook’s list of reserved strings to prevent applications for labels that the IETF has already designated for special use.[14]

Examples and Private Namespaces edit

Prominent special-use names illustrate how the mechanism is used to separate particular use cases from the public DNS and to reduce name collisions.

The label .onion, registered by RFC 7686, is reserved for Tor onion services and is not meant to appear in the public DNS at all.[8][15] Its designation as special-use tells resolvers not to send queries for .onion names to the DNS root and provides a stable hook for browser behaviour and Web PKI rules, while leaving the details of the Tor namespace to a separate technical and policy discussion.

The label .local is reserved for link-local names resolved using Multicast DNS rather than the global DNS; software is expected to intercept such names and handle them via mDNS, effectively isolating a local naming scope from the public root while keeping familiar DNS-like syntax.[16][5]

home.arpa was introduced as a special-use domain for residential gateways and home networks after widespread informal use of .home led to leakage into the root and to name collision concerns in the first New gTLD Program round.[6][7][17] By providing a documented, non-delegated namespace for home networks, it gives vendors and ISPs a safer alternative to ad hoc TLDs.

RFC 9476 reserves .alt as a generic suffix for alternative namespaces, such as blockchain-based or peer-to-peer naming systems that deliberately sit outside the DNS.[9][3] Names ending in .alt are meant to be resolved only by those systems, not by DNS resolvers, and the label signals that they are not candidates for delegation in the public DNS root.

On the ICANN side, .internal was reserved by Board resolution (July 2024) as a TLD for private-use and internal network applications, with the aim of steering operators away from undelegated choices such as .corp, .home or .lan that might later collide with public delegations.[18] This follows the recommendation in SSAC113 for a dedicated private-use TLD that can aggregate such internal naming and reduce collision risk.[19]

Taken together, these examples show how special-use names, ICANN-reserved labels and private-use TLDs are being used to structure non-public naming in ways that are less likely to conflict with the global DNS.

Name Collisions, New gTLD Rounds, and Alternative Namespaces edit

Special-use names are closely tied to the broader problem of name collisions: situations where the same label is used in private namespaces and in the public DNS, producing ambiguous or surprising resolution. SAC090 frames collisions as a structural risk in an environment where “no one owns (or can own) the domain namespace” and where designers will continue to create private naming schemes regardless of policy decisions.[11][12]

In the first New gTLD round, heavy internal use of strings such as .corp, .home and .mail generated substantial leakage into the root and led ICANN to halt delegation of those labels. The subsequent Name Collision Analysis Project (NCAP) documented the operational impact and proposed frameworks for managing collision risk.[20] SSAC and the ICANN Board have both recommended that future gTLD rounds integrate special-use names, reserved strings and collision management into a coherent policy before new applications proceed.[14][21] SAC094 explicitly raises the question of whether all special-use names should be listed as reserved in the Applicant Guidebook, to avoid applications for labels that the IETF has already set aside.[14]

From the protocol side, RFC 8244 notes that the RFC 6761 policy for populating the special-use registry has been difficult to apply consistently and that the lack of a formal coordination process with ICANN complicates management of the namespace.[10] Earlier SSAC work such as SAC009 warned that large-scale deployment of alternative TLD name systems and roots could fragment the single coherent namespace assumed by users and applications, and highlighted the need for cooperation between protocol and policy communities.[22]

More recent analysis in SAC123 examines blockchain-based naming and other non-DNS systems that imitate DNS syntax. It stresses that as these ecosystems grow, collisions between DNS and non-DNS names may undermine user trust in Internet identifiers.[23] In this landscape, mechanisms such as the special-use registry (for names like .alt) and ICANN-reserved private TLDs (such as .internal) are attempts to give private and alternative namespaces clearer boundaries while preserving the integrity of the public DNS root.

References edit

  1. ↑ 1.0 1.1 S. Cheshire, M. Krochmal, "Special-Use Domain Names", RFC 6761, IETF, February 2013.
  2. ↑ IANA, "IANA-managed Reserved Domains" (accessed 2025-12-02).
  3. ↑ 3.0 3.1 3.2 "Special-use domain name", Wikipedia (accessed 2025-12-02).
  4. ↑ S. Cheshire, M. Krochmal, "Multicast DNS", RFC 6762, IETF, February 2013.
  5. ↑ 5.0 5.1 ".local", Wikipedia (accessed 2025-12-02).
  6. ↑ 6.0 6.1 P. Pfister, T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, IETF, May 2018.
  7. ↑ 7.0 7.1 ".arpa", Wikipedia – section on home.arpa (accessed 2025-12-02).
  8. ↑ 8.0 8.1 J. Appelbaum, A. Muffett, "The '.onion' Special-Use Domain Name", RFC 7686, IETF, October 2015.
  9. ↑ 9.0 9.1 P. Hoffman et al., "The .alt Special-Use Top-Level Domain", RFC 9476, IETF, September 2023.
  10. ↑ 10.0 10.1 10.2 T. Lemon et al., "Special-Use Domain Names Problem Statement", RFC 8244, IETF, October 2017.
  11. ↑ 11.0 11.1 ICANN SSAC, "SAC090: SSAC Advisory on the Stability of the Domain Namespace", December 2016.
  12. ↑ 12.0 12.1 Google Research, "SAC090 – SSAC Advisory on the Stability of the Domain Namespace" (accessed 2025-12-02).
  13. ↑ G. Huston, "Thoughts from IETF 106", APNIC Blog, 27 November 2019.
  14. ↑ 14.0 14.1 14.2 ICANN SSAC, "SAC094: SSAC Response to the New gTLD Subsequent Procedures Policy Development Process Working Group", May 2017.
  15. ↑ ".onion", Wikipedia (accessed 2025-12-02).
  16. ↑ S. Cheshire, M. Krochmal, "Multicast DNS", RFC 6762, IETF, February 2013.
  17. ↑ ".home", Wikipedia (accessed 2025-12-02).
  18. ↑ ".internal", Wikipedia (accessed 2025-12-02).
  19. ↑ ICANN SSAC, "SAC113: SSAC Advisory on Private-Use TLDs", 18 September 2020.
  20. ↑ K. Scarfone et al., "Managing the Risks of Top-Level Domain Name Collisions", NCAP Study 1, June 2020.
  21. ↑ ICANN Board, "Board Action on SSAC Advice", 8 June 2018.
  22. ↑ ICANN SSAC, "SAC009: Alternative TLD Name Systems and Roots: Conflict, Control and Consequences", 31 March 2006.
  23. ↑ ICANN SSAC, "SAC123: SSAC Report on the Evolution of the Internet Name Space", 15 December 2023.

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).

Retrieved from "https://icannwiki.org/index.php?title=Special-Use_Domain_Name&oldid=1398459"
Semantic properties for "Special-Use Domain Name"
RDF feed