What Is mDNS / Bonjour?

What mDNS Does

Multicast DNS (mDNS) solves a simple problem: how do devices on a local network find each other without a dedicated DNS server? On a home network, there is typically no local DNS infrastructure. When your laptop needs to find your printer, or your phone needs to discover your smart TV, mDNS provides the answer.

Instead of sending DNS queries to a central server, mDNS broadcasts queries to every device on the local network. Any device that recognizes the requested name can respond directly. No server configuration, no manual IP address entry, no IT department required.

mDNS was defined in RFC 6762, published in 2013, though Apple had been using it since 2002 under the name Bonjour (originally Rendezvous).

How mDNS Works

mDNS uses the same packet format as regular DNS but sends queries to a multicast address instead of a specific server. On IPv4, mDNS queries go to 224.0.0.251 on UDP port 5353. On IPv6, the multicast address is ff02::fb.

When a device wants to resolve a name, it sends a DNS query to the multicast address. Every device on the local network receives this query. If any device owns the requested name, it responds - also via multicast, so all devices on the network can cache the answer.

graph TD
    subgraph "Traditional DNS"
        C1[Client] -->|Query: printer.example.com| DNS[DNS Server]
        DNS -->|Response: 192.168.1.50| C1
    end
    subgraph "mDNS - Multicast DNS"
        C2[Client] -->|Query: printer.local to 224.0.0.251| ALL[All devices on LAN]
        P[Printer] -->|Response: 192.168.1.50 to 224.0.0.251| C2
        TV[Smart TV hears and caches] --> CACHE[Local cache updated]
        PHONE[Phone hears and caches] --> CACHE
    end

mDNS sends queries to all devices on the network - any device can respond

Devices also send unsolicited mDNS announcements when they join the network or when their IP address changes. This proactive announcement ensures other devices learn about new services quickly without having to query for them.

The .local Domain

mDNS uses the .local top-level domain. Any hostname ending in .local is resolved via mDNS rather than traditional DNS. When your operating system sees a query for "myprinter.local", it knows to send an mDNS multicast query instead of contacting a DNS server.

This creates a potential conflict. If an organization uses .local for their internal Active Directory domain (which was common before Microsoft recommended against it), mDNS queries and unicast DNS queries can interfere with each other. Devices may try mDNS for names that should be resolved by the corporate DNS server, causing delays or resolution failures.

The lesson: never use .local for internal DNS domains. Use a subdomain of a domain you own (like internal.example.com) instead.

Apple Bonjour

Apple was the driving force behind mDNS. Bonjour (originally called Rendezvous) is Apple's implementation of mDNS and DNS-SD (DNS Service Discovery). It powers most of the zero-configuration networking features in macOS and iOS.

AirPrint uses Bonjour to discover printers on the network. AirPlay uses it to find Apple TVs and compatible speakers. AirDrop uses a combination of Bluetooth Low Energy and Bonjour to discover nearby devices for file transfer. When you open the printer dialog on a Mac and see printers automatically listed, that is Bonjour at work.

Bonjour is also installed on Windows when you install iTunes or other Apple software. This allows Windows applications to discover Apple services on the network.

Avahi on Linux

Avahi is the Linux equivalent of Bonjour. It provides mDNS/DNS-SD functionality on Linux distributions and is installed by default on most desktop Linux systems (Ubuntu, Fedora, and others include it).

Avahi allows Linux machines to be discovered on the network as hostname.local and to discover services advertised by other devices. It integrates with the system's name resolution through the nss-mdns module, which adds .local resolution to the standard name lookup chain.

On servers, Avahi is sometimes installed but not needed. Running unnecessary network services increases the attack surface. If a Linux server does not need mDNS discovery, disabling Avahi reduces exposure.

DNS-SD - Service Discovery

mDNS resolves names to IP addresses. DNS-SD (DNS Service Discovery, RFC 6763) builds on top of mDNS to help devices discover what services are available on the network - not just where a specific device is, but what it offers.

