.local. is the mDNS top-level domain. From RFC 6762:
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
.local. MUST be sent to the
mDNS IPv4 link-local multicast address 184.108.40.206 (or its IPv6
You get those special semantics only when using
.local. So you should name your devices accordingly:
However, it is still possible to set up your DNS so that also the simple
movies.nas resolves to your local address.
It is unimportant whether a name ending with
because the user explicitly typed in a fully qualified domain name
.local., or because the user entered an unqualified
domain name and the host software appended the suffix
because that suffix appears in the user's search list. The
suffix could appear in the search list because the user manually
configured it, or because it was received via DHCP [RFC2132] or via
any other mechanism for configuring the DNS search list. In this
.local. suffix is treated no differently from any other
search domain that might appear in the DNS search list.
DNS queries for names that do not end with
.local. MAY be sent to
the mDNS multicast address, if no other conventional DNS server is
available. This can allow hosts on the same link to continue
communicating using each other's globally unique DNS names during
network outages that disrupt communication with the greater Internet.
When resolving global names via local multicast, it is even more
important to use DNS Security Extensions (DNSSEC) [RFC4033] or other
security mechanisms to ensure that the response is trustworthy.
Resolving global names via local multicast is a contentious issue,
and this document does not discuss it further […].
(from 3. Multicast DNS Names)
The option to fail-over to Multicast DNS for names not ending in
.local. SHOULD be a user-configured option, and SHOULD be disabled
by default because of the possible security issues related to
unintended local resolution of apparently global names. Enabling
Multicast DNS for names not ending in
.local. may be appropriate on
a secure isolated network, or on some future network were machines
exclusively use DNSSEC for all DNS queries, and have Multicast DNS
responders capable of generating the appropriate cryptographic DNSSEC
signatures, thereby guarding against spoofing.
The option to look up unqualified (relative) names by appending
.local. (or not) is controlled by whether
.local. appears (or
not) in the client's DNS search list.
(from 13. Enabling and Disabling Multicast DNS)
If DNS queries for global DNS names are sent to the mDNS multicast
address (during network outages which disrupt communication with the
greater Internet) it is especially important to use DNSSEC, because
the user may have the impression that he or she is communicating with
some authentic host, when in fact he or she is really communicating
with some local host that is merely masquerading as that name. This
is less critical for names ending with
.local., because the user
should be aware that those names have only local significance and no
global authority is implied.
Most computer users neglect to type the trailing dot at the end of a
fully qualified domain name, making it a relative domain name (e.g.,
www.example.com). In the event of network outage, attempts to
positively resolve the name as entered will fail, resulting in
application of the search list, including
.local., if present. A
malicious host could masquerade as
www.example.com. by answering
the resulting Multicast DNS query for
avoid this, a host MUST NOT append the search suffix
present, to any relative (partially qualified) host name containing
two or more labels. Appending
.local. to single-label relative
host names is acceptable, since the user should have no expectation
that a single-label host name will resolve as is. However, users who
local in their search lists should be
aware that if they type
www into their web browser, it may not be
immediately clear to them whether the page that appears is
(from 21. Security Considerations)
So you could set up the name resolvers on all your clients to use
.local., not just
., in their search list, and it would resolve
.camera (and also everything else) via mDNS; at least if no global resolver is available. And that's exactly the problem, you will likely conflict with some global names, e.g.
.kitchen and many many others are actually registered top-level domains.
One approach to remedy this is to buy the respective global domain yourself, to ensure it won't be used by anyone else in a conflicting manner, but the recommended approach is to use single-label domain names for your mDNS devices, i.e.
Furthermore, if you are using mDNS for service discovery (RFC6763), you can give those services completely arbitrary userfriendly names, e.g.
My most lovely NAS._http._tcp.local.
The livingroom machine._ipp._tcp.local.
In a service browser, only the first label will be visible to the user as the service name.