If I don't want to use .local for mDNS services, can I use a different Top-Level Domain (TLD)?

Say for example, could I setup a few home NAS devices, and name them something like:

  • movies.nas
  • pictures.nas

Or rename some printers to

  • livingroom.printer
  • upstairs.printer

Or rename some IoT devices in my home to something more meaningful like:

  • patio.lights
  • bedroom.lights
  • garage.door
  • driveway.camera

How could I do it, and what issues could this cause?

  • mDNS is a zero-conf, so it kinda expects that you don't want to configure much of anything. its most useful in circumstances where people don't care about anything other than that it just works. since you want to do your own thing, as it were, it may be best to implement your own DNS server. One thing to note however, is that since you want to implement tld's, be careful to choose names that don't overlap with established gtld's, or you may find those zones inaccessible. it may be better to use a single tld, and create subdomains, as is traditional. Nov 27, 2022 at 0:25
  • 3
    Note that there is a .camera gTLD. At the moment no 'driveway.camera' domain is registered, but it could happen in the future, and then, the question arises, is 'driveway.camera' what your mDNS setup says, or what global DNS says? The other domains are not (yet) gTLDs, but it could happen... The main reason for using .local is that it is explicitly reserved for that use.
    – jcaron
    Nov 27, 2022 at 11:07
  • You can't use .camera for mDNS because it is an actual TLD likd .com and exists on the internet
    – slebetman
    Nov 28, 2022 at 7:43
  • If you're willing to set things up then is there any reason you're not setting up your PC's/laptops/raspberry-pi hosts file? On my home network my laptop is simply gandalf, my PC is bilbo and my other laptop is frodo, my router is router my media box is tv and my NAS is storage (all of them without dots)
    – slebetman
    Nov 28, 2022 at 7:48
  • @slebetman I swap out hardware and reconfigure the network very frequently (sometimes on an hourly basis). I need a solution that uses broadcasts, instead of host files/DNS servers. Nov 28, 2022 at 22:44

2 Answers 2


Although technically possible in the protocol (and there have been appliances that forget to add the suffix), it would be incompatible with most implementations, many of which will not even route names to the mDNS handler unless they're suffixed with .local. (Avahi on Linux is the only implementation on common PC operating systems I know that allows adding other suffixes.)

  • 5
    Additionally, for this to work reliably even if you’re using an implementation that allows it, you have to make sure that none of the TLDs match up with any official TLD. .local is explicitly reserved for this usage, but no other domains are, and, for example, .camera is actually a registered TLD. Nov 27, 2022 at 13:20
  • This answer does answer the question asked (so I'm leaving it marked as the correct one), but I would like to emphasize to future readers that @Bergi's answer is much more comprehensive. Well done to the both of you Nov 28, 2022 at 23:20

No, .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 (or its IPv6 equivalent FF02::FB).

You get those special semantics only when using .local. So you should name your devices accordingly:

  • movies.nas.local.
  • pictures.nas.local.
  • livingroom.printer.local.
  • upstairs.printer.local.
  • patio.lights.local.
  • bedroom.lights.local.
  • garage.door.local.
  • driveway.camera.local.

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 .local. occurred because the user explicitly typed in a fully qualified domain name ending in .local., or because the user entered an unqualified domain name and the host software appended the suffix .local. because that suffix appears in the user's search list. The .local. 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 respect the .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 www.example.com.local.. To avoid this, a host MUST NOT append the search suffix .local., if 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 have both example.com and 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 www.example.com or www.local.

(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 .nas, .printer, .lights, .door and .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. .camera, .movie, .furniture, .lighting, .house, .frontdoor, .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.

  • movies-nas.local.
  • pictures-nas.local.
  • livingroom-printer.local.
  • upstairs-printer.local.
  • patio-lights.local.
  • bedroom-lights.local.
  • garage-door.local.
  • driveway-camera.local.

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.

  • I appreciate the effort put into this answer. I am leaving the marked answer as is, since the other answers the question asked. However, I would like to emphasize that this answer is much more comprehensive. Well done. Nov 28, 2022 at 23:18
  • 1
    @DaMaxContent It mostly consists of quotes from the relevant sections of the RFC, it wasn't that much effort :-)
    – Bergi
    Nov 29, 2022 at 0:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .