49

How can I reliably address different machines on my network?

I've always used the .local suffix to talk to computers on my local network before. With a new router, though, .local rarely (though sometimes) works. I've found that .home and .lan both usually work, but not always.

.-------.   .--------.                 .-----.
| modem |---| router |))))))(wifi))))))| foo |
.-------.   .--------.         v       .-----.
   ||            |             v
 /_^_^_\         |             \))))))).-----.
/ cloud \        |                     | bar |
 \-_-_-/      .-----.                  .-----.
              | baz |
              .-----.

So, from a terminal on foo, I can try:

ssh bar.local
ssh bar.home
ssh bar.lan

ssh baz.local
ssh baz.home
ssh baz.lan

and sometimes some of those suffixes work and some don't, but I don't know how to predict which or when.

foo, bar, and baz are all modern Linux or Android systems and the Linux boxes all have (or can have) avahi-daemon, or other reasonably-available packages, installed

(I don't want to set up static IP addresses: I'd like to keep using DHCP (from the router) for each machine, and even if I was okay with static addresses I'd want to be able to enter hostnames in the unrooted Android machines, where I can't edit the hosts file to map a chosen hostname to an IP address.)

Improve this question
2
  • what are you using in your /etc/resolv.conf for nameservers? Also if you have dig install what output do you get when you execute dig +trace baz.local?
    – Red Cricket
    Sep 26, 2013 at 7:29
  • You should add additional information (like provided in your last comment) to your question. Also add what router(s) you are using.
    – maxschlepzig
    Sep 26, 2013 at 16:37

3 Answers 3

Reset to default
38

There are no RFCs that specify .lan and .home. Thus, it is up to the router's vendor what pseudo TLDs (top-level-domain names) are by default configured.

For example my router vendor (AVM) seems to use .fritz.box by default.

.local is used by mDNS (multicast DNS), a protocol engineered by Apple. Using example.local only works on systems (and for destinations) that have a mDNS daemon running (e.g. MacOSX, current Linux distributions like Ubuntu/Fedora).

You can keep using dhcp - but perhaps you have to configure your router a little bit. Most routers let you configure such things like the domain name for the network.

Note that using pseudo TLDs is kind of dangerous - .lan seems to be popular - and better than .local (because it does not clash with mDNSs .local) - but there is no guarantee that ICANN will not introduce it as new TLD at some point.

2019 update: Case in point, .box isn't a pseudo TLD, anymore. ICANN delegated .box in 2016.

Thus, it makes sense to get a real domain name - and use sub-domains of it for private stuff, e.g. when your domain is example.org you could use:

lan.example.org
internal.example.org
...
Improve this answer
6
  • 4
    Actually tools.ietf.org/html/rfc6762 mention both .lan and .home.
    – Powerman
    Apr 9, 2018 at 20:55
  • 9
    @Powerman, well, RFC6762 mentions .lan and .home in the Appendix G but it doesn't specify their use nor their semantics. Instead it just lists them as part of a comment: 'We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose'
    – maxschlepzig
    Apr 9, 2018 at 21:11
  • 6
    As of February 2018, .home, .corp, and .mail can be considered safe: icann.org/resources/board-material/… Using .lan should still be considered risky.
    – Daniel Martin
    Oct 8, 2019 at 10:55
  • 4
    Another update: RFC8375 (May 2018) specifies .home.arpa for home scoped networks (tools.ietf.org/html/rfc8375)
    – John O'M.
    Oct 15, 2019 at 22:15
  • 1
    IANA maintain a list of Special Use Domain names at iana.org/assignments/special-use-domain-names/… with links to the RFC where each is described.
    – dunxd
    Aug 9, 2021 at 11:22
1

The networks using "made up" Top Level Domain (TLD) identifiers such as "LAN" or "LOCAL" or "HOME" might succeed if the hosts on the a shared local collision domain network segment and have implement mDNS (MultiCast DNS) as promulgated in RFC6762, Microsoft's LLMNR (Link-Local Multicast Name Resolution), as promulgated in RFC4795, or "Microsoft Networking" (or SAMBA) NetBIOS Broadcasts (assuming B-Node or H-Node provisioning) as promulgated in RFCs 1001 and 1002.

Traffic will only cross collision domains (that is, be routed) if a HOSTS or LMHOSTS file exists locally, or manual DNS or WINS (NBNS) entries have been made to indicated the underlying IP addresses of the hosts. However, the .LOCAL domain is officially reserved solely for mDNS and should NOT be used with traditional DNS, and all other "Made Up" TLDs end up polluting the Internet (and especially the DNS servers) with bogus, zombie traffic of queries which are never answerable.

Hosts should in fact use the "Home.ARPA" top-level domain name, as promulgated in RFC8375. Home.ARPA has been specifically created to handle "home" or "small business" name queries by shunting it to "black holes" early in the hops. The Black Holes, defined by the AS112.Net project and currently published as RFC7534, are being implemented by savvy network operators throughout the universe; I wonder whether someday soon we may even seen home routers implementing it by default.

Improve this answer
0

As I understand things, if you use one of the RFC-1918 private network numeric addresses, these are guaranteed by the Internet "rules" not to route beyond their own subnet.

Some names are reserved for special use ({invalid., localhost., test. in RFC6761} {local. in RFC6762} {onion. in RFC7686} iana site)

The result of this is that you can use some names you please on your private network LAN. If the address numbers are in the RFC1918 range: even if folks on the public internet know your node names, they cannot route to that addresses.

Improve this answer

You must log in to answer this question.