.local
.local is a Special-Use Domain Name reserved by the IETF so that it cannot be delegated as a top-level domain in the public [[DNS root. RFC 6762 designates .local. as a link-local namespace for hostnames resolved using Multicast DNS (mDNS) and zero-configuration networking, rather than via conventional unicast DNS.[1][2]
Role in Multicast DNS[edit | edit source]
Multicast DNS provides DNS-like naming on a local link when no unicast DNS server is available. RFC 6762 specifies that any fully qualified name ending in .local. is treated as link-local: such queries are sent to the mDNS IPv4 multicast address "224.0.0.251" or IPv6 address FF02::FB on UDP port 5353, and have meaning only on the originating link.[1] Software is expected to intercept these names and resolve them via mDNS instead of forwarding them to recursive resolvers or the DNS root.[2]
This behaviour underlies zero-configuration service discovery frameworks and open-source implementations like Avahi, where devices advertise hostnames such as printer.local. or host.local. that should never appear in the global DNS.[2] IANA lists .local in its registry of Special-Use Domain Names accordingly.[3]
Legacy Private Use and Conflicts[edit | edit source]
Long before Multicast DNS was standardised, system and network administrators widely adopted .local as an informal "private TLD" for internal naming, particularly in environments using Active Directory (for example, corp.local).[4] This practice pre-dated RFC 6762 and was never backed by a delegation in the public DNS, but became embedded in vendor documentation and tooling.
Once .local was formally reserved for mDNS, these legacy uses began to conflict with link-local behaviour on modern operating systems. Apple explicitly warns that Bonjour’s use of .local for mDNS, as documented in RFC 6762 and the IANA registry, can prevent Apple devices from correctly resolving unicast DNS names or joining Active Directory domains that end in .local.[5] Linux distributions similarly caution that domain names ending in .local may clash with mDNS resolution, causing failures when joining such domains.[6]
These conflicts are not limited to a single vendor; operational experience and community discussions describe intermittent name-resolution problems, inconsistent behaviour between platforms, and security concerns when mDNS and unicast DNS both respond to names under .local in the same environment.[4][7]
Name Collisions and Governance Aspects[edit | edit source]
From an Internet Governance perspective, .local illustrates several recurring themes in the interaction between protocol design, operational practice, and naming policy.
Because .local is reserved for mDNS and never delegated in the DNS root, it is not available to the New gTLD Program, and ICANN material often cites it alongside .onion as a label that is explicitly outside the gTLD application space.[8] At the same time, historic private use of .local means that queries for such names still leak into the public DNS infrastructure when systems or resolvers are misconfigured. Measurements of NXDOMAIN traffic, including large-scale studies of DNS traffic from national networks, observe persistent query volume for .local and treat it as part of the overall Name Collision problem.[9]
APNIC commentary on IETF discussions notes that operators have long "invented their own label" for local use, including .local, .home, .corp and .mail, and that this practice became problematic once ICANN began delegating new TLDs at scale.[4] ICANN’s Security and Stability Advisory Committee (SSAC) has highlighted such overlaps in advisories on namespace stability and name collisions, treating .local as one of several examples where private or special-use naming intersects with the public DNS and needs coordinated handling.[10][11]
In this landscape, .local functions as a concrete case study in how special-use labels, ad hoc private namespaces, and ICANN-reserved names (such as .internal) interact. It shows that reserving a label at the protocol level is not sufficient on its own: long-lived operational habits and vendor guidance can continue to generate collisions and ambiguity unless they are aligned with the special-use designation.
See Also[edit | edit source]
References[edit | edit source]
- ↑ 1.0 1.1 S. Cheshire, M. Krochmal, "Multicast DNS", RFC 6762, IETF, February 2013.
- ↑ 2.0 2.1 2.2 ".local", Wikipedia (accessed 2025-12-11).
- ↑ IANA, "IANA-managed Reserved Domains" (accessed 2025-12-11).
- ↑ 4.0 4.1 4.2 G. Huston, "DNS talk @ IETF 111", APNIC Blog, 4 August 2021.
- ↑ Apple, "Apple devices might not open your internal network's '.local' websites", 2024.
- ↑ SUSE, "Active Directory support – Names ending in .local", SLES 15 SP6 (accessed 2025-12-11).
- ↑ Veeam Community, "Why using .local as your domain name extension is a BAD idea", 15 May 2023.
- ↑ "What's in a Name?", CircleID, 22 December 2015.
- ↑ L. Wei, "Deep dive into China’s NXDOMAIN data", APNIC Blog, 21 February 2024.
- ↑ ICANN SSAC, "SAC090: SSAC Advisory on the Stability of the Domain Namespace", December 2016.
- ↑ ICANN SSAC, "SAC123: SSAC Report on the Evolution of the Internet Name Space", 15 December 2023.
ICANNWiki resources: Special Pages | Content Guide | Documentation | Development || Maintenance: Articles needing attention | Candidates for deletion || Projects: Internet & Digital Governance Library