# Multicast DNS and DNS Service Discovery

Canonical: https://learndns.org/learn/5-5-mdns-dns-sd/

> mDNS, DNS-SD, and zero-configuration networking — how your devices find printers, AirPlay speakers, and each other without any server.

You open your laptop, and it immediately sees the network printer. Your phone finds your AirPlay-enabled TV. A smart speaker discovers the smart lights. No configuration, no DNS server, no IT department required.

This magic is **Multicast DNS (mDNS)** and **DNS Service Discovery (DNS-SD)** — a pair of protocols that let devices discover each other on local networks using the DNS message format, but without any DNS infrastructure at all.

## The Zero-Configuration Problem

Traditional DNS requires infrastructure: authoritative servers, recursive resolvers, zone files, and administrators. That's fine for the internet. But what about a home network where someone just wants their laptop to find their printer?

The **Zeroconf** (zero-configuration networking) initiative aimed to solve three problems:

1. **IP address assignment** without a DHCP server — solved by link-local addressing (RFC 3927)
2. **Name resolution** without a DNS server — solved by mDNS (RFC 6762)
3. **Service discovery** without a directory server — solved by DNS-SD (RFC 6763)

Together, these protocols create a plug-and-play networking experience. Connect a device to the network, and it can immediately announce itself and discover others.

## Multicast DNS (mDNS) — RFC 6762

mDNS takes the DNS protocol — same message format, same record types — and runs it over **multicast** on the local network instead of unicast to a server.

### How mDNS Works

1. A device wants to resolve `myprinter.local`
2. Instead of sending a unicast query to a DNS server, it sends a **multicast** DNS query to `224.0.0.251` (IPv4) or `ff02::fb` (IPv6) on **port 5353**
3. **Every device on the local network** receives this query
4. The device that owns `myprinter.local` responds — also via multicast, so all devices can cache the answer

```
Laptop → [multicast] → Who has myprinter.local?
                          ↑ every device hears this
Printer → [multicast] → myprinter.local is at 192.168.1.42
                          ↑ every device caches this
```

The use of multicast for responses (not just queries) is a deliberate design choice. When one device asks "where is the printer?", the answer benefits everyone on the network. This **passive observation** means devices learn about each other even without actively querying.

### The .local Domain

mDNS uses the **`.local`** top-level domain, reserved specifically for link-local multicast name resolution. Any name ending in `.local` is resolved via mDNS rather than standard DNS.

RFC 6762 §22 required IANA to reserve `.local` for this purpose:

> "The name 'local.' has been reserved for use by mDNS... It is not possible for names within the 'local.' domain to be resolved using conventional unicast DNS."

This is why you see names like `macbook-pro.local`, `living-room-speaker.local`, and `raspberrypi.local` on your home network. They're mDNS names, resolved entirely through local multicast.

### Conflict Detection

What happens if two devices try to claim the same `.local` name? mDNS includes a **probing** mechanism:

1. Before claiming a name, a device sends probe queries asking if anyone else owns it
2. If no one responds within 250ms (repeated three times), the device claims the name
3. If a conflict is detected, the device appends a number: `macbook-pro.local` becomes `macbook-pro-2.local`

This ensures unique names without any central authority managing assignments.

### Continuous Multicast DNS

Unlike traditional DNS where you query and get a response, mDNS supports **continuous querying**. A device can express ongoing interest in a name and receive updates whenever the answer changes:

- Printer comes online → multicast announcement
- Printer goes offline → multicast goodbye (TTL=0)
- Printer changes IP → multicast update

This is how your computer's printer list stays current without you ever refreshing it.

## DNS Service Discovery (DNS-SD) — RFC 6763

mDNS tells you *where* a named device is. But what if you don't know the name? What if you just want to find "all printers on this network" or "all AirPlay speakers"?

**DNS-SD** solves this using standard DNS record types (SRV, TXT, and PTR) in a clever way to enable browsable service discovery.

### Service Types and Naming

DNS-SD defines a naming convention for services:

```
_<service>._<transport>.local
```

For example:
- `_http._tcp.local` — HTTP web servers
- `_ipp._tcp.local` — IPP printers
- `_airplay._tcp.local` — AirPlay devices
- `_raop._tcp.local` — AirPlay audio (Remote Audio Output Protocol)
- `_smb._tcp.local` — SMB file shares
- `_googlecast._tcp.local` — Chromecast devices

### The Three-Step Discovery Process

DNS-SD uses three DNS queries to go from "I want a printer" to "here's how to connect":

**Step 1: Browse — Find service instances (PTR records)**

