Special-use domain name

A special-use domain name is a domain name reserved within the Domain Name System (DNS) hierarchy for specific technical purposes, requiring universal and consistent treatment by all DNS software, protocols, and network hardware, rather than standard DNS resolution or registration. These names are explicitly excluded from the general domain registration process to avoid conflicts, ensure predictable behavior in specialized contexts, and support essential internet functions without relying on the global DNS infrastructure.^[1] Defined and standardized in RFC 6761, published by the Internet Engineering Task Force (IETF) in 2013, the concept of special-use domain names updates and formalizes earlier reservations from RFC 2606 (for documentation and testing) and RFC 1918 (for private IP address mappings).^[1] The policy requires that reservations be made through IETF Standards Action or IESG Approval, with detailed specifications addressing implications for users, applications, name servers, resolvers, and registrars, among others.^[1] The Internet Assigned Numbers Authority (IANA) maintains an official registry of these names, which as of 2025 includes over 40 entries, covering both top-level domains and reverse DNS zones.^[2] Prominent examples include localhost., which universally resolves to the loopback IP address (127.0.0.1 or ::1) for local testing; test., intended for non-routable private testing and typically returning NXDOMAIN responses; and example.com., example.net., and example.org., reserved for use in technical documentation and examples.^[1] Other notable reservations support specific protocols, such as onion. for the Tor network's hidden services, home.arpa. for home networking discovery, and reverse zones like 10.in-addr.arpa. for private IPv4 address spaces.^[2] These domains and their subdomains inherit the special-use status, influencing DNS caching, resolution, and delegation to promote interoperability while preventing unintended global impacts.^[1]

Definition and Purpose

Definition

Special-use domain names are domain names reserved within the Domain Name System (DNS) hierarchy for specific purposes that do not align with the standard DNS delegation and resolution processes. These names are explicitly designated to avoid general registration or public delegation, ensuring they remain unavailable for use as top-level domains (TLDs) or subdomains in the global DNS namespace. According to RFC 6761, published in 2013 by the Internet Engineering Task Force (IETF), a special-use domain name is one that applications should neither register nor attempt to resolve through the public DNS, as it serves functions outside conventional internet addressing.^[3] Unlike other reserved names such as generic TLDs (gTLDs) or country-code TLDs (ccTLDs), which are allocated and managed through established registries for public use, special-use domain names apply to both potential TLD-level labels and any subdomains beneath them without requiring hierarchical delegation. This reservation prevents their inclusion in DNS zones or root server configurations, distinguishing them from delegable domains that follow IANA oversight for allocation. The IETF's framework in RFC 6761 emphasizes that this status is not merely a naming convention but a protocol-level guideline to maintain DNS integrity across implementations.^[3] Key characteristics of special-use domain names include their non-resolvability in the public DNS infrastructure, meaning DNS resolvers and authoritative servers are instructed to treat queries for these names as invalid or local-only, rather than propagating them globally. They are employed for purposes such as documentation examples (e.g., .example), testing environments (e.g., .invalid), local network identification (e.g., .localhost), or protocol-specific operations, without supporting actual internet routing or resource records in public contexts. This design ensures interoperability by signaling to software that these names have predefined, non-standard behaviors. Furthermore, the special-use designation extends recursively: if a domain is reserved, all its subdomains inherit the same status, prohibiting any delegation or resolution attempts beneath it.^[3]

Purpose and Benefits

