Internet Engineering Task Force                              S. Cheshire
Internet-Draft                                               M. Krochmal
Intended status: Standards Track                              Apple Inc.
Expires: June 11, 2012                                       Dec 9, 2011


                      DNS-Based Service Discovery

                 <draft-cheshire-dnsext-dns-sd-11.txt>

Abstract

   This document specifies how DNS resource records are named and
   structured to facilitate service discovery. Given a type of service
   that a client is looking for, and a domain in which the client is
   looking for that service, this allows clients to discover a list of
   named instances of that desired service, using standard DNS queries.
   This is referred to as DNS-based Service Discovery, or DNS-SD.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 11, 2012.









Cheshire & Krochmal       Expires June 11, 2012                 [Page 1]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


Table of Contents

   1.   Introduction...................................................3
   2.   Conventions and Terminology Used in this Document..............5
   3.   Design Goals...................................................5
   4.   Service Instance Enumeration (Browsing)........................6
   4.1  Structured Instance Names......................................6
   4.2  User Interface Presentation....................................9
   4.3  Internal Handling of Names.....................................9
   5.   Service Name Resolution.......................................10
   6.   Data Syntax for DNS-SD TXT Records............................11
   6.1  General Format Rules for DNS TXT Records......................12
   6.2  DNS-SD TXT Record Size........................................13
   6.3  DNS TXT Record Format Rules for use in DNS-SD.................13
   6.4  Rules for Names in DNS-SD Name/Value Pairs....................14
   6.5  Rules for Values in DNS-SD Name/Value Pairs...................17
   6.6  Example TXT Record............................................17
   6.7  Version Tag...................................................18
   6.8  Service Instances with Multiple TXT Records...................19
   7.   Application Protocol Names....................................20
   7.1  Selective Instance Enumeration (Subtypes).....................22
   7.2  Service Name Length Limits....................................24
   8.   Flagship Naming...............................................26
   9.   Service Type Enumeration......................................28
   10.  Populating the DNS with Information...........................29
   11.  Discovery of Browsing and Registration Domains................30
   12.  DNS Additional Record Generation..............................32
   13.  Working Examples..............................................34
   14.  IPv6 Considerations...........................................35
   15.  Security Considerations.......................................35
   16.  IANA Considerations...........................................36
   17.  Acknowledgments...............................................37
   18.  Copyright Notice..............................................37
   19.  Normative References..........................................38
   20.  Informative References........................................39
   Appendix A. Rationale for using DNS as a basis for Service Disc....41
   Appendix B. Ordering of Service Instance Name Components...........43
   Appendix C. What You See Is What You Get...........................45
   Appendix D. Choice of Factory-Default Names........................47
   Appendix E. Name Encodings in the Domain Name System...............49
   Appendix F. "Continuous Live Update" Browsing Model................50
   Appendix G. Deployment History.....................................52
   Authors' Addresses.................................................54








Cheshire & Krochmal       Expires June 11, 2012                 [Page 2]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


1. Introduction

   This document specifies how DNS resource records are named and
   structured to facilitate service discovery. Given a type of service
   that a client is looking for, and a domain in which the client is
   looking for that service, this allows clients to discover a list of
   named instances of that desired service, using standard DNS queries.
   This is referred to as DNS-based Service Discovery, or DNS-SD.

   This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types,
   or any other new DNS protocol values.

   This document specifies that a particular service instance can be
   described using a DNS SRV [RFC 2782] and DNS TXT [RFC 1035] record.
   The SRV record has a name of the form "<Instance>.<Service>.<Domain>"
   and gives the target host and port where the service instance can
   be reached. The DNS TXT record of the same name gives additional
   information about this instance, in a structured form using
   key/value pairs, described in Section 6. A client discovers
   the list of available instances of a given service type using
   a query for a DNS PTR [RFC 1035] record with a name of the form
   "<Service>.<Domain>", which returns a set of zero or more names,
   which are the names of the aforementioned DNS SRV/TXT record pairs.

   This specification is compatible with both Multicast DNS [mDNS]
   and with today's existing unicast DNS server and client software.

   When used with Multicast DNS, DNS-SD can provide zero-configuration
   operation -- just connect a DNS-SD/mDNS device and its services
   are advertised on the local link with no further user interaction
   [Zeroconf].

   When used with conventional unicast DNS, some configuration will
   usually be required -- such as configuring the device with the DNS
   domain(s) in which it should advertise its services, and configuring
   it with the DNS Update [RFC 2136] [RFC 3007] keys to give it
   permission to do so. In rare cases, such as a secure corporate
   network behind a firewall where no DNS Update keys are required,
   zero-configuration operation may be achieved by simply having the
   device register its services in a default registration domain learned
   from the network (See Section 11 "Discovery of Browsing and
   Registration Domains") but this is the exception and usually security
   credentials will be required to perform DNS Updates.

   Note that when using DNS-SD with unicast DNS, the unicast DNS-SD
   service does NOT have to be provided by the same DNS server hardware
   that is currently providing an organization's conventional host name
   lookup service. When many people use the term "DNS" they are thinking


Cheshire & Krochmal       Expires June 11, 2012                 [Page 3]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   exclusively of mapping host names to IP addresses, but in fact, "the
   DNS is a general (if somewhat limited) hierarchical database, and can
   store almost any kind of data, for almost any purpose." [RFC 2181]
   By delegating the "_tcp" and "_udp" subdomains, all the workload
   related to DNS-SD can be offloaded to a different machine. This
   flexibility, to handle DNS-SD on the main DNS server, or not, at the
   network administrator's discretion, is one of the benefits of using
   DNS.

   Even when the DNS-SD functions are delegated to a different machine,
   the benefits of using DNS remain: It is mature technology, well
   understood, with multiple independent implementations from different
   vendors, a wide selection of books published on the subject, and an
   established workforce experienced in its operation. In contrast,
   adopting some other service discovery technology would require every
   site in the world to install, learn, configure, operate and maintain
   some entirely new and unfamiliar server software. Faced with these
   obstacles, it seems unlikely that any other service discovery
   technology could hope to compete with the ubiquitous deployment
   that DNS already enjoys. For further discussion of the rationale
   for using DNS as the underlying technology for Service Discovery,
   see Appendix A.

   This document is written for two audiences: developers creating
   application software that offers or accesses services on the network,
   and developers creating DNS-SD libraries to implement the advertising
   and discovery mechanisms. For both audiences, understanding the
   entire document is helpful. For developers creating application
   software this document provides guidance on choice of instance names,
   service names, and other aspects that play a role in creating a good
   overall user experience. However, also understanding the underlying
   DNS mechanisms used to provide those facilities helps application
   developers understand the capabilities and limitations of those
   underlying mechanisms (e.g. name length limits). For library
   developers writing software to construct the DNS records (to
   advertise a service) and generate the DNS queries (to discover and
   use a service), understanding the ultimate user-experience goals
   helps them provide APIs that can meet those goals.













Cheshire & Krochmal       Expires June 11, 2012                 [Page 4]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


2. Conventions and Terminology Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC 2119].


3. Design Goals

   Of the many properties a good service discovery protocol needs to
   have, three in particular are:

   (i) The ability to query for services of a certain type in a certain
   logical domain, and receive in response a list of named instances
   (network browsing, or "Service Instance Enumeration").

   (ii) Given a particular named instance, the ability to efficiently
   resolve that instance name to the required information a client needs
   to actually use the service, i.e. IP address and port number, at the
   very least (Service Name Resolution).

   (iii) Instance names should be relatively persistent. If a user
   selects their default printer from a list of available choices today,
   then tomorrow they should still be able to print on that printer --
   even if the IP address and/or port number where the service resides
   have changed -- without the user (or their software) having to repeat
   the network browsing step a second time.

   In addition, if it is to become successful, a service discovery
   protocol should be so simple to implement that virtually any
   device capable of implementing IP should not have any trouble
   implementing the service discovery software as well.

   These goals are discussed in more detail in the remainder of this
   document. A more thorough treatment of service discovery requirements
   may be found in "Requirements for a Protocol to Replace AppleTalk
   NBP" [NBP]. That document draws upon examples from two decades of
   operational experience with AppleTalk Name Binding Protocol to
   develop a list of universal requirements that are broadly applicable
   to any potential service discovery protocol.










Cheshire & Krochmal       Expires June 11, 2012                 [Page 5]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


4. Service Instance Enumeration (Browsing)

   Traditional DNS SRV records [RFC 2782] are useful for locating
   instances of a particular type of service when all the instances are
   effectively indistinguishable and provide the same service to the
   client.

   For example, SRV records with the (hypothetical) name
   "_http._tcp.example.com." would allow a client to discover servers
   implementing the "_http._tcp" service (i.e. web servers) for the
   "example.com." domain. The unstated assumption is that all these
   servers offer an identical set of web pages, and it doesn't matter to
   the client which of the servers it uses, as long as it selects one at
   random according to the weight and priority rules laid out in the DNS
   SRV specification [RFC 2782].

   Instances of other kinds of service are less easily interchangeable.
   If a word processing application were to look up the (hypothetical)
   SRV record "_ipp._tcp.example.com." to find the list of IPP [RFC
   2910] printers at Example Co., then picking one at random and
   printing on it would probably not be what the user wanted.

   The remainder of this section describes how SRV records may be used
   in a slightly different way to allow a user to discover the names of
   all available instances of a given type of service, to allow the user
   to select the particular instance they desire.


