RFC 6762
Multicast DNS
24. References
24.1. Normative References
[MC4] IANA, "IPv4 Multicast Address Space Registry", <http://www.iana.org/assignments/multicast-addresses/>. [MC6] IANA, "IPv6 Multicast Address Space Registry", <http://www.iana.org/assignments/ ipv6-multicast-addresses/>. [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008. [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6195, March 2011. [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013. [SN] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers/>.24.2. Informative References
[B4W] "Bonjour for Windows", <http://en.wikipedia.org/wiki/Bonjour_(software)>. [BJ] Apple Bonjour Open Source Software, <http://developer.apple.com/bonjour/>. [IEEE.802.3] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CMSA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2008, December 2008, <http://standards.ieee.org/getieee802/802.3.html>. [IEEE.802.11] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2007, June 2007, <http://standards.ieee.org/getieee802/802.11.html>.
[Jumbo] "Ethernet Jumbo Frames", November 2009, <http://www.ethernetalliance.org/library/whitepaper/ ethernet-jumbo-frames/>. [NIAS] Cheshire, S. "Discovering Named Instances of Abstract Services using DNS", Work in Progress, July 2001. [NSD] "NsdManager | Android Developer", June 2012, <http://developer.android.com/reference/ android/net/nsd/NsdManager.html>. [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011. [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, February 2013. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. [Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration Networking: The Definitive Guide", O'Reilly Media, Inc., ISBN 0-596-10100-7, December 2005.
Appendix A. Design Rationale for Choice of UDP Port Number
Arguments were made for and against using UDP port 53, the standard Unicast DNS port. Some of the arguments are given below. The arguments for using a different port were greater in number and more compelling, so that option was ultimately selected. The UDP port "5353" was selected for its mnemonic similarity to "53". Arguments for using UDP port 53: * This is "just DNS", so it should be the same port. * There is less work to be done updating old resolver libraries to do simple Multicast DNS queries. Only the destination address need be changed. In some cases, this can be achieved without any code changes, just by adding the address 224.0.0.251 to a configuration file. Arguments for using a different port (UDP port 5353): * This is not "just DNS". This is a DNS-like protocol, but different. * Changing resolver library code to use a different port number is not hard. In some cases, this can be achieved without any code changes, just by adding the address 224.0.0.251:5353 to a configuration file. * Using the same port number makes it hard to run a Multicast DNS responder and a conventional Unicast DNS server on the same machine. If a conventional Unicast DNS server wishes to implement Multicast DNS as well, it can still do that, by opening two sockets. Having two different port numbers allows this flexibility. * Some VPN software hijacks all outgoing traffic to port 53 and redirects it to a special DNS server set up to serve those VPN clients while they are connected to the corporate network. It is questionable whether this is the right thing to do, but it is common, and redirecting link-local multicast DNS packets to a remote server rarely produces any useful results. It does mean, for example, that a user of such VPN software becomes unable to access their local network printer sitting on their desk right next to their computer. Using a different UDP port helps avoid this particular problem.
* On many operating systems, unprivileged software may not send or
receive packets on low-numbered ports. This means that any
software sending or receiving Multicast DNS packets on port 53
would have to run as "root", which is an undesirable security risk.
Using a higher-numbered UDP port avoids this restriction.
Appendix B. Design Rationale for Not Using Hashed Multicast Addresses
Some discovery protocols use a range of multicast addresses, and
determine the address to be used by a hash function of the name being
sought. Queries are sent via multicast to the address as indicated
by the hash function, and responses are returned to the querier via
unicast. Particularly in IPv6, where multicast addresses are
extremely plentiful, this approach is frequently advocated. For
example, IPv6 Neighbor Discovery [RFC4861] sends Neighbor
Solicitation messages to the "solicited-node multicast address",
which is computed as a function of the solicited IPv6 address.
There are some disadvantages to using hashed multicast addresses like
this in a service discovery protocol:
* When a host has a large number of records with different names, the
host may have to join a large number of multicast groups. Each
time a host joins or leaves a multicast group, this results in
Internet Group Management Protocol (IGMP) or Multicast Listener
Discovery (MLD) traffic on the network announcing this fact.
Joining a large number of multicast groups can place undue burden
on the Ethernet hardware, which typically supports a limited number
of multicast addresses efficiently. When this number is exceeded,
the Ethernet hardware may have to resort to receiving all
multicasts and passing them up to the host networking code for
filtering in software, thereby defeating much of the point of using
a multicast address range in the first place. Finally, many IPv6
stacks have a fixed limit IPV6_MAX_MEMBERSHIPS, and the code simply
fails with an error if a client attempts to exceed this limit.
Common values for IPV6_MAX_MEMBERSHIPS are 20 or 31.
* Multiple questions cannot be placed in one packet if they don't all
hash to the same multicast address.
* Duplicate Question Suppression doesn't work if queriers are not
seeing each other's queries.
* Duplicate Answer Suppression doesn't work if responders are not
seeing each other's responses.
* Opportunistic Caching doesn't work.
* Ongoing Conflict Detection doesn't work.Appendix C. Design Rationale for Maximum Multicast DNS Name Length
Multicast DNS names may be up to 255 bytes long (in the on-the-wire message format), not counting the terminating zero byte at the end. "Domain Names - Implementation and Specification" [RFC1035] says: Various objects and parameters in the DNS have size limits. They are listed below. Some could be easily changed, others are more fundamental. labels 63 octets or less names 255 octets or less ... the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less. This text does not state whether this 255-byte limit includes the terminating zero at the end of every name. Several factors lead us to conclude that the 255-byte limit does *not* include the terminating zero: o It is common in software engineering to have size limits that are a power of two, or a multiple of a power of two, for efficiency. For example, an integer on a modern processor is typically 2, 4, or 8 bytes, not 3 or 5 bytes. The number 255 is not a power of two, nor is it to most people a particularly noteworthy number. It is noteworthy to computer scientists for only one reason -- because it is exactly one *less* than a power of two. When a size limit is exactly one less than a power of two, that suggests strongly that the one extra byte is being reserved for some specific reason -- in this case reserved, perhaps, to leave room for a terminating zero at the end. o In the case of DNS label lengths, the stated limit is 63 bytes. As with the total name length, this limit is exactly one less than a power of two. This label length limit also excludes the label length byte at the start of every label. Including that extra byte, a 63-byte label takes 64 bytes of space in memory or in a DNS message.
o It is common in software engineering for the semantic "length" of
an object to be one less than the number of bytes it takes to store
that object. For example, in C, strlen("foo") is 3, but
sizeof("foo") (which includes the terminating zero byte at the end)
is 4.
o The text describing the total length of a domain name mentions
explicitly that label length and data octets are included, but does
not mention the terminating zero at the end. The zero byte at the
end of a domain name is not a label length. Indeed, the value zero
is chosen as the terminating marker precisely because it is not a
legal length byte value -- DNS prohibits empty labels. For
example, a name like "bad..name." is not a valid domain name
because it contains a zero-length label in the middle, which cannot
be expressed in a DNS message, because software parsing the message
would misinterpret a zero label-length byte as being a zero "end of
name" marker instead.
Finally, "Clarifications to the DNS Specification" [RFC2181] offers
additional confirmation that, in the context of DNS specifications,
the stated "length" of a domain name does not include the terminating
zero byte at the end. That document refers to the root name, which
is typically written as "." and is represented in a DNS message by a
single lone zero byte (i.e., zero bytes of data plus a terminating
zero), as the "zero length full name":
The zero length full name is defined as representing the root of
the DNS tree, and is typically written and displayed as ".".
This wording supports the interpretation that, in a DNS context, when
talking about lengths of names, the terminating zero byte at the end
is not counted. If the root name (".") is considered to be zero
length, then to be consistent, the length (for example) of "org" has
to be 4 and the length of "ietf.org" has to be 9, as shown below:
------
| 0x00 | length = 0
------
------------------ ------
| 0x03 | o | r | g | | 0x00 | length = 4
------------------ ------
----------------------------------------- ------
| 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 | length = 9
----------------------------------------- ------
This means that the maximum length of a domain name, as represented in a Multicast DNS message, up to but not including the final terminating zero, must not exceed 255 bytes. However, many Unicast DNS implementers have read these RFCs differently, and argue that the 255-byte limit does include the terminating zero, and that the "Clarifications to the DNS Specification" [RFC2181] statement that "." is the "zero length full name" was simply a mistake. Hence, implementers should be aware that other Unicast DNS implementations may limit the maximum domain name to 254 bytes plus a terminating zero, depending on how that implementer interpreted the DNS specifications. Compliant Multicast DNS implementations MUST support names up to 255 bytes plus a terminating zero, i.e., 256 bytes total.Appendix D. Benefits of Multicast Responses
Some people have argued that sending responses via multicast is inefficient on the network. In fact, using multicast responses can result in a net lowering of overall multicast traffic for a variety of reasons, and provides other benefits too: * Opportunistic Caching. One multicast response can update the caches on all machines on the network. If another machine later wants to issue the same query, and it already has the answer in its cache, it may not need to even transmit that multicast query on the network at all. * Duplicate Query Suppression. When more than one machine has the same ongoing long-lived query running, every machine does not have to transmit its own independent query. When one machine transmits a query, all the other hosts see the answers, so they can suppress their own queries. * Passive Observation Of Failures (POOF). When a host sees a multicast query, but does not see the corresponding multicast response, it can use this information to promptly delete stale data from its cache. To achieve the same level of user-interface quality and responsiveness without multicast responses would require lower cache lifetimes and more frequent network polling, resulting in a higher packet rate. * Passive Conflict Detection. Just because a name has been previously verified to be unique does not guarantee it will continue to be so indefinitely. By allowing all Multicast DNS
responders to constantly monitor their peers' responses, conflicts
arising out of network topology changes can be promptly detected
and resolved. If responses were not sent via multicast, some other
conflict detection mechanism would be needed, imposing its own
additional burden on the network.
* Use on devices with constrained memory resources: When using
delayed responses to reduce network collisions, responders need to
maintain a list recording to whom each answer should be sent. The
option of multicast responses allows responders with limited
storage, which cannot store an arbitrarily long list of response
addresses, to choose to fail-over to a single multicast response in
place of multiple unicast responses, when appropriate.
* Overlayed Subnets. In the case of overlayed subnets, multicast
responses allow a receiver to know with certainty that a response
originated on the local link, even when its source address may
apparently suggest otherwise.
* Robustness in the face of misconfiguration: Link-local multicast
transcends virtually every conceivable network misconfiguration.
Even if you have a collection of devices where every device's IP
address, subnet mask, default gateway, and DNS server address are
all wrong, packets sent by any of those devices addressed to a
link-local multicast destination address will still be delivered to
all peers on the local link. This can be extremely helpful when
diagnosing and rectifying network problems, since it facilitates a
direct communication channel between client and server that works
without reliance on ARP, IP routing tables, etc. Being able to
discover what IP address a device has (or thinks it has) is
frequently a very valuable first step in diagnosing why it is
unable to communicate on the local network.
Appendix E. Design Rationale for Encoding Negative Responses
Alternative methods of asserting nonexistence were considered, such
as using an NXDOMAIN response, or emitting a resource record with
zero-length rdata.
Using an NXDOMAIN response does not work well with Multicast DNS. A
Unicast DNS NXDOMAIN response applies to the entire message, but for
efficiency Multicast DNS allows (and encourages) multiple responses
in a single message. If the error code in the header were NXDOMAIN,
it would not be clear to which name(s) that error code applied.
Asserting nonexistence by emitting a resource record with zero-length
rdata would mean that there would be no way to differentiate between
a record that doesn't exist, and a record that does exist, with zero-
length rdata. By analogy, most file systems today allow empty files, so a file that exists with zero bytes of data is not considered equivalent to a filename that does not exist. A benefit of asserting nonexistence through NSEC records instead of through NXDOMAIN responses is that NSEC records can be added to the Additional Section of a DNS response to offer additional information beyond what the querier explicitly requested. For example, in response to an SRV query, a responder should include A record(s) giving its IPv4 addresses in the Additional Section, and an NSEC record indicating which other types it does or does not have for this name. If the responder is running on a host that does not support IPv6 (or does support IPv6 but currently has no IPv6 address on that interface) then this NSEC record in the Additional Section will indicate this absence of AAAA records. In effect, the responder is saying, "Here's my SRV record, and here are my IPv4 addresses, and no, I don't have any IPv6 addresses, so don't waste your time asking". Without this information in the Additional Section, it would take the querier an additional round-trip to perform an additional query to ascertain that the target host has no AAAA records. (Arguably Unicast DNS could also benefit from this ability to express nonexistence in the Additional Section, but that is outside the scope of this document.)Appendix F. Use of UTF-8
After many years of debate, as a result of the perceived need to accommodate certain DNS implementations that apparently couldn't handle any character that's not a letter, digit, or hyphen (and apparently never would be updated to remedy this limitation), the Unicast DNS community settled on an extremely baroque encoding called "Punycode" [RFC3492]. Punycode is a remarkably ingenious encoding solution, but it is complicated, hard to understand, and hard to implement, using sophisticated techniques including insertion unsort coding, generalized variable-length integers, and bias adaptation. The resulting encoding is remarkably compact given the constraints, but it's still not as good as simple straightforward UTF-8, and it's hard even to predict whether a given input string will encode to a Punycode string that fits within DNS's 63-byte limit, except by simply trying the encoding and seeing whether it fits. Indeed, the encoded size depends not only on the input characters, but on the order they appear, so the same set of characters may or may not encode to a legal Punycode string that fits within DNS's 63-byte limit, depending on the order the characters appear. This is extremely hard to present in a user interface that explains to users why one name is allowed, but another name containing the exact same characters is not. Neither Punycode nor any other of the "ASCII- Compatible Encodings" [RFC5890] proposed for Unicast DNS may be used
in Multicast DNS messages. Any text being represented internally in some other representation must be converted to canonical precomposed UTF-8 before being placed in any Multicast DNS message.Appendix G. Private DNS Namespaces
The special treatment of names ending in ".local." has been implemented in Macintosh computers since the days of Mac OS 9, and continues today in Mac OS X and iOS. There are also implementations for Microsoft Windows [B4W], Linux, and other platforms. Some network operators setting up private internal networks ("intranets") have used unregistered top-level domains, and some may have used the ".local" top-level domain. Using ".local" as a private top-level domain conflicts with Multicast DNS and may cause problems for users. Clients can be configured to send both Multicast and Unicast DNS queries in parallel for these names, and this does allow names to be looked up both ways, but this results in additional network traffic and additional delays in name resolution, as well as potentially creating user confusion when it is not clear whether any given result was received via link-local multicast from a peer on the same link, or from the configured unicast name server. Because of this, we recommend against using ".local" as a private Unicast DNS top-level domain. We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose: .intranet. .internal. .private. .corp. .home. .lan.Appendix H. Deployment History
In July 1997, in an email to the net-thinkers@thumper.vmeng.com mailing list, Stuart Cheshire first proposed the idea of running the AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of this and related IETF discussions, the IETF Zeroconf working group was chartered September 1999. After various working group discussions and other informal IETF discussions, several Internet- Drafts were written that were loosely related to the general themes of DNS and multicast, but did not address the service discovery aspect of NBP.
In April 2000, Stuart Cheshire registered IPv4 multicast address 224.0.0.251 with IANA [MC4] and began writing code to test and develop the idea of performing NBP-like service discovery using Multicast DNS, which was documented in a group of three Internet- Drafts: o "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk Name Binding Protocol, because many in the IETF community had little first-hand experience using AppleTalk, and confusion in the IETF community about what AppleTalk NBP did was causing confusion about what would be required in an IP-based replacement. o "Discovering Named Instances of Abstract Services using DNS" [NIAS] proposed a way to perform NBP-like service discovery using DNS- compatible names and record types. o "Multicast DNS" (this document) specifies a way to transport those DNS-compatible queries and responses using IP multicast, for zero- configuration environments where no conventional Unicast DNS server was available. In 2001, an update to Mac OS 9 added resolver library support for host name lookup using Multicast DNS. If the user typed a name such as "MyPrinter.local." into any piece of networking software that used the standard Mac OS 9 name lookup APIs, then those name lookup APIs would recognize the name as a dot-local name and query for it by sending simple one-shot Multicast DNS queries to 224.0.0.251:5353. This enabled the user to, for example, enter the name "MyPrinter.local." into their web browser in order to view a printer's status and configuration web page, or enter the name "MyPrinter.local." into the printer setup utility to create a print queue for printing documents on that printer. Multicast DNS responder software, with full service discovery, first began shipping to end users in volume with the launch of Mac OS X 10.2 "Jaguar" in August 2002, and network printer makers (who had historically supported AppleTalk in their network printers and were receptive to IP-based technologies that could offer them similar ease-of-use) started adopting Multicast DNS shortly thereafter. In September 2002, Apple released the source code for the mDNSResponder daemon as Open Source under Apple's standard Apple Public Source License (APSL). Multicast DNS responder software became available for Microsoft Windows users in June 2004 with the launch of Apple's "Rendezvous for Windows" (now "Bonjour for Windows"), both in executable form (a
downloadable installer for end users) and as Open Source (one of the supported platforms within Apple's body of cross-platform code in the publicly accessible mDNSResponder CVS source code repository) [BJ]. In August 2006, Apple re-licensed the cross-platform mDNSResponder source code under the Apache License, Version 2.0. In addition to desktop and laptop computers running Mac OS X and Microsoft Windows, Multicast DNS is now implemented in a wide range of hardware devices, such as Apple's "AirPort" wireless base stations, iPhone and iPad, and in home gateways from other vendors, network printers, network cameras, TiVo DVRs, etc. The Open Source community has produced many independent implementations of Multicast DNS, some in C like Apple's mDNSResponder daemon, and others in a variety of different languages including Java, Python, Perl, and C#/Mono. In January 2007, the IETF published the Informational RFC "Link-Local Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially similar to Multicast DNS, but incompatible in some small but important ways. In particular, the LLMNR design explicitly excluded support for service discovery, which made it an unsuitable candidate for a protocol to replace AppleTalk NBP [RFC6760]. While the original focus of Multicast DNS and DNS-Based Service Discovery was for zero-configuration environments without a conventional Unicast DNS server, DNS-Based Service Discovery also works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007] to create service discovery records and standard DNS queries to query for them. Apple's Back to My Mac service, launched with Mac OS X 10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over Unicast DNS [RFC6281]. In June 2012, Google's Android operating system added native support for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].
Authors' Addresses
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Phone: +1 408 974 3207 EMail: cheshire@apple.com Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Phone: +1 408 974 4368 EMail: marc@apple.com