Stuart Cheshire
Document: draft-cheshire-dnsext-nias-00.txt               Apple Computer
Expires 13th January 2002                                 13th July 2001

      Discovering Named Instances of Abstract Services using DNS

                  <draft-cheshire-dnsext-nias-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF),
   its areas, and its working groups.  Note that other groups may
   also distribute working documents as Internet-Drafts.

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

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

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

   Distribution of this memo is unlimited.


Abstract

   This document proposes a convention for naming and structuring DNS
   resource records that allows clients to discover a list of named
   instances of a particular given desired type of service.


1. Acknowledgements

   This concepts described in this draft have been explored and
   developed with help from Bill Woodcock, Erik Guttman, and others.














Expires 13th January 2002           Cheshire                    [Page 1]


Internet Draft    Named Instances of Abstract Services    13th July 2001

2. Introduction

   This is a rough first draft. Its purpose is to describe the proposed
   idea well enough for meaningful discussion to take place. As such,
   while feedback concerning typographical mistakes and similar minutiae
   is always appreciated, the reader is advised that it is probably
   unwise to waste a lot of time on such trivia until after we find out
   whether this proposal will even live long enough to become a
   'draft-01'.

   This document proposes a convention for naming and structuring DNS
   resource records that allows clients to discover a list of named
   instances of a particular given desired type of service.

   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 simply proposes a
   convention for how existing resource record types can be named and
   structured to facilitate service discovery.

   This proposal is entirely compatible with today's existing unicast
   DNS server and client software.

   This proposal is also compatible with the proposal for Multicast DNS
   outlined in "Performing DNS queries via IP Multicast" [mDNS-SC].

3. Design Goals

   A good service discovery protocol needs to have three properties:

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

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

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

   These goals are discussed in detail below.

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

Expires 13th January 2002           Cheshire                    [Page 2]


Internet Draft    Named Instances of Abstract Services    13th July 2001

4. Service Instance Enumeration

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

   For example, SRV records with the (hypothetical) name
   "_http._tcp.example.com." would allow a client to discover a list of
   all 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 RFC 2782.

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

   This proposal 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 "_lpr._tcp.example.com.",
   the client requests records of type "PTR" (pointer from one name in
   the DNS namespace to another). The result of this PTR lookup is a
   list of zero or more Service Instance Names of the form:

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

   The <Instance> portion of the name is a single DNS label, containing
   arbitrary UTF-8-encoded text [RFC 2279]. DNS recommends guidelines
   for allowable characters for host names [RFC 1034][RFC 1033], but
   Service Instance Names are not host names. Service Instance Names are
   not intended to ever be typed in by a normal user; the user selects a
   Service Instance Name by selecting it from a list of choices
   presented on the screen. Note that just because this protocol
   supports arbitrary UTF-8-encoded names doesn't mean that any
   particular user or administrator setting up a service is obliged to
   name that service using any characters outside the standard US-ASCII
   range.

   The names resulting from the PTR lookup are presented to the user in
   a list for the user to select one (or more). Having chosen 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.

   DNS labels are limited to 63 octets in length. UTF-8 encoding can
   require up to six octets per 31-bit UCS-4 character, which means that
   in the worst case, the <Instance> portion of a name could be limited


Expires 13th January 2002           Cheshire                    [Page 3]


Internet Draft    Named Instances of Abstract Services    13th July 2001

   to ten characters. However, the UCS-4 characters with longer UTF-8
   encodings tend to be the ones which convey greater meaning. A printer
   name consisting of ten ancient Egyptian Hieroglyphs may well be far
   more descriptive (to an ancient Egyptian) than a name written in
   English consisting of just 63 characters.

   I welcome input from the IDN Working Group about whether this method
   of encoding international text is the most appropriate for this
   particular usage.

   There have been proposals to keep the true DNS name of the service
   typically terse and cryptic, and to use a TXT records attached to
   that DNS name to hold the 'user-friendly' name which is displayed to
   the user. The problem with this is that it decouples user perception
   from reality. Two different instances of services with different DNS
   names could inadvertently have the same TXT record name, which could
   be very confusing to users. Maintaining a tight one-to-one mapping
   between the true DNS name and the 'user-friendly' name as displayed
   on the screen avoids these anomalies.

   There have been questions about why services are not named using
   Service Instance Names of the form: <Service> . <Instance> . <Domain>

   There are three reasons why it is beneficial to name service
   instances as:

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

   The first reason is that, the logical decomposition is that a domain
   has various services; a service has various instances of that
   service. It does not make sense to say that an instance has various
   services. These are not host names. The usage model is not, first,
   what's the name of the host, and then second, what services is it
   running? The usage model is, first, what's the name of the service,
   and then second, what are the names of the specific instances of that
   service?

   The second reason is that, when a DNS response contains multiple
   answers, name compression works more effectively if all the names
   contain a common suffix. If all the answers in the packet have the
   same <Service> and <Domain>, then each PTR's rdata only has to
   give the <Instance> part followed by a two-byte compression pointer.

   The third reason is that, this allows subdomains to be delegated
   along logical service boundaries. For example, the network
   administrator at Example Co. could choose to delegate the
   _lpr._tcp.example.com subdomain to a particular machine that has the
   responsibility to know about all the printers at Example Co. If the
   service name were the least significant component of the Service
   Instance Name, then there would be no way to separate the printers
   from the file servers.