graph TD
    subgraph "DNS-SD Service Discovery Flow"
        Q1[Client queries _services._dns-sd._udp.local] --> R1[Receives list of service types]
        R1 --> Q2[Client queries _ipp._tcp.local]
        Q2 --> R2[Receives printer instances]
        R2 --> Q3[Client queries MyPrinter._ipp._tcp.local SRV]
        Q3 --> R3[Receives hostname and port]
        R3 --> Q4[Client queries hostname.local A record]
        Q4 --> R4[Receives IP address]
        R4 --> CONNECT[Client connects to printer]
    end

DNS-SD discovers service types, then instances, then resolves to an IP address and port

DNS-SD uses specially formatted DNS records. A PTR record for _ipp._tcp.local lists all IPP (Internet Printing Protocol) printers on the network. SRV records provide the hostname and port for each printer instance. TXT records carry additional metadata like printer capabilities, paper sizes, and color support.

This layered discovery allows a client to enumerate all available service types, find specific service instances, and gather the connection details needed to use them - all without any manual configuration.

IoT and mDNS

IoT devices heavily rely on mDNS for discovery. Smart home devices from Google (Chromecast), Amazon (Echo), Philips (Hue), and countless others announce their presence on the network via mDNS. Home automation platforms like Home Assistant discover devices primarily through mDNS announcements.

This means a typical home network may have dozens of devices constantly sending and responding to mDNS queries. Each smart bulb, speaker, thermostat, and camera advertises its services to the entire local network.

When you use the BLEShark Nano's WiFi scanner to identify devices on your network, many of those devices are actively participating in mDNS. The scanner helps you see what is connected, and understanding mDNS helps you understand what those devices are doing on the network.

Security Implications

mDNS has several security problems that stem from its fundamental design. It was built for convenience, not security.

No authentication. mDNS responses are not authenticated. Any device on the network can respond to any mDNS query, claiming to be any hostname. An attacker on the local network can answer mDNS queries for "fileserver.local" and redirect traffic to their own machine.

Information disclosure. mDNS announcements reveal detailed information about every device on the network. Service types, hostnames, software versions, and device capabilities are all broadcast to everyone on the LAN. An attacker who gains access to the network can passively collect a complete inventory of all devices and services without sending a single probe.

Hostname leakage. Devices announce their hostnames via mDNS. On a public WiFi network, your laptop broadcasts its hostname (which often contains your name) to every other device on the network. This is a privacy leak.

Reflection attacks. mDNS can be abused for reflection and amplification attacks. An attacker sends mDNS queries with a spoofed source IP address. The responses go to the victim. While the amplification factor is lower than some other protocols (like SSDP or memcached), it can still contribute to DDoS attacks.

graph TD
    subgraph "mDNS Spoofing Attack"
        VICTIM[Victim queries fileserver.local] -->|Multicast query| NET[Local Network]
        ATTACKER[Attacker on same network] -->|Responds first with own IP| VICTIM
        REAL[Real fileserver] -->|Responds too late| VICTIM
        VICTIM -->|Connects to attacker| ATTACKER
        ATTACKER -->|Captures credentials or serves malware| STOLEN[Data compromised]
    end

Any device on the LAN can respond to mDNS queries - attackers respond with their own address

Mitigation Strategies

Mitigating mDNS risks requires a layered approach. On enterprise networks, mDNS traffic should be confined to specific VLANs. There is no reason for IoT devices to discover services in the corporate VLAN, and vice versa.

Disable mDNS on devices and systems that do not need it. Linux servers that are not providing discovery services should have Avahi disabled. Windows systems that do not need local discovery can have mDNS disabled through configuration.

On public or untrusted networks, be aware that your device is broadcasting its hostname. Some operating systems allow you to set a generic hostname for use on untrusted networks.

Network segmentation is the most effective defense. Placing IoT devices, workstations, and servers on separate VLANs with firewall rules that block mDNS multicast between segments limits the blast radius of any mDNS-based attack.

Understanding what protocols your devices use on the network - mDNS, SSDP, LLMNR, and others - is the first step toward securing your environment. The BLEShark Nano gives you visibility into the wireless devices sharing your network, helping you map what is connected and identify devices that should not be there.