The purpose of the multicast Domain Name System is to resolve host names to IP addresses within
small networks that do not include a local name server.
It is a zero configuration service, utilizing essentially the same programming interfaces,
packet formats and operating semantics as the unicast Domain Name System.
While it is designed to be stand-alone capable, it can work in concert with unicast DNS servers.
The mDNS protocol is published as RFC 6762, uses IP multicast User Datagram Protocol packets,
and is implemented by the Apple Bonjour and Linux nss-mdns services.
mDNS should not be confused with DNS Service Discovery, which is a companion zero configuration
technique that is separately specified and implemented.
Protocol overview When an mDNS client needs to resolve a host
name, it sends an IP multicast query message that asks the host having that name to identify
itself.
That target machine then multicasts a message that includes its IP address.
All machines in that subnet can then use that information to update their mDNS caches.
In addition, any host can relinquish its claim to a domain name by sending a response packet
with a time to live equal to zero.
By default, mDNS only and exclusively resolves host names ending with the .local top-level
domain.
This can cause problems if that domain includes hosts that do not implement mDNS but can be
found via a conventional unicast DNS server.
Resolving such conflicts requires network configuration changes that violate the zero
configuration goal.
Packet structure The mDNS Ethernet frame is a multicast UDP
packet to: MAC address 01:00:5E:00:00:FB or 33:33:00:00:00:FB
IPv4 address 224.0.0.251 or IPv6 address FF02::FB UDP port 5353
Its payload is based on the DNS packet format.
It consists of two parts—the header and the data.
The Flags word will generally be 00 00 for a query and 84 00 for a response.
Each packet's data begins with the fully qualified domain name to be resolved, and ends with
two 2-byte flags indicating the QTYPE and QCLASS:
A query packet's data includes no other information.
In a response packet's data, the FQDN is followed by the target host's IPv4 address, IPv6 address
and name section records.
The FQDN is specified by a list of component strings, beginning with the host name and
ending with the top-level domain.
Each such string consists of a length byte followed by that many UTF-8 bytes.
The TLD is followed by a null string that terminates the FQDN.
The target host's IPv4 address record consists of:
a 2-byte type field, a 2-byte class field,
a 32-bit signed integer Time To Live field, a 2-byte length field, and
the 4 IPv4 address bytes.
Its IPv6 address record consists of: a 2-byte link indicating the offset of the
host name, a 2-byte type field,
a 2-byte class field, a 32-bit signed integer Time To Live field,
a 2-byte length field, and the 16 IPv6 address bytes.
The name section record consists of: a 2-byte link indicating the offset of the
host name, a 2-byte type field,
a 2-byte class field, a 32-bit signed integer Time To Live field,
a 2-byte length field, and the 8 block and bitmap bytes.
In a standard DNS message the upper byte of any class field is always 0x00, in mDNS the
upper bit of this byte may be set, resulting in a value of 0x80.
This is the cache-flush bit and should not be interpreted as part of the class value
- see section 10.2 of RFC 6762.
Example Trying to ping the appletv.local host would
cause an mDNS client computer to multicast the following UDP packet:
00 00 00 00 00 01 00 00 00 00 00 00 07 61 70 70
6c 65 74 76 05 6c 6f 63 61 6c 00 00 01 00 01
All six header fields equal zero except the QDCOUNT, which equals one.
The data begin with the seven character appletv host name followed by the five character local
domain string and the requisite null string.
That entire FQDN is followed by the host address QTYPE flag and the internet QCLASS flag.
The appletv.local host would respond by multicasting its mDNS response packet.
For example:
00 00 84 00 00 00 00 01 00 00 00 02 07 61 70 70
6c 65 74 76 05 6c 6f 63 61 6c 00 00 01 80 01 00
00 78 00 00 04 99 6d 07 5a c0 0c 00 1c 80 01 00
00 78 00 00 10 fe 80 00 00 00 00 00 00 02 23 32
ff fe b1 21 52 c0 0c 00 2f 80 01 00 00 78 00 00
08 c0 0c 00 04 40 00 00 08
In its header, the non-zero fields are the Flags word, the ANCOUNT word, and the ARCOUNT
word.
The data again begin with the FQDN, followed by that host's DNS information:
the A/IPv4 address type code, the IPv4 class code,
the IPv4 TTL, the IPv4 length,
the four IPv4 address bytes, the FQDN offset,
the AAAA/IPv6 address type code, the IPv6 class code,
the IPv6 TTL, the IPv6 length,
the 16 IPv6 address bytes, the FQDN offset,
the NSEC type code, the NSEC class code,
the NSEC TTL, the NSEC length, and
the 8 NSEC block and bitmap bytes See also
Avahi Bonjour
Name Service Switch Zero configuration networking
References
External links Multicast DNS
New DNS Technologies in the LAN