GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc6763

Internet Engineering Task Force (IETF) S. Cheshire Request for Comments: 6763 M. Krochmal Category: Standards Track Apple Inc. ISSN: 2070-1721 February 2013

                    DNS-Based Service Discovery

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 mechanism allows clients to discover
 a list of named instances of that desired service, using standard
 DNS queries.  This mechanism is referred to as DNS-based Service
 Discovery, or DNS-SD.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6763.

Copyright Notice

 Copyright (c) 2013 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.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Cheshire & Krochmal Standards Track [Page 1] RFC 6763 DNS-Based Service Discovery February 2013

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 Service Instance Names ..........................6
    4.2. User Interface Presentation ................................9
    4.3. Internal Handling of Names .................................9
 5. Service Instance Resolution ....................................10
 6. Data Syntax for DNS-SD TXT Records .............................11
    6.1. General Format Rules for DNS TXT Records ..................11
    6.2. DNS-SD TXT Record Size ....................................12
    6.3. DNS TXT Record Format Rules for Use in DNS-SD .............13
    6.4. Rules for Keys in DNS-SD Key/Value Pairs ..................14
    6.5. Rules for Values in DNS-SD Key/Value Pairs ................16
    6.6. Example TXT Record ........................................17
    6.7. Version Tag ...............................................17
    6.8. Service Instances with Multiple TXT Records ...............18
 7. Service Names ..................................................19
    7.1. Selective Instance Enumeration (Subtypes) .................21
    7.2. Service Name Length Limits ................................23
 8. Flagship Naming ................................................25
 9. Service Type Enumeration .......................................27
 10. Populating the DNS with Information ...........................27
 11. Discovery of Browsing and Registration Domains (Domain
     Enumeration) ..................................................28
 12. DNS Additional Record Generation ..............................30
    12.1. PTR Records ..............................................30
    12.2. SRV Records ..............................................30
    12.3. TXT Records ..............................................31
    12.4. Other Record Types .......................................31
 13. Working Examples ..............................................31
    13.1. What web pages are being advertised from dns-sd.org? .....31
    13.2. What printer-configuration web pages are there? ..........31
    13.3. How do I access the web page called "Service
          Discovery"? ..............................................32
 14. IPv6 Considerations ...........................................32
 15. Security Considerations .......................................32
 16. IANA Considerations ...........................................32
 17. Acknowledgments ...............................................33
 18. References ....................................................33
    18.1. Normative References .....................................33
    18.2. Informative References ...................................34
 Appendix A. Rationale for Using DNS as a Basis for Service
             Discovery .............................................37

Cheshire & Krochmal Standards Track [Page 2] RFC 6763 DNS-Based Service Discovery February 2013

 Appendix B. Ordering of Service Instance Name Components ..........38
    B.1. Semantic Structure ........................................38
    B.2. Network Efficiency ........................................39
    B.3. Operational Flexibility ...................................39
 Appendix C. What You See Is What You Get ..........................40
 Appendix D. Choice of Factory-Default Names .......................42
 Appendix E. Name Encodings in the Domain Name System ..............44
 Appendix F. "Continuous Live Update" Browsing Model ...............45
 Appendix G. Deployment History ....................................47

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 mechanism allows clients to discover a
 list of named instances of that desired service, using standard DNS
 queries.  This mechanism 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 [RFC2782] and DNS TXT [RFC1035] 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 [RFC1035] 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 [RFC6762]
 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 [ZC].
 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 [RFC2136] [RFC3007] keys to give it permission
 to do so.  In rare cases, such as a secure corporate network behind a

Cheshire & Krochmal Standards Track [Page 3] RFC 6763 DNS-Based Service Discovery February 2013

 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.  While many people think of "DNS" exclusively in the
 context of mapping host names to IP addresses, in fact, "the DNS is a
 general (if somewhat limited) hierarchical database, and can store
 almost any kind of data, for almost any purpose" [RFC2181].  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, see Appendix A,
 "Rationale for Using DNS as a Basis for Service Discovery".
 This document is written for two audiences: for developers creating
 application software that offers or accesses services on the network,
 and for 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
 choosing 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 the
 service discovery 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 Standards Track [Page 4] RFC 6763 DNS-Based Service Discovery February 2013

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" [RFC2119].

3. Design Goals

 Of the many properties a good service discovery protocol needs to
 have, three of particular importance 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 Instance 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 step (i) (the initial network
    browsing) 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
 the AppleTalk Name Binding Protocol (NBP)" [RFC6760].  That document
 draws upon examples from two decades of operational experience with
 AppleTalk to develop a list of universal requirements that are
 broadly applicable to any potential service discovery protocol.

Cheshire & Krochmal Standards Track [Page 5] RFC 6763 DNS-Based Service Discovery February 2013

4. Service Instance Enumeration (Browsing)

 Traditional DNS SRV records [RFC2782] 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 [RFC2782].
 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 Internet
 Printing Protocol (IPP) [RFC2910] 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, and then select,
 from that list, the particular instance they desire.

4.1. Structured Service 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) [RFC1035].
 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 entries 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 Standards Track [Page 6] RFC 6763 DNS-Based Service Discovery February 2013

 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, "Ordering of Service Instance Name Components".

4.1.1. Instance Names

 The <Instance> portion of the Service Instance Name is a user-
 friendly name consisting of arbitrary Net-Unicode text [RFC5198].  It
 MUST NOT contain ASCII control characters (byte values 0x00-0x1F and
 0x7F) [RFC20] but otherwise is allowed to contain any characters,
 without restriction, including spaces, uppercase, lowercase,
 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, "What You See Is What You Get".
 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 in many cases
 allow the device or service to be accessed without any manual
 configuration at all.  The default name should be short and
 descriptive, and SHOULD NOT include the device's Media Access Control
 (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, "Choice of
 Factory-Default Names".
 This <Instance> portion of the Service Instance Name is stored
 directly in the DNS as a single DNS label of canonical precomposed
 UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C)
 [RFC5198] text.  For further discussion of text encodings, see
 Appendix E, "Name Encodings in the Domain Name System".
 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

