In computer networking, the multicast DNS (mDNS) protocol resolves host names to IP addresses within small networks that do not include a local name server. It is a zero-configuration service, using essentially the same programming interfaces, packet formats and operating semantics as the unicast Domain Name System (DNS). Although Stuart Cheshire designed mDNS as a stand-alone protocol, it can work in concert with standard DNS servers.
The mDNS protocol is published as RFC 6762, uses IP multicast User Datagram Protocol (UDP) packets, and is implemented by the Apple Bonjour and open source Avahi software packages. Android contains an mDNS implementation. mDNS has also been implemented in Windows 10, but its use there is limited to discovering networked printers.
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.
Any host can relinquish its claim to a domain name by sending a response packet with a time to live (TTL) equal to zero.
By default, mDNS only and exclusively resolves host names ending with the
.local top-level domain (TLD). This can cause problems if that domain includes hosts which do not implement mDNS but which can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that violate the zero-configuration goal.
An mDNS message is a multicast UDP packet sent to the following locations:
- When using Ethernet frames, the standard multicast MAC address 01:00:5E:00:00:FB (for IPv4) or 33:33:00:00:00:FB (for IPv6).
- IPv4 address 22.214.171.124 or IPv6 address ff02::fb.
- UDP port 5353.
The header is identical to that found in unicast DNS, as are the sub-sections in the data part: queries, answers, authoritative-nameservers, and additional records.
The number of records in each sub-section matches the value of the corresponding *COUNT field in the header.
The wire format for records in the query section is slightly modified from that in unicast DNS, adding one single-bit field.
|QNAME||Name of the node to which the query pertains||Variable|
|QTYPE||The type of the query, i.e. the type of RR which should be returned in responses.||16|
|UNICAST-RESPONSE||Boolean flag indicating whether a unicast-response is desired||1|
|QCLASS||Class code, 1 a.k.a. "IN" for the Internet and IP networks||15|
As in unicast DNS, the QNAME field consists of a series of length/value sub-fields called "labels". Each label represents one of the dot-separated substrings in a fully qualified domain name (FQDN). The list is terminated by a single null-byte, representing the "root" of the DNS.
The UNICAST-RESPONSE field is used to minimize unnecessary broadcasts on the network: if the bit is set, responders SHOULD send a directed-unicast response directly to the inquiring node rather than broadcasting the response to the entire network.
The QCLASS field is identical to that found in unicast DNS.
All records in the answers, authoritative-nameservers, and additional records sections have the same format and are collectively known as "Resource Records" (RR).
Resource Records in mDNS also have a slightly modified general format from unicast DNS:
|RRNAME||Name of the node to which the record pertains||Variable|
|RRTYPE||The type of the Resource Record||16|
|CACHE-FLUSH||Boolean flag indicating whether outdated cached records should be purged||1|
|RRCLASS||Class code, 1 a.k.a. "IN" for the Internet and IP networks||15|
|TTL||Time interval (in seconds) that the RR should be cached||32|
|RDLENGTH||Integer representing the length (in octets) of the RDATA field||16|
|RDATA||Resource data; internal structure varies by RRTYPE||Variable|
The CACHE-FLUSH bit is used to instruct neighbor-nodes that the record should overwrite, rather than be appended onto, any existing cached entries for this RRNAME and RRTYPE.
The formats of the RDATA fields are the same as those found in unicast DNS. However, DNS Service Discovery (DNS-SD), the most common use-case for mDNS, specifies slight modifications to some of their formats (notably TXT records).
appletv.local host would cause an mDNS client computer to multicast the following UDP packet:
00 00 Transaction ID 00 00 Flags 00 01 Number of questions 00 00 Number of answers 00 00 Number of authority resource records 00 00 Number of additional resource records 07 61 70 70 6c 65 74 76 "appletv" 05 6c 6f 63 61 6c "local" 00 Terminator 00 01 Type (A record) 00 01 Class
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 (84 00), the
ANCOUNT word (00 01), and the
ARCOUNT word (00 02). The data again begin with the FQDN (hex 07 61 70 70 6c 65 74 76 05 6c 6f 63 61 6c 00 for appletv.local), followed by that host's DNS information:
- the A/IPv4 address type code (hex 00 01),
- the IPv4 class code (hex 80 01),
- the IPv4 TTL (hex 00 00 78 00 for 30720 seconds),
- the IPv4 length (hex 00 04),
- the four IPv4 address bytes (hex 99 6D 07 5A, or 126.96.36.199 in dotted-decimal notation),
- the FQDN offset (hex C0 0C for byte 12),
- the AAAA/IPv6 address type code (hex 00 1C),
- the IPv6 class code (hex 80 01),
- the IPv6 TTL (again hex 00 00 78 00),
- the IPv6 length (hex 00 10),
- the 16 IPv6 address bytes (hex FE 80 00 00 00 00 00 00 02 23 32 FF FE B1 21 52),
- the FQDN offset (hex C0 0C for byte 12),
- the NSEC type code (hex 00 2F),
- the NSEC class code (hex 80 01),
- the NSEC TTL (again hex 00 00 78 00),
- the NSEC length (hex 00 08, for an 8-byte name section record), and
- the 8 NSEC block and bitmap bytes (hex C0 0C 00 04 40 00 00 08)
- Avahi (software)
- Bonjour (software)
- Bonjour Sleep Proxy
- Name Service Switch (NSS)
- Zero configuration networking (Zeroconf)
- Link-Local Multicast Name Resolution (LLMNR)
- Multicast DNS. Internet Engineering Task Force (IETF). doi:10.17487/RFC6762. RFC 6762. https://tools.ietf.org/html/rfc6762. .
- Using Network Service Discovery, Google, retrieved 2017-09-01
- mDNS and DNS‐SD slowly making their way into Windows 10, Ctrl blog, retrieved 2017-08-30
- DNS Service Discovery. Internet Engineering Task Force (IETF). doi:10.17487/RFC6763. RFC 6763. https://tools.ietf.org/html/rfc6763.
- P. Mockapetris (November 1987). DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. Network Working Group, IETF. doi:10.17487/RFC1035. RFC 1035. https://tools.ietf.org/html/rfc1035. .