Expires 13th January 2002           Cheshire                    [Page 4]


Internet Draft    Named Instances of Abstract Services    13th July 2001


5. Service Name Resolution

   Given a particular Service Instance Name, when a client needs to
   contact that service, it sends a DNS request for the SRV record of
   that name.

   The result of the DNS request is a SRV record giving the port number
   and target host where the service may be found.

   In some environments such as Zeroconf, the host providing the named
   service may itself not have a well-defined host name. In this case,
   the 'target' name in the SRV record may simply repeat the same name
   as the SRV record itself, with an address record attached to the same
   name giving the appropriate IP address.

   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.

   Some services discovered via Service Instance Enumeration may need
   more than just an IP address and port number to properly identify the
   service. For example, printing via lpr typically specifies a queue
   name. 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.

6. Selective Queries

   This proposal does not attempt to define an arbitrary query language
   for service discovery, nor do we believe one is necessary.

   However, there are some circumstances where narrowing the list of
   results may be useful. A printing client that wishes to discover only
   printers that accept Postscript over lpr over TCP should issue a PTR
   query for the name "_postscript._lpr._tcp.example.com." Only printers
   that support Postscript should register this PTR record pointing to
   their name.

   Note that the printer's Service Instance Name which this PTR record
   points to is unchanged -- it is still something of the form
   "ThePrinter._lpr._tcp.example.com." The domain in which printer SRV
   records are registered defines the namespace within which printer
   names are unique. Additional subtypes (e.g. "_postscript") of the
   basic service type (e.g. "_lpr._tcp") serve to narrow the list of
   results, not to create more namespace.


Expires 13th January 2002           Cheshire                    [Page 5]


Internet Draft    Named Instances of Abstract Services    13th July 2001


   The list of possible subtypes, if any, and the additional data stored
   in TXT records, if any, are defined separately for each basic service
   type.

7. Populating the DNS with information.

   How the SRV and PTR records that describe services and allow them to
   be enumerated make their way into the DNS is outside the scope of
   this document. However, it can happen easily in any of a number of
   ways, for example:

   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.

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

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

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

   Zeroconf printers on an unconfigured ad-hoc network answer Multicast
   DNS requests on their own behalf for appropriate PTR and SRV names
   within the "local.arpa." domain [mDNS-SC].

8. Relationship to Multicast DNS

   This proposal is not strictly related to Multicast DNS, but the two
   are highly complementary, particularly in Zeroconf environments [ZC].

   Lookups for PTR records of the form "<Service>.local.arpa." are
   defined to use multicast, and return a list of named instances of the
   form "<Instance>.<Service>.local.arpa."

   In Zeroconf environments where state can be transient and
   configuration information like IP addresses can change at any time,
   the DNS TTL on SRV and A records should be short, on the order of
   seconds. However, the DNS TTL on the PTR records pointing to those
   SRV names should be long, on the order of hours or days, so that once
   a name has been displayed in some other host's network browser
   window, the browsing client doesn't have to keep repeatedly asking
   for the PTR record to make sure it hasn't disappeared.


Expires 13th January 2002           Cheshire                    [Page 6]


Internet Draft    Named Instances of Abstract Services    13th July 2001


