tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6762

 
 
 

Multicast DNS

Part 4 of 4, p. 56 to 70
Prev RFC Part

 


prevText      Top      Up      ToC       Page 56 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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