SMIP
All articles
dnsnetworkingadvanced

What is mDNS / Bonjour? Local network discovery explained

Your printer just appears on your network. Your AirPods reconnect automatically. Chromecast finds your TV. The reason all of that 'just works' is mDNS — multicast DNS, the silent infrastructure of local networks.

May 6, 20265 min read

You plug in a printer. Your laptop sees it. You buy a smart speaker. Your phone finds it. You connect AirPods. They pair without typing anything. None of these devices know each other's IP addresses, your router doesn't broadcast a directory of services, and there's no central registry. So how does it all work?

The answer is mDNS — multicast DNS — and its sibling DNS-SD (DNS Service Discovery). Together they're sometimes called Bonjour (Apple's brand for it) or Avahi (Linux's open-source implementation), but it's the same protocol family.

If you've ever wondered how your home network "just knows" about devices, this is it.

The two-line summary

mDNS lets devices on the same local network resolve each other's names without a central DNS server. DNS-SD layers on top to advertise services like printers, file shares, and music players.

Together they replace centralized server discovery with a "shout into the room and listen for replies" model — and it's what makes most consumer networking feel magical instead of painful.

How mDNS works

In normal DNS, your laptop asks a central resolver "what's the IP for example.com?" The resolver answers.

In mDNS, your laptop asks the whole local network — by sending a multicast UDP packet — "who has the name printer.local?" The device that owns that name responds. No server needed.

A few specifics:

  • Multicast group: 224.0.0.251 for IPv4 / ff02::fb for IPv6.
  • Port: 5353/UDP.
  • Special TLD: .local. The .local domain is reserved for mDNS; resolving it bypasses the DNS hierarchy entirely.

When you type myprinter.local into your browser:

  1. Your OS detects .local and routes the query to the mDNS resolver instead of standard DNS.
  2. The mDNS resolver multicasts a query: "anyone here named myprinter.local?"
  3. The printer (which has claimed that name) responds with its IP.
  4. Your browser connects.

No DNS server. No DHCP-distributed name. Just devices announcing themselves.

Name conflicts and resolution

What if two devices both claim printer.local? mDNS has built-in conflict detection:

  • When a device wants a name, it sends a "probe" — three multicast queries asking who already claims it.
  • If nobody responds, the name is taken.
  • If someone does, the new device adjusts (typically by appending a number — printer-2.local).

This is decentralized and self-healing, like most parts of mDNS. Names always resolve; collisions just cause an automatic rename.

DNS-SD: the service-advertisement layer

mDNS resolves names. DNS-SD uses mDNS to discover services. It's a convention layered on top.

A service announces itself via specially-formatted DNS records:

  • _printer._tcp.local — "I'm a printer service"
  • _airplay._tcp.local — "I support AirPlay"
  • _googlecast._tcp.local — "I'm a Chromecast"
  • _http._tcp.local — "I have a web interface"
  • _ssh._tcp.local — "I accept SSH connections"

When your phone wants to find Chromecasts, it asks the network "give me everything advertising _googlecast._tcp.local." Every Chromecast on the network responds with its info. The phone shows them in a list.

This is how your phone lists nearby AirPlay devices, how your laptop sees printers, how Chromecast discovery works. All of it.

Real-world systems built on mDNS

  • Bonjour (Apple) — runs on every Mac, iPhone, iPad. Powers AirDrop discovery, AirPlay, HomeKit, Find My (local), printer setup.
  • Avahi (Linux) — equivalent for Linux desktops. Same protocols.
  • Windows mDNS support — added in Windows 10. Enables discovery of .local hostnames and many service types.
  • iOS / Android — full mDNS clients in modern mobile OSes.
  • Chromecast and AirPlay protocols — discovery layer is mDNS.
  • Home Assistant — auto-discovers most smart-home devices via mDNS/SSDP.
  • Plex — your local Plex server announces itself via mDNS so clients on the same network find it.

If your home network's ever felt friendly, mDNS is the reason.

Why mDNS doesn't work over the internet

By design. The protocol uses multicast, which routers don't forward across networks. mDNS packets stay on your local subnet. Your printer at home isn't reachable as myprinter.local from the internet.

This is a privacy and security feature, not a bug. Local discovery is local. Anyone trying to reach printer.local from outside your network gets NXDOMAIN.

If you want a device reachable from the internet, you need a real public DNS name and an actual reachable IP — see our Cloudflare Tunnel guide for the modern way to do that.

Common issues

"myprinter.local" doesn't work

Most often, mDNS isn't enabled or isn't getting through. Possible causes:

  • VPN running — many VPNs intercept all DNS, including .local. Disable the VPN or configure it to route .local queries to the local resolver.
  • Restrictive Wi-Fi — corporate guest networks, hotel Wi-Fi, and some coffee shops block multicast traffic to prevent device-to-device discovery. mDNS won't work there.
  • Cross-VLAN networks — by default, multicast doesn't cross VLAN boundaries. Devices on a guest VLAN can't see your main-VLAN printer. Some routers offer "mDNS reflector" or "Avahi" features to bridge this; otherwise you're stuck.
  • Firewall blocking 5353/UDP — host firewalls sometimes drop multicast. macOS and Linux generally allow it by default.

"Privacy" mDNS announcements

Modern OSes increasingly randomize mDNS hostnames per network for privacy (preventing tracking across Wi-Fi networks). Your laptop might appear as dGFsZHJv.local on one network and cnl4.local on another. This is expected and generally helpful; if it confuses your home network, name your devices manually in their settings.

Phantom devices

mDNS announcements have TTLs but caches sometimes hold stale entries. A device that's been unplugged might appear in discovery for several minutes. Patience usually clears it; some clients need a refresh.

Quick FAQ

Is mDNS the same as link-local addresses? No, but they're related. Link-local IPv6 addresses (fe80::/10) and link-local IPv4 (169.254.0.0/16) are addresses that are only valid on the local link. mDNS uses these to operate, but mDNS is about names while link-local is about addresses.

Why .local and not something else? The IETF reserved .local for mDNS in RFC 6762. It's a "special-use" domain like .localhost and .invalid. ICANN doesn't issue real .local domains.

Does mDNS leak information? Within your local network, yes — devices can see each other's hostnames and service offerings. Across networks, no. This is generally fine, but on hostile networks (corporate Wi-Fi, public hotels), be aware that other guests can see your devices' mDNS announcements.

Is mDNS encrypted? No. mDNS is plaintext on the local network. For sensitive applications, you'd use the IP discovered via mDNS to open a TLS connection — the discovery is open, the actual communication is encrypted.

Why is it sometimes called Bonjour? "Bonjour" is Apple's marketing name for their mDNS+DNS-SD implementation. Released in 2002 (originally as "Rendezvous"), they later renamed to avoid trademark conflicts. The protocols themselves are open IETF standards.

TL;DR

  • mDNS resolves names on the local network without a central server, via multicast UDP on 224.0.0.251 / port 5353.
  • DNS-SD layers on top to advertise services like printers, AirPlay devices, and Chromecasts.
  • The .local domain is reserved for mDNS.
  • It's the silent infrastructure of "discoverable" home networking.
  • It doesn't work across networks — by design.

If a device on your network "just appeared" today, mDNS made it happen.