Internet-Draft Ryan Moats draft-ietf-svrloc-discovery-10.txt AT&T Expires in six months Martin Hamilton Loughborough University October 1998 Finding Stuff (How to discover services) Filename: draft-ietf-svrloc-discovery-10.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. In addition, there are evolving methods for doing service location via other methods [4] & [5]. Expires 4/30/99 [Page 1] INTERNET DRAFT Finding Stuff October 1998 This document proposes a possible process to order 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 procedure 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 procedure in more detail... 2.1 Support for SVRLOC A client that supports the service location protocol (SVRLOC) [4] may try to use it for finding a service. In the case where the client and target are in the same domain, no extra effort is required. When the client and target are not in the same domain, support for remote SVRLOC requests requires that the administrator of the target domain set up a "read only" SVRLOC directory agent where remote clients can reach it. To advertise this agent, one could use either SRV records, service URLs, or fallback. 2.2 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.3 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 (DNS query name)="wka.target", QCLASS (DNS query class)=IN, QTYPE (DNS query type)=A and use any returned records for connection attempts. Expires 4/30/99 [Page 2] INTERNET DRAFT Finding Stuff October 1998 2.4 Support for Service Advertising via Service URLs This technique requires that a site administrator add properly formatted NAPTR records to the DNS (see [5]). Clients supporting this should do a lookup for QNAME=service.target, QCLASS=IN, QTYPE=NAPTR and process any returned records for "service:" URLs for the desired in the specified domain. If no records are returned, clients should then do a lookup for QNAME=target, QCLASS=IN, QTYPE=NAPTR and process any returned records for "service:" URLs for the desired in the specified domain. 2.5 Fallback As a fallback (in the case that previous lookups have failed), 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. For example, if the user was trying to connect to a LDAP server in domain "foo.bar", lookups for "ldap.foo.bar" has failed, so the client should lookup A records for foo.bar and try connecting to port 389 for each A record returned. 3. Security Considerations This document specifies a procedure for discovering services that uses either the Service Location Protocol [4] or DNS [6]. Therefore, the security considerations of these protocols apply here. The order in which the protocols are applied is also significant as the security associated with these two protocols are different. 4. 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. 5. 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. Expires 4/30/99 [Page 3] INTERNET DRAFT Finding Stuff October 1998 [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 sys- tem," 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] D. Eastlake, C. Kaufman, "Domain Name System Secu- rity Extensions," RFC 2065, January 3, 1997. 6. 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 Expires 4/30/99 [Page 4]