Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6763


DNS-Based Service Discovery

Part 3 of 3, p. 33 to 49
Prev RFC Part


prevText      Top      Up      ToC       Page 33 
18.  References

18.1.  Normative References

   [RFC20]     Cerf, V., "ASCII format for network interchange", RFC 20,
               October 1969.

   [RFC1033]   Lottor, M., "Domain Administrators Operations Guide", RFC
               1033, November 1987.

   [RFC1034]   Mockapetris, P., "Domain names - concepts and
               facilities", STD 13, RFC 1034, November 1987.

Top      Up      ToC       Page 34 
   [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.

   [RFC2782]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
               specifying the location of services (DNS SRV)", RFC 2782,
               February 2000.

   [RFC3492]   Costello, A., "Punycode: A Bootstring encoding of Unicode
               for Internationalized Domain Names in Applications
               (IDNA)", RFC 3492, March 2003.

   [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO
               10646", STD 63, RFC 3629, November 2003.

   [RFC3927]   Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
               Configuration of IPv4 Link-Local Addresses", RFC 3927,
               May 2005.

   [RFC4862]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
               Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5198]   Klensin, J. and M. Padlipsky, "Unicode Format for Network
               Interchange", RFC 5198, March 2008.

   [RFC5890]   Klensin, J., "Internationalized Domain Names for
               Applications (IDNA): Definitions and Document Framework",
               RFC 5890, August 2010.

   [RFC6335]   Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
               Cheshire, "Internet Assigned Numbers Authority (IANA)
               Procedures for the Management of the Service Name and
               Transport Protocol Port Number Registry", BCP 165, RFC
               6335, August 2011.

18.2.  Informative References

   [AFP]       Mac OS X Developer Library, "Apple Filing Protocol
               Programming Guide", <

   [BJ]        Apple Bonjour Open Source Software,

Top      Up      ToC       Page 35 
   [BJP]       Bonjour Printing Specification,

   [IEEEW]     IEEE 802 LAN/MAN Standards Committee,

   [NIAS]      Cheshire, S., "Discovering Named Instances of Abstract
               Services using DNS", Work in Progress, July 2001.

   [NSD]       "NsdManager | Android Developer", June 2012,

   [RFC1179]   McLaughlin, L., "Line printer daemon protocol", RFC 1179,
               August 1990.

   [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.

   [RFC2910]   Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and
               J. Wenn, "Internet Printing Protocol/1.1: Encoding and
               Transport", RFC 2910, September 2000.

   [RFC4960]   Stewart, R., Ed., "Stream Control Transmission Protocol",
               RFC 4960, September 2007.

   [RFC3007]   Wellington, B., "Secure Domain Name System (DNS) Dynamic
               Update", RFC 3007, November 2000.

   [RFC4340]   Kohler, E., Handley, M., and S. Floyd, "Datagram
               Congestion Control Protocol (DCCP)", RFC 4340, March

   [RFC3397]   Aboba, B. and S. Cheshire, "Dynamic Host Configuration
               Protocol (DHCP) Domain Search Option", RFC 3397, November

   [RFC4033]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "DNS Security Introduction and Requirements", RFC
               4033, March 2005.

Top      Up      ToC       Page 36 
   [RFC4648]   Josefsson, S., "The Base16, Base32, and Base64 Data
               Encodings", RFC 4648, October 2006.

   [RFC4795]   Aboba, B., Thaler, D., and L. Esibov, "Link-local
               Multicast Name Resolution (LLMNR)", RFC 4795, January

   [RFC6106]   Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
               "IPv6 Router Advertisement Options for DNS
               Configuration", RFC 6106, November 2010.

   [RFC6281]   Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
               "Understanding Apple's Back to My Mac (BTMM) Service",
               RFC 6281, June 2011.

   [RFC6709]   Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
               Considerations for Protocol Extensions", RFC 6709,
               September 2012.

   [RFC6760]   Cheshire, S. and M. Krochmal, "Requirements for a
               Protocol to Replace the AppleTalk Name Binding Protocol
               (NBP)", RFC 6760, February 2013.

   [RFC6762]   Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
               February 2013.

   [SN]        IANA, "Service Name and Transport Protocol Port Number
               Registry", <

   [SOAP]      Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C
               Proposed Recommendation 24 June 2003,

   [Unicode6]  The Unicode Consortium. The Unicode Standard, Version
               6.0.0, (Mountain View, CA: The Unicode Consortium, 2011.
               ISBN 978-1-936213-01-6)

   [ZC]        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 37 
Appendix A.  Rationale for Using DNS as a Basis for Service Discovery

   Over the years, there have been many proposed ways to do network
   service discovery with IP, but none achieved ubiquity in the
   marketplace.  Certainly none has achieved anything close to the
   ubiquity of today's deployment of DNS servers, clients, and other

   The advantage of using DNS as the basis for service discovery is that
   it makes use of those existing servers, clients, protocols,
   infrastructure, and expertise.  Existing network analyzer tools
   already know how to decode and display DNS packets for network

   For ad hoc networks such as Zeroconf environments, peer-to-peer
   multicast protocols are appropriate.  Using DNS-SD running over
   Multicast DNS [RFC6762] provides zero-configuration ad hoc service
   discovery, while maintaining the DNS-SD semantics and record types
   described here.

   In larger networks, a high volume of enterprise-wide IP multicast
   traffic may not be desirable, so any credible service discovery
   protocol intended for larger networks has to provide some facility to
   aggregate registrations and lookups at a central server (or servers)
   instead of working exclusively using multicast.  This requires some
   service discovery aggregation server software to be written,
   debugged, deployed, and maintained.  This also requires some service
   discovery registration protocol to be implemented and deployed for
   clients to register with the central aggregation server.  Virtually
   every company with an IP network already runs a DNS server, and DNS
   already has a dynamic registration protocol [RFC2136] [RFC3007].
   Given that virtually every company already has to operate and
   maintain a DNS server anyway, it makes sense to take advantage of
   this expertise instead of also having to learn, operate, and maintain
   a different service registration server.  It should be stressed again
   that using the same software and protocols doesn't necessarily mean
   using the same physical piece of hardware.  The DNS-SD service
   discovery functions do not have to be provided by the same piece of
   hardware that is currently providing the company's DNS name service.
   The "_tcp.<Domain>" and "_udp.<Domain>" subdomains may be delegated
   to a different piece of hardware.  However, even when the DNS-SD
   service is being provided by a different piece of hardware, it is
   still the same familiar DNS server software, with the same
   configuration file syntax, the same log file format, and so forth.

   Service discovery needs to be able to provide appropriate security.
   DNS already has existing mechanisms for security [RFC4033].

Top      Up      ToC       Page 38 
   In summary:

      Service discovery requires a central aggregation server.
      DNS already has one: a DNS server.

      Service discovery requires a service registration protocol.
      DNS already has one: DNS Dynamic Update.

      Service discovery requires a query protocol.
      DNS already has one: DNS queries.

      Service discovery requires security mechanisms.
      DNS already has security mechanisms: DNSSEC.

      Service discovery requires a multicast mode for ad hoc networks.
      Using DNS-SD in conjunction with Multicast DNS provides this,
      using peer-to-peer multicast instead of a DNS server.

   It makes more sense to use the existing software that every network
   needs already, instead of deploying an entire parallel system just
   for service discovery.

Appendix B.  Ordering of Service Instance Name Components

   There have been questions about why services are named using DNS
   Service Instance Names of the form:

      Service Instance Name = <Instance> . <Service> . <Domain>

   instead of:

      Service Instance Name = <Service> . <Instance> . <Domain>

   There are three reasons why it is beneficial to name service
   instances with the parent domain as the most-significant (rightmost)
   part of the name, then the abstract service type as the next-most
   significant, and then the specific instance name as the least-
   significant (leftmost) part of the name.  These reasons are discussed
   below in Sections B.1, B.2, and B.3.

B.1.  Semantic Structure

   The facility being provided by browsing ("Service Instance
   Enumeration") is effectively enumerating the leaves of a tree
   structure.  A given domain offers zero or more services.  For each of
   those service types, there may be zero or more instances of that

Top      Up      ToC       Page 39 
   The user knows what type of service they are seeking.  (If they are
   running an FTP client, they are looking for FTP servers.  If they
   have a document to print, they are looking for entities that speak
   some known printing protocol.)  The user knows in which
   organizational or geographical domain they wish to search.  (The user
   does not want a single flat list of every single printer on the
   planet, even if such a thing were possible.)  What the user does not
   know in advance is whether the service they seek is offered in the
   given domain, or if so, the number of instances that are offered and
   the names of those instances.

   Hence, having the instance names be the leaves of the tree is
   consistent with this semantic model.

   Having the service types be the terminal leaves of the tree would
   imply that the user knows the domain name and the name of the service
   instance, but doesn't have any idea what the service does.  We would
   argue that this is a less useful model.

B.2.  Network Efficiency

   When a DNS response contains multiple answers, name compression works
   more effectively if all the names contain a common suffix.  If many
   answers in the packet have the same <Service> and <Domain>, then each
   occurrence of a Service Instance Name can be expressed using only the
   <Instance> part followed by a two-byte compression pointer
   referencing a previous appearance of "<Service>.<Domain>".  This
   efficiency would not be possible if the <Service> component appeared
   first in each name.

B.3.  Operational Flexibility

   This name structure allows subdomains to be delegated along logical
   service boundaries.  For example, the network administrator at
   Example Co. could choose to delegate the ""
   subdomain to a different machine, so that the machine handling
   service discovery doesn't have to be the machine that handles other
   day-to-day DNS operations.  (It *can* be the same machine if the
   administrator so chooses, but the administrator is free to make that
   choice.)  Furthermore, if the network administrator wishes to
   delegate all information related to IPP printers to a machine
   dedicated to that specific task, this is easily done by delegating
   the "" subdomain to the desired machine.  It is
   also convenient to set security policies on a per-zone/per-subdomain
   basis.  For example, the administrator may choose to enable DNS
   Dynamic Update [RFC2136] [RFC3007] for printers registering in the

Top      Up      ToC       Page 40 
   "" subdomain, but not for other
   zones/subdomains.  This easy flexibility would not exist if the
   <Service> component appeared first in each name.

Appendix C.  What You See Is What You Get

   Some service discovery protocols decouple the true service identifier
   from the name presented to the user.  The true service identifier
   used by the protocol is an opaque unique identifier, often
   represented using a long string of hexadecimal digits, which should
   never be seen by the typical user.  The name presented to the user is
   merely one of the decorative ephemeral attributes attached to this
   opaque identifier.

   The problem with this approach is that it decouples user perception
   from network reality:

   *  What happens if there are two service instances, with different
      unique ids, but they have inadvertently been given the same user-
      visible name?  If two instances appear in an on-screen list with
      the same name, how does the user know which is which?

   *  Suppose a printer breaks down, and the user replaces it with
      another printer of the same make and model, and configures the new
      printer with the exact same name as the one being replaced:
      "Stuart's Printer".  Now, when the user tries to print, the on-
      screen print dialog tells them that their selected default printer
      is "Stuart's Printer".  When they browse the network to see what
      is there, they see a printer called "Stuart's Printer", yet when
      the user tries to print, they are told that the printer "Stuart's
      Printer" can't be found.  The hidden internal unique identifier
      that the software is trying to find on the network doesn't match
      the hidden internal unique identifier of the new printer, even
      though its apparent "name" and its logical purpose for being there
      are the same.  To remedy this, the user typically has to delete
      the print queue they have created, and then create a new
      (apparently identical) queue for the new printer, so that the new
      queue will contain the right hidden internal unique identifier.
      Having all this hidden information that the user can't see makes
      for a confusing and frustrating user experience, and exposing
      long, ugly hexadecimal strings to the user and forcing them to
      understand what they mean is even worse.

   *  Suppose an existing printer is moved to a new department, and
      given a new name and a new function.  Changing the user-visible
      name of that piece of hardware doesn't change its hidden internal
      unique identifier.  Users who had previously created a print queue

Top      Up      ToC       Page 41 
      for that printer will still be accessing the same hardware by its
      unique identifier, even though the logical service that used to be
      offered by that hardware has ceased to exist.

   Solving these problems requires the user or administrator to be aware
   of the supposedly hidden unique identifier, and to set its value
   correctly as hardware is moved around, repurposed, or replaced,
   thereby contradicting the notion that it is a hidden identifier that
   human users never need to deal with.  Requiring the user to
   understand this expert behind-the-scenes knowledge of what is
   *really* going on is just one more burden placed on the user when
   they are trying to diagnose why their computers and network devices
   are not working as expected.

   These anomalies and counterintuitive behaviors can be eliminated by
   maintaining a tight bidirectional one-to-one mapping between what the
   user sees on the screen and what is really happening "behind the
   curtain".  If something is configured incorrectly, then that is
   apparent in the familiar day-to-day user interface that everyone
   understands, not in some little-known, rarely used "expert"

   In summary: in DNS-SD the user-visible name is also the primary
   identifier for a service.  If the user-visible name is changed, then
   conceptually the service being offered is a different logical service
   -- even though the hardware offering the service may have stayed the
   same.  If the user-visible name doesn't change, then conceptually the
   service being offered is the same logical service -- even if the
   hardware offering the service is new hardware brought in to replace
   some old equipment.

   There are certainly arguments on both sides of this debate.
   Nonetheless, the designers of any service discovery protocol have to
   make a choice between having the primary identifiers be hidden, or
   having them be visible, and these are the reasons that we chose to
   make them visible.  We're not claiming that there are no
   disadvantages of having primary identifiers be visible.  We
   considered both alternatives, and we believe that the few
   disadvantages of visible identifiers are far outweighed by the many
   problems caused by use of hidden identifiers.

Top      Up      ToC       Page 42 
Appendix D.  Choice of Factory-Default Names

   When a DNS-SD service is advertised using Multicast DNS [RFC6762], if
   there is already another service of the same type advertising with
   the same name then automatic name conflict resolution will occur.  As
   described in the Multicast DNS specification [RFC6762], upon
   detecting a conflict, the service should:

   1.  Automatically select a new name (typically by appending or
       incrementing a digit at the end of the name),
   2.  Try advertising with the new name, and
   3.  Upon success, record the new name in persistent storage.

   This renaming behavior is very important, because it is key to
   providing user-friendly instance names in the out-of-the-box factory-
   default configuration.  Some product developers apparently have not
   realized this, because there are some products today where the
   factory-default name is distinctly unfriendly, containing random-
   looking strings of characters, such as the device's Ethernet address
   in hexadecimal.  This is unnecessary and undesirable, because the
   point of the user-visible name is that it should be friendly and
   meaningful to human users.  If the name is not unique on the local
   network then the protocol will remedy this as necessary.  It is
   ironic that many of the devices with this design mistake are network
   printers, given that these same printers also simultaneously support
   AppleTalk-over-Ethernet, with nice user-friendly default names (and
   automatic conflict detection and renaming).  Some examples of good
   factory-default names are:

      Brother 5070N
      Canon W2200
      HP LaserJet 4600
      Lexmark W840
      Okidata C5300
      Ricoh Aficio CL7100
      Xerox Phaser 6200DX

   To make the case for why adding long, ugly factory-unique serial
   numbers to the end of names is neither necessary nor desirable,
   consider the cases where the user has (a) only one network printer,
   (b) two network printers, and (c) many network printers.

   (a)  In the case where the user has only one network printer,
        a simple name like (to use a vendor-neutral example)
        "Printer" is more user-friendly than an ugly name like
        "Printer_0001E68C74FB".  Appending ugly hexadecimal goop to the
        end of the name to make sure the name is unique is irrelevant to
        a user who only has one printer anyway.

Top      Up      ToC       Page 43 
   (b)  In the case where the user gets a second network printer, having
        the new printer detect that the name "Printer" is already in use
        and automatically name itself "Printer (2)" instead, provides a
        good user experience.  For most users, remembering that the old
        printer is "Printer" and the new one is "Printer (2)" is easy
        and intuitive.  Seeing a printer called "Printer_0001E68C74FB"
        and another called "Printer_00306EC3FD1C" is a lot less helpful.

   (c)  In the case of a network with ten network printers, seeing a
        list of ten names all of the form "Printer_xxxxxxxxxxxx" has
        effectively taken what was supposed to be a list of user-
        friendly rich-text names (supporting mixed case, spaces,
        punctuation, non-Roman characters, and other symbols) and turned
        it into just about the worst user interface imaginable: a list
        of incomprehensible random-looking strings of letters and
        digits.  In a network with a lot of printers, it would be
        advisable for the people setting up the printers to take a
        moment to give each one a descriptive name, but in the event
        they don't, presenting the users with a list of sequentially
        numbered printers is a much more desirable default user
        experience than showing a list of raw Ethernet addresses.

Top      Up      ToC       Page 44 
Appendix E.  Name Encodings in the Domain Name System

   Although the original DNS specifications [RFC1033] [RFC1034]
   [RFC1035] recommend that host names contain only letters, digits, and
   hyphens (because of the limitations of the typing-based user
   interfaces of that era), Service Instance Names are not host names.
   Users generally access a service by selecting it from a list
   presented by a user interface, not by typing in its Service Instance
   Name. "Clarifications to the DNS Specification" [RFC2181] directly
   discusses the subject of allowable character set in Section 11 ("Name
   syntax"), and explicitly states that the traditional letters-digits-
   hyphens rule applies only to conventional host names:

      Occasionally it is assumed that the Domain Name System serves only
      the purpose of mapping Internet host names to data, and mapping
      Internet addresses to host names.  This is not correct, the DNS is
      a general (if somewhat limited) hierarchical database, and can
      store almost any kind of data, for almost any purpose.

      The DNS itself places only one restriction on the particular
      labels that can be used to identify resource records.  That one
      restriction relates to the length of the label and the full name.
      The length of any one label is limited to between 1 and 63 octets.
      A full domain name is limited to 255 octets (including the
      separators).  The zero length full name is defined as representing
      the root of the DNS tree, and is typically written and displayed
      as ".".  Those restrictions aside, any binary string whatever can
      be used as the label of any resource record.  Similarly, any
      binary string can serve as the value of any record that includes a
      domain name as some or all of its value (SOA, NS, MX, PTR, CNAME,
      and any others that may be added).  Implementations of the DNS
      protocols must not place any restrictions on the labels that can
      be used.  In particular, DNS servers must not refuse to serve a
      zone because it contains labels that might not be acceptable to
      some DNS client programs.

   Note that just because DNS-based Service Discovery supports arbitrary
   UTF-8-encoded names doesn't mean that any particular user or
   administrator is obliged to make use of that capability.  Any user is
   free, if they wish, to continue naming their services using only
   letters, digits, and hyphens, with no spaces, capital letters, or
   other punctuation.

Top      Up      ToC       Page 45 
Appendix F.  "Continuous Live Update" Browsing Model

   Of particular concern in the design of DNS-SD, especially when used
   in conjunction with ad hoc Multicast DNS, is the dynamic nature of
   service discovery in a changing network environment.  Other service
   discovery protocols seem to have been designed with an implicit
   unstated assumption that the usage model is:

   (a)  client software calls the service discovery API,
   (b)  service discovery code spends a few seconds getting a list of
        instances available at a particular moment in time, and then
   (c)  client software displays the list for the user to select from.

   Superficially this usage model seems reasonable, but the problem is
   that it's too optimistic.  It only considers the success case, where
   the software immediately finds the service instance the user is
   looking for.

   In the case where the user is looking for (say) a particular printer,
   and that printer is not turned on or not connected, the user first
   has to attempt to remedy the problem, and then has to click a
   "refresh" button to retry the service discovery to find out whether
   they were successful.  Because nothing happens instantaneously in
   networking, and packets can be lost, necessitating some number of
   retransmissions, a service discovery search is not instantaneous and
   typically takes a few seconds.  As a result, a fairly typical user
   experience is:

   (a)  display an empty window,
   (b)  display some animation like a searchlight sweeping back and
        forth for ten seconds, and then
   (c)  at the end of the ten-second search, display a static list
        showing what was discovered.

   Every time the user clicks the "refresh" button they have to endure
   another ten-second wait, and every time the discovered list is
   finally shown at the end of the ten-second wait, it's already
   beginning to get stale and out-of-date the moment it's displayed on
   the screen.

   The service discovery user experience that the DNS-SD designers had
   in mind has some rather different properties:

   1.  Displaying the initial list of discovered services should be
       effectively instantaneous -- i.e., typically 0.1 seconds, not 10

Top      Up      ToC       Page 46 
   2.  The list of discovered services should not be getting stale and
       out-of-date from the moment it's displayed.  The list should be
       'live' and should continue to update as new services are
       discovered.  Because of the delays, packet losses, and
       retransmissions inherent in networking, it is to be expected that
       sometimes, after the initial list is displayed showing the
       majority of discovered services, a few remaining stragglers may
       continue to trickle in during the subsequent few seconds.  Even
       after this stable list has been built and displayed, it should
       remain 'live' and should continue to update.  At any future time,
       be it minutes, hours, or even days later, if a new service of the
       desired type is discovered, it should be displayed in the list
       automatically, without the user having to click a "refresh"
       button or take any other explicit action to update the display.

   3.  With users getting in the habit of leaving service discovery
       windows open, and expecting them to show a continuous 'live' view
       of current network reality, this gives us an additional
       requirement: deletion of stale services.  When a service
       discovery list shows just a static snapshot at a moment in time,
       then the situation is simple: either a service was discovered and
       appears in the list, or it was not and does not.  However, when
       our list is live and updates continuously with the discovery of
       new services, then this implies the corollary: when a service
       goes away, it needs to *disappear* from the service discovery
       list.  Otherwise, the service discovery list would simply grow
       monotonically over time, accreting stale data, and would require
       a periodic "refresh" (or complete dismissal and recreation) to
       restore correct display.

   4.  Another consequence of users leaving service discovery windows
       open for extended periods of time is that these windows should
       update not only in response to services coming and going, but
       also in response to changes in configuration and connectivity of
       the client machine itself.  For example, if a user opens a
       service discovery window when the client machine has no network
       connectivity, then the window will typically appear empty, with
       no discovered services.  When the user connects an Ethernet cable
       or joins an 802.11 [IEEEW] wireless network the window should
       then automatically populate with discovered services, without
       requiring any explicit user action.  If the user disconnects the
       Ethernet cable or turns off 802.11 wireless then all the services
       discovered via that network interface should automatically
       disappear.  If the user switches from one 802.11 wireless access
       point to another, the service discovery window should
       automatically update to remove all the services discovered via
       the old wireless access point, and add all the services
       discovered via the new one.

Top      Up      ToC       Page 47 
Appendix G.  Deployment History

   In July 1997, in an email to the
   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 with IANA 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], which later became this document, proposed a way to
      perform NBP-like service discovery using DNS-compatible names and
      record types.

   o "Multicast DNS" [RFC6762] 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
   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.

Top      Up      ToC       Page 48 
   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].

Top      Up      ToC       Page 49 
   In June 2012, Google's Android operating system added native support
   for DNS-SD and Multicast DNS with the
   class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].

Authors' Addresses

   Stuart Cheshire
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014

   Phone: +1 408 974 3207

   Marc Krochmal
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014

   Phone: +1 408 974 4368