Special-use domain names are reserved to establish universal protocol-level behaviors in the Domain Name System (DNS), ensuring consistent handling across diverse networks and implementations regardless of connectivity.^[4] A primary purpose is to avoid name collisions, particularly in documentation and examples, where using reserved names prevents real-world confusion with globally unique domain names that might later be delegated.^[4] They also support local resolution mechanisms that operate without querying public DNS infrastructure, allowing devices to resolve names internally on a network link.^[4] Furthermore, these reservations facilitate protocol innovations by designating namespaces for specialized functionalities, such as Multicast DNS (mDNS) using the .local domain for link-local service discovery and the .onion domain in Tor for anonymized overlay networks.^[5]^[6] The benefits of special-use domain names include enhanced DNS stability through the reservation of names for non-routable, experimental, or local purposes, which reduces unnecessary queries to root and authoritative servers.^[4] This reservation minimizes administrative overhead for common setups, as organizations and users avoid the need for formal registration, delegation, or configuration of conventional DNS servers for internal or temporary uses.^[4]^[5] They promote interoperability by standardizing behaviors in protocols like mDNS, which enables zero-configuration networking, and Tor, which integrates cryptographic authentication directly into name resolution for secure, resilient services.^[5]^[6] In the broader DNS ecosystem, special-use domain names ensure predictable resolver behavior by mandating specific responses, such as non-existence indicators, which prevent the leakage of local or invalid queries to upstream servers and maintain system integrity.^[4] Unlike private IP addresses, such as those in the 192.168.0.0/16 range defined in RFC 1918, which are configurable at the network layer for local use without global coordination, special-use domain names operate at the naming layer with protocol-enforced semantics to guarantee consistent, universal treatment across all implementations.^[4]

History and Standards

Origins and RFC 6761

The concept of special-use domain names evolved from earlier efforts to reserve portions of the Domain Name System (DNS) namespace for specific, non-routable purposes, avoiding conflicts in documentation, testing, and local networking. In 1999, RFC 2606 introduced reserved top-level domains such as .test, .example, and .invalid to prevent their use in production environments and support illustrative examples in technical specifications.^[7] These reservations addressed ad-hoc needs but lacked a formalized process for broader special uses, including reverse-mapping domains for private IP address spaces defined in RFC 1918, such as 10.in-addr.arpa. In the early 2010s, discussions within the Internet Engineering Task Force (IETF) highlighted the need for a structured framework to reserve domain names requiring consistent, universal handling across DNS implementations, similar to special-use IPv4 addresses outlined in RFC 5735. This was driven by growing applications like multicast DNS (mDNS), which informally reserved names such as .local for local network discovery without global delegation. The initiative aimed to standardize behaviors for resolvers and applications, ensuring that certain names trigger specific actions like local resolution or error responses rather than attempts to query authoritative servers. RFC 6761, titled "Special-Use Domain Names," was published in February 2013 as a Proposed Standard by the IETF, authored by Stuart Cheshire and Marc Krochmal of Apple Inc.^[3] It defines a special-use domain name as one reserved to require special treatment by DNS clients, servers, and applications, with no delegation to authoritative name servers and prescribed resolver behaviors such as generating NXDOMAIN responses or local synthesis.^[1] The document updates prior reservations from RFC 2606 and RFC 1918, emphasizing criteria like the necessity for global consistency and avoidance of operational impacts on the public DNS. Key provisions in RFC 6761 establish a process for proposing new special-use names through IETF Standards Action or IESG Approval, requiring proposers to address considerations across seven categories, including effects on users, software, and network operators.^[1] It also creates an IANA registry for these names and introduces an initial list of reserved domains, including .test for experimentation, .example (with second-level variants like example.com), .invalid for invalid name testing, and .localhost for loopback addressing.^[1] This foundational registry formalized the handling of these names to promote interoperability without altering core DNS protocols.

Evolution Through Subsequent RFCs

