Multicast DNS

For the technical specification, see RFC 6762.

Multicast DNS (mDNS) is a local-link name resolution protocol that reuses the DNS packet format over IP multicast to provide DNS-like queries and responses on networks without a conventional unicast DNS server. It is a core building block of zero-configuration networking and underlies implementations such as Apple’s Bonjour and the Avahi stack on Linux.

Origins and Standardization

mDNS emerged from work on Zero Configuration Networking, which aimed to make small or unmanaged networks usable without manual DNS or DHCP configuration. Apple’s proprietary Rendezvous/Bonjour technologies provided early implementations of multicast-based name resolution and service discovery, later aligned with IETF standardisation.

The IETF standardised Multicast DNS as a DNS-compatible mechanism in RFC 6762 and paired it with DNS-Based Service Discovery in RFC 6763. RFC 6762 explicitly limits mDNS to the local link and designates part of the DNS namespace, notably .local, for link-local use so that local naming does not depend on delegations in the global DNS.

Operation and Deployment

Multicast DNS uses standard DNS message formats carried over UDP to the well-known multicast addresses "224.0.0.251" (IPv4) and "FF02::FB" (IPv6) on Port 5353, with a hop limit that confines traffic to the local link. Hosts act as both queriers and responders, probing to ensure name uniqueness and announcing records when they come online or change; conflict-detection rules require a host to abandon a name if it discovers another host using it.

In typical deployments, mDNS is combined with DNS-SD. Services advertise themselves using PTR, SRV, TXT and A/AAAA records under well-known service-type names, and client software browses these service records via multicast queries rather than using manually configured server addresses. Apple’s Bonjour stack provides this functionality on macOS and iOS, while Avahi offers a widely used free implementation on Linux and other Unix-like systems. Home and small-office devices (printers, media servers, IoT equipment) often rely on mDNS/DNS-SD to appear automatically in user interfaces such as "network browser" panels and device lists.

.local and Name-Space Boundaries

See .local.

Governance and Operational Aspects

Multicast DNS itself is specified entirely within the IETF and operates below the scope of ICANN’s policy authority over the global DNS root. Its governance relevance lies in how it partitions name space and traffic visibility between link-local and global contexts.

From an operational standpoint, mDNS changes which actors can observe or intervene in name resolution. Link-local queries and responses may bypass enterprise DNS infrastructure and logging entirely, which is attractive for zero-configuration usability but can complicate asset inventory, policy enforcement and forensic analysis on managed networks. Some administrators respond by filtering or proxying mDNS traffic at subnet boundaries or by disabling it on specific segments, trading convenience for tighter control.

At the namespace level, mDNS and .local are part of a layered approach to non-public naming that also includes special-use domains (such as home.arpa and .alt) and ICANN-reserved labels like .internal. SSAC’s advice in SAC090 and SAC123 situates mDNS within a broader effort to keep private, special-use and alternative naming systems from undermining the coherence of the public DNS, while acknowledging that developers will continue to create local naming scopes regardless of policy decisions.

See Also

• Special-Use Domain Names

Dynamic Host Configuration Protocol

Internet Engineering Task Force

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP) (RFC 768).

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).