Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6762

Multicast DNS

Pages: 70
Proposed Standard
Errata
Part 4 of 4 – Pages 56 to 70
First   Prev   None

Top   ToC   RFC6762 - Page 56   prevText

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.
Top   ToC   RFC6762 - Page 57
   [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>.
Top   ToC   RFC6762 - Page 58
   [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.
Top   ToC   RFC6762 - Page 59
   [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.
Top   ToC   RFC6762 - Page 60

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.
Top   ToC   RFC6762 - Page 61
   * 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.
Top   ToC   RFC6762 - Page 62
   * 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.
Top   ToC   RFC6762 - Page 63
   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
      -----------------------------------------   ------
Top   ToC   RFC6762 - Page 64
   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
Top   ToC   RFC6762 - Page 65
     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-
Top   ToC   RFC6762 - Page 66
   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
Top   ToC   RFC6762 - Page 67
   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.
Top   ToC   RFC6762 - Page 68
   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
Top   ToC   RFC6762 - Page 69
   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].
Top   ToC   RFC6762 - Page 70

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