Following the foundational framework established in RFC 6761, which initially registered a small set of special-use domain names, subsequent RFCs have progressively expanded the registry to accommodate emerging network protocols and use cases. In 2013, RFC 6762 designated ".local" as a special-use domain to support Multicast DNS (mDNS) operations on local links without requiring a central DNS authority.^[5] This was followed in 2015 by RFC 7686, which reserved ".onion" for the Tor protocol, enabling anonymized, end-to-end encrypted services by obscuring server identities and locations.^[6] By 2018, RFC 8375 introduced "home.arpa" under the .arpa namespace for non-unique use in residential home networks, updating the Home Networking Control Protocol to leverage this domain for local resolution. The evolution continued into the 2020s with additions tailored to specific technical needs. RFC 8880 in 2020 registered "ipv4only.arpa" as a special-use domain for NAT64 prefix discovery in IPv6-dominant networks, along with associated reverse mappings such as 170.0.0.192.in-addr.arpa and 171.0.0.192.in-addr.arpa to facilitate PTR record queries.^[8] In 2021, RFC 9031 allocated "6tisch.arpa" under .arpa for the Constrained Join Protocol in 6TiSCH networks, serving as an anycast identifier for secure device joining in IoT environments.^[9] Further advancements in 2023 included RFC 9462, which designated "resolver.arpa" to enable DNS clients to discover encrypted resolvers (such as DoH or DoT) via SVCB records, and RFC 9476, reserving ".alt" as a top-level domain for non-DNS contexts like alternative naming systems in applications.^[10]^[11] More recent developments reflect ongoing refinements. In 2025, RFC 9665 registered "service.arpa" to support the Service Registration Protocol for DNS-Based Service Discovery, allowing constrained devices to update unicast DNS records for service advertisement.^[12] Deprecations have also occurred to streamline the registry; for instance, "eap-noob.arpa," originally allocated in RFC 9140 for EAP-NOOB authentication, was marked as deprecated in favor of alternatives like "[email protected]" to better align with provisioning needs in the Extensible Authentication Protocol framework.^[13]^[2] The IANA Special-Use Domain Names registry, established in 2012 pursuant to RFC 6761 guidelines, manages these allocations and has grown significantly, listing 47 entries as of its last update on October 6, 2025.^[2] This expansion underscores the IETF's adaptive approach to reserving domain names for specialized, non-global DNS functions while preventing conflicts in the broader internet namespace.^[4]

Categories of Special-Use Domains

Documentation and Testing Domains

Special-use domain names designated for documentation and testing purposes are reserved to prevent conflicts with production DNS infrastructure, allowing safe illustration and experimentation without impacting real-world networks. These domains were initially established in RFC 2606, published in June 1999 as an Internet Best Current Practice (BCP 32), which permanently reserves specific top-level domains (TLDs) for non-operational uses.^[14] This framework was reaffirmed and expanded in RFC 6761 (February 2013), which introduces formal guidelines for their resolution behavior and establishes an IANA registry for special-use domains to ensure consistent implementation across DNS software.^[4] The .example TLD is exclusively reserved for use in technical documentation, tutorials, and sample configurations. Its primary purpose is to provide unambiguous examples of domain names in written materials, avoiding any risk of collision with actual registered domains. Separately, the second-level domains example.com, example.net, and example.org are also reserved for the same purpose.^[14] According to RFC 6761, queries for .example domains may be resolved normally by caching or authoritative DNS servers if locally configured, but they are not intended for public resolution and hold no operational status.^[4] The .test TLD is designated for non-production testing environments, particularly for developing and evaluating DNS-related code and applications. It enables isolated experimentation without queries being forwarded to the global DNS, as resolvers are instructed to return immediate negative responses by default.^[4] This reservation ensures that .test domains remain free from central authority or public registration, supporting private, controlled testing scenarios.^[14] In contrast, the .invalid TLD serves to construct domain names that are explicitly meant to be unresolvable, signaling invalidity in applications or tests. DNS servers and name resolution APIs must respond to .invalid queries with an immediate NXDOMAIN (non-existent domain) error, guaranteeing no resolution occurs.^[4] This domain is particularly useful for validating error-handling behaviors in software.^[14] These domains are commonly employed in RFCs, software documentation, and educational resources to demonstrate DNS concepts without requiring actual domain ownership or risking unintended network interactions. For instance, .example appears frequently in IETF documents to illustrate query examples, while .test and .invalid facilitate safe prototyping of DNS clients and servers.^[4] Their use promotes clarity and reliability in technical communications by standardizing placeholder names across the internet community.^[14]

Local and Private Network Domains

