RFC 6762

For implications on Internet governance, see Multicast DNS.

RFC 6762, Multicast DNS, is an IETF Standards-Track RFC that specifies how DNS-style queries and responses can be carried over IP multicast on a local link, without requiring any conventional unicast DNS server. It defines the behaviour commonly known as "mDNS" and designates the .local. domain and certain reverse-mapping domains as link-local namespaces.

Background

RFC 6762 was produced in the context of Zero Configuration Networking and the need for host naming and service discovery on small or unmanaged networks where users have no authority over any portion of the global DNS namespace. It is designed as an IP-based replacement for AppleTalk’s Name Binding Protocol and is paired with DNS-Based Service Discovery (DNS-SD), specified separately in RFC 6763. The RFC explicitly reuses the existing DNS message format, adding only rules for how DNS messages are sent and interpreted over link-local multicast. No new DNS opcodes or response codes are introduced.

Multicast DNS Operation

RFC 6762 defines Multicast DNS as clients performing DNS-like queries by sending DNS-format UDP queries and responses to the well-known multicast address "224.0.0.251" (IPv4) or "FF02::FB" (IPv6) on UDP port 5353, with an IP Time To Live (hop limit) of 255 so that traffic remains on the local link. Messages maintain the standard DNS header and Question/Answer/Authority/Additional sections.

The specification distinguishes between "One-shot queries", where a legacy resolver simply sends a query to 224.0.0.251:5353 and uses the first response; and "Continuous queries", used by fully compliant mDNS queriers that maintain ongoing interest and update results asynchronously, as required by DNS-SD.

Responders are expected to act as both queriers and answerers so they can first verify uniqueness (for example, a host’s own address records) before answering queries about them. The protocol defines probing on startup, announcements, and conflict resolution rules: a host that detects a name conflict during probing or operation must relinquish the contested name and choose another. RFC 6762 also describes TTL and cache-coherency rules adapted to multicast operation and summarises the behavioural differences between mDNS and unicast DNS.

Special Names and Link-Local Scope

A central element of RFC 6762 is its designation of specific names and domains as link-local and therefore subject to mDNS handling.

The RFC specifies that the DNS top-level domain .local. is a special domain: any fully qualified name ending in .local. is considered link-local, with meaning only on the originating link. Queries for such names must be sent to the mDNS multicast address rather than to configured unicast resolvers. Implementations may also, if they choose, query other mechanisms (including Unicast DNS) in parallel and merge results, but the document warns that this can create user confusion when different mechanisms return different answers.

Similarly, RFC 6762 marks specific reverse-mapping domains as link-local. Queries for names under 254.169.in-addr.arpa. (IPv4 link-local) and for prefixes 8.e.f.ip6.arpa., 9.e.f.ip6.arpa., a.e.f.ip6.arpa., and b.e.f.ip6.arpa. (IPv6 link-local) MUST be sent to the mDNS multicast address. These domains correspond to IPv4 169.254/16 and IPv6 FE80::/10 link-local address ranges respectively.

The IANA Special-Use Domain Names registry lists .local and the link-local reverse domains as special-use names, citing RFC 6762 as the authority document, while RFC 6761 defines the general framework for such reservations.

Relationship to Service Discovery

RFC 6762 is intended to be used together with RFC 6763, where mDNS provides local-link name resolution and DNS-SD defines the naming conventions and resource records for discovering services such as printers, file shares and other devices. This combination underlies implementations such as Apple’s Bonjour and other "zero-configuration" service discovery stacks that rely on RFC 6762-compliant behaviour for host naming.

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).

Internet Engineering Task Force

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).

Internet Assigned Numbers Authority