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 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 = . . The 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 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: . . There are three reasons why it is beneficial to name service instances as: Service Instance Name = . . 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 and , then each PTR's rdata only has to give the 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 ".local.arpa." are defined to use multicast, and return a list of named instances of the form "..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 * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org