Special-use domains for local and private networks are designed to facilitate naming within isolated or non-routable environments, such as loopback interfaces, home networks, and internal enterprise setups, without requiring delegation from the public DNS root. These domains ensure that local applications and devices can resolve names efficiently while preventing conflicts with global DNS infrastructure.^[4] The .localhost domain is reserved exclusively for the loopback interface, mapping to the IPv4 address 127.0.0.1 and the IPv6 address ::1. It serves as a standard mechanism for self-referencing in host files, local applications, and development environments, allowing systems to communicate with themselves without external network involvement. This reservation, established in RFC 6761, prohibits delegation of .localhost in the public DNS and mandates that resolvers handle it locally to avoid unnecessary queries.^[4] In contrast, the .local domain is designated for use with Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD), enabling zero-configuration networking on local links without a traditional unicast DNS server. Devices on the same network can discover and resolve services, such as printers or file shares, by appending .local to hostnames (e.g., printer.local). This approach is integral to protocols like Apple's Bonjour, which relies on mDNS for seamless service advertisement and resolution in home or office environments. As specified in RFC 6762, .local must not be delegated publicly, and queries for it should be resolved via multicast on the local link.^[5] For residential home networks, the .home.arpa domain provides a structured namespace for internal naming of devices and services, such as smart home appliances, without exposing them to the public internet. Introduced in RFC 8375 in 2018, it supports protocols like the Home Networking Control Protocol (HNCP) by allowing local DNS resolvers to manage names hierarchically under .home.arpa, ensuring uniqueness within the home while avoiding collisions with global domains. This special-use designation prevents registration in the public DNS and promotes privacy by keeping home network details isolated. Reverse DNS mappings for private IP addresses, as defined in RFC 1918, use dedicated zones under in-addr.arpa to enable local resolution of IPv4 addresses in non-routable ranges: 10.in-addr.arpa for the 10.0.0.0/8 block, 16.172.in-addr.arpa through 31.172.in-addr.arpa for the 172.16.0.0/12 block, and 168.192.in-addr.arpa for the 192.168.0.0/16 block. These zones are intended for local serving only, as public DNS servers should not respond to queries for them to prevent leakage of private network information. RFC 6303 formalizes this practice, recommending that sites configure their own resolvers for these zones to support internal operations like logging and diagnostics without global exposure.^[15]

Advanced and Protocol-Specific Domains

Security and Overlay Network Domains

Special-use domain names in the security and overlay network category are designed to support protocols and systems that prioritize privacy, anonymity, and secure authentication, often operating outside the conventional Domain Name System (DNS) resolution process. These domains facilitate end-to-end encrypted communications and alternative resolution mechanisms, ensuring that queries are handled by specialized software rather than standard DNS resolvers. By reserving these labels, the Internet Engineering Task Force (IETF) prevents their delegation in the public DNS, reducing risks such as domain hijacking or unintended exposure of sensitive services. The .onion domain is reserved exclusively for The Onion Router (Tor) hidden services, enabling anonymous access to services without revealing the server's identity or location. Introduced in RFC 7686 in 2015, .onion addresses are self-authenticating, derived from the service's public key, and resolved through Tor's distributed hash table rather than traditional DNS queries. This setup allows clients to connect via multiple encrypted relays, providing strong anonymity for both users and service providers in applications like whistleblower platforms and privacy-focused websites. Standard DNS resolvers must reject .onion queries to avoid leakage to the public internet. Similarly, the .alt domain, defined in RFC 9476 published in 2023, serves as a special-use top-level domain for alternative name resolution in non-DNS contexts, particularly in secure and privacy-oriented environments. It supports systems that employ custom resolution protocols, such as those in encrypted messaging or decentralized networks, where names under .alt are not intended for global DNS lookup. Developers are advised to use .alt labels in configurations for local or application-specific name spaces, ensuring compatibility with tools that recognize it as non-routable in the public DNS. This reservation helps prevent conflicts with delegated top-level domains while promoting secure, isolated naming in experimental or proprietary setups.^[16] The eap.arpa subdomain is designated for dynamic delegation in the Extensible Authentication Protocol (EAP), aiding secure network authentication processes such as those in Wi-Fi or VPN setups. As outlined in draft-ietf-emu-eap-arpa-10, last revised in September 2025 and pending publication as an RFC, eap.arpa enables provisional domain names during EAP negotiations, allowing authenticators to assign temporary identifiers for client-server interactions without relying on external DNS. This facilitates rapid, secure bootstrapping of credentials in enterprise or mobile networks, with resolvers directed to handle queries locally via EAP-specific mechanisms. These domains distinguish themselves by intentionally bypassing standard DNS infrastructure to enhance security; resolvers are required to process .onion, .alt, and eap.arpa queries through dedicated protocols like Tor's overlay network or EAP handlers, rather than forwarding them upstream, thereby maintaining isolation from the global namespace.^[16]

