What Is mDNS and Bonjour?

mDNS in Plain English

Multicast DNS (mDNS), defined in RFC 6762, sends a DNS-like question to the local network segment instead of a recursive DNS resolver. Every device on that link receives the multicast packet. If a device owns the requested name or service, it sends a response directly to the querier. Names in the .local pseudo-TLD are reserved for mDNS use and must not be sent to a regular DNS resolver. This zero-configuration approach means no DNS server needs to be configured or maintained for local name resolution.

Multicast Mechanics: 224.0.0.251 and Port 5353

mDNS uses the IPv4 multicast address 224.0.0.251 and the IPv6 multicast address ff02::fb, both on UDP port 5353. These are link-local multicast addresses, meaning they are never forwarded by routers across subnet boundaries. When a device wants to resolve myprinter.local, it sends a multicast DNS query to 224.0.0.251:5353. All mDNS-capable devices on the same layer-2 segment receive and inspect the query. The device that owns the name sends a multicast response containing its address records, which all listening devices can cache. Responses are also multicast rather than unicast in most cases, which lets other devices on the link update their caches from overheard traffic.

Service Discovery with DNS-SD

DNS Service Discovery (DNS-SD), defined in RFC 6763, layers service advertising on top of mDNS. A device advertising a service publishes three record types: a PTR record under the service type (e.g., _ipp._tcp.local for printers), an SRV record with the hostname and port, and a TXT record with service-specific metadata. A client looking for printers queries the PTR record for _ipp._tcp.local and receives the names of all printers currently advertising on the network. It then resolves the SRV record to get the hostname and port, and resolves the A or AAAA record for the IP address. The full discovery requires no manual configuration on either side.

The .local Domain and Conflict Resolution

The .local domain is a special-use domain reserved by RFC 6762 exclusively for mDNS. Hostnames under .local are claimed by devices when they join a network. To avoid conflicts when two devices want the same name, mDNS defines a probing and announcement process: a device sends probe queries for its desired name before committing to it. If another device responds claiming that name, the newcomer must choose an alternative, typically by appending a number such as mydevice-2.local. Once a name is claimed, periodic announcements keep it fresh in other devices' caches. When a device leaves the network gracefully, it sends a goodbye packet with a TTL of zero to signal that its records should be removed from caches immediately.

Platform Implementations

Practical Uses

• AirPrint: iPhones and Macs discover printers advertising _ipp._tcp.local without any printer driver setup.
• AirPlay: Apple devices find speakers and TVs via _airplay._tcp.local service records.
• Chromecast: Google Cast uses mDNS to advertise cast targets on the local network.
• Home Assistant: discovers compatible devices such as Philips Hue bridges, Sonos speakers, and WLED controllers automatically via mDNS and DNS-SD.
• Samba and SMB shares: Linux systems running Avahi advertise file shares so Windows and macOS can discover them in network browsers.
• Developer tooling: frameworks like Next.js dev servers and tools like Vite can be reached by hostname on the local network without manual IP lookup.

mDNS Across Subnets: Unicast DNS-SD and Discovery Proxy

mDNS is inherently link-local and does not cross router boundaries. When devices are on separate VLANs — a common setup for isolating IoT devices from the main network — multicast packets are not forwarded between segments. Several approaches exist to bridge this gap. An mDNS reflector or repeater (available in some home routers and in software like avahi-daemon with reflector mode enabled) copies mDNS packets between interfaces. A more scalable solution is a Discovery Proxy (RFC 8766), which acts as a DNS server that proxies mDNS queries from one subnet for clients on another. Unicast DNS-SD (RFC 6763 Section 11) allows service discovery via conventional DNS, enabling clients on different subnets to query a regular DNS resolver for service records rather than relying on multicast. This approach works across the internet as well as between VLANs.

Security Considerations

mDNS operates without authentication. Any device on the local link can claim any name or advertise any service. A malicious device could send conflicting responses to hijack a name, or advertise a fake printer to intercept documents. mDNS traffic also leaks information: hostnames, device types, operating system versions, and service capabilities are all visible to anyone passively monitoring the link. On home networks this is generally acceptable, but on guest Wi-Fi networks, public hotspots, or enterprise segments, mDNS should be suppressed or tightly scoped. Many enterprise Wi-Fi controllers allow per-SSID control of mDNS forwarding. Devices that do not need to be discovered — such as corporate laptops on a guest VLAN — should have mDNS disabled or blocked at the network edge to limit the information they expose.

Frequently Asked Questions

What does mDNS do?

mDNS lets devices on the same local network answer DNS-like name queries without a central DNS server.

Is Bonjour the same as mDNS?

Bonjour is Apple's zero-configuration networking technology. It uses mDNS and DNS Service Discovery to find local devices and services.

Why does mDNS not work across VLANs?

mDNS is designed for the local link and uses multicast traffic that routers normally do not forward between VLANs unless an mDNS reflector or gateway is configured.