1. Zero-config protocols (in order of preference)
1.1. mDNS (Multicast DNS)
mDNS originates from Apple and is also known by the name Bonjour, which is Apple's branding for their mDNS implementation. It was originally an IP-based replacement for AppleTalk discovery services.
These days mDNS is available on most platforms and is generally the preferred choice, both for hostname lookup and for service discovery (where it's simpler than many alternatives).
mDNS hostnames are always in the form name.local
. (Exception: The built-in mDNS handling in Windows 10+ will accept bare hostnames like it has done previously, automatically translating them to the mDNS format behind the scenes.)
Software:
- Natively supported on Windows 10.1709 and later. (At first it was opt-in through a Registry setting, but I believe it's on-by-default now, at least in Windows 11.)
- Can be installed as Apple's Bonjour on Windows XP.
- Avahi with
nss_mdns
is still the preferred option for Linux and BSDs.
systemd-resolved
with nss_resolve
is another option for Linux (newer than Avahi but still incomplete).
- Natively supported by macOS (OS X) and iOS.
- Natively supported by Android _(I know Android 11 recognizes .local domains, but from what I remember, Android 7 did not yet).
- Natively supported by my Bosch washing machine, apparently.
1.2. LLMNR
LLMNR was introduced with Windows Vista as a modern alternative to NetBIOS Name Services (NBNS), being a very similar protocol to mDNS (but using bare hostnames, and lacking the service discovery features – Vista uses the WS-Discovery protocol for that purpose instead).
However, as of 2023, considered a dead-end – Microsoft eventually gave up and fully pivoted to mDNS for local name resolution.
- Natively supported by Windows Vista – Windows 11.
systemd-resolved
with nss_resolve
(part of systemd 216) on Linux.
.
1.3. NBNS (NetBIOS Name Services)
Part of the old NetBIOS network protocol suite used by Windows, OS/2, MS-DOS, etc. Anything that speaks SMBv1 is likely to support NBNS. (And likewise, it's as obsolete as SMBv1 is, and if you disable SMBv1 support in Windows, this also disables NBNS.)
Provides name resolution and (to some extent) service discovery – NBNS was part of what originally powered "Network Neighbourhood" or "My Network Places" in Windows.
NBNS has no IPv6 support whatsoever. It's also prone to breaking due to some underlying complexity (the "Browser Election" mechanism that was originally meant to reduce the chattiness).
- Natively supported on Windows and OS/2.
nmbd
with nss_wins
(part of Samba) on Linux and BSDs.
- Apparently OS X supports it natively as well?
2. Methods that are often pre-configured for you
2.1. DNS using a local (internal) domain name
Home gateways tend to have this built-in, as part of the local DNS cache. Often it's just regular dnsmasq
, which you could run manually if you're setting up a Linux/BSD-based gateway.
Your gateway takes the hostname from your DHCP request, registers it within its internal DNS service under a domain like .home
or .lan
, and offers itself as the main DNS server (acting as DNS cache).
Works by default with most operating systems, but only with DHCP (the gateway doesn't know hostnames of manually-configured hosts), and generally tends to be rather flaky in my experience.
Software:
3. Methods involving manual configuration
3.1. DNS using your own domain name
Works everywhere. (Won't help you to actually connect over the Internet, though.)
Dynamic DNS possible if you use DHCP and control a DNS server; otherwise all data is static.
You need to actually own a domain name (which will cost a few bucks).
3.2. Free DNS subdomains
Still DNS, just free (or much cheaper than a domain), but also quite limited. Services like FreeDNS and Dyn offer registration of individual subdomains under a domain they control (for example myhost.dyndns.com
).
(Way too often, the subdomain has already been picked by someone else...)
Dynamic DNS updates are often allowed (DynDNS-style).
3.3. /etc/hosts
A text file listing IP address – hostname pairs, which must be manually configured on each client machine.
The location is %SystemRoot%\system32\drivers\etc\hosts
on Windows, /etc/hosts
on Linux and others.
3.4. SSH client configuration
You can save pre-filled hostnames in PuTTY connection profiles, and you can similarly define short names through ~/.ssh/config
in OpenSSH.
3.5. PostIt notes all over your desk
Pros: Very cheap. No naming policy. Infinite data types.
Cons: Rather unreliable. Must be manually distributed. No TTL, which often results in stale information being cached for months until someone notices. Query algorithms are inefficient. Responses to queries tend to get lost easily, sometimes leaving just a glue record on your monitor. (Three months later, you might find them buffered behind your desk.)