Internet-Draft Ryan Moats draft-ietf-svrloc-discovery-01.txt AT&T Expires in six months Martin Hamilton Loughborough University Paul J. Leach Microsoft May 1997 Finding Stuff (How to discover services) Filename: draft-ietf-svrloc-discovery-01.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), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document proposes a solution to the problem of finding information about that services are being offered at a particular Internet domain. Therefore, it is possible for clients, using this approach, to locate services in a domain with only prior knowledge of the domain name. 1. Rationale Currently, there is no one 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 Expires 11/30/97 [Page 1] INTERNET DRAFT Finding Stuff April 1997 for finding the hosts that offer particular services, such as DNS servers themselves (NS records), mail exchangers (MX records [3]). Recently general service records (SRV records [1]) have been proposed for DNS, along with storing geographic information (LOC records [6]). In addition, there are evolving methods for doing service location via other methods [4] & [5]. This document sets forth a process to rationalize how a client could use these various methods for service location. 2. The process For a client in domain "srcdom" that wants to locate service "service" in domain "tgtdom", the following process should be followed: 1. If "srcdom" == "tgtdom", use the Service Location Protocol [4] to determine if the service can be found that way. 2. Look for SRV records [1] for a directory agent (i.e. da.udp."tgtdom" or da.tcp."tgtdom"). This consists of: 2a. Do a lookup of QNAME=da.tcp.tgtdom, QCLASS=IN, QTYPE=SRV. 2b. If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV RR which specifies the requested Service and Protocol in the reply: If there is precisely one SRV RR, and its Target is "." (the root domain), go to step 2c. For all SRV RR's build a list of (Priority, Weight, Target) tuples and sort the list by priority (lowest number first). Create a new empty list. For each distinct priority level For each element at this priority level While there are still elements left at this priority level, select an element randomly, with probability weight, and move it to the tail of the new list. For each element in the new list Query the DNS for A RR's for the target or use any RR's found in the additional data section of the earlier SRV query Expires 11/30/97 [Page 2] INTERNET DRAFT Finding Stuff April 1997 For each A RR found, try to connect to the directory agent using the Service Location Protocol over TCP. 2c. Else do a lookup of QNAME=da.udp.tgtdom, QCLASS=IN, QTYPE=SRV. 2d. Process the reply as in 2b, except that if there is precisely one SRV RR with a target of ".", go to step 3 and connections to the directory agent use Service Location Protocol over UDP. 3. Look for SRV records for service.protocol.tgtdom, where protocol is whichever protocol (TCP or UDP) is associated with service. This consists of: 3a. Do a lookup for QNAME=service.protocol.target, QCLASS=IN, QTYPE=SRV. 3b. If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV RR which specifies the requested Service and Protocol in the reply: If there is precisely one SRV RR, and its Target is "." (the root domain), go to step 4. For all SRV RR's, build a list of (Priority, Weight, Target) tuples and sort the list by priority (lowest number first). Create a new empty list. For each distinct priority level For each element at this priority level Query the DNS for LOC RR [6] for the Target (if not found in the Additional Data section of the earlier SRV query). Find the nearest target and all targets "close" to the nearest target (target to target distance less than 2-3% of client to nearest target distance) Remove all other targets at this priority level While there are still elements left at this priority level, select an element randomly, with probability weight, and move it to the tail of the new list For each element in the new list Query the DNS for A RR's for the Target or use any RR's found in the Additional Data section of the earlier SRV query. Expires 11/30/97 [Page 3] INTERNET DRAFT Finding Stuff April 1997 For each A RR found, if the protocol is TCP (connection- oriented) try to connect to the (protocol, address, service); if the protocol is UDP, send a service request 4. If the service desired is SMTP, skip to RFC 974 (MX records) else go to step 5. 5. If the service has a "well known" alias (see [2]) service', look for A RRs for service'.target. This is done in the following way: 5a. Do a lookup for QNAME=service'.target, QCLASS=IN, QTYPE=A. If no A RR's returned, go to step 6. For each A RR found, try to connect to the (protocol, address, service). If successful, stop. If all A RR's have been tried go to step 6. 6. Look for "service:" URLs stored in TXT RRs for service.target: 6a. Do a lookup for QNAME=service.target, QCLASS=IN, QTYPE=TXT. If no TXT RR's returned, go to step 7. For each TXT RR found, try to connect to the (address, port) specified in the service: URL. If successful, stop. If all TXT RR's have been tried go to step 7. 7. Look for "service:" URLs stored in TXT RRs for target: 7a. Do a lookup for QNAME=target, QCLASS=IN, QTYPE=TXT. If no TXT RR's returned, go to step 8. For each TXT RR found, try to connect to the (address, port) specified in the service: URL. If successful, stop. If all TXT RR's have been tried go to step 8. 8. Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A For each A RR found, try to connect to the (protocol, address, service). If successful, stop. Expires 11/30/97 [Page 4] INTERNET DRAFT Finding Stuff April 1997 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 [7] 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 and 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," Internet Draft (work in pro- gress), June 1996. [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," Internet Draft (work in progress), April 3, 1997. [5] R. Moats, M. Hamilton, "Advertising Services," Expires 11/30/97 [Page 5] INTERNET DRAFT Finding Stuff April 1997 Internet Draft (work in progress), February 1997. [6] C. Davis, P. Vixie, T. Goodwin, I. Dickinson, "A Means for Expressing Location Information in the Domain Name System," RFC 1876, January 15, 1996. [7] D. Eastlake, C. Kaufman, "Domain Name System Secu- rity Extensions," RFC 2065, January 3, 1997. 7. Authors' addresses Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net Martin Hamilton Department of Computer Studies Loughborough University of Technology Leics. LE11 3TU, UK Email: m.t.hamilton@lut.ac.uk Paul J. Leach Microsoft 1 Microsoft Way Redmond, Washington, 98052, U.S.A. Email: paulle@microsoft.com This Internet Draft expires November 30, 1997. Expires 11/30/97 [Page 6]