Internet-Draft Ryan Moats draft-ietf-svrloc-discovery-08.txt AT&T Expires in six months Martin Hamilton Loughborough University September 1998 Finding Stuff (How to discover services) Filename: draft-ietf-svrloc-discovery-08.txt Status of This Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document proposes a possible solution to the problem of finding information about which services are being offered at a particular Internet domain. By using this approach, it is possible for clients to locate services in a domain with only prior knowledge of the domain name. 1. Rationale Currently, there is no single way of discovering the network services and application protocols supported at a particular Internet domain. The Domain Name System (DNS) provides some basic facilities for finding the hosts that offer particular services, such as DNS servers themselves (NS records) and mail exchangers (MX records [3]). Recently general service records (SRV records [1]) have been proposed for DNS, along with storing geographic information (LOC records [7]). In addition, there are evolving methods for doing service location via other methods [4] & [5]. This document proposes a possible process to rationalize how a client could use these various methods for service location. This process highlights the use of the Service Location Protocol [4] to allow clients to discover services by characteristics rather than by type alone. 2. Overview The basic process proposed is as follows: If the client supports SVRLOC [4], try using it. If the client supports SRV records [1], try using those. Try using well known aliases [2]. If the client supports NAPTR records, look for "service:" URLs stored in NAPTR records [5]. If nothing else works, use fallback lookups. The following sections discuss portions of this proposal in more detail... 2.1 Support for SRV records The use of SRV records by a client requires that the administrator add those records to the DNS entries for the server. If SRV records are used, the client should follow the SRV specific procedures in [5]. 2.2 Support for "Well Known" Aliases Note: "Well Known" aliases require that the administrator for a site add those entries to the DNS. Further, this requires that the service have a "well known" alias (see [2]). The client uses the well known alias for (wka = well known alias) a lookup for QNAME=wka, QCLASS=IN, QTYPE=A and use any returned records for connection attempts. 2.3 Support for Service Advertising via Service URLs This technique requires that a site administrator add properly formatted NAPTR records to the DNS (see [5]). Variations of this technique (using TXT records) are currently supported (in an early form) by both the Netfind search engine and the Java Naming and Directory Interface (JNDI). In addition, a similar technique has been proposed in H.225.O version 2 [6]. Clients supporting this should do a lookup for QNAME=service.target, QCLASS=IN, QTYPE=NAPTR and process any returned records for understandable "service:" URL information. If no records are returned, clients should then do a lookup for QNAME=target, QCLASS=IN, QTYPE=NAPTR and process any returned records for understandable "service:" URL information. 2.5 Fallback In any case, the client should do a lookup for QNAME=target, QCLASS=IN, QTYPE=A and attempt to connect to the (protocol, address, service) for each a record returned. 3. Security Considerations Because of the suggested mechanisms for service discovery, this document inherits all the security considerations of using DNS RR's and the Service Location Protocol. Implementors should consider both [8] and the security section of [4] for appropriate methods. 4. Conclusion By following the above process, a client may be reasonably certain of determining whether a particular service is provided for a particular domain name, given the domain name. 5. Acknowledgments This document is partially supported by the National Science Foundation, Cooperative Agreement NCR-9218179, the UK Electronic Libraries Programme (eLib) grant 12/39/01, and the European Commission's Telematics for Research Programme grant RE 1004. 6. References Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites. [1] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)," RFC 2052, October 1996. [2] M. Hamilton, R. Wright, "Use of DNS Aliases for Network Services," RFC 2219, October 1997. [3] S. C. Partridge, "Mail routing and the domain system," RFC 974, January 1, 1986. [4] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service Location Protocol," RFC 2165, June 1997. [5] R. Moats, M. Hamilton, "Advertising Services," Internet Draft (work in progress), October 1997. [6] ITU-T Recommendation H.225.0, Version 2, "Call Signaling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Systems," February 1998. Available from ftp://standard.pictel.com/avc- site/9801_Gen/H2250v2w_6.zip [7] C. Davis, P. Vixie, T. Goodwin, I. Dickinson, "A Means for Expressing Location Information in the Domain Name System," RFC 1876, January 15, 1996. [8] D. Eastlake, C. Kaufman, "Domain Name System Security Extensions," RFC 2065, January 3, 1997. [9] R. Daniel, M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System," RFC 2168, June, 1997. 7. Authors' addresses Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@att.com Martin Hamilton Department of Computer Studies Loughborough University of Technology Leics. LE11 3TU, UK Email: m.t.hamilton@lut.ac.uk