Multicast DNS

In computer networking, the multicast Domain Name System (mDNS) 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 to be stand-alone capable, it can work in concert with unicast DNS servers.[1]

The mDNS protocol is published as RFC 6762, uses IP multicast User Datagram Protocol (UDP) packets, and is implemented by the Apple Bonjour, Spotify Connect, Philips Hue, Google Chromecast and open source Avahi (software) software packages.

mDNS can work in conjunction with DNS Service Discovery (DNS-SD), a companion zero-configuration technique specified separately in RFC 6763.[2]

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.

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.

Packet structure

An mDNS Ethernet frame is a multicast UDP packet to:

The payload structure is based on the unicast DNS packet format, consisting of two parts—the header and the data.[3] 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.

Queries

The wire format for records in the query section is slightly modified from that in unicast DNS, adding one single-bit field.[1]

mDNS Query section fields
Field Description Length bits
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.

Resource Records

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:

mDNS Resource Record fields
Field Description Length bits
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).

Example

Trying to ping the 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:

See also

References

  1. 1 2 RFC 6762 - Multicast DNS, Internet Engineering Task Force (IETF).
  2. ↑ RFC 6763 - DNS Service Discovery, Internet Engineering Task Force (IETF)
  3. ↑ RFC 1035, Internet Engineering Task Force (IETF).
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.