Networking device hostnames ending with
.local are often employed in private networks, where they are resolved either
via the multicast domain name service or local Domain Name System servers. The
implementation of both approaches on the same network can be problematic,
however, so resolving such names via “unicast” DNS servers has fallen into
disfavor as computers, printers and other devices supporting
zero-configuration networking have become increasingly common.
Multicast DNS standard Internet Engineering Task Force
standards-track RFC 6762, which has been approved and was officially published on
February 20, 2013, essentially reserves the use of local as a pseudo-TLD for
link-local hostnames that can be resolved via the Multicast DNS name
resolution protocol. Page 5 of that publication states:
…this document allows any computer user to elect to give their computers
link-local Multicast DNS host names of the form: “single-dns-label.local.”. For
example, a laptop computer may answer to the name “MyComputer.local.”…
This document specifies that the DNS top-level domain “.local.” is a special
domain with special semantics, namely that any fully qualified name ending in
“.local.” is link-local, and names within this domain are meaningful only
on the link where they originate. This is analogous to IPv4 addresses in the
169.254/16 prefix or IPv6 addresses in the FE80::/10 prefix, which are
link-local and meaningful only on the link where they originate.
Any DNS query for a name ending with the label “.local.” MUST be sent to the mDNS
IPv4 link-local multicast address 220.127.116.11…
Implementers MAY choose to look up such names concurrently via other mechanisms
and coalesce the results in some fashion. Implementers choosing to do
this should be aware of the potential for user confusion when a given name can
produce different results depending on external network conditions.
Name resolution issues may arise if multicast DNS software is used in
conjunction with a network that implements the “.local.” top-level DNS
domain. mDNS implementations
RFC 6762 was authored by two Apple Inc. employees, so it should not be
surprising that its Bonjour zeroconf networking software implements mDNS.
That service will automatically resolve the private IP addresses of link-local
Macintosh computers running OS X and mobile devices running iOS if .local is
appended to their hostnames. In addition, Bonjour devices will use those
.local hostnames when advertising services to DNS Service Discovery
clients. Most Linux distributions also
incorporate and are configured to use zero configuration networking. By
default, each computer’s Avahi daemon will respond to mDNS hostname.local
queries, and most shell commands and application program calls that attempt
to resolve such names are routed to that daemon by the default hosts: line in the
Name Service Switch configuration file. It is also possible to configure the
nss-mdns modules and Avahi to resolve hostnames with other pseudo-TLDs.
Although current Windows operating systems do not have built-in mDNS
support, it can be added by installing zeroconf software available from Apple
and other third parties. Finally, many printers and other
peripheral devices also implement the mDNS protocol in order to provide
simplified connections to them from computers that support zero
configuration networking. Microsoft recommendations
The connection of Macintosh and Linux computers or zeroconf peripherals to
Windows networks can be problematic if those networks include name servers that
use .local as a search domain for internal devices.
At one time, Microsoft at least suggested the use of .local as a
pseudo-TLD for small private networks with internal DNS servers, via documents
that are still accessible. For example, support article 296250 included the
following option: Make the name a private domain name that
is used for name resolution on the internal Small Business Server network.
This name is usually configured with the first-level domain of .local. At the
present time, the .local domain name is not registered on the Internet.
However, more recent articles have cautioned or advised against such use of
the .local TLD. Support article 300684 listed
contoso.local as an example of a “best-practice Active Directory domain
name”, but then added: We recommend that you register DNS names
for the top-most internal and external DNS namespaces with an Internet
registrar. which would of course preclude using
that or any other domain ending with .local.
Microsoft TechNet article 708159 suggested .local for the exact opposite
reason: Using the .local label for the full DNS
name for the internal domain is a more secure configuration because the .local
label is not registered for use on the Internet. This separates your internal
domain from your public Internet domain name.
but later recommended against it: If you have Macintosh client computers
that are running the Macintosh OS X version 10.3 operating system or later,
… it is recommended that you do not use the .local label for the full DNS name
of your internal domain. If you must use the .local label, then you must also
configure settings on the Macintosh computers so they can discover other
computers on the network. For more information about how to configure
client computers running Macintosh OS X version 10.3 or later, see “Connecting
Macintosh Computers to a Windows Small Business Server 2003 Network” on the
Microsoft Web site at . TechNet article 726016 cautioned against
using .local: …we do not recommend using unregistered
suffixes, such as .local. Global DNS queries
Although .local is an officially reserved Special-Use Domain Name and
such host names will never be resolvable by the global Domain Name System, a
considerable proportion of the queries submitted to it do specify that
pseudo-TLD. Current statistics for the L root name
server operated by ICANN are available from root-servers.org.
As of August 14, 2015, that server has received approximately 1331 .local
queries per second, third in frequency after .com, and .net, or sixth including
the invalid gTLDs of .www, .html, .net, and .home. From ICANN.org.
As of April 12, 2013, that server has received approximately 2300 .local
queries per second, fourth in frequency after .com, .net, and .org.
Historical data from that site are available via the Wayback Machine. In
June 2009, for example, the L server received an average of 400 such queries
per second, fourth after .com, .arpa, and .net.
See also Multicast DNS
Zero-configuration networking References