Understanding UDP in Multicast DNS (mDNS)

Multicast DNS (mDNS) relies fundamentally on the User Datagram Protocol (UDP) to discover devices and resolve hostnames on local networks without a dedicated DNS server. By utilizing UDP’s connectionless nature and built-in multicast capabilities, mDNS enables devices to broadcast queries and announce services simultaneously to all listening nodes on a local subnet. This article details how UDP operates within the mDNS framework, why it is preferred over TCP, and how it enables zero-configuration networking.

Multicast Transmission on Dedicated Ports

The primary reason mDNS uses UDP is its native support for multicast traffic. Unlike unicast communication, which establishes a one-to-one link, multicast sends a single packet to a designated multicast group address that multiple receivers listen to.

Under the mDNS specification (RFC 6762), systems send UDP packets to reserved multicast IP addresses: * IPv4: 224.0.0.251 * IPv6: FF02::FB * Port: UDP port 5353

When a device needs to resolve a .local domain name or discover a service (such as a network printer or smart speaker), it sends a standard DNS query format wrapped inside a UDP datagram to port 5353. Every device on the local network configured to process mDNS receives this single packet simultaneously.

Low Overhead and Connectionless Efficiency

Standard TCP requires a three-way handshake before transmitting data and maintains a continuous connection state. In a dynamic local network where devices frequently join, leave, or query for services, managing point-to-point TCP connections for every single resolution request would generate excessive latency and resource overhead.

UDP eliminates connection handshakes. A device simply emits a query datagram onto the network interface. Devices that recognize the requested name or service respond with a UDP reply, either by multicasting the answer back to the group or sending a unicast UDP response directly to the querier.

Mitigating Packet Loss in an Unreliable Protocol

Because UDP is an inherently unreliable transport protocol without built-in packet retransmission or flow control, the mDNS protocol implements its own lightweight reliability mechanisms:

• Query Retransmission: If a device does not receive an answer to a UDP query, it retransmits the query with exponential backoff to avoid congesting the local network.
• Caching: Nodes maintain a local cache of received mDNS records with specified Time to Live (TTL) values, reducing the frequency of UDP query broadcasts.
• Passive Conflict Detection: When a device advertises its own name, it monitors incoming UDP packets on port 5353 to ensure no other device is claiming the same hostname.

Through UDP, mDNS delivers a lightweight, scalable, and decentralized name resolution solution essential for modern local device discovery protocols like Apple Bonjour and Linux Avahi.