4.1 Structured Instance Names

   This document borrows the logical service naming syntax and semantics
   from DNS SRV records, but adds one level of indirection. Instead of
   requesting records of type "SRV" with name "_ipp._tcp.example.com.",
   the client requests records of type "PTR" (pointer from one name to
   another in the DNS namespace).

   In effect, if one thinks of the domain name "_ipp._tcp.example.com."
   as being analogous to an absolute path to a directory in a file
   system, then DNS-SD's PTR lookup is akin to performing a listing of
   that directory to find all the files it contains. (Remember that
   domain names are expressed in reverse order compared to path names
   -- an absolute path name starts with the root on the left and is read
   from left to right, whereas a fully-qualified domain name starts with
   the root on the right and is read from right to left. If the fully-
   qualified domain name "_ipp._tcp.example.com." were expressed as a
   file system path name, it would be "/com/example/_tcp/_ipp".)





Cheshire & Krochmal       Expires June 11, 2012                 [Page 6]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   The result of this PTR lookup for the name "<Service>.<Domain>" is a
   set of zero or more PTR records giving Service Instance Names of the
   form:

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

   For explanation of why the components are in this order, see Appendix
   B.

4.1.1 Instance Names

   The <Instance> portion of the Service Instance Name is a user-
   friendly name consisting of arbitrary Net-Unicode text [RFC 5198].
   It MUST NOT contain ASCII control characters (byte values 0x00-0x1F
   and 0x7F) [RFC 20] but otherwise is allowed to contain any
   characters, without restriction, including spaces, upper case, lower
   case, punctuation -- including dots -- accented characters, non-roman
   text, and anything else that may be represented using Net-Unicode.
   For discussion of why the <Instance> name should be a user-visible
   user-friendly name rather than an invisible machine-generated opaque
   identifier, see Appendix C.

   The <Instance> portion of the name of a service being offered on the
   network SHOULD be configurable by the user setting up the service, so
   that he or she may give it an informative name. However, the device
   or service SHOULD NOT require the user to configure a name before it
   can be used. A sensible choice of default name can allow the device
   or service to be accessed in many cases without any manual
   configuration at all. The default name should be short and
   descriptive, and SHOULD NOT include the device's MAC address, serial
   number, or any similar incomprehensible hexadecimal string in an
   attempt to make the name globally unique. For discussion of why
   <Instance> names don't need to be (and SHOULD NOT be) made unique
   at the factory, see Appendix D.

   This <Instance> portion of the Service Instance Name is stored
   directly in the DNS as a single DNS label of canonical precomposed
   UTF-8 [RFC 3629] "Net-Unicode" (Unicode Normalization Form C) [RFC
   5198] text. For further discussion of text encodings see Appendix E.

   DNS labels are currently limited to 63 octets in length. UTF-8
   encoding can require up to four octets per Unicode character, which
   means that in the worst case, the <Instance> portion of a name could
   be limited to fifteen Unicode characters. However, the Unicode
   characters with longer octet length under UTF-8 encoding tend to be
   the more rarely-used ones, and tend to be the ones that convey
   greater meaning per character.




Cheshire & Krochmal       Expires June 11, 2012                 [Page 7]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   Note that any character in the commonly-used 16-bit Unicode Basic
   Multilingual Plane [Unicode6] can be encoded with no more than three
   octets of UTF-8 encoding. This means that an Instance name can
   contain up to 21 Kanji characters, which is a sufficiently expressive
   name for most purposes.

4.1.2 Service Names

   The <Service> portion of the Service Instance Name consists of a
   pair of DNS labels, following the convention already established for
   SRV records [RFC 2782], namely: the first label of the pair is an
   underscore character followed by the Application Protocol Name
   [RFC 6335], and the second label is either "_tcp" (for application
   protocols that run over TCP) or "_udp" (for all others). More details
   are given in Section 7, "Application Protocol Names".

4.1.3 Domain Names

   The <Domain> portion of the Service Instance Name specifies the DNS
   subdomain within which the service names are registered. It may be
   "local.", meaning "link-local Multicast DNS" [mDNS], or it may be
   a conventional unicast DNS domain name, such as "ietf.org.",
   "cs.stanford.edu.", or "eng.us.ibm.com." Because service names are
   not host names, they are not constrained by the usual rules for host
   names [RFC 1033][RFC 1034][RFC 1035], and rich-text service
   subdomains are allowed and encouraged, for example:

     Building 2, 1st Floor  .  example  .  com  .
     Building 2, 2nd Floor  .  example  .  com  .
     Building 2, 3rd Floor  .  example  .  com  .
     Building 2, 4th Floor  .  example  .  com  .

   In addition, because Service Instance Names are not constrained by
   the limitations of host names, this document recommends that they
   be stored in the DNS, and communicated over the wire, encoded
   as straightforward canonical precomposed UTF-8 [RFC 3629]
   "Net-Unicode" (Unicode Normalization Form C) [RFC 5198] text.
   In cases where the DNS server returns a negative response for the
   name in question, client software MAY choose to retry the query using
   the "Punycode" algorithm [RFC 3492] to convert the UTF-8 name to an
   IDNA "A-label" [RFC 5890], beginning with the top-level label, and
   then issuing the query repeatedly, with successively more labels
   translated to IDNA A-labels each time, and giving up if it has
   converted all labels to IDNA A-labels and the query still fails.







Cheshire & Krochmal       Expires June 11, 2012                 [Page 8]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