Cheshire & Krochmal Standards Track [Page 7] RFC 6763 DNS-Based Service Discovery February 2013

 characters with longer octet lengths under UTF-8 encoding tend to be
 the more rarely used ones, and tend to be the ones that convey
 greater meaning per character.
 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 [RFC2782].  The first label of the pair is an underscore
 character followed by the Service Name [RFC6335].  The Service Name
 identifies what the service does and what application protocol it
 uses to do it.  The second label is either "_tcp" (for application
 protocols that run over TCP) or "_udp" (for all others).  For more
 details, see Section 7, "Service Names".

4.1.3. Domain Names

 The <Domain> portion of the Service Instance Name specifies the DNS
 subdomain within which those names are registered.  It may be
 "local.", meaning "link-local Multicast DNS" [RFC6762], or it may be
 a conventional Unicast DNS domain name, such as "ietf.org.",
 "cs.stanford.edu.", or "eng.us.ibm.com."  Because Service Instance
 Names are not host names, they are not constrained by the usual rules
 for host names [RFC1033] [RFC1034] [RFC1035], 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 [RFC3629] "Net-Unicode"
 (Unicode Normalization Form C) [RFC5198] 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 [RFC3492] to convert the UTF-8 name to an IDNA "A-label"
 [RFC5890], beginning with the top-level label, then issuing the query

Cheshire & Krochmal Standards Track [Page 8] RFC 6763 DNS-Based Service Discovery February 2013

 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.

4.2. User Interface Presentation

 The names resulting from the Service Instance Enumeration 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 that 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 Section 7.1,
 "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, see Appendix F, "'Continuous Live
 Update' Browsing Model".
 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 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 "\\").

Cheshire & Krochmal Standards Track [Page 9] RFC 6763 DNS-Based Service Discovery February 2013

 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.

5. Service Instance 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, "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 traditionally allocated one per
 application protocol [RFC6335].  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, as was done for the X Window System, 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 Standards Track [Page 10] RFC 6763 DNS-Based Service Discovery February 2013

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 [RFC1179] 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 Time
 to Live (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 [RFC2782] may still be used in other contexts without any
 requirement for accompanying PTR and TXT records.

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 [RFC6762] the maximum packet size
 is 9000 bytes, including the 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 is smaller even than this, typically at most a few hundred
 bytes, as described below in Section 6.2.

Cheshire & Krochmal Standards Track [Page 11] RFC 6763 DNS-Based Service Discovery February 2013

 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 for TXT records are defined in Section 3.3.14 of
 the DNS specification [RFC1035] 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 not allowed [RFC1035].
 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.)

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 [RFC1035].
 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 [RFC6762] offload, so that computers can sleep and
 still be discoverable on the network.  Early versions of such
 chipsets were sometimes quite limited: for example, some were

