|
|
|
|
|
The Multicast Domain Name System (mDNS) is a zero configuratuion (zeroconf) DNS service to resolve hostnames to IP addresses within small networks.
Overview
The purpose of the multicast Domain Name System (mDNS) is to resolve hostnames 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 (DNS). 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 (UDP) packets, and is implemented by the Apple Bonjour and Linux nss-mdns services. The mDNS can work in conjunction with DNS Service Discovery (DNS-SD), which is a companion zero configuration technique that is separately specified in RFC 6763.
When an mDNS client needs to resolve a hostname, 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 (TTL) equal to zero.By default, mDNS only and exclusively resolves hostnames ending with the .local top-level domain (TLD). 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.
Background
Computer networks use numerical "addresses" to identify communications endpoints in a network of network-enabled devices. This is not unlike the telephone network, which assigns a string of digits to identify each phone, In modern networking protocols, information to be transmitted is broken down into a series of network packets, and every packet contains the source and destination addresses. Equipment embedded in the network examines these addresses to determine the best route to forward the data packet in the proper direction. These numbers are not intended to be human-readable, and may be reassigned dynamically as the network configuration changes.
This presents a problem of identifying devices to the end user. Telephones often have their number written on them, and this was not uncommon on early networks as well, where it was not uncommon to see the address written on a piece of tape stuck to the front of the device. More recently, devices often include some sort of display that reads the number from the internal configuration, and is therefore up-to-date when any changes to addressing occur. But even if the user can determine the address, this does not completely solve the problems. While it is possible for the user to type in short addresses, like
100
or even the longer
10.165.43.27
which is used for most internet addresses based on IPv4, this fails for systems like IPv6 where the addresses are very long and the chance of correctly typing in the full address without errors is lower.
To address this problem, many networking systems include some sort of directory service, a database that allows human-readable names to be assigned to the numeric addresses. Computer software asking the user to identify a device instead asks them to type in a name, and then the software asks the database to translate that to an address. The software then uses the provided address for further communications with the other network devices. Data from the database is automatically collected and distributed so it is always up-to-date and reflects changes in addresses.
The primary benefits of mDNS names are:
Packet Structure
The mDNS Ethernet frame is a multicast UDP packet to:
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 (FQDN) to be resolved, and ends with two 2-byte flags indicating the QTYPE (001 for a host address query) and QCLASS (00 01 for Internet):
The FQDN is specified by a list of component strings, beginning with the hostname and ending with the top-level domain (TLD). Each such string consists of a length byte followed by that many UTF-8 bytes. The TLD is followed by a null string (hex 00) that terminates the FQDN.The target host's IPv4 address record consists of:
Its IPv6 address record consists of:
The name section record consists of:
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.