Wiki / Protocols

mDNS

Zero-config LAN name resolution: enumerate and spoof local services on .local.

mdns bonjour avahi dns-sd local multicast discovery
Service discovery (DNS-SD)
.local 224.0.0.251:5353
_http._tcp
cam.local:80
_ipp._tcp
printer.local:631
DNS-SD layers service discovery on mDNS. A querier multicasts for a service type (PTR record, e.g. _http._tcp.local); each matching host answers with an SRV record (its hostname + port) and a TXT record of key=value metadata. The A record then resolves the .local hostname to an IP. No server, no authentication.

mDNS (Multicast DNS) resolves hostnames and, together with DNS-SD, discovers services on a local network with no DNS server at all. Queries and answers are ordinary DNS records sent by multicast to 224.0.0.251:5353 (and ff02::fb on IPv6), scoped to the .local top-level domain. It is what makes Apple Bonjour, printer.local, and Chromecast "just work" the moment a device joins the LAN.

What it is

Instead of asking a central resolver, an mDNS node multicasts its question to every host on the link; the host that owns the name answers, also by multicast, so everyone updates their cache. DNS-SD (DNS Service Discovery, RFC 6763) builds a discovery layer from the same record types: a PTR record enumerates instances of a service type (_http._tcp.local), an SRV record gives an instance's hostname and port, a TXT record carries key=value metadata (model, firmware, API path), and an A/AAAA record resolves the .local hostname to an address. See the diagram for how those nest.

Why it matters

mDNS is a free reconnaissance feed. IoT devices advertise themselves loudly and continuously, so a single passive listen or one broadcast query returns model names, firmware versions, service ports, and often admin paths, with zero credentials required. And because mDNS has no authentication, any host on the LAN can also answer for a name it does not own. That makes it both an enumeration goldmine and a spoofing / MITM primitive: poison the response to printer.local and the print job (or the login) comes to you.

How to attack it

Enumerate first, then consider spoofing:

# 1. Browse every advertised service on the link (Avahi).
avahi-browse -a -r                # -a all types, -r resolve to host/port/TXT

# 2. On macOS, or cross-checking, use dns-sd.
dns-sd -B _services._dns-sd._udp   # list which service types even exist
dns-sd -B _http._tcp               # then browse a specific type

# 3. Read SRV/TXT to map devices, ports, models, and admin URLs.

# 4. Active probe / scripted enumeration.
nmap --script=dns-service-discovery -p 5353 <target>

# 5. Spoofing / poisoning to redirect a name (LAN, with care).
sudo responder -I eth0            # answers LLMNR/NBT-NS/mDNS for MITM

The pure-enumeration path (avahi-browse -a -r) is almost always the right first move: it is passive-ish, noisy in your favour, and hands you the LAN's device inventory before you touch anything.

Pitfalls

  • mDNS is link-local: it does not cross routers or subnets. If you see nothing, confirm you are on the same L2 segment (and same VLAN) as the target.
  • Many hosts rate-limit and cache aggressively; a single query can miss slow responders. Browse continuously rather than one-shot.
  • Spoofing is disruptive and unmistakably active; on a shared network it breaks legitimate discovery for everyone and is easy to detect. Keep it to your own lab.
  • TXT metadata is attacker-influenceable on a spoofed record, so do not trust a .local device's self-description as ground truth.

Further reading