```
Query: _ipp._tcp.local PTR
Answer: _ipp._tcp.local PTR "Office LaserJet._ipp._tcp.local"
Answer: _ipp._tcp.local PTR "Bob's Printer._ipp._tcp.local"
```

PTR records list all instances of a service type. The instance names are human-readable.

**Step 2: Resolve — Get connection details (SRV + TXT records)**

```
Query: Office LaserJet._ipp._tcp.local SRV
Answer: SRV 0 0 631 officeprinter.local.

Query: Office LaserJet._ipp._tcp.local TXT
Answer: TXT "pdl=application/pdf" "Color=T" "Duplex=T"
```

The SRV record provides the hostname and port. The TXT record contains service-specific metadata (in this case, the printer's capabilities).

**Step 3: Address Resolution — Get the IP (A/AAAA records)**

```
Query: officeprinter.local A
Answer: A 192.168.1.42
```

Standard mDNS resolves the hostname to an IP address.

This three-step process — browse, resolve, address lookup — is elegant because it reuses standard DNS record types. No new protocol was needed, just a convention for how to use existing ones.

## Apple Bonjour

**Bonjour** is Apple's implementation of mDNS/DNS-SD, built into macOS, iOS, and every Apple device. It's the reason Apple devices "just work" when finding each other on a network.

Bonjour powers:
- **AirPrint** — finding printers without drivers
- **AirPlay** — discovering Apple TVs and AirPlay speakers
- **AirDrop** — peer-to-peer file sharing (discovery phase)
- **iTunes/Music sharing** — discovering shared libraries
- **HomeKit** — discovering smart home accessories
- **Back to My Mac** (discontinued) — used wide-area Bonjour for remote access

Apple publishes the Bonjour specification and provides open-source components, including `mDNSResponder` — the daemon that handles mDNS/DNS-SD on macOS and iOS.

## Avahi: The Linux Implementation

**Avahi** is the open-source mDNS/DNS-SD implementation for Linux, functionally equivalent to Apple's Bonjour. It's included in most Linux distributions and enables:

- Service discovery on Linux desktops (finding printers, file shares)
- Service announcement from Linux servers
- `.local` name resolution

```bash
# Browse for all services
avahi-browse -a

# Browse for printers
avahi-browse _ipp._tcp

# Resolve a specific service
avahi-resolve -n myprinter.local
```

Avahi and Bonjour are interoperable — a Mac can discover services announced by a Linux Avahi daemon and vice versa.

## Smart Home and IoT Discovery

mDNS/DNS-SD has become the de facto discovery protocol for smart home devices:

- **Matter** (the smart home standard from Apple, Google, Amazon, and Samsung) uses mDNS/DNS-SD for device discovery and commissioning
- **Google Chromecast** uses `_googlecast._tcp` for discovery
- **Philips Hue** bridges announce themselves via mDNS
- **Home Assistant** auto-discovers many devices using mDNS/DNS-SD

The protocol's simplicity and lack of infrastructure requirements make it ideal for consumer IoT. A smart bulb doesn't need to know about DNS servers — it just multicasts its presence.

## Limitations and Scaling

mDNS was designed for small networks, and it shows:

### Multicast Traffic Overhead

Every mDNS query and response is multicast to all devices on the network segment. On a network with hundreds of devices (a busy office, a conference), the multicast traffic can become significant. WiFi networks are particularly affected because multicast frames are sent at the lowest data rate.

### No Cross-Subnet Discovery

mDNS multicast is link-local — it doesn't cross routers. Devices on different subnets can't discover each other via mDNS. Solutions include:

- **Unicast DNS-SD**: DNS-SD can work over standard unicast DNS (not just mDNS), allowing cross-subnet discovery
- **mDNS reflectors/repeaters**: Software that forwards mDNS between subnets (e.g., Avahi's reflector mode)
- **Wide-Area Bonjour**: Apple's extension that registers services in standard DNS for organization-wide discovery

### Security: None by Default

mDNS has no authentication. Any device on the network can claim any name and announce any service. On trusted home networks this is fine; on shared or public networks, it's a concern. A malicious device could announce fake services to redirect traffic.

## Key Takeaways

- **mDNS** (RFC 6762) resolves `.local` names via multicast on port 5353 — no DNS server needed
- **DNS-SD** (RFC 6763) enables service browsing using PTR, SRV, and TXT records
- **Bonjour** (Apple) and **Avahi** (Linux) are the major mDNS/DNS-SD implementations — they're fully interoperable
- **Smart home protocols** like Matter rely on mDNS/DNS-SD for device discovery
- **Limitations**: link-local only (no cross-subnet), multicast overhead on large networks, no built-in security
- **The elegance**: zero infrastructure, standard DNS message format, and it just works