Reverse DNS and Infrastructure Domains

Special-use domain names play a critical role in reverse DNS mappings for specific IP address ranges and in supporting core DNS infrastructure functions. Reverse DNS, or rDNS, translates IP addresses back to domain names, and certain special-use domains are reserved exclusively for this purpose with non-routable or infrastructure-specific IP spaces to prevent conflicts in global DNS resolution. These domains ensure that queries for special IP addresses are handled locally or through defined mechanisms without requiring delegation in the public DNS hierarchy. One key set of reverse mappings addresses special IP address allocations. For IPv4 link-local addresses in the 169.254.0.0/16 range, used in Zeroconf networking for automatic configuration without a DHCP server, the domain 254.169.in-addr.arpa. is designated. This allows reverse lookups for these auto-assigned addresses to resolve appropriately in local networks. For IPv6 link-local addresses (fe80::/10), the domains 8.e.f.ip6.arpa., 9.e.f.ip6.arpa., a.e.f.ip6.arpa., and b.e.f.ip6.arpa. provide reverse resolution, enabling mDNS queries to be multicast to the appropriate link-local addresses for service discovery and name resolution in the absence of a unicast DNS infrastructure. Additionally, for IPv4-embedded IPv6 addresses in NAT64 environments, the domains 170.0.0.192.in-addr.arpa. and 171.0.0.192.in-addr.arpa. support reverse mappings, facilitating compatibility between IPv4 and IPv6 during network transitions. Infrastructure domains under .arpa. further extend special-use capabilities for transitional and operational needs. The .ipv4only.arpa. domain, introduced in 2020, is specifically for NAT64 and DNS64 scenarios where IPv6 networks need to access IPv4-only resources. It allows clients to query for IPv4 addresses in IPv6-dominant environments by synthesizing responses that map IPv4 queries to equivalent IPv6 representations, easing the IPv4-to-IPv6 migration without altering existing applications. The .resolver.arpa. domain enables discovery of DNS resolver capabilities and configurations. Defined in 2023, it supports queries via Service Binding (SVCB) and HTTPS records to identify designated resolvers that offer encrypted DNS protocols like DNS over HTTPS (DoH) or DNS over TLS (DoT). This allows clients to automatically detect and connect to secure resolvers provided by the network, enhancing privacy and security in DNS operations without manual configuration. Similarly, .service.arpa. facilitates advanced service discovery in infrastructure settings through the Service Registration Protocol (SRP) for DNS-based enumeration. Specified in RFC 9665 in June 2025, it permits servers to register offered services using unicast DNS updates, enabling scalable discovery of resources like printers or file shares in enterprise networks beyond traditional multicast limits.^[17] In Internet of Things (IoT) contexts, the 6tisch.arpa. domain supports the 6TiSCH protocol, which provides IPv6 over time-slotted channel hopping (TSCH) in IEEE 802.15.4e networks for low-power wireless mesh topologies. Established in 2021, it serves as an anycast identifier for join coordinators in constrained join protocols, allowing pledges (new devices) to securely bootstrap into the network by resolving the domain to obtain IPv6 addresses for enrollment and operation. These reverse and infrastructure domains collectively ensure robust handling of special IP mappings and DNS operational discovery, maintaining compatibility and security in diverse network environments while adhering to IETF standards for non-delegated resolution.