4.2 User Interface Presentation

   The names resulting from the PTR lookup are presented to the user in
   a list for the user to select one (or more). Typically only the first
   label is shown (the user-friendly <Instance> portion of the name).

   In the common case, the <Service> and <Domain> are already known to
   the client software, these having been provided implicitly by the
   user in the first place, by the act of indicating the service being
   sought, and the domain in which to look for it. Note: The software
   handling the response should be careful not to make invalid
   assumptions though, since it *is* possible, though rare, for a
   service enumeration in one domain to return the names of services in
   a different domain. Similarly, when using subtypes (see "Selective
   Instance Enumeration") the <Service> of the discovered instance may
   not be exactly the same as the <Service> that was requested.

   For further discussion of Service Instance Enumeration (Browsing)
   user-interface considerations, particularly, the "continuous live
   update" user-experience model, see Appendix F.

   Once the user has selected the desired named instance, the Service
   Instance Name may then be used immediately, or saved away in some
   persistent user-preference data structure for future use, depending
   on what is appropriate for the application in question.


4.3 Internal Handling of Names

   If client software takes the <Instance>, <Service> and <Domain>
   portions of a Service Instance Name and internally concatenates them
   together into a single string, then because the <Instance> portion is
   allowed to contain any characters, including dots, appropriate
   precautions MUST be taken to ensure that DNS label boundaries are
   properly preserved. Client software can do this in a variety of ways,
   such as character escaping.

   This document RECOMMENDS that if concatenating the three portions of
   a Service Instance Name, any dots in the <Instance> portion should
   be escaped following the customary DNS convention for text files:
   by preceding literal dots with a backslash (so "." becomes "\.").
   Likewise, any backslashes in the <Instance> portion should also be
   escaped by preceding them with a backslash (so "\" becomes "\\").
   Having done this, the three components of the name may be safely
   concatenated. The backslash-escaping allows literal dots in the name
   (escaped) to be distinguished from label-separator dots (not
   escaped), and the resulting concatenated string may be safely passed
   to standard DNS APIs like res_query(), which will interpret the
   backslash-escaped string as intended.


Cheshire & Krochmal       Expires June 11, 2012                 [Page 9]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


5. Service Name Resolution

   When a client needs to contact a particular service, identified by
   a Service Instance Name, previously discovered via Service Instance
   Enumeration (browsing), it queries for the SRV and TXT records of
   that name. The SRV record for a service gives the port number and
   target host name where the service may be found. The TXT record gives
   additional information about the service, as described in Section 6
   below, "Data Syntax for DNS-SD TXT Records".

   SRV records are extremely useful because they remove the need for
   preassigned port numbers. There are only 65535 TCP port numbers
   available. These port numbers are being allocated one-per-
   application-protocol. Some protocols like the X Window System have
   a block of 64 TCP ports allocated (6000-6063). Using a different TCP
   port for each different instance of a given service on a given
   machine is entirely sensible, but allocating each application its own
   large static range is not a practical way to do that. On any given
   host, most TCP ports are reserved for services that will never run on
   that particular host in its lifetime. This is very poor utilization
   of the limited port space. Using SRV records allows each host to
   allocate its available port numbers dynamically to those services
   actually running on that host that need them, and then advertise the
   allocated port numbers via SRV records. Allocating the available
   listening port numbers locally on a per-host basis as needed allows
   much better utilization of the available port space than today's
   centralized global allocation.

   In the event that more than one SRV is returned, clients MUST
   correctly interpret the priority and weight fields -- i.e. lower
   numbered priority servers should be used in preference to higher
   numbered priority servers, and servers with equal priority should be
   selected randomly in proportion to their relative weights. However,
   in the overwhelmingly common case, a single advertised DNS-SD service
   instance is described by exactly one SRV record, and in this common
   case the priority and weight fields of the SRV record SHOULD both be
   set to zero.














Cheshire & Krochmal       Expires June 11, 2012                [Page 10]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


6. Data Syntax for DNS-SD TXT Records

   Some services discovered via Service Instance Enumeration may need
   more than just an IP address and port number to completely identify
   the service instance. For example, printing via the old Unix LPR
   (port 515) protocol [RFC 1179] often specifies a queue name [BJP].
   This queue name is typically short and cryptic, and need not be shown
   to the user. It should be regarded the same way as the IP address and
   port number -- it is another component of the addressing information
   required to identify a specific instance of a service being offered
   by some piece of hardware. Similarly, a file server may have multiple
   volumes, each identified by its own volume name. A web server
   typically has multiple pages, each identified by its own URL. In
   these cases, the necessary additional data is stored in a TXT record
   with the same name as the SRV record. The specific nature of that
   additional data, and how it is to be used, is service-dependent, but
   the overall syntax of the data in the TXT record is standardized, as
   described below.

   Every DNS-SD service MUST have a TXT record in addition to its SRV
   record, with the same name, even if the service has no additional
   data to store and the TXT record contains no more than a single zero
   byte. This allows a service to have explicit control over the TTL of
   its (empty) TXT record, rather than using the default negative
   caching TTL which would otherwise be used for a "no error no answer"
   DNS response.

   Note that this requirement for a mandatory TXT record applies
   exclusively to DNS-SD service advertising, i.e. services advertised
   using the PTR+SRV+TXT convention specified in this document.
   It is not a requirement of SRV records in general. The DNS SRV record
   datatype [RFC 2782] may still be used in other contexts without any
   requirement for accompanying PTR and TXT records.


















Cheshire & Krochmal       Expires June 11, 2012                [Page 11]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


6.1 General Format Rules for DNS TXT Records

   A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total
   length is indicated by the length given in the resource record header
   in the DNS message. There is no way to tell directly from the data
   alone how long it is (e.g. there is no length count at the start, or
   terminating NULL byte at the end).

   Note that when using Multicast DNS [mDNS] the maximum packet size is
   9000 bytes, including IP header, UDP header, and DNS message header,
   which imposes an upper limit on the size of TXT records of about 8900
   bytes. In practice the maximum sensible size of a DNS-SD TXT record
   size is smaller even than this, typically at most a few hundred
   bytes, as described below in Section 6.2.

   The format of the data within a DNS TXT record is one or more
   strings, packed together in memory without any intervening gaps
   or padding bytes for word alignment.

   The format of each constituent string within the DNS TXT record is
   a single length byte, followed by 0-255 bytes of text data.

   These format rules are defined in Section 3.3.14 of the DNS
   specification [RFC 1035], and are not specific to DNS-SD. DNS-SD
   specifies additional rules for what data should be stored in those
   constituent strings when used for DNS-SD service advertising, i.e.
   when used to describe services advertised using the PTR+SRV+TXT
   convention specified in this document.

   An empty TXT record containing zero strings is disallowed by RFC
   1035. DNS-SD implementations MUST NOT emit empty TXT records.
   DNS-SD clients MUST treat the following as equivalent:

    o A TXT record containing a single zero byte.
      (i.e. a single empty string.)

    o An empty (zero-length) TXT record
      (This is not strictly legal, but should one be received it should
      be interpreted as the same as a single empty string.)

    o No TXT record.
      (i.e. an NXDOMAIN or no-error-no-answer response.)









Cheshire & Krochmal       Expires June 11, 2012                [Page 12]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


6.2 DNS-SD TXT Record Size

   The total size of a typical DNS-SD TXT record is intended to be small
   -- 200 bytes or less.

   In cases where more data is justified (e.g. LPR printing [BJP]),
   keeping the total size under 400 bytes should allow it to fit in a
   single 512-byte DNS message [RFC 1035].

   In extreme cases where even this is not enough, keeping the size of
   the TXT record under 1300 bytes should allow it to fit in a single
   1500-byte Ethernet packet.

   Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this
   time.

   Note that some Ethernet hardware vendors offer chipsets with
   Multicast DNS [mDNS] offload, so that computers can sleep and still
   be discoverable on the network. Early versions of such chipsets were
   sometimes quite limited, and, for example, some were (unwisely)
   limited to handling TXT records no larger than 256 bytes (which meant
   that LPR printer services with larger TXT records did not work).
   Developers should be aware of this real-world limitation, and should
   understand that even on hardware which is otherwise perfectly
   capable, it may have low-power and sleep modes that are more limited.


6.3 DNS TXT Record Format Rules for use in DNS-SD

   DNS-SD uses DNS TXT records to store arbitrary key/value pairs
   conveying additional information about the named service. Each
   key/value pair is encoded as its own constituent string within the
   DNS TXT record, in the form "key=value" (without the quotation
   marks). Everything up to the first '=' character is the key (Section
   6.4). Everything after the first '=' character to the end of the
   string (including subsequent '=' characters, if any) is the value.
   No quotation marks are required around the value, even if it contains
   spaces, '=' characters, or other punctuation marks (see Section 6.5).
   Each author defining a DNS-SD profile for discovering instances of a
   particular type of service should define the base set of key/value
   attributes that are valid for that type of service.

   Using this standardized key/value syntax within the TXT record makes
   it easier for these base definitions to be expanded later by defining
   additional named attributes. If an implementation sees unknown
   keys in a service TXT record, it MUST silently ignore them.





Cheshire & Krochmal       Expires June 11, 2012                [Page 13]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   The target host name and TCP (or UDP) port number of the service are
   given in the SRV record. This information -- target host name and
   port number -- MUST NOT be duplicated using key/value attributes
   in the TXT record.

   The intention of DNS-SD TXT records is to convey a small amount of
   useful additional information about a service. Ideally it should not
   be necessary for a client to retrieve this additional information
   before it can usefully establish a connection to the service. For a
   well-designed application protocol, even if there is no information
   at all in the TXT record, it should be possible, knowing only the
   host name, port number, and protocol being used, to communicate with
   that listening process, and then perform version- or feature-
   negotiation to determine any further options or capabilities of the
   service instance. For example, when connecting to an Apple Filing
   Protocol (AFP) [AFP] server over TCP, the client enters into a
   protocol exchange with the server to determine which version of AFP
   the server implements, and which optional features or capabilities
   (if any) are available.

   For protocols designed with adequate in-band version- and feature-
   negotiation, any information in the TXT record should be viewed as a
   performance optimization -- when a client discovers many instances of
   a service, the TXT record allows the client to know some rudimentary
   information about each instance without having to open a TCP
   connection to each one and interrogate every service instance
   separately. Care should be taken when doing this to ensure that the
   information in the TXT record is in agreement with the information
   that would be retrieved by a client connecting over TCP.

   There are legacy protocols which provide no feature negotiation
   capability, and in these cases it may be useful to convey necessary
   information in the TXT record. For example, when printing using LPR
   [RFC 1179], the LPR protocol provides no way for the client to
   determine whether a particular printer accepts PostScript, or what
   version of PostScript, etc. In this case it is appropriate to embed
   this information in the TXT record [BJP], because the alternative
   would be worse -- passing around written instructions to the users,
   arcane manual configuration of "/etc/printcap" files, etc.


6.4 Rules for Keys in DNS-SD Key/Value Pairs

   The "Key" MUST be at least one character. Strings beginning with an
   '=' character (i.e. the key is missing) MUST be silently ignored.

   The "Key" SHOULD be no more than nine characters long. This is
   because it is beneficial to keep packet sizes small for the sake of
   network efficiency. When using DNS-SD in conjunction with Multicast


Cheshire & Krochmal       Expires June 11, 2012                [Page 14]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   DNS [mDNS] this is important because on 802.11 wireless networks
   multicast traffic is especially expensive [IEEE W], but even when
   using conventional Unicast DNS, keeping the TXT records small helps
   improve the chance that responses will fit within the original DNS
   512-byte size limit [RFC 1035]. Also, each constituent string of a
   DNS TXT record is limited to 255 bytes, so excessively long keys
   reduce the space available for that key's values.

   The Keys in Key/Value Pairs can be as short as a single character.
   A key name needs only to be unique and unambiguous within the context
   of the service type for which it is defined. A key name is intended
   solely to be a machine-readable identifier, not a human-readable
   essay giving detailed discussion of the purpose of a parameter, with
   a URL for a web page giving yet more details of the specification.
   For ease of development and debugging it can be valuable to use key
   names that are mnemonic textual names, but excessively verbose keys
   are wasteful and inefficient, hence the recommendation to keep them
   to nine characters or fewer.

   The characters of "Key" MUST be printable US-ASCII values
   (0x20-0x7E) [RFC 20], excluding '=' (0x3D).

   Spaces in the key are significant, whether leading, trailing, or in
   the middle -- so don't include any spaces unless you really intend
   that.

   Case is ignored when interpreting a key, so "papersize=A4",
   "PAPERSIZE=A4" and "Papersize=A4" are all identical.

   If there is no '=', then it is a boolean attribute, and is simply
   identified as being present, with no value.

   A given key may appear at most once in a TXT record. The reason for
   this simplifying rule is to facilitate the creation of client
   libraries that parse the TXT record into an internal data structure,
   such as a hash table or dictionary object that maps from keys to
   values, and then make that abstraction available to client code. The
   rule that a given key may not appear more than once simplifies these
   abstractions because they aren't required to support the case of
   returning more than one value for a given key.

   If a client receives a TXT record containing the same key more than
   once, then the client MUST silently ignore all but the first
   occurrence of that attribute. For client implementations that process
   a DNS-SD TXT record from start to end, placing key/value pairs into a
   hash table, using the key as the hash table key, this means that if
   the implementation attempts to add a new key/value pair into the
   table and finds an entry with the same key already present, then the
   new entry being added should be silently discarded instead. For


Cheshire & Krochmal       Expires June 11, 2012                [Page 15]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   client implementations that retrieve key/value pairs by searching the
   TXT record for the requested key, they should search the TXT record
   from the start, and simply return the first matching key they find.

   When examining a TXT record for a given key, there are therefore four
   categories of results which may be returned:

   * Attribute not present (Absent)

   * Attribute present, with no value
     (e.g. "passreq" -- password required for this service)

   * Attribute present, with empty value (e.g. "PlugIns=" --
     server supports plugins, but none are presently installed)

   * Attribute present, with non-empty value
     (e.g. "PlugIns=JPEG,MPEG2,MPEG4")

   Each author defining a DNS-SD profile for discovering instances of a
   particular type of service should define the interpretation of these
   different kinds of result. For example, for some keys, there may be
   a natural true/false boolean interpretation:

   * Absent implies 'false'
   * Present implies 'true'

   For other keys it may be sensible to define other semantics, such as
   value/no-value/unknown:

   * Present with value implies that value.
     E.g. "Color=4" for a four-color ink-jet printer,
     or "Color=6" for a six-color ink-jet printer.

   * Present with empty value implies 'false'. E.g. Not a color printer.

   * Absent implies 'Unknown'. E.g. A print server connected to some
     unknown printer where the print server doesn't actually know if the
     printer does color or not (which gives a very bad user experience
     and should be avoided wherever possible).

   Note that this is a hypothetical example, not an example of actual
   key/value keys used by DNS-SD network printers, which are documented
   in the "Bonjour Printing Specification" [BJP].








Cheshire & Krochmal       Expires June 11, 2012                [Page 16]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


6.5 Rules for Values in DNS-SD Key/Value Pairs

   If there is an '=', then everything after the first '=' to the end of
   the string is the value. The value can contain any eight-bit values
   including '='. The value MUST NOT be enclosed in quotation marks or
   any similar punctuation, and any quotation marks, or leading or
   trailing spaces, are part of the value.

   The value is opaque binary data. Often the value for a particular
   attribute will be US-ASCII [RFC 20] (or UTF-8 [RFC 3629]) text, but
   it is legal for a value to be any binary data.

   Generic debugging tools should generally display all attribute values
   as a hex dump, with accompanying text alongside displaying the UTF-8
   interpretation of those bytes, except for attributes where the
   debugging tool has embedded knowledge that the value is some other
   kind of data.

   Authors defining DNS-SD profiles SHOULD NOT generically convert
   binary attribute data types into printable text using hexadecimal
   representation, Base-64 [RFC 4648] or UU encoding, merely for the
   sake of making the data be printable text when seen in a generic
   debugging tool. Doing this simply bloats the size of the TXT record,
   without actually making the data any more understandable to someone
   looking at it in a generic debugging tool.


6.6 Example TXT Record

   The TXT record below contains three syntactically valid key/value
   pairs. (The meaning of these key/value pairs, if any, would depend
   on the definitions pertaining to the service in question that is
   using them.)

        -------------------------------------------------------
        | 0x09 | key=value | 0x08 | paper=A4 | 0x07 | passreq |
        -------------------------------------------------------














Cheshire & Krochmal       Expires June 11, 2012                [Page 17]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


6.7 Version Tag

   It is recommended that authors defining DNS-SD profiles include an
   attribute of the form "txtvers=x" in their definition, and require
   it to be the first key/value pair in the TXT record. This
   information in the TXT record can be useful to help clients maintain
   backwards compatibility with older implementations if it becomes
   necessary to change or update the specification over time. Even if
   the profile author doesn't anticipate the need for any future
   incompatible changes, having a version number in the TXT record
   provides useful insurance should incompatible changes become
   unavoidable. Clients SHOULD ignore TXT records with a txtvers number
   higher (or lower) than the version(s) they know how to interpret.

   Note that the version number in the txtvers tag describes the version
   of the specification governing the defined keys and the meaning of
   those keys for that particular TXT record, not the version of the
   application protocol that will be used if the client subsequently
   decides to contact that service. Ideally, every DNS-SD TXT record
   specification starts at txtvers=1 and stays that way forever.
   Improvements can be made by defining new keys that older clients
   silently ignore. The only reason to increment the version number is
   if the old specification is subsequently found to be so horribly
   broken that there's no way to do a compatible forward revision, so
   the txtvers number has to be incremented to tell all the old clients
   they should just not even try to understand this new TXT record.

   If there is a need to indicate which version number(s) of the
   application protocol the service implements, the recommended key
   for this is "protovers".





















Cheshire & Krochmal       Expires June 11, 2012                [Page 18]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


6.8 Service Instances with Multiple TXT Records

   Generally speaking every DNS-SD service instance has exactly one TXT
   record. However it is possible for a particular protocol's DNS-SD
   advertising specification to state that it allows multiple TXT
   records. In this case, each TXT record describes a different variant
   of the same logical service, offered using the same underlying
   protocol on the same port, described by the same SRV record.

   Having multiple TXT records to describe a single service instance is
   very rare, and to date, of the many hundreds of registered DNS-SD
   service types [SN], only one makes use of this capability, namely LPR
   printing [BJP]. This capability is used when a printer conceptually
   supports multiple logical queue names, where each different logical
   queue name implements a different page description language, such as
   80-column monospaced plain text, seven-bit Adobe PostScript,
   eight-bit ("binary") PostScript, or some proprietary page description
   language. When multiple TXT records are used to describe multiple
   logical LPR queue names for the same underlying service, printers
   include two additional keys in each TXT record, 'qtotal', which
   specifies the total number of TXT records associated with this SRV
   record, and 'priority', which gives the printer's relative preference
   for this particular TXT record. Clients then select the most
   preferred TXT record which meets the client's needs [BJP]. The only
   reason multiple TXT records are used is because the LPR protocol
   lacks in-band feature-negotiation capabilities for the client and
   server to agree on a data representation for the print job, so this
   information has to be communicated out-of-band instead using the
   DNS-SD TXT records. Future protocol designs should not emulate this
   inadequacy of the LPR printing protocol.





















Cheshire & Krochmal       Expires June 11, 2012                [Page 19]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


7. Application Protocol Names

   The <Service> portion of a Service Instance Name consists of a pair
   of DNS labels, following the convention already established for
   SRV records [RFC 2782], namely: the first label of the pair is an
   underscore character followed by the Application Protocol Name
   [RFC 6335], and the second label is either "_tcp" or "_udp".

   For applications using other transport protocols, such as SCTP
   [RFC 4960], DCCP [RFC 4340], Adobe's RTMFP, etc., the second label
   of the <Service> portion of its DNS-SD name should be "_udp". (In
   retrospect perhaps the SRV specification should not have used the
   "_tcp" and "_udp" labels at all, and instead should have used a
   single label "_srv" to carve off subdomains of DNS namespace for this
   use, but that specification is already published and deployed. Thus
   it makes sense to use "_tcp" for TCP-based services and "_udp" for
   all other transport protocols -- which are in fact, in today's world,
   often encapsulated over UDP -- rather than defining new a subdomain
   for every new transport protocol. At this point there is no benefit
   in changing established practice. While "_srv" might be aesthetically
   nicer than "_udp", it is not a user-visible string, and all that is
   required protocol-wise is that it be a label which can form a DNS
   delegation point, and that it be short so that it does not take up
   too much space in the packet, and in this respect either string is
   equally good.) Note that this usage of the "_udp" label for all
   protocols other than TCP applies exclusively to DNS-SD service
   advertising, i.e. services advertised using the PTR+SRV+TXT
   convention specified in this document. It is not a requirement of
   SRV records in general. Other specifications that are independent of
   DNS-SD and not intended to interoperate with DNS-SD records are not
   in any way constrained by how DNS-SD works just because they also use
   the DNS SRV record datatype [RFC 2782], and they are free to specify
   their own naming conventions as appropriate.

   As defined the rules for service names [RFC 6335], Application
   Protocol Names may be no more than fifteen characters (not counting
   the mandatory underscore), consisting of only letters, digits, and
   hyphens, must begin and end with a letter or digit, must not contain
   consecutive hyphens, and must contain at least one letter. The
   requirement to contain at least one letter is to disallow service
   names such as "80" or "6000-6063" which could be misinterpreted as
   port numbers or port number ranges. While both upper case and lower
   case letters may be used for mnemonic clarity, case is ignored for
   comparison purposes, so the strings "HTTP" and "http" refer to the
   same service.

   Wise selection of an Application Protocol Name is important, and the
   choice is not always as obvious as it may appear.



Cheshire & Krochmal       Expires June 11, 2012                [Page 20]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   In many cases, the Application Protocol Name merely names and refers
   to the on-the-wire message format and semantics being used. FTP is
   "ftp", IPP printing is "ipp", and so on.

   However, it is common to "borrow" an existing protocol and repurpose
   it for a new task. This is entirely sensible and sound engineering
   practice, but that doesn't mean that the new protocol is providing
   the same semantic service as the old one, even if it borrows the same
   message formats. For example, the network music sharing protocol
   implemented by iTunes on Macintosh and Windows is built upon
   "HTTP GET" commands. However, that does *not* mean that it is
   sensible or useful to try to access one of these music servers by
   connecting to it with a standard web browser. Consequently, the
   DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp"
   (Digital Audio Access Protocol), not "_http._tcp". Advertising
   "_http._tcp" service would cause iTunes servers to show up in
   conventional web browsers (Safari, Camino, OmniWeb, Internet
   Explorer, Firefox, Chrome, etc.) which is of little use since it
   offers no pages containing human-readable content. Equally, if
   iTunes were to browse for "_http._tcp" service, that would cause it
   to find generic web servers, such as the embedded web servers in
   devices like printers, which is of little use since printers
   generally don't have much music to offer.

   Analogously, NFS is built on top of SUN RPC, but that doesn't mean it
   makes sense for an NFS server to advertise that it provides "SUN RPC"
   service. Likewise, Microsoft SMB file service is built on top of
   Netbios running over IP, but that doesn't mean it makes sense for
   an SMB file server to advertise that it provides "Netbios-over-IP"
   service. The DNS-SD name of a service needs to encapsulate both the
   "what" (semantics) and the "how" (protocol implementation) of the
   service, since knowledge of both is necessary for a client to
   usefully use the service. Merely advertising that a service was
   built on top of SUN RPC is no use if the client has no idea what
   the service actually does.

   Another common question is whether the service type advertised
   by iTunes should be "_daap._http._tcp." This would also be incorrect.
   Similarly, a protocol designer implementing a network service that
   happens to use Simple Object Access Protocol [SOAP] should not feel
   compelled to have "_soap" appear somewhere in the Application
   Protocol Name. Part of the confusion here is that the presence of
   "_tcp" or "_udp" in the <Service> portion of a Service Instance Name
   has led people to assume that the visible structure of a service name
   has to reflect the private internal structure of how the protocol was
   implemented. This is not correct. All that is required is that the
   service be identified by some unique opaque Application Protocol
   Name. Making the Application Protocol Name be English text which
   is at least marginally descriptive of what the service does may be
   convenient, but it is by no means essential.

Cheshire & Krochmal       Expires June 11, 2012                [Page 21]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


7.1. Selective Instance Enumeration (Subtypes)

   This document does not attempt to define a sophisticated (e.g. Turing
   Complete, or even regular expression) query language for service
   discovery, nor do we believe one is necessary.

   However, there are some limited circumstances where narrowing the
   set of results may be useful. For example, many network printers
   offer a web-based user interface, for management and administration,
   using HTML/HTTP. A web browser wanting to discover all advertised web
   pages on the local network issues a query for "_http._tcp.<Domain>".
   On the other hand, there are cases where users wish to manage
   printers specifically, not to discover web pages in general, and it
   would be good accommodate this. In this case we define the "_printer"
   subtype of "_http._tcp", and the web browser issues a query for
   "_printer._sub._http._tcp.<Domain>", to discover only the subset
   of pages advertised as having that subtype property.

   The Safari web browser on Mac OS X 10.5 "Leopard" uses subtypes
   in this way. If an "_http._tcp" service is discovered both via
   "_printer._sub._http._tcp" browsing and via "_http._tcp" browsing
   then it is displayed in the "Printers" section of Safari's UI.
   If a service is discovered only via "_http._tcp" browsing then it is
   displayed in the "Webpages" section of Safari's UI. This can be seen
   by using the commands below on Mac OS X to advertise two "fake"
   services. The service instance "A web page" is displayed in the
   "Webpages" section of Safari's Bonjour list, while the instance
   "A printer's web page" is displayed in the "Printers" section.

      dns-sd -R "A web page"           _http._tcp          local 100
      dns-sd -R "A printer's web page" _http._tcp,_printer local 101

   Note that the advertised web page's Service Instance Name is
   unchanged by the use of subtypes -- it is still something of the form
   "The Server._http._tcp.example.com.", and the advertised web page is
   still discoverable using a standard browsing query for services of
   type "_http._tcp". The subdomain in which HTTP server SRV records are
   registered defines the namespace within which HTTP server names are
   unique. Additional subtypes (e.g. "_printer") of the basic service
   type (e.g. "_http._tcp") serve to allow certain clients to query for
   a narrower set of results, not to create more namespace.

   Using DNS zone file syntax, the service instance "A web page" is
   advertised using one PTR record, while the instance "A printer's web
   page" is advertised using two: the primary service type and the
   additional subtype. Even though the "A printer's web page" service is
   advertised two different ways, both PTR records refer to the name of
   the same SRV+TXT record pair:



Cheshire & Krochmal       Expires June 11, 2012                [Page 22]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   ; One PTR record advertises "A web page"
   _http._tcp.local. PTR A\032web\032page._http._tcp.local.

   ; Two different PTR records advertise "A printer's web page"
   _http._tcp.local. PTR A\032printer's\032web\032page._http._tcp.local.
   _printer._sub._http._tcp.local.
                     PTR A\032printer's\032web\032page._http._tcp.local.

   Subtypes are appropriate when it is desirable for different kinds of
   clients to be able to browse for services at two levels of
   granularity. In the example above, we describe two classes of HTTP
   clients: general web browsing clients that are interested in all web
   pages, and specific printer management tools that would like to
   discover only web UI pages advertised by printers. The set of HTTP
   servers on the network is the same in both cases; the difference is
   that some clients want to discover all of them, whereas other clients
   only want to find the subset of HTTP servers whose purpose is printer
   administration.

   Subtypes are only appropriate in two-level scenarios such as this
   one, where some clients want to find the full set of services of a
   given type, and at the same time other clients only want to find some
   subset. Generally speaking, if there is no client that wants to find
   the entire set, then it's neither necessary nor desirable to use the
   subtype mechanism. If all clients are browsing for some particular
   subtype, and no client exists that browses for the parent type, then
   a new Application Protocol Name representing the logical service
   should be defined, and software should simply advertise and browse
   for that particular service type directly. In particular, just
   because a particular network service happens to be implemented in
   terms of some other underlying protocol, like HTTP, Sun RPC, or SOAP,
   doesn't mean that it's sensible for that service to be defined as a
   subtype of "_http", "_sunrpc", or "_soap". That would only be useful
   if there were some class of client for which it is sensible to say,
   "I want to discover a service on the network, and I don't care what
   it does, as long as it does it using the SOAP XML RPC mechanism."

   As with the TXT record key/value pairs, the list of possible
   subtypes, if any, are defined and specified separately for each
   basic service type.

   Subtype strings (e.g. "_printer" in the example above) may be
   constructed using arbitrary 8-bit data values. These data values may
   in many cases be UTF-8 [RFC 3629] representations of text, or even
   (as in the example above) plain ASCII [RFC 20], but they do not have
   to be. Note however that even when using arbitrary 8-bit data for
   subtype strings, DNS name comparisons are still case-insensitive, so
   (for example) the byte values 0x41 and 0x61 will be considered
   equivalent for subtype comparison purposes.


Cheshire & Krochmal       Expires June 11, 2012                [Page 23]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


7.2 Service Name Length Limits

   As specified above, application protocol names are allowed to be no
   more than fifteen characters long. The reason for this limit is to
   leave as many bytes of the domain name as possible available for use
   by both the network administrator (choosing service domain names) and
   the end user (choosing instance names).

   A domain name may be up to 255 bytes long, plus one byte for the
   final terminating root label at the end. Domain names used by DNS-SD
   take the following forms:

                   <app>._tcp . <servicedomain> . <parentdomain>.
      <Instance> . <app>._tcp . <servicedomain> . <parentdomain>.
      <sub>._sub . <app>._tcp . <servicedomain> . <parentdomain>.

   The first example shows the name used for PTR queries. The second
   shows a service instance name, i.e. the name of the service's SRV and
   TXT records. The third shows a subtype browsing name, i.e. the name
   of a PTR record pointing to a service instance name (see Section 7.1
   "Selective Instance Enumeration").

   The instance name <Instance> may be up to 63 bytes. Including the
   length byte used by the DNS format when the name is stored in a
   packet, that makes 64 bytes.

   When using subtypes, the subtype identifier is allowed to be up to
   63 bytes, plus the length byte, making 64. Including the "_sub"
   and its length byte, this makes 69 bytes.

   The application protocol name <app> may be up to 15 bytes, plus
   the underscore and length byte, making a total of 17. Including
   the "_udp" or "_tcp" and its length byte, this makes 22 bytes.

   Typically, DNS-SD service records are placed into subdomains of their
   own beneath a company's existing domain name. Since these subdomains
   are intended to be accessed through graphical user interfaces, not
   typed on a command-line, they are frequently long and descriptive.
   Including the length byte, the user-visible service domain may be up
   to 64 bytes.

   Of our available 255 bytes, we have now accounted for 69+22+64 =
   155 bytes. This leaves 100 bytes to accommodate the organization's
   existing domain name <parentdomain>. When used with Multicast DNS,
   <parentdomain> is "local.", which easily fits. When used with parent
   domains of 100 bytes or less, the full functionality of DNS-SD is
   available without restriction. When used with parent domains longer
   than 100 bytes, the protocol risks exceeding the maximum possible
   length of domain names, causing failures. In this case, careful


Cheshire & Krochmal       Expires June 11, 2012                [Page 24]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   choice of short <servicedomain> names can help avoid overflows.
   If the <servicedomain> and <parentdomain> are too long, then service
   instances with long instance names will not be discoverable or
   resolvable, and applications making use of long subtype names
   may fail.

   Because of this constraint, we choose to limit Application Protocol
   Names to 15 characters or less. Allowing more characters would not
   increase the expressive power of the protocol, and would needlessly
   reduce the maximum <parentdomain> length that may be safely used.

   Note that <Instance> name lengths affect the maximum number of
   services of a given type that can be discovered in a given
   <servicedomain>. The largest unicast DNS response than can be sent
   (typically using TCP, not UDP) is 64kB. Using DNS name compression,
   a Service Instance Enumeration PTR record requires 2 bytes for the
   (compressed) name, plus 10 bytes for type, class, ttl and rdata
   length. The rdata of the PTR record requires up to 64 bytes for the
   <Instance> part of the name, plus 2 bytes for a name compression
   pointer to the common suffix, making a maximum of 78 bytes total.
   This means that using maximum-sized <Instance> names, up to 839
   instances of a given service type can be discovered in a given
   <servicedomain>.

   Multicast DNS aggregates response packets, so it does not have the
   same hard limit, but in practice it is also useful for up to a few
   hundred instances of a given service type, but probably not
   thousands.

   However, displaying even 100 instances in a flat list is probably too
   many to be helpful to a typical user. If a network has more than
   100 instances of a given service type, it's probably appropriate to
   divide those services into logical subdomains by building, by floor,
   by department, etc.

















Cheshire & Krochmal       Expires June 11, 2012                [Page 25]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


8. Flagship Naming

   In some cases, there may be several network protocols available which
   all perform roughly the same logical function. For example, the
   printing world has the LPR protocol [RFC 1179], and the Internet
   Printing Protocol (IPP) [RFC 2910], both of which cause printed
   sheets to be emitted from printers in much the same way. In addition,
   many printer vendors send their own proprietary page description
   language (PDL) data over a TCP connection to TCP port 9100, herein
   referred to generically as the "pdl-datastream" protocol. In an ideal
   world we would have only one network printing protocol, and it would
   be sufficiently good that no one felt a compelling need to invent a
   different one. However, in practice, multiple legacy protocols do
   exist, and a service discovery protocol has to accommodate that.

   Many printers implement all three printing protocols: LPR, IPP, and
   pdl-datastream. For the benefit of clients that may speak only one of
   those protocols, all three are advertised.

   However, some clients may implement two, or all three of those
   printing protocols. When a client looks for all three service types
   on the network, it will find three distinct services -- an LPR
   service, an IPP service, and a pdl-datastream service -- all of which
   cause printed sheets to be emitted from the same physical printer.

   In the case of multiple protocols like this that all perform
   effectively the same function, the client should suppress duplicate
   names and display each name only once. When the user prints to a
   given named printer, the printing client is responsible for choosing
   the protocol which will best achieve the desired effect, without, for
   example, requiring the user to make a manual choice between LPR and
   IPP.

   As described so far, this all works very well. However, consider some
   future printer that only supports IPP printing, and some other future
   printer that only supports pdl-datastream printing. The name spaces
   for different service types are intentionally disjoint (it is
   acceptable and desirable to be able to have both a file server
   called "Sales Department" and a printer called "Sales Department").
   However, it is not desirable, in the common case, to allow two
   different printers both called "Sales Department", just because
   those printers implement different protocols.

   To help guard against this, when there are two or more network
   protocols which perform roughly the same logical function, one of
   the protocols is declared the "flagship" of the fleet of related
   protocols. Typically the flagship protocol is the oldest and/or
   best-known protocol of the set.



Cheshire & Krochmal       Expires June 11, 2012                [Page 26]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   If a device does not implement the flagship protocol, then it instead
   creates a placeholder SRV record (priority=0, weight=0, port=0,
   target host = host name of device) with that name. If, when it
   attempts to create this SRV record, it finds that a record with the
   same name already exists, then it knows that this name is already
   taken by some other entity implementing at least one of the protocols
   from the fleet, and it must choose another. If no SRV record already
   exists, then the act of creating it stakes a claim to that name so
   that future devices in the same protocol fleet will detect a conflict
   when they try to use it.

   Note: When used with Multicast DNS [mDNS], the target host field of
   the placeholder SRV record MUST NOT be the empty root label. The SRV
   record needs to contain a real target host name in order for the
   Multicast DNS conflict detection rules to operate. If two different
   devices were to create placeholder SRV records both using a null
   target host name (just the root label), then the two SRV records
   would be seen to be in agreement so no conflict would be detected.

   By defining a common well-known flagship protocol for the class,
   future devices that may not even know about each other's protocols
   establish a common ground where they can coordinate to verify
   uniqueness of names.

   No PTR record is created advertising the presence of empty flagship
   SRV records, since they do not represent a real service being
   advertised, and hence are not (and should not be) discoverable via
   Service Instance Enumeration (browsing).























Cheshire & Krochmal       Expires June 11, 2012                [Page 27]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


9. Service Type Enumeration

   In general, normal clients are not interested in finding *every*
   service on the network, just the services that the client knows how
   to use.

   However, for problem diagnosis and network management tools, it may
   be useful for network administrators to find the list of advertised
   service types on the network, even if those service names are just
   opaque identifiers and not particularly informative in isolation.

   For this reason, a special meta-query is defined. A DNS query
   for PTR records with the name "_services._dns-sd._udp.<Domain>"
   yields a set of PTR records, where the rdata of each PTR record
   is the two-label <Service> name, plus the same domain,
   e.g. "_http._tcp.<Domain>". Including the domain in the PTR rdata
   allows for better name compression in DNS packets, but only the first
   two labels are relevant for the purposes of service type enumeration.
   These two-label service types can then be used to construct
   subsequent Service Instance Enumeration PTR queries, in this <Domain>
   or others, to discover instances of that service type.






























Cheshire & Krochmal       Expires June 11, 2012                [Page 28]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


10. Populating the DNS with Information

   How a service's PTR, SRV and TXT records make their way into the DNS
   is outside the scope of this document, but for illustrative purposes
   some examples are given here:

   On some networks, the administrator might manually enter the records
   into the name server's configuration file.

   A network monitoring tool could output a standard zone file to be
   read into a conventional DNS server. For example, a tool that can
   find networked PostScript laser printers using AppleTalk NBP, could
   find the list of printers, communicate with each one to find its IP
   address, PostScript version, installed options, etc., and then write
   out a DNS zone file describing those printers and their capabilities
   using DNS resource records. That information would then be available
   to DNS-SD clients that don't implement AppleTalk NBP.

   A printer manager device which has knowledge of printers on the
   network through some other management protocol could also use Dynamic
   DNS Update [RFC 2136] [RFC 3007].

   Alternatively, a printer manager device could implement enough of
   the DNS protocol that it is able to answer DNS queries directly,
   and Example Co.'s main DNS server could delegate the
   _ipp._tcp.example.com subdomain to the printer manager device.

   IP printers could use Dynamic DNS Update [RFC 2136] [RFC 3007] to
   automatically register their own PTR, SRV and TXT records with the
   DNS server.

   Zeroconf printers answer Multicast DNS queries on the local link
   for appropriate PTR, SRV and TXT names ending with ".local." [mDNS]


















Cheshire & Krochmal       Expires June 11, 2012                [Page 29]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


11. Discovery of Browsing and Registration Domains (Domain Enumeration)

   One of the motivations for DNS-based Service Discovery is to enable
   a visiting client (e.g. a Wi-Fi-equipped laptop computer, tablet, or
   telephone) arriving on a new network to discover what services are
   available on that network, without any manual configuration.
   This logic (discovering services without manual configuration)
   also applies to discovering the domains in which services may be
   discovered, also without manual configuration.

   This discovery is performed using DNS queries, using Unicast or
   Multicast DNS. Five special RR names are reserved for this purpose:

                      b._dns-sd._udp.<domain>.
                     db._dns-sd._udp.<domain>.
                      r._dns-sd._udp.<domain>.
                     dr._dns-sd._udp.<domain>.
                     lb._dns-sd._udp.<domain>.

   By performing PTR queries for these names, a client can learn,
   respectively:

    o A list of domains recommended for browsing

    o A single recommended default domain for browsing

    o A list of domains recommended for registering services using
      Dynamic Update

    o A single recommended default domain for registering services.

    o The final query shown yields the "legacy browsing" or "automatic
      browsing" domain. Sophisticated client applications that care to
      present choices of domain to the user, use the answers learned
      from the previous four queries to discover the domains to present.
      In contrast, many current applications browse without specifying
      an explicit domain, allowing the operating system to automatically
      select an appropriate domain on their behalf. It is for this class
      of application that the "automatic browsing" query is provided, to
      allow the network administrator to communicate to the client
      operating systems which domain(s) should be used automatically for
      these applications.

   These domains are purely advisory. The client or user is free to
   browse and/or register services in any domains. The purpose of these
   special queries is to allow software to create a user-interface that
   displays a useful list of suggested choices to the user, from which
   the user may make an informed selection, or ignore the offered
   suggestions and manually enter their own choice.


Cheshire & Krochmal       Expires June 11, 2012                [Page 30]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   The <domain> part of the Domain Enumeration query name may be
   "local." (meaning "perform the query using link-local multicast) or
   it may be learned through some other mechanism, such as the DHCP
   "Domain" option (option code 15) [RFC 2132], the DHCP "Domain Search"
   option (option code 119) [RFC 3397], or IPv6 Router Advertisement
   Options [RFC 6106].

   The <domain> part of the query name may also be derived a different
   way, from the host's IP address. The host takes its IP address, and
   calculates the logical AND of that address and its subnet mask, to
   derive the 'base' address of the subnet (the 'network address' of
   that subnet, or equivalently the IP address of the 'all-zero' host
   address on that subnet). It then constructs the conventional DNS
   "reverse mapping" name corresponding to that base address, and uses
   that as the <domain> part of the name for the queries described
   above. For example, if a host has address 192.168.12.34, with
   subnet mask 255.255.0.0, then the 'base' address of the subnet is
   192.168.0.0, and to discover the recommended automatic browsing
   domain for devices on this subnet, the host issues a DNS PTR query
   for the name "lb._dns-sd._udp.0.0.168.192.in-addr.arpa."

   Equivalent address-derived Domain Enumeration queries should also be
   done for the host's IPv6 address(es).

   Address-derived Domain Enumeration queries SHOULD NOT be done for
   IPv4 link-local addresses [RFC 3927] or IPv6 link-local addresses
   [RFC 4862].

   Sophisticated clients may perform domain enumeration queries both
   in "local." and in one or more unicast domains, using both
   name-derived and address-derived queries, and then present the
   user with an aggregate result, combining the information received
   from all sources.


















Cheshire & Krochmal       Expires June 11, 2012                [Page 31]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


12. DNS Additional Record Generation

   DNS has an efficiency feature whereby a DNS server may place
   additional records in the Additional Section of the DNS Message.
   These additional records are records that the client did not
   explicitly request, but the server has reasonable grounds to
   expect that the client might request them shortly, so including
   them can save the client from having to issue additional queries.

   This section recommends which additional records SHOULD be generated
   to improve network efficiency, for both unicast and multicast DNS-SD
   responses.

   Note that while servers SHOULD add these additional records for
   efficiency purposes, as with all DNS additional records it is
   the client's responsibility to determine whether it trusts them.

   Generally speaking, stub resolvers that talk to a single recursive
   name server for all their queries will trust all records they receive
   from that recursive name server (whom else would they ask?) Recursive
   name servers that talk to multiple authoritative name servers should
   verify that any records they receive from a given authoritative name
   server are "in bailiwick" for that server, and ignore them if not.

   Clients MUST be capable of functioning correctly with DNS Servers
   (and Multicast DNS Responders) that fail to generate these additional
   records automatically, by issuing subsequent queries for any further
   record(s) they require. The additional-record generation rules in
   this section are RECOMMENDED for improving network efficiency, but
   are not required for correctness.


12.1 PTR Records

   When including a DNS-SD Service Instance Enumeration or Selective
   Instance Enumeration (subtype) PTR record in a response packet, the
   server/responder SHOULD include the following additional records:

   o The SRV record(s) named in the PTR rdata.
   o The TXT record(s) named in the PTR rdata.
   o All address records (type "A" and "AAAA") named in the SRV rdata.


12.2 SRV Records

   When including an SRV record in a response packet, the
   server/responder SHOULD include the following additional records:

   o All address records (type "A" and "AAAA") named in the SRV rdata.


Cheshire & Krochmal       Expires June 11, 2012                [Page 32]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


12.3 TXT Records

   When including a TXT record in a response packet, no additional
   records are required.


12.4 Other Record Types

   In response to address queries, or other record types, no additional
   records are recommended by this document.









































Cheshire & Krochmal       Expires June 11, 2012                [Page 33]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


13. Working Examples

   The following examples were prepared using standard unmodified
   nslookup and standard unmodified BIND running on GNU/Linux.

   Note: In real products, this information is obtained and presented to
   the user using graphical network browser software, not command-line
   tools, but if you wish you can try these examples for yourself as you
   read along, using the nslookup command already available on most Unix
   machines.


13.1 Question: What web pages are being advertised from dns-sd.org?

   nslookup -q=ptr _http._tcp.dns-sd.org.
   _http._tcp.dns-sd.org
                name = Zeroconf._http._tcp.dns-sd.org
   _http._tcp.dns-sd.org
                name = Multicast\032DNS._http._tcp.dns-sd.org
   _http._tcp.dns-sd.org
                name = DNS\032Service\032Discovery._http._tcp.dns-sd.org
   _http._tcp.dns-sd.org
                name = Stuart's\032Printer._http._tcp.dns-sd.org

   Answer: There are four, called "Zeroconf", "Multicast DNS",
   "DNS Service Discovery" and "Stuart's Printer".

   Note that nslookup escapes spaces as "\032" for display purposes,
   but a graphical DNS-SD browser should not.


13.2 Question: What printer-configuration web pages are there?

   nslookup -q=ptr _printer._sub._http._tcp.dns-sd.org
   _printer._sub._http._tcp.dns-sd.org
                name = Stuart's\032Printer._http._tcp.dns-sd.org

   Answer: "Stuart's Printer" is the web configuration UI of a network
   printer.












Cheshire & Krochmal       Expires June 11, 2012                [Page 34]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


13.3 Question: How do I access the "DNS Service Discovery" web page?

   nslookup -q=any "DNS\032Service\032Discovery._http._tcp.dns-sd.org."
   DNS\032Service\032Discovery._http._tcp.dns-sd.org
                  priority = 0, weight = 0, port = 80, host = dns-sd.org
   DNS\032Service\032Discovery._http._tcp.dns-sd.org
                  text = "txtvers=1" "path=/"
   dns-sd.org     nameserver = ns1.bolo.net
   dns-sd.org     internet address = 64.142.82.154
   ns1.bolo.net   internet address = 64.142.82.152

   Answer: You need to connect to dns-sd.org port 80, path "/".
   The address for dns-sd.org is also given (64.142.82.154).


14. IPv6 Considerations

   IPv6 has only minor differences.

   The address of the SRV record's target host is given by the
   appropriate IPv6 "AAAA" address records instead of (or in addition
   to) IPv4 "A" records.

   Address-based Domain Enumeration queries are performed using names
   under the IPv6 reverse-mapping tree, which is different to the IPv4
   reverse-mapping tree and has longer names in it.


15. Security Considerations

   Since DNS-SD is just a specification for how to name and use records
   in the existing DNS system, it has no specific additional security
   requirements over and above those that already apply to DNS queries
   and DNS updates.

   For DNS queries, DNSSEC [RFC 4033] should be used where the
   authenticity of information is important.

   For DNS updates, secure updates [RFC 2136] [RFC 3007] should
   generally be used to control which clients have permission to update
   DNS records.










Cheshire & Krochmal       Expires June 11, 2012                [Page 35]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


16. IANA Considerations

   IANA manages the name space of unique application protocol names
   [RFC 6335].

   When a protocol service advertising specification includes subtypes,
   these should be documented in the protocol specification in question
   and/or in the "notes" field of the registration request sent to IANA.
   In the event that a new subtype becomes relevant after a protocol
   specification has been published, this can be recorded by requesting
   IANA to add it to the "notes" field. For example, vendors of network
   printers advertise their embedded web servers using the subtype
   _printer. This allows printer management clients to browse for only
   printer-related web servers by browsing for the _printer subtype.
   While the existence of the _printer subtype of _http._tcp is not
   directly relevant to the HTTP protocol specification, it is useful
   to record this usage in the IANA registry to help avoid another
   community of developers inadvertently using the same subtype string
   for a different purpose. The namespace of possible subtypes is
   separate for each different service type. For example, the existence
   of the _printer subtype of _http._tcp does not imply that the
   _printer subtype is defined or has any meaning for any other service
   type.

   When IANA records an application protocol name registration, if the
   new application protocol is one that conceptually duplicates existing
   functionality of an older protocol, and the implementers desire the
   Flagship Naming behavior described in Section 8, then the registrant
   should request IANA to note the name of the flagship protocol in the
   "notes" field of the new registration. For example, the registrations
   for "ipp" and "pdl-datastream" both reference "printer" as the
   flagship name for this family of printing-related protocols.



















Cheshire & Krochmal       Expires June 11, 2012                [Page 36]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


17. Acknowledgments

   The concepts described in this document have been explored, developed
   and implemented with help from Ran Atkinson, Richard Brown, Freek
   Dijkstra, Ralph Droms, Erik Guttman, Pasi Sarolahti, Pekka Savola,
   Mark Townsley, Paul Vixie, Bill Woodcock, and others. Special thanks
   go to Bob Bradley, Josh Graessley, Scott Herscher, Rory McGuire,
   Roger Pantos and Kiren Sekar for their significant contributions.


18. Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.






























Cheshire & Krochmal       Expires June 11, 2012                [Page 37]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


19. Normative References

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

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

   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
              Facilities", STD 13, RFC 1034, November 1987.

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
              Specifications", STD 13, RFC 1035, November 1987.

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the
              location of services (DNS SRV)", RFC 2782, February 2000.

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

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

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

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

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

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

   [RFC 6335] 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.





Cheshire & Krochmal       Expires June 11, 2012                [Page 38]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


20. Informative References

   [AFP]      Apple Filing Protocol <http://developer.apple.com/
              documentation/Networking/Conceptual/AFP/>

   [B4W]      Bonjour for Windows
              <http://en.wikipedia.org/wiki/Bonjour_(software)>.

   [BJP]      Bonjour Printing Specification <http://developer.
              apple.com/networking/bonjour/bonjourprinting.pdf>

   [IEEE W]   <http://standards.ieee.org/wireless/>

   [mDNS]     Cheshire, S., and M. Krochmal, "Multicast DNS",
              Internet-Draft (work in progress),
              draft-cheshire-dnsext-multicastdns-15.txt, December 2011.

   [NBP]      Cheshire, S., and M. Krochmal,
              "Requirements for a Protocol to Replace AppleTalk NBP",
              Internet-Draft (work in progress),
              draft-cheshire-dnsext-nbp-10.txt, January 2011.

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

   [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP
              Vendor Extensions", RFC 2132, March 1997.

   [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
              System (DNS UPDATE)", RFC 2136, April 1997.

   [RFC 2181] Elz, R., and Bush, R., "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [Unicode6] The Unicode Consortium, "The Unicode Standard, Version
              6.0.0", October 2010.

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

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

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

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


Cheshire & Krochmal       Expires June 11, 2012                [Page 39]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


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

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

   [RFC 4648] Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006

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

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

   [SN]       "Service Name and Transport Protocol Port Number
              Registry", <http://www.iana.org/assignments/
              service-names-port-numbers/>.

   [SOAP]     Nilo Mitra, "SOAP Version 1.2 Part 0: Primer",
              W3C Proposed Recommendation, 24 June 2003
              http://www.w3.org/TR/2003/REC-soap12-part0-20030624

   [Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration
              Networking: The Definitive Guide", O'Reilly Media, Inc. ,
              ISBN 0-596-10100-7, December 2005.





















Cheshire & Krochmal       Expires June 11, 2012                [Page 40]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


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

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

   For ad hoc networks such as Zeroconf environments, peer-to-peer
   multicast protocols are appropriate. Using DNS-SD running over
   Multicast DNS [mDNS] 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 [RFC 2136] [RFC 3007].
   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 [RFC 4033].




Cheshire & Krochmal       Expires June 11, 2012                [Page 41]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   In summary:

      Service discovery requires a central aggregation server.
      DNS already has one: It's called a DNS server.

      Service discovery requires a service registration protocol.
      DNS already has one: It's called DNS Dynamic Update.

      Service discovery requires a query protocol.
      DNS already has one: It's called DNS.

      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.






























Cheshire & Krochmal       Expires June 11, 2012                [Page 42]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


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:


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

   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, how many instances 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 already knows 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.








Cheshire & Krochmal       Expires June 11, 2012                [Page 43]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


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 "_tcp.example.com." 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
   "_ipp._tcp.example.com." 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 [RFC 2136] [RFC 3007] for printers registering
   in the "_ipp._tcp.example.com." subdomain, but not for other
   zones/subdomains. This easy flexibility would not exist if the
   <Service> component appeared first in each name.




















Cheshire & Krochmal       Expires June 11, 2012                [Page 44]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


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 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 print queues 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.





Cheshire & Krochmal       Expires June 11, 2012                [Page 45]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   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 counter-intuitive 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" interface.

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
















Cheshire & Krochmal       Expires June 11, 2012                [Page 46]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


Appendix D. Choice of Factory-Default Names

   When a DNS-SD service is advertised using Multicast DNS [mDNS],
   automatic name conflict and resolution will occur if there is already
   another service of the same type advertising with the same name.
   As described in the Multicast DNS specification [mDNS], upon 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 the key
   to providing user-friendly service names in the out-of-the-box
   factory-default configuration. Some product developers have
   not realized this, because there are some products today where
   the factory-default name is distinctly unfriendly, containing
   random-looking strings of characters, like 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.



Cheshire & Krochmal       Expires June 11, 2012                [Page 47]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   (b) In the case where the user gets a second network printer,
       having it detect that the name "Printer" is already in use
       and automatically instead name itself "Printer (2)" 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 two printers called "Printer 0001E68C74FB"
       and "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 desirable 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.






























Cheshire & Krochmal       Expires June 11, 2012                [Page 48]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


Appendix E. Name Encodings in the Domain Name System

   Although the original DNS specifications [RFC 1033][RFC 1034][RFC
   1035] recommended 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 not by typing in the Instance Name,
   but by selecting it from a list presented by a user interface.
   "Clarifications to the DNS Specification" [RFC 2181] directly
   discusses the subject of allowable character set in Section 11 ("Name
   syntax"), and explicitly states that the traditional letters-digits-
   hyphens rule only applies 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.









Cheshire & Krochmal       Expires June 11, 2012                [Page 49]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


Appendix F. "Continuous Live Update" Browsing Model

   Of particular concern in the design of DNS-SD, particularly when
   used in conjunction with ad hoc Multicast DNS, was 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 code
      (b) service discovery code spends a few seconds getting list of
          instances available at a particular moment in time, and then
      (c) client software displays list for 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's 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. 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, the moment it's
   displayed on the screen it's already beginning to get stale and
   out-of-date.

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

   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


Cheshire & Krochmal       Expires June 11, 2012                [Page 50]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


      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 to be in the habit of leaving service discovery
      windows open, and coming to expect to be able to rely on 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. With users getting to be in the habit of leaving service discovery
      windows open, these windows need to 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 no
      Ethernet cable is connected to the client machine, and the window
      appears empty with no discovered services, then when the user
      connects the cable the window should automatically populate with
      discovered services without requiring any explicit user action.
      If the user disconnects the Ethernet cable, all the services
      discovered via that network interface should automatically
      disappear. If the user switches from one 802.11 [IEEE W] wireless
      base station to another, the service discovery window should
      automatically update to remove all the services discovered via the
      old wireless base station, and add all the services discovered via
      the new one.








Cheshire & Krochmal       Expires June 11, 2012                [Page 51]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


Appendix G. 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
   AppleTalk Name Binding Protocol [NBP] 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, which were loosely-related to the general themes of DNS and
   multicast, but did not address the service discovery aspect of NBP.

   In April 2000 Stuart Cheshire registered IPv4 multicast address
   224.0.0.251 with IANA 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 "draft-cheshire-dnsext-nbp-00.txt", was an overview explaining
      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 "draft-cheshire-dnsext-nias-00.txt" ("Named Instances of Abstract
      Services") proposed a way to perform NBP-like service discovery
      using DNS-compatible names and record types.

    o "draft-cheshire-dnsext-multicastdns-00.txt" proposed 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



Cheshire & Krochmal       Expires June 11, 2012                [Page 52]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


   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) [B4W].

   In August 2006, Apple re-licensed the cross-platform mDNSResponder
   source code under the Apache License, Version 2.0.

   In January 2007, the IETF published the Informational RFC "Link-Local
   Multicast Name Resolution", 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 [RFC 4795], which made it an unsuitable candidate for a
   protocol to replace AppleTalk NBP [NBP].

   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.

   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 [RFC 2136]
   [RFC 3007] 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.








Cheshire & Krochmal       Expires June 11, 2012                [Page 53]


Internet-Draft           DNS-Based Service Discovery            Dec 2011


Authors' Addresses

   Stuart Cheshire
   Apple Inc.
   1 Infinite Loop
   Cupertino
   California 95014
   USA

   Phone: +1 408 974 3207
   EMail: cheshire@apple.com


   Marc Krochmal
   Apple Inc.
   1 Infinite Loop
   Cupertino
   California 95014
   USA

   Phone: +1 408 974 4368
   EMail: marc@apple.com





























Cheshire & Krochmal       Expires June 11, 2012                [Page 54]