Cheshire & Krochmal Standards Track [Page 12] RFC 6763 DNS-Based Service Discovery February 2013

 (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 hardware which is otherwise perfectly
 capable 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
 (Section 6.5).  No quotation marks are required around the value,
 even if it contains spaces, '=' characters, or other punctuation
 marks.  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.
 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 AFP (Apple
 Filing Protocol) server [AFP] 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

Cheshire & Krochmal Standards Track [Page 13] RFC 6763 DNS-Based Service Discovery February 2013

 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 that 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
 [RFC1179], the LPR protocol provides no way for the client to
 determine whether a particular printer accepts PostScript, 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.
 The engineering decision about what keys to define for the TXT record
 needs to be decided on a case-by-case basis for each service type.
 For some service types it is appropriate to communicate information
 via the TXT record as well as (or instead of) via in-band
 communication in the application protocol.

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

 The key MUST be at least one character.  DNS-SD TXT record 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 DNS
 [RFC6762] this is important because multicast traffic is especially
 expensive on 802.11 wireless networks [IEEEW], 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 [RFC1035].  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

Cheshire & Krochmal Standards Track [Page 14] RFC 6763 DNS-Based Service Discovery February 2013

 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 a key MUST be printable US-ASCII values (0x20-0x7E)
 [RFC20], 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 '=' in a DNS-SD TXT record string, then it is a
 boolean attribute, simply identified as being present, with no value.
 A given key SHOULD NOT appear more than 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.
 Client implementations that retrieve key/value pairs by searching the
 TXT record for the requested key should search the TXT record from
 the start and simply return the first matching key they find.

Cheshire & Krochmal Standards Track [Page 15] RFC 6763 DNS-Based Service Discovery February 2013

 When examining a TXT record for a given key, there are therefore four
 categories of results that 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=" – the 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].

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

 If there is an '=' in a DNS-SD TXT record string, 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

Cheshire & Krochmal Standards Track [Page 16] RFC 6763 DNS-Based Service Discovery February 2013

 be enclosed in additional quotation marks or any similar punctuation;
 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 [RFC20] or UTF-8 [RFC3629] 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 [RFC4648], or Unix-to-Unix (UU) encoding,
 merely for the sake of making the data appear to 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
 strings.  (The meaning of these key/value pairs, if any, would depend
 on the definitions pertaining to the service in question that is
 using them.)
  1. ——————————————————

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

  1. ——————————————————

6.7. Version Tag

 It is recommended that authors defining DNS-SD profiles include an
 attribute of the form "txtvers=x", where "x" is a decimal version
 number in US-ASCII [RFC20] text (e.g., "txtvers=1" or "txtvers=8"),
 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 [RFC6709].  Clients SHOULD
 ignore TXT records with a txtvers number higher (or lower) than the
 version(s) they know how to interpret.

Cheshire & Krochmal Standards Track [Page 17] RFC 6763 DNS-Based Service Discovery February 2013

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

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 that 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 follow this bad
 example by mimicking this inadequacy of the LPR printing protocol.

Cheshire & Krochmal Standards Track [Page 18] RFC 6763 DNS-Based Service Discovery February 2013

7. Service Names

 The <Service> portion of a Service Instance Name consists of a pair
 of DNS labels, following the convention already established for SRV
 records [RFC2782].
 The first label of the pair is an underscore character followed by
 the Service Name [RFC6335].  The Service Name identifies what the
 service does and what application protocol it uses to do it.
 For applications using TCP, the second label is "_tcp".
 For applications using any transport protocol other than TCP, the
 second label is "_udp".  This applies to all other transport
 protocols, including User Datagram Protocol (UDP), Stream Control
 Transmission Protocol (SCTP) [RFC4960], Datagram Congestion Control
 Protocol (DCCP) [RFC4340], Adobe's Real Time Media Flow Protocol
 (RTMFP), etc.  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 a subdomain of DNS
 namespace for this use, but that specification is already published
 and deployed.  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 (i) that it be a label that can form a DNS
 delegation point, and (ii) that it be short so that it does not take
 up too much space in the packet, and in this respect either "_udp" or
 "_srv" is equally good.  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 a new subdomain for every new transport protocol.
 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 [RFC2782]; they are free to specify their own naming
 conventions as appropriate.
 The rules for Service Names [RFC6335] state that they may be no more
 than fifteen characters long (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

Cheshire & Krochmal Standards Track [Page 19] RFC 6763 DNS-Based Service Discovery February 2013

 "6000-6063", which could be misinterpreted as port numbers or port
 number ranges.  While both uppercase and lowercase 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 a Service Name is important, and the choice is not
 always as obvious as it may appear.
 In many cases, the Service 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".
 If iTunes were to advertise that it offered "_http._tcp" service,
 that would cause iTunes servers to appear in conventional web
 browsers (Safari, Camino, OmniWeb, Internet Explorer, Firefox,
 Chrome, etc.), which is of little use since an iTunes music library
 offers no HTML pages containing human-readable content that a web
 browser could display.
 Equally, if iTunes were to browse for "_http._tcp" service, that
 would cause it to discover 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, Sun Microsystems's Network File System (NFS) is built on
 top of Sun Microsystems's Remote Procedure Call (Sun RPC) mechanism,
 but that doesn't mean it makes sense for an NFS server to advertise
 that it provides "Sun RPC" service.  Likewise, Microsoft's Server
 Message Block (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 use the service
 meaningfully.  Merely advertising that a service was built on top of
 Sun RPC is no use if the client has no idea what the service does.

Cheshire & Krochmal Standards Track [Page 20] RFC 6763 DNS-Based Service Discovery February 2013

 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 the Simple Object Access Protocol [SOAP] should not
 feel compelled to have "_soap" appear somewhere in the Service 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 the <Service> should 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 Service Name.  Making the Service
 Name be English text that is at least marginally descriptive of what
 the service does may be convenient, but it is by no means essential.

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 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 is good accommodate this.
 In this case, we define the "_printer" subtype of "_http._tcp", and
 to discover only the subset of pages advertised as having that
 subtype property, the web browser issues a query for
 "_printer._sub._http._tcp.<Domain>".
 The Safari web browser on Mac OS X 10.5 "Leopard" and later 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

Cheshire & Krochmal Standards Track [Page 21] RFC 6763 DNS-Based Service Discovery February 2013

 "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 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:
 ; 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
 client 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 Service 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

Cheshire & Krochmal Standards Track [Page 22] RFC 6763 DNS-Based Service Discovery February 2013

 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."
 Subtype strings are not required to begin with an underscore, though
 they often do.  As with the TXT record key/value pairs, the list of
 possible subtypes, if any (including whether some or all begin with
 an underscore) 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.  In many cases these
 data values may be UTF-8 [RFC3629] representations of text, or even
 (as in the example above) plain ASCII [RFC20], 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.

7.2. Service Name Length Limits

 As specified above, Service Names are allowed to be no more than
 fifteen characters long.  The reason for this limit is to conserve
 bytes in the domain name for use both by the network administrator
 (choosing service domain names) and by the end user (choosing
 instance names).
 A fully qualified 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:
                 <sn>._tcp . <servicedomain> . <parentdomain>.
    <Instance> . <sn>._tcp . <servicedomain> . <parentdomain>.
    <sub>._sub . <sn>._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 Service Name <sn> 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.
 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.

Cheshire & Krochmal Standards Track [Page 23] RFC 6763 DNS-Based Service Discovery February 2013

 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.
 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
 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 Service 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 64 kB.  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.

Cheshire & Krochmal Standards Track [Page 24] RFC 6763 DNS-Based Service Discovery February 2013

 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.

8. Flagship Naming

 In some cases, there may be several network protocols available that
 all perform roughly the same logical function.  For example, the
 printing world has the lineprinter (LPR) protocol [RFC1179] and the
 Internet Printing Protocol (IPP) [RFC2910], 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 a case like this, where multiple protocols all perform effectively
 the same function, a client may browse for all the service types it
 supports and display all the discovered instance names in a single
 aggregated list.  Where the same instance name is discovered more
 than once because that entity supports more than one service type
 (e.g. a single printer which implements multiple printing protocols)
 the duplicates should be suppressed and the name should appear only
 once in the list.  When the user indicates their desire to print on a
 given named printer, the printing client is responsible for choosing
 which of the available protocols 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 the
 case of: some future printer that only supports IPP printing, and
 some other future printer that only supports pdl-datastream printing.

Cheshire & Krochmal Standards Track [Page 25] RFC 6763 DNS-Based Service Discovery February 2013

 The namespaces 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 to be called "Sales Department" merely
 because those two printers implement different printing protocols.
 To help guard against this, when there are two or more network
 protocols that 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.
 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 [RFC6762], 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, and 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 Standards Track [Page 26] RFC 6763 DNS-Based Service Discovery February 2013

9. Service Type Enumeration

 In general, a normal client is 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 purpose, 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 slightly better name compression in Unicast DNS responses, 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.

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 IP-only clients that implement DNS-SD but not AppleTalk NBP.
 A printer manager device that has knowledge of printers on the
 network through some other management protocol could also output a
 zone file or use DNS Update [RFC2136] [RFC3007].
 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.

Cheshire & Krochmal Standards Track [Page 27] RFC 6763 DNS-Based Service Discovery February 2013

 IP printers could use Dynamic DNS Update [RFC2136] [RFC3007] 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
 their own PTR, SRV, and TXT names ending with ".local." [RFC6762].

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 [IEEEW] laptop computer,
 tablet, or mobile telephone) arriving on a new network to discover
 what services are available on that network, without any manual
 configuration.  The logic that discovering services without manual
 configuration is a good idea also dictates that discovering
 recommended registration and browsing domains without manual
 configuration is a similarly good idea.
 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 "legacy browsing" or "automatic browsing" domain(s).
    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

Cheshire & Krochmal Standards Track [Page 28] RFC 6763 DNS-Based Service Discovery February 2013

    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
 register services and/or browse 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.
 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) [RFC2132], the DHCP "Domain Search"
 option (option code 119) [RFC3397], or IPv6 Router Advertisement
 Options [RFC6106].
 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 the address 192.168.12.34, with
 the 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(s) 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 [RFC3927] or IPv6 link-local addresses
 [RFC4862].
 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
 combined result, aggregating the information received from all
 sources.

Cheshire & Krochmal Standards Track [Page 29] RFC 6763 DNS-Based Service Discovery February 2013

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 or not to trust 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 Standards Track [Page 30] RFC 6763 DNS-Based Service Discovery February 2013

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 new
 additional records are recommended by this document.

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.  However, 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. 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 = Service\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", "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. 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 Standards Track [Page 31] RFC 6763 DNS-Based Service Discovery February 2013

13.3. How do I access the web page called "Service Discovery"?

 nslookup -q=any "Service\032Discovery._http._tcp.dns-sd.org."
 Service\032Discovery._http._tcp.dns-sd.org
                priority = 0, weight = 0, port = 80, host = dns-sd.org
 Service\032Discovery._http._tcp.dns-sd.org
                text = "txtvers=1" "path=/"
 dns-sd.org     nameserver = ns1.dns-sd.org
 dns-sd.org     internet address = 64.142.82.154
 ns1.dns-sd.org 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 from IPv4.
 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 from 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, DNS Security Extensions (DNSSEC) [RFC4033] should be
 used where the authenticity of information is important.
 For DNS updates, secure updates [RFC2136] [RFC3007] should generally
 be used to control which clients have permission to update DNS
 records.

16. IANA Considerations

 IANA manages the namespace of unique Service Names [RFC6335].
 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

Cheshire & Krochmal Standards Track [Page 32] RFC 6763 DNS-Based Service Discovery February 2013

 specification has been published, this can be recorded by requesting
 that IANA 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 a Service 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
 that IANA record 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.

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

18.1. Normative References

 [RFC20]     Cerf, V., "ASCII format for network interchange", RFC 20,
             October 1969.
 [RFC1033]   Lottor, M., "Domain Administrators Operations Guide", RFC
             1033, November 1987.
 [RFC1034]   Mockapetris, P., "Domain names - concepts and
             facilities", STD 13, RFC 1034, November 1987.

Cheshire & Krochmal Standards Track [Page 33] RFC 6763 DNS-Based Service Discovery February 2013

 [RFC1035]   Mockapetris, P., "Domain names - implementation and
             specification", STD 13, RFC 1035, November 1987.
 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2782]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
             specifying the location of services (DNS SRV)", RFC 2782,
             February 2000.
 [RFC3492]   Costello, A., "Punycode: A Bootstring encoding of Unicode
             for Internationalized Domain Names in Applications
             (IDNA)", RFC 3492, March 2003.
 [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO
             10646", STD 63, RFC 3629, November 2003.
 [RFC3927]   Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
             Configuration of IPv4 Link-Local Addresses", RFC 3927,
             May 2005.
 [RFC4862]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
             Address Autoconfiguration", RFC 4862, September 2007.
 [RFC5198]   Klensin, J. and M. Padlipsky, "Unicode Format for Network
             Interchange", RFC 5198, March 2008.
 [RFC5890]   Klensin, J., "Internationalized Domain Names for
             Applications (IDNA): Definitions and Document Framework",
             RFC 5890, August 2010.
 [RFC6335]   Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
             Cheshire, "Internet Assigned Numbers Authority (IANA)
             Procedures for the Management of the Service Name and
             Transport Protocol Port Number Registry", BCP 165, RFC
             6335, August 2011.

18.2. Informative References

 [AFP]       Mac OS X Developer Library, "Apple Filing Protocol
             Programming Guide", <http://developer.apple.com/
             documentation/Networking/Conceptual/AFP/>.
 [BJ]        Apple Bonjour Open Source Software,
             <http://developer.apple.com/bonjour/>.

Cheshire & Krochmal Standards Track [Page 34] RFC 6763 DNS-Based Service Discovery February 2013

 [BJP]       Bonjour Printing Specification,
             <https://developer.apple.com/bonjour/
             printing-specification/bonjourprinting-1.0.2.pdf>.
 [IEEEW]     IEEE 802 LAN/MAN Standards Committee,
             <http://standards.ieee.org/wireless/>.
 [NIAS]      Cheshire, S., "Discovering Named Instances of Abstract
             Services using DNS", Work in Progress, July 2001.
 [NSD]       "NsdManager | Android Developer", June 2012,
             <http://developer.android.com/reference/android/
             net/nsd/NsdManager.html>.
 [RFC1179]   McLaughlin, L., "Line printer daemon protocol", RFC 1179,
             August 1990.
 [RFC2132]   Alexander, S. and R. Droms, "DHCP Options and BOOTP
             Vendor Extensions", RFC 2132, March 1997.
 [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
             "Dynamic Updates in the Domain Name System (DNS UPDATE)",
             RFC 2136, April 1997.
 [RFC2181]   Elz, R. and R. Bush, "Clarifications to the DNS
             Specification", RFC 2181, July 1997.
 [RFC2910]   Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and
             J. Wenn, "Internet Printing Protocol/1.1: Encoding and
             Transport", RFC 2910, September 2000.
 [RFC4960]   Stewart, R., Ed., "Stream Control Transmission Protocol",
             RFC 4960, September 2007.
 [RFC3007]   Wellington, B., "Secure Domain Name System (DNS) Dynamic
             Update", RFC 3007, November 2000.
 [RFC4340]   Kohler, E., Handley, M., and S. Floyd, "Datagram
             Congestion Control Protocol (DCCP)", RFC 4340, March
             2006.
 [RFC3397]   Aboba, B. and S. Cheshire, "Dynamic Host Configuration
             Protocol (DHCP) Domain Search Option", RFC 3397, November
             2002.
 [RFC4033]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
             Rose, "DNS Security Introduction and Requirements", RFC
             4033, March 2005.

Cheshire & Krochmal Standards Track [Page 35] RFC 6763 DNS-Based Service Discovery February 2013

 [RFC4648]   Josefsson, S., "The Base16, Base32, and Base64 Data
             Encodings", RFC 4648, October 2006.
 [RFC4795]   Aboba, B., Thaler, D., and L. Esibov, "Link-local
             Multicast Name Resolution (LLMNR)", RFC 4795, January
             2007.
 [RFC6106]   Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
             "IPv6 Router Advertisement Options for DNS
             Configuration", RFC 6106, November 2010.
 [RFC6281]   Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
             "Understanding Apple's Back to My Mac (BTMM) Service",
             RFC 6281, June 2011.
 [RFC6709]   Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
             Considerations for Protocol Extensions", RFC 6709,
             September 2012.
 [RFC6760]   Cheshire, S. and M. Krochmal, "Requirements for a
             Protocol to Replace the AppleTalk Name Binding Protocol
             (NBP)", RFC 6760, February 2013.
 [RFC6762]   Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
             February 2013.
 [SN]        IANA, "Service Name and Transport Protocol Port Number
             Registry", <http://www.iana.org/assignments/
             service-names-port-numbers/>.
 [SOAP]      Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C
             Proposed Recommendation 24 June 2003,
             <http://www.w3.org/TR/2003/REC-soap12-part0-20030624>.
 [Unicode6]  The Unicode Consortium. The Unicode Standard, Version
             6.0.0, (Mountain View, CA: The Unicode Consortium, 2011.
             ISBN 978-1-936213-01-6)
             <http://www.unicode.org/versions/Unicode6.0.0/>.
 [ZC]        Cheshire, S. and D. Steinberg, "Zero Configuration
             Networking: The Definitive Guide", O'Reilly Media, Inc.,
             ISBN 0-596-10100-7, December 2005.

Cheshire & Krochmal Standards Track [Page 36] RFC 6763 DNS-Based Service Discovery February 2013

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

Cheshire & Krochmal Standards Track [Page 37] RFC 6763 DNS-Based Service Discovery February 2013

 In summary:
    Service discovery requires a central aggregation server.
    DNS already has one: a DNS server.
    Service discovery requires a service registration protocol.
    DNS already has one: DNS Dynamic Update.
    Service discovery requires a query protocol.
    DNS already has one: DNS queries.
    Service discovery requires security mechanisms.
    DNS already has security mechanisms: DNSSEC.
    Service discovery requires a multicast mode for ad hoc networks.
    Using DNS-SD in conjunction with Multicast DNS provides this,
    using peer-to-peer multicast instead of a DNS server.
 It makes more sense to use the existing software that every network
 needs already, instead of deploying an entire parallel system just
 for service discovery.

Appendix B. Ordering of Service Instance Name Components

 There have been questions about why services are named using DNS
 Service Instance Names of the form:
    Service Instance Name = <Instance> . <Service> . <Domain>
 instead of:
    Service Instance Name = <Service> . <Instance> . <Domain>
 There are three reasons why it is beneficial to name service
 instances with the parent domain as the most-significant (rightmost)
 part of the name, then the abstract service type as the next-most
 significant, and then the specific instance name as the least-
 significant (leftmost) part of the name.  These reasons are discussed
 below in Sections B.1, B.2, and B.3.

B.1. Semantic Structure

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

Cheshire & Krochmal Standards Track [Page 38] RFC 6763 DNS-Based Service Discovery February 2013

 The user knows what type of service they are seeking.  (If they are
 running an FTP client, they are looking for FTP servers.  If they
 have a document to print, they are looking for entities that speak
 some known printing protocol.)  The user knows in which
 organizational or geographical domain they wish to search.  (The user
 does not want a single flat list of every single printer on the
 planet, even if such a thing were possible.)  What the user does not
 know in advance is whether the service they seek is offered in the
 given domain, or if so, the number of instances that are offered and
 the names of those instances.
 Hence, having the instance names be the leaves of the tree is
 consistent with this semantic model.
 Having the service types be the terminal leaves of the tree would
 imply that the user knows the domain name and the name of the service
 instance, but doesn't have any idea what the service does.  We would
 argue that this is a less useful model.

B.2. Network Efficiency

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

B.3. Operational Flexibility

 This name structure allows subdomains to be delegated along logical
 service boundaries.  For example, the network administrator at
 Example Co. could choose to delegate the "_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 [RFC2136] [RFC3007] for printers registering in the

Cheshire & Krochmal Standards Track [Page 39] RFC 6763 DNS-Based Service Discovery February 2013

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

Appendix C. What You See Is What You Get

 Some service discovery protocols decouple the true service identifier
 from the name presented to the user.  The true service identifier
 used by the protocol is an opaque unique identifier, often
 represented using a long string of hexadecimal digits, which should
 never be seen by the typical user.  The name presented to the user is
 merely one of the decorative ephemeral attributes attached to this
 opaque identifier.
 The problem with this approach is that it decouples user perception
 from network reality:
  • What happens if there are two service instances, with different

unique ids, but they have inadvertently been given the same user-

    visible name?  If two instances appear in an on-screen list with
    the same name, how does the user know which is which?
  • Suppose a printer breaks down, and the user replaces it with

another printer of the same make and model, and configures the new

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

given a new name and a new function. Changing the user-visible

    name of that piece of hardware doesn't change its hidden internal
    unique identifier.  Users who had previously created a print queue

Cheshire & Krochmal Standards Track [Page 40] RFC 6763 DNS-Based Service Discovery February 2013

    for that printer will still be accessing the same hardware by its
    unique identifier, even though the logical service that used to be
    offered by that hardware has ceased to exist.
 Solving these problems requires the user or administrator to be aware
 of the supposedly hidden unique identifier, and to set its value
 correctly as hardware is moved around, repurposed, or replaced,
 thereby contradicting the notion that it is a hidden identifier that
 human users never need to deal with.  Requiring the user to
 understand this expert behind-the-scenes knowledge of what is
 *really* going on is just one more burden placed on the user when
 they are trying to diagnose why their computers and network devices
 are not working as expected.
 These anomalies and counterintuitive behaviors can be eliminated by
 maintaining a tight bidirectional one-to-one mapping between what the
 user sees on the screen and what is really happening "behind the
 curtain".  If something is configured incorrectly, then that is
 apparent in the familiar day-to-day user interface that everyone
 understands, not in some little-known, rarely used "expert"
 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 may have stayed the
 same.  If the user-visible name doesn't change, then conceptually the
 service being offered is the same logical service -- even if the
 hardware offering the service is new hardware brought in to replace
 some old equipment.
 There are certainly arguments on both sides of this debate.
 Nonetheless, the designers of any service discovery protocol have to
 make a choice between having the primary identifiers be hidden, or
 having them be visible, and these are the reasons that we chose to
 make them visible.  We're not claiming that there are no
 disadvantages of having primary identifiers be visible.  We
 considered both alternatives, and we believe that the few
 disadvantages of visible identifiers are far outweighed by the many
 problems caused by use of hidden identifiers.

Cheshire & Krochmal Standards Track [Page 41] RFC 6763 DNS-Based Service Discovery February 2013

Appendix D. Choice of Factory-Default Names

 When a DNS-SD service is advertised using Multicast DNS [RFC6762], if
 there is already another service of the same type advertising with
 the same name then automatic name conflict resolution will occur.  As
 described in the Multicast DNS specification [RFC6762], upon
 detecting a conflict, the service should:
 1.  Automatically select a new name (typically by appending or
     incrementing a digit at the end of the name),
 2.  Try advertising with the new name, and
 3.  Upon success, record the new name in persistent storage.
 This renaming behavior is very important, because it is key to
 providing user-friendly instance names in the out-of-the-box factory-
 default configuration.  Some product developers apparently have not
 realized this, because there are some products today where the
 factory-default name is distinctly unfriendly, containing random-
 looking strings of characters, such as the device's Ethernet address
 in hexadecimal.  This is unnecessary and undesirable, because the
 point of the user-visible name is that it should be friendly and
 meaningful to human users.  If the name is not unique on the local
 network then the protocol will remedy this as necessary.  It is
 ironic that many of the devices with this design mistake are network
 printers, given that these same printers also simultaneously support
 AppleTalk-over-Ethernet, with nice user-friendly default names (and
 automatic conflict detection and renaming).  Some examples of good
 factory-default names are:
    Brother 5070N
    Canon W2200
    HP LaserJet 4600
    Lexmark W840
    Okidata C5300
    Ricoh Aficio CL7100
    Xerox Phaser 6200DX
 To make the case for why adding long, ugly factory-unique serial
 numbers to the end of names is neither necessary nor desirable,
 consider the cases where the user has (a) only one network printer,
 (b) two network printers, and (c) many network printers.
 (a)  In the case where the user has only one network printer,
      a simple name like (to use a vendor-neutral example)
      "Printer" is more user-friendly than an ugly name like
      "Printer_0001E68C74FB".  Appending ugly hexadecimal goop to the
      end of the name to make sure the name is unique is irrelevant to
      a user who only has one printer anyway.

Cheshire & Krochmal Standards Track [Page 42] RFC 6763 DNS-Based Service Discovery February 2013

 (b)  In the case where the user gets a second network printer, having
      the new printer detect that the name "Printer" is already in use
      and automatically name itself "Printer (2)" instead, provides a
      good user experience.  For most users, remembering that the old
      printer is "Printer" and the new one is "Printer (2)" is easy
      and intuitive.  Seeing a printer called "Printer_0001E68C74FB"
      and another called "Printer_00306EC3FD1C" is a lot less helpful.
 (c)  In the case of a network with ten network printers, seeing a
      list of ten names all of the form "Printer_xxxxxxxxxxxx" has
      effectively taken what was supposed to be a list of user-
      friendly rich-text names (supporting mixed case, spaces,
      punctuation, non-Roman characters, and other symbols) and turned
      it into just about the worst user interface imaginable: a list
      of incomprehensible random-looking strings of letters and
      digits.  In a network with a lot of printers, it would be
      advisable for the people setting up the printers to take a
      moment to give each one a descriptive name, but in the event
      they don't, presenting the users with a list of sequentially
      numbered printers is a much more desirable default user
      experience than showing a list of raw Ethernet addresses.

Cheshire & Krochmal Standards Track [Page 43] RFC 6763 DNS-Based Service Discovery February 2013

Appendix E. Name Encodings in the Domain Name System

 Although the original DNS specifications [RFC1033] [RFC1034]
 [RFC1035] recommend that host names contain only letters, digits, and
 hyphens (because of the limitations of the typing-based user
 interfaces of that era), Service Instance Names are not host names.
 Users generally access a service by selecting it from a list
 presented by a user interface, not by typing in its Service Instance
 Name. "Clarifications to the DNS Specification" [RFC2181] directly
 discusses the subject of allowable character set in Section 11 ("Name
 syntax"), and explicitly states that the traditional letters-digits-
 hyphens rule applies only to conventional host names:
    Occasionally it is assumed that the Domain Name System serves only
    the purpose of mapping Internet host names to data, and mapping
    Internet addresses to host names.  This is not correct, the DNS is
    a general (if somewhat limited) hierarchical database, and can
    store almost any kind of data, for almost any purpose.
    The DNS itself places only one restriction on the particular
    labels that can be used to identify resource records.  That one
    restriction relates to the length of the label and the full name.
    The length of any one label is limited to between 1 and 63 octets.
    A full domain name is limited to 255 octets (including the
    separators).  The zero length full name is defined as representing
    the root of the DNS tree, and is typically written and displayed
    as ".".  Those restrictions aside, any binary string whatever can
    be used as the label of any resource record.  Similarly, any
    binary string can serve as the value of any record that includes a
    domain name as some or all of its value (SOA, NS, MX, PTR, CNAME,
    and any others that may be added).  Implementations of the DNS
    protocols must not place any restrictions on the labels that can
    be used.  In particular, DNS servers must not refuse to serve a
    zone because it contains labels that might not be acceptable to
    some DNS client programs.
 Note that just because DNS-based Service Discovery supports arbitrary
 UTF-8-encoded names doesn't mean that any particular user or
 administrator is obliged to make use of that capability.  Any user is
 free, if they wish, to continue naming their services using only
 letters, digits, and hyphens, with no spaces, capital letters, or
 other punctuation.

Cheshire & Krochmal Standards Track [Page 44] RFC 6763 DNS-Based Service Discovery February 2013

Appendix F. "Continuous Live Update" Browsing Model

 Of particular concern in the design of DNS-SD, especially when used
 in conjunction with ad hoc Multicast DNS, is the dynamic nature of
 service discovery in a changing network environment.  Other service
 discovery protocols seem to have been designed with an implicit
 unstated assumption that the usage model is:
 (a)  client software calls the service discovery API,
 (b)  service discovery code spends a few seconds getting a list of
      instances available at a particular moment in time, and then
 (c)  client software displays the list for the user to select from.
 Superficially this usage model seems reasonable, but the problem is
 that it's too optimistic.  It only considers the success case, where
 the software immediately finds the service instance the user is
 looking for.
 In the case where the user is looking for (say) a particular printer,
 and that printer is not turned on or not connected, the user first
 has to attempt to remedy the problem, and then has to click a
 "refresh" button to retry the service discovery to find out whether
 they were successful.  Because nothing happens instantaneously in
 networking, and packets can be lost, necessitating some number of
 retransmissions, a service discovery search is not instantaneous and
 typically takes a few seconds.  As a result, a fairly typical user
 experience is:
 (a)  display an empty window,
 (b)  display some animation like a searchlight sweeping back and
      forth for ten seconds, and then
 (c)  at the end of the ten-second search, display a static list
      showing what was discovered.
 Every time the user clicks the "refresh" button they have to endure
 another ten-second wait, and every time the discovered list is
 finally shown at the end of the ten-second wait, it's already
 beginning to get stale and out-of-date the moment it's displayed on
 the screen.
 The service discovery user experience that the DNS-SD designers had
 in mind has some rather different properties:
 1.  Displaying the initial list of discovered services should be
     effectively instantaneous -- i.e., typically 0.1 seconds, not 10
     seconds.

Cheshire & Krochmal Standards Track [Page 45] RFC 6763 DNS-Based Service Discovery February 2013

 2.  The list of discovered services should not be getting stale and
     out-of-date from the moment it's displayed.  The list should be
     'live' and should continue to update as new services are
     discovered.  Because of the delays, packet losses, and
     retransmissions inherent in networking, it is to be expected that
     sometimes, after the initial list is displayed showing the
     majority of discovered services, a few remaining stragglers may
     continue to trickle in during the subsequent few seconds.  Even
     after this stable list has been built and displayed, it should
     remain 'live' and should continue to update.  At any future time,
     be it minutes, hours, or even days later, if a new service of the
     desired type is discovered, it should be displayed in the list
     automatically, without the user having to click a "refresh"
     button or take any other explicit action to update the display.
 3.  With users getting in the habit of leaving service discovery
     windows open, and expecting them to show a continuous 'live' view
     of current network reality, this gives us an additional
     requirement: deletion of stale services.  When a service
     discovery list shows just a static snapshot at a moment in time,
     then the situation is simple: either a service was discovered and
     appears in the list, or it was not and does not.  However, when
     our list is live and updates continuously with the discovery of
     new services, then this implies the corollary: when a service
     goes away, it needs to *disappear* from the service discovery
     list.  Otherwise, the service discovery list would simply grow
     monotonically over time, accreting stale data, and would require
     a periodic "refresh" (or complete dismissal and recreation) to
     restore correct display.
 4.  Another consequence of users leaving service discovery windows
     open for extended periods of time is that these windows should
     update not only in response to services coming and going, but
     also in response to changes in configuration and connectivity of
     the client machine itself.  For example, if a user opens a
     service discovery window when the client machine has no network
     connectivity, then the window will typically appear empty, with
     no discovered services.  When the user connects an Ethernet cable
     or joins an 802.11 [IEEEW] wireless network the window should
     then automatically populate with discovered services, without
     requiring any explicit user action.  If the user disconnects the
     Ethernet cable or turns off 802.11 wireless then all the services
     discovered via that network interface should automatically
     disappear.  If the user switches from one 802.11 wireless access
     point to another, the service discovery window should
     automatically update to remove all the services discovered via
     the old wireless access point, and add all the services
     discovered via the new one.

Cheshire & Krochmal Standards Track [Page 46] RFC 6763 DNS-Based Service Discovery February 2013

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 the
 AppleTalk Name Binding Protocol [RFC6760] over IP.  As a result of
 this and related IETF discussions, the IETF Zeroconf working group
 was chartered September 1999.  After various working group
 discussions and other informal IETF discussions, several Internet-
 Drafts were written that were loosely related to the general themes
 of DNS and multicast, but did not address the service discovery
 aspect of NBP.
 In April 2000, Stuart Cheshire registered IPv4 multicast address
 224.0.0.251 with IANA and began writing code to test and develop the
 idea of performing NBP-like service discovery using Multicast DNS,
 which was documented in a group of three Internet-Drafts:
 o "Requirements for a Protocol to Replace the AppleTalk Name Binding
    Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk
    Name Binding Protocol, because many in the IETF community had
    little first-hand experience using AppleTalk, and confusion in the
    IETF community about what AppleTalk NBP did was causing confusion
    about what would be required in an IP-based replacement.
 o "Discovering Named Instances of Abstract Services using DNS"
    [NIAS], which later became this document, proposed a way to
    perform NBP-like service discovery using DNS-compatible names and
    record types.
 o "Multicast DNS" [RFC6762] specifies a way to transport those DNS-
    compatible queries and responses using IP multicast, for zero-
    configuration environments where no conventional Unicast DNS
    server was available.
 In 2001, an update to Mac OS 9 added resolver library support for
 host name lookup using Multicast DNS.  If the user typed a name such
 as "MyPrinter.local." into any piece of networking software that used
 the standard Mac OS 9 name lookup APIs, then those name lookup APIs
 would recognize the name as a dot-local name and query for it by
 sending simple one-shot Multicast DNS queries to 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.

Cheshire & Krochmal Standards Track [Page 47] RFC 6763 DNS-Based Service Discovery February 2013

 Multicast DNS responder software, with full service discovery, first
 began shipping to end users in volume with the launch of Mac OS X
 10.2 "Jaguar" in August 2002, and network printer makers (who had
 historically supported AppleTalk in their network printers and were
 receptive to IP-based technologies that could offer them similar
 ease-of-use) started adopting Multicast DNS shortly thereafter.
 In September 2002, Apple released the source code for the
 mDNSResponder daemon as Open Source under Apple's standard Apple
 Public Source License (APSL).
 Multicast DNS responder software became available for Microsoft
 Windows users in June 2004 with the launch of Apple's "Rendezvous for
 Windows" (now "Bonjour for Windows"), both in executable form (a
 downloadable installer for end users) and as Open Source (one of the
 supported platforms within Apple's body of cross-platform code in the
 publicly accessible mDNSResponder CVS source code repository) [BJ].
 In August 2006, Apple re-licensed the cross-platform mDNSResponder
 source code under the Apache License, Version 2.0.
 In addition to desktop and laptop computers running Mac OS X and
 Microsoft Windows, Multicast DNS is now implemented in a wide range
 of hardware devices, such as Apple's "AirPort" wireless base
 stations, iPhone and iPad, and in home gateways from other vendors,
 network printers, network cameras, TiVo DVRs, etc.
 The Open Source community has produced many independent
 implementations of Multicast DNS, some in C like Apple's
 mDNSResponder daemon, and others in a variety of different languages
 including Java, Python, Perl, and C#/Mono.
 In January 2007, the IETF published the Informational RFC "Link-Local
 Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially
 similar to Multicast DNS, but incompatible in some small but
 important ways.  In particular, the LLMNR design explicitly excluded
 support for service discovery, which made it an unsuitable candidate
 for a protocol to replace AppleTalk NBP [RFC6760].
 While the original focus of Multicast DNS and DNS-Based Service
 Discovery was for zero-configuration environments without a
 conventional Unicast DNS server, DNS-Based Service Discovery also
 works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007]
 to create service discovery records and standard DNS queries to query
 for them.  Apple's Back to My Mac service, launched with Mac OS X
 10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over
 Unicast DNS [RFC6281].

Cheshire & Krochmal Standards Track [Page 48] RFC 6763 DNS-Based Service Discovery February 2013

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

Authors' Addresses

 Stuart Cheshire
 Apple Inc.
 1 Infinite Loop
 Cupertino, CA  95014
 USA
 Phone: +1 408 974 3207
 EMail: cheshire@apple.com
 Marc Krochmal
 Apple Inc.
 1 Infinite Loop
 Cupertino, CA  95014
 USA
 Phone: +1 408 974 4368
 EMail: marc@apple.com

Cheshire & Krochmal Standards Track [Page 49]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6763.txt · Last modified: 2013/02/20 20:51 (external edit)