HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 03:13:59 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 02 Sep 1996 22:22:00 GMT ETag: "323b5c-632f-322b5e08" Accept-Ranges: bytes Content-Length: 25391 Connection: close Content-Type: text/plain Internet-Draft Ryan Moats draft-ietf-ids-discovery-01.txt AT&T Expires in six months Martin Hamilton Loughborough University August 1996 Finding Stuff (Providing information to support service discovery) Filename: draft-ietf-ids-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 which services are being offered at a particular Internet domain, based on deployment experience with the Netfind White Pages directory software. This approach makes it possible to supply clients with more information than the DNS aliases which have been widely deployed in this role - notably the port numbers being used by servers. However, it is not without problems, and we have tried to take account of these. Expires 2/97 [Page 1] INTERNET DRAFT Finding Stuff August 1996 1. Rationale 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 - [1,2]) provides some basic facilities for finding the hosts which offer particular services, such as DNS servers themselves (NS records), and mail exchangers (MX records). It does not provide a mechanism for locating arbitrary servers of arbitrary protocols, or a search capability. In addition to the name and IP address(es) of the host offering the service, clients also sometimes require further information to make effective use of the service - e.g. TCP or UDP port numbers, protocol version information, and information about the protocol options supported by the server. Another example would be the organization's base within the X.500 [3] Directory Information Tree (DIT), which is needed for X.500 browsing and searching. At the time of writing, it was common practice to "hint" at the services and protocols offered at a given domain via DNS aliases, e.g. the alias "www.internic.net" implies that the HTTP server for the domain "internic.net" is running on TCP port 80 of the machine (or machines) which answer to the name "www.internic.net". A slight formalization of this approach is proposed by [4]. Other schemes have been suggested for explicitly registering services either by DNS extensions, as in [5], or by the use of dedicated directory services such as X.500. A number of mechanisms have been suggested to address the problem of finding this service information, ranging from new DNS record types to dedicated directory services. No single one of these would-be solutions has as yet gained the competitive edge, and if the lengthy gestation period to date is anything to go by, it seems that we can expect even more delay before there is any widespread deployment - unless there is a "killer application" that forces the issue. 2. Where Netfind has gone before The Netfind software [6,7] follows what has been proposed in RFC1588 [8]: using URLs [9] for passing directory service information to clients. It uses stylized Text (TXT) record encoding within the DNS and currently understands the following "White Pages" URLs: ----------------------------------------------------------- White Pages URL Information ----------------------------------------------------------- wp-noop:// This site should not be visited wp-dap:// X.500 search base for the site Expires 2/97 [Page 2] INTERNET DRAFT Finding Stuff August 1996 e.g. wp-dap://o=Loughborough%20University,c=GB wp-ph://host/port Indicates CCSO nameserver [10] wp-whois://host/port Indicates WHOIS [11] server wp-smtp-expn-finger://host Use the SMTP [12] EXPN command, and the finger [13] protocol wp-smtp-expn://host/port Indicates the SMTP EXPN command wp-finger://host/port Indicates the finger protocol wp-telnet://host/port Indicates a text based info service which should be used via telnet [14] ----------------------------------------------------------- Note that the notation "protocol://host/port" is used, rather than the "protocol://host:port" format which is being standardized for generic URLs. Note also that these URL schemes have not all been standardized, although wp-ph and wp-whois may be accommodated by translation to the widely supported Internet Gopher Protocol [15]. 3. A simple interim solution In this document, we propose that the "service:" as described in [20] be encoded in DNS TXT records as a solution. With this scheme, software agents would perform a DNS lookup on .. The TXT record associated with . would have the following syntax: IN TXT "service:- [preference] [protocol specific information]" where the preference value and protocol specific information are optional and are separated by spaces. Alternatively, software agents could perform a lookup on the parent domain, but this could lead to overloading the DNS response packet. We propose that the following values be used for --------------------------------------------------------------------- Prefix Meaning --------------------------------------------------------------------- keys Public key server info urn URN resolver info wp "White Pages" service info yp "Yellow Pages" service info --------------------------------------------------------------------- This scheme is not compatible with the Netfind "wp-" scheme, but that Expires 2/97 [Page 3] INTERNET DRAFT Finding Stuff August 1996 is not viewed as a problem due to lack of deployment of "wp-" URLs. Alternatively, clients may support both "wp-" URLs and "service:" URLs. Thus for general white pages discovery, we propose that software agents perform a DNS lookup on wp.. In this case, the TXT records would contain URLs of the "wp-" service type. For example, the TXT records for wp.lut.ac.uk could be written as service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of%20 Technology,c=GB service:wp-http://www.lut.ac.uk/cgi-bin/local Whilst not an optimal solution, for reasons we will discuss below, this approach does provide an additional level of flexibility and only requires a trivial amount of work to deploy - typically adding a single line to the site's DNS configuration file for each service being advertised. 4. Further details and usage scenarios 4.1. Finding "White Pages" information This is the case which is already catered for by the Netfind "wp-" prefix. In order to explicitly advertise their White Pages services, a site would create one or more TXT records under both wp and the service being advertised, e.g. wp IN TXT "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University %20of%20Technology,c=GB" wp IN TXT "service:wp-whois://whois.lut.ac.uk/" wp IN TXT "service:wp-gopher://cso.lut.ac.uk/2" ldap IN TXT "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University %20of%20Technology,c=GB" whois IN TXT "service:whois-whois://whois.lut.ac.uk/" ph IN TXT "service:ph-gopher://cso.lut.ac.uk/2" Another example showing the possibility of multiple protocols for accessing a service would be (the domain for this example is aecom.yu.edu): ns IN TXT "service:wp-gopher://gopher.aecom.yu.edu/2" ns IN TXT "service:wp-http://www.middlebury.edu/cgi-bin/ WebPh?other_ph_servers" ns IN TXT "service:wp-http://faker.ncsa.uiuc.edu:8080/cgi-bin/phfd" Expires 2/97 [Page 4] INTERNET DRAFT Finding Stuff August 1996 It is envisaged that this information could be used in a number of situations. For example, mail user agents with integrated support could offer to perform directory service lookups in order to determine a correspondent's address from their name (assuming their Internet domain is already known - e.g. through a directory of organization name to domain name mappings), to verify the contents of address books, and to determine alternative email addresses should delivery fail. This last technique might also be applied by lower level mail delivery software. 4.2. Locating URN resolvers In most of the recent proposals for Uniform Resource Names (URNs, cf. [17]), it has been assumed that the URN will have a naming authority component - essentially a publisher ID - and that this will be somehow mapped onto a domain name in the process of resolving the URN. Once a domain name has been obtained, it will be necessary to determine at least a protocol, and possibly other information (e.g. a port number) for use in performing the URN lookup. The "urn-" prefix provides a simple mechanism by which this may be done, e.g. urn.ietf.org IN TXT "service:urn-http://purl.ietf.org/" urn.ietf.org IN TXT "service:urn-whois://registry.ietf.org/" In this scenario, URN resolvers would not be tied to using a particular protocol, port number, and server for a given naming authority. 4.3. Public key lookup Attempts to build a scalable infrastructure for the distribution of public key information, in particular for the public keys of individuals, have been hampered by the lack of a convention which could be used to indicate the public key servers for a site or organization. The "keys-" prefix gives us a flexible means by which this may be done, e.g. keys IN TXT "service:keys-finger://mrrl.lut.ac.uk 5" lut.ac.uk IN TXT "service:keys-finger://mrrl.lut.ac.uk 5" It does not, however, address the issue of public key (certificate) format. It is anticipated that this would be taken care of by format negotiation in the protocol or protocols being used to perform the Expires 2/97 [Page 5] INTERNET DRAFT Finding Stuff August 1996 lookup. Public key lookup would be of immediate use in software which has integrated support for public key authentication, signing and encryption - e.g. mail and news user agents. 4.4. Finding "Yellow Pages" information By "Yellow Pages" we mean a catch-all category: information about services offered which do not fall into any of the above categories. For example, consider the case of a machine which is running an HTTP server - but not on the IANA registered default port (80) www IN A 204.179.186.65 IN A 198.49.45.10 IN A 192.20.239.132 IN TXT "service:yp-http://www.ds.internic.net:8888/" yp IN A 204.179.186.65 IN A 198.49.45.10 IN A 192.20.239.132 IN TXT "service:yp-http://www.ds.internic.net:8888/" This "Yellow Pages" mechanism provides a means for DNS maintainers to effectively register the existence of their major network services. This can have a variety of uses - e.g. the service information is available to any "web crawler" type applications which might choose to index it, and to interactive applications such as World-Wide Web browsers, which might use it to override their default behavior. 4.5 Finding "Directory Agent" information [20] also defines a scheme for Directory Agent discovery (Here directory is being used in the SVRLOC context, not the IDS context) "directory-agent". A site may wish to present services to hosts outside its domain may elect to set up a Directory Agent (with the remote registration features turned off, see [20]) outside its firewall. A client supporting the service location protocol would then make queries for individual services inside the domain. The Directory Agent would be found via the following DNS entries: (Domain entry) catch22.com IN TXT "service:directory-agent://slp-resolver.catch22.com" (host in domain catch22.com) directory-agent IN TXT "service:directory-agent://slp-resolver.catch22.com" Expires 2/97 [Page 6] INTERNET DRAFT Finding Stuff August 1996 5. Support in DNS clients and servers In general, server configuration is simply a matter of adding an extra line to the relevant zone, e.g. internic.net. IN TXT "service:yp-wais://ds.internic.net:8210/rfcs" or, using whatever origin was current at the time keys 32768 IN TXT "service:keys-http://www.nic.surfnet.nl:2082/pgp-cgi-bi n/pks-extract-key.pl?op=get&search=" or, adding an extra record to the previous entry IN TXT "service:yp-whois://services.bunyip.com:6300 5" Clients should generate question sections which have type TXT and class IN, and the desired domain name. As noted above, implementors are advised to check not only the TXT records for the domain itself, but also those obtained by appending the domain name to the desired URL prefixes, e.g. in finding White Pages services for "internic.net", the TXT records for both "internic.net" and "wp.internic.net" might be looked up. 6. Limitations of this approach Note that older DNS servers may not support the TXT record type, and some servers fail to implement it properly - e.g. BIND 4.9.2 misses out every other letter in the TXT record. Some resolvers are not capable of requesting a TXT record, or not capable of generating any DNS lookup requests other than a simple address lookup. TXT records can actually be requested by setting the question type in the request to 16 (decimal), regardless of the symbolic names defined by the stack's resolver code. Implementing more advanced resolver functionality when the stack only provides address lookup requires a little work, but sample code is freely available. The size limitations on DNS packets will have some effect on the number of URLs which can be associated with a domain name using TXT records. Response packets are liable to be truncated if they grow to over 576 bytes. Characters which are illegal in URLs must be escaped, for example: "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of %20Technology,c=GB" Expires 2/97 [Page 7] INTERNET DRAFT Finding Stuff August 1996 Domain name compression is normally used to reduce the size of the response packet needed for a given domain name. Clearly, this will not be possible on arbitrary strings embedded within the response packet. Widespread use of TXT records in the role proposed by this document would increase the amount of information held in nameserver caches, and in particular might cause problems where negative caching is concerned. Consequently we suggest that clients use them as a fall back mechanism if more conventional methods, such as DNS aliases, prove unproductive. 7. Security Considerations Since this draft proposes to use DNS for storage of URL information, all the normal security considerations for applications which depend on the DNS apply. The DNS is open to many kinds of "spoofing" attacks, and it cannot be guaranteed that the result returned by a DNS lookup is indeed the genuine information. Spoofing may take the form of denial of service, such as directing of the client to a non- existent address, or a passive attack such as an intruder's server which masquerades as the legitimate one. Work is ongoing to remedy this situation insofar as the DNS is concerned [19]. In the meantime it should be noted that stronger authentication mechanisms such as public key cryptography with large key sizes are a pre-requisite if the DNS is being used in any sensitive situations. Examples of these would be on-line financial transactions, and any situation where privacy is a concern - such as the querying of medical records over the network. Strong encryption of the network traffic may also be advisable, to protect against TCP connection "hijacking" and packet sniffing. There are some additional considerations which are specific to URLs. Specifically, client applications should be wary of URLs which direct them to alternative Internet domains and/or unusual port numbers. They should also be proactive when passing URLs to external programs, to ensure that the user's environment is not exposed to malevolent meta-characters. Finally, implementors should take care to avoid buffer overruns when processing these DNS response packets. 8. Conclusions Whilst far from ideal, we believe the approach outlined in this document does provide a workable interim solution to the problem of locating the network services offered at a particular Internet domain - particularly when used in combination with DNS aliases, as outlined in [4]. Suitable DNS server software is already widely deployed, and Expires 2/97 [Page 8] INTERNET DRAFT Finding Stuff August 1996 client support may be implemented without any great difficulty. It is debatable whether any of this is strictly necessary. Certainly there is less work involved in adding a few lines to an existing DNS server configuration than in setting up a whole new directory service, such as X.500. From this point of view, a new DNS resource record type or types would perhaps address the problem more effectively, but it may be some time before any new types are widely deployed. 9. Acknowledgments Special thanks to Erik Guttman for his help with the service location example, information on the "service:" scheme, as well as much e-mail in working out the service schemes proposed here. Thanks to Tim Howes, Sri Sataluri and <> for their comments on earlier drafts of this document. This work was partially supported by the National Science Foundation, the UK Electronic Libraries Programme (eLib), and the European Commission's Telematics for Research Programme. The format used for representing Netfind White Pages URLs within the DNS was originally defined by Mike Schwartz, with assistance from Carl Malamud and Marshall Rose. The Netfind work was supported in part by grants from the National Science Foundation, the Advanced Research Projects Agency, Sun Microsystems' Collaborative Research Program, and AT&T Bell Laboratories. Some of the points in the security considerations section were drawn from [4]. 10. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] P. V. Mockapetris. "Domain names - concepts and facilities", RFC 1034. November 1987. [2] P. V. Mockapetris. "Domain names - implementation and specification", RFC 1035. November 1987. [3] C. Weider, J. Reynolds, S. Heker. "Technical Over- view of Directory Services Using the X.500 Proto- col", RFC 1309. March 1992. Expires 2/97 [Page 9] INTERNET DRAFT Finding Stuff August 1996 [4] M. Hamilton, R. Wright. "Use of DNS Aliases for Network Services", Internet Draft (work in pro- gress). June 1996. [5] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location of services (DNS SRV)", Internet Draft (work in progress). March 1996. [6] M. F. Schwartz. "Netfind Support for URL-Based Search Customization", June 28, 1994. [7] M. F. Schwartz, C. Pu. "Applying an Information Gathering Architecture to Netfind: A White Pages Tool for a Changing and Growing Internet", Univer- sity of Colorado Technical Report CU-CS-656-93. December 1993, revised July 1994. [8] J. Postel, C. Anderson, "White Pages Meeting Report", RFC 1588. February 1994. [9] T. Berners-Lee, L. Masinter & M. McCahill. "Uni- form Resource Locators (URL)", RFC 1738. December 1994. [10] R. Hedberg, S. Dorner, and P. Pomes, "The CCSO Nameserver (Ph) Architecture", Internet Draft (work in progress), January 1996. [11] K. Harrenstien, M. K. Stahl, E.J. Feinler. "NICNAME/WHOIS", RFC 954. October 1985. [12] D. Crocker. "Standard for the format of ARPA Internet text messages", RFC 822. August 1982. [13] D. Zimmerman. "The Finger User Information Expires 2/97 [Page 10] INTERNET DRAFT Finding Stuff August 1996 Protocol", RFC 1288. December 1992. [14] J. Postel, J .K. Reynolds. "Telnet Protocol specification", RFC 855. May 1983. [15] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey & B. Albert. "The Internet Gopher Proto- col (a distributed document search and retrieval protocol)", RFC 1436. March 1993. [16] C. Partridge. "Mail routing and the domain sys- tem", RFC 974. January 1986. [17] K. Sollins & L. Masinter. "Functional Requirements for Uniform Resource Names", RFC 1737. December 1994. [18] P. Deutsch, R. Schoultz, P. Faltstrom and C. Weider. "Architecture of the WHOIS++ service", RFC 1835. August 1995. [19] D. E. Eastlake 3rd, C. W. Kaufman. "Domain Name System Security Extensions", Internet Draft (work in progress). January 1996. [20] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service Location Protocol", Internet Draft (work in progress), June 1996. 11. Authors' addresses Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net Expires 2/97 [Page 11] INTERNET DRAFT Finding Stuff August 1996 Martin Hamilton Department of Computer Studies Loughborough University of Technology Leics. LE11 3TU, UK Email: m.t.hamilton@lut.ac.uk This Internet Draft expires December 1, 1996. Expires 2/97 [Page 12]