9. Comparison to Alternative Service Discovery Protocols

   At the present time there are many proposed ways to do network
   service discovery.

   The advantage of using DNS is that it makes use of existing software,
   protocols, infrastructure, and expertise. Existing network analyser
   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. It is almost certain that the
   Zeroconf host profile [ZCHP] will specify the use of Multicast DNS
   for host name resolution in the absence of DNS servers. Given that
   Zeroconf hosts will have to implement Multicast DNS anyway, it makes
   sense for them to also perform service discovery using that same
   Multicast DNS software instead of also having to implement an
   entirely different service discovery protocol.

   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 DNS server, and DNS
   already has a dynamic registration protocol [RFC 2136]. Given that
   virtually every company already has to operate and maintain a DNS
   server anyway, it makes sense to take advantage of this instead of
   also having to learn, operate and maintain a different service
   registration server.

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

   In summary:

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

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

      Service discovery requires a security model.
      DNS already has one: It's called DNSSEC.

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

Expires 13th January 2002           Cheshire                    [Page 7]


Internet Draft    Named Instances of Abstract Services    13th July 2001


      Service discovery requires a multicast mode for ad-hoc networks.
      DNS doesn't have one right now, but it will soon, to meet Zeroconf
      requirements.

   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.


10. Real Example

   The following examples were prepared using standard unmodified
   nslookup and standard unmodified BIND running on GNU/Linux.
   Note: In real life, this information is obtained using graphical
   network browser software, not command-line tools.


10.1 Question: What printers do we have at example.com?

   nslookup -q=ptr _lpr._tcp.example.com
   _lpr._tcp.example.com   name = Sales._lpr._tcp.example.com
   _lpr._tcp.example.com   name = Marketing._lpr._tcp.example.com
   _lpr._tcp.example.com   name = Engineering._lpr._tcp.example.com

   Answer: We have three, called Sales, Marketing, and Engineering.


10.2 Question: What postscript printers do we have at example.com?

   nslookup -q=ptr _postscript._lpr._tcp.example.com
   _postscript._lpr._tcp.example.com  name = Sales._lpr._tcp.example.com

   Answer: Only Sales is a postscript printer.


10.3 Question: How do I print on Sales?

   nslookup -q=any Sales._lpr._tcp.example.com
   Sales._lpr._tcp.example.com     text = "SPQ"
   Sales._lpr._tcp.example.com     priority = 0, weight = 0, port= 49152
           host = bigserver.example.com
   bigserver.example.com   internet address = 10.1.2.3

   Answer: You need to connect to 10.1.2.3, port 49152, queue name "SPQ"








Expires 13th January 2002           Cheshire                    [Page 8]


Internet Draft    Named Instances of Abstract Services    13th July 2001


11. IPv6 Considerations

   IPv6 has no significant differences, except that the address of the
   SRV record's target host is given by the appropriate IPv6 address
   records instead of the IPv4 "A" record.

12. Security Considerations

   DNSSEC [RFC 2535] should be used where the authenticity of
   information is important.

13. IANA Considerations

   The IANA will have to allocate symbolic service/protocol names, much
   as they allocate TCP port numbers today. However, the textual nature
   of service/protocol names means that there are almost infinitely many
   more of them available than the finite set of 65535 possible port
   numbers. It may also be appropriate to allow use of temporary
   self-assigned service/protocol names, much like the "x-foo/bar"
   self-assigned experimental MIME types.

14. Copyright

   Copyright (C) The Internet Society 8th March 2000.
   All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Expires 13th January 2002           Cheshire                    [Page 9]


Internet Draft    Named Instances of Abstract Services    13th July 2001


15. References

   [mDNS-SC]  S. Cheshire, "Performing DNS queries via IP Multicast",
              Internet-Draft (work in progress),
              draft-cheshire-dnsext-multicastdns-00.txt, July 2001.

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

   [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
              RFC 2279, January 1998.

   [RFC 2535] D. Eastlake, "Domain Name System Security Extensions",
              RFC 2535, March 1999.

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

   [ZC]       M. Hattig, "Zeroconf Requirements", Internet-Draft (work
              in progress), draft-ietf-zeroconf-reqts-08.txt, May 2001.

   [ZCHP]     E. Guttman, "Zeroconf Host Profile", Internet-Draft (work
              in progress), draft-ietf-zeroconf-host-prof-00.txt, July
              2001.

16. Author's Address

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

   Phone: +1 408 974 3207
   EMail: rfc@stuartcheshire.org
















Expires 13th January 2002           Cheshire                   [Page 10]

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org