Usage Guidelines and Implications

DNS Resolution Rules

DNS resolvers are required to handle special-use domain names in a manner that prevents unnecessary network traffic and ensures consistent local behavior, as defined in RFC 6761. Specifically, resolvers must not perform root referrals or forward queries for special-use names to authoritative DNS servers; instead, they should process these queries locally or generate appropriate negative responses to sink the queries without upstream propagation. This rule applies universally to all special-use domains to avoid loading the global DNS infrastructure with non-routable or test-related requests.^[18] For particular domains, resolution behaviors are precisely specified to align with their intended purposes. Queries for names ending in .localhost should resolve to loopback addresses, such as 127.0.0.1 for IPv4 or ::1 for IPv6, for address (A or AAAA) record types, while other record types receive negative responses; name resolution APIs must not forward .localhost queries to caching DNS servers. Similarly, .invalid names trigger immediate NXDOMAIN responses, indicating non-existence, and APIs should handle these locally without sending queries upstream. For .test, caching DNS servers generate negative responses by default, treating these names as non-existent in public contexts, though a configuration option (disabled by default) may allow upstream resolution for controlled environments.^[19]^[20]^[21] Subsequent RFCs extend these rules for protocol-specific domains. For .local, used in Multicast DNS (mDNS), resolvers must send queries via multicast to the link-local group (224.0.0.251 for IPv4 or FF02::FB for IPv6 on UDP port 5353) and must not issue unicast queries to DNS servers, which should respond with NXDOMAIN if queried. In the case of .onion, associated with the Tor network, resolvers must either resolve via the Tor protocol or a proxy (e.g., SOCKS) or return NXDOMAIN; caching and authoritative servers must not perform lookups and should immediately return NXDOMAIN to prevent leakage.^[22]^[23]^[24] Error handling emphasizes preventing unintended network activity: applications and stub resolvers should recognize special-use names early to avoid forwarding queries, thereby reducing risks of traffic to external servers or exposure of local configurations. If a special-use name is encountered without local handling capabilities, the system should generate an error or NXDOMAIN rather than attempting global resolution. These guidelines ensure that special-use domains remain isolated from the public DNS, promoting security and efficiency in diverse network environments.^[25]^[26]

Registration and Management

The Special-Use Domain Names registry is maintained by the Internet Assigned Numbers Authority (IANA) since its creation on July 6, 2012, and is publicly accessible at iana.org/assignments/special-use-domain-names.^[2] This registry documents domain names reserved for special purposes, applying the designation to both the listed domains and their subdomains, with available formats including CSV, XML, HTML, and plain text for easy access and integration.^[2] Additions to the registry require either a Standards Action, involving the publication of a full Request for Comments (RFC), or IESG Approval, as defined in RFC 5226.^[27] Proposals are submitted through the Internet Engineering Task Force (IETF) for review, where applicants must demonstrate a clear special need for universal protocol-level handling, ensure no conflicts with existing DNS mechanisms or other domain reservations, and specify precise resolver behaviors, such as returning NXDOMAIN or mapping to loopback addresses.^[27] The IANA, in consultation with the Internet Engineering Steering Group (IESG), verifies that proposals include a dedicated "Domain Name Reservation Considerations" section addressing these criteria before approval.^[27] The registry undergoes periodic updates to reflect new designations, deprecations, or changes; the most recent update occurred on October 6, 2025.^[2] Deprecation mechanisms allow for the retirement of entries when they are superseded, as seen with "eap-noob.arpa.", which was marked as deprecated following its replacement in the Extensible Authentication Protocol framework per RFC 9140 and subsequent updates.^[2] Oversight of the registry is provided by the IETF and IESG to ensure all reservations align with DNS best practices and do not circumvent standard registration processes.^[27] Unlike generic top-level domains managed through ICANN-accredited registrars, special-use domains receive no delegation or registration services, remaining strictly reserved at the protocol level without hierarchical sub-delegation.^[2]