Networking Group Glenn Mansfield [glenn@wide.ad.jp] INTERNET-DRAFT Cyber Solutions Inc. draft-glenn-dns-dir-00.txt Kohei Ohta [kohei@nemoto.ecei.tohoku.ac.jp] Tohoku University Tomohiro Ika [ika@nemoto.ecei.tohoku.ac.jp] Tohoku University November 1997 A Directory for organizations and services from DNS and WHOIS. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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 ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract An Internet Directory is a necessity. The lack of an Internet Directory is posing serious problems. There are several Directory Protocols ready for deployment in the Internet. But, among other factors, content generation for the directory has been a major stumbling block. A simple and straight-forward method of generating contents for a directory of organizations and their network services using information from the Domain Name System (DNS) and the WHOIS servers is described in this memo. Expires: May 16, 1998 [Page 1]
Internet Draft November 16 1997 Table of Contents 1. Introduction .................................................. 3 2. The Background ................................................ 3 3. The Problems .................................................. 3 4. The solution: Use a Directory Service ......................... 5 5. The Directory Deployment Strategy ............................. 5 6. Acknowledgements .............................................. 7 7. References .................................................... 7 Security Considerations ........................................... 8 Authors' Addresses ................................................ 8 Expires: May 16, 1998 [Page 2]
Internet Draft November 16 1997 1. The Introduction. The explosive growth of the Internet without a Directory is causing serious problems. The present trend of using the Domain Name System to "guess" the address of an organization's Home Page is causing a lot of confusion. Copyright and trademark litigations are the order of the day. On the other hand the popular usage of URLs to refer to Home Pages reminds one of the days when IP- addresses were the only means of addressing Internet hosts. That was before the Domain Name Service was deployed. An Internet Directory is now a necessity. There are several Directory Protocols ready for deployment in the Internet. A simple and straightforward method of deploying the directory for organizations and services using information from the Domain Name System (DNS) and the WHOIS servers is described in this memo. 2. The Background. There have been sporadic efforts towards developing an Internet Directory. What started with the promise of a single globally distributed X.500[1] directory system evolved into an environment of several competing proposals and prototypes. LDAP[2], CLDAP[3], WHOIS++[4], RWHOIS [5] emerged. However the developments in the Internet has far overtaken the developments in the Directory. There has been explosive growth in the usage of Internet. Most important of all, it is perceived as one of the most important marketing vehicle, thanks to the World Wide Web. In the absence of an Internet Directory URLs have become the most popular means of addressing an Internet Resource. URLs use the domain name as a component. So, popular WWW clients are (mis-)using the DNS to guess the domain name (and thus the URLs) from an organization's name. E.g. if the company name is CoName, http://www.coname.com will be tried as a possible address of the companies Home Page and so on. This works in some cases but doesn't work in many more. Nevertheless, there is a trend to register domain names that will make the URL more "guessable". So much so that, the prevaling psyche is- the domain name is just another "name" of an organization that will be used by the masses(read consumers) to identify the organization and its services and as such is of paramount important. 3. The problems Domain names are assuming an un-intended significance. The domain name of an organization has become as important as its trademark or logo. This has brought much pressure on the administration of the Domain Name System which perhaps is one of the most widely used Expires: May 16, 1998 [Page 3]
Internet Draft November 16 1997 distributed database system. There is a demand for easily guessable domain names, thus the pressure on the top-level domains (TLDs). There is also a trend to register names simply to preempt others. Sometimes, on all branches of the DNS-tree. All this is a very undesirable trend as: o NICs which assign domain names, generally, do not have the resources to administer and/or assign names, trademarks, etc. to organizations in accordance with the rules of the land. It's concern is the network, its addresses and codes such as "Domain Names" which map onto these addresses. o The number of "usable" names and "preferred" names that are easy to guess and/or remember is finite and is likely to be exhausted in the near future. o The top level domains like .com domain are likely to come under severe pressure for name space. Already, it is unlikely that one will get one's favorite name there - more likely than not it will be taken! The DNS cannot be used to guess the domain name of an organizations o It cannot do searches based on approximate keys. The DNS wasn't meant to be a directory. It is a distributed database widely used for mapping "domain names" which are strings of characters, to IP addresses. It does not have the provisions for official names like "The Lazy Lamba Company (p) Ltd." and addresses like " Some Street, Some State, Some Country". The DNS will take an exact key (e.g. the domain-name) and retrieve the data (e.g. the address) corresponding to the key. If there is no exact match no data will be retrieved. URLs are not meant for public consumption. o In the present environment URLs are advertised. The consumer is given ugly strings like http://abstruse.com/even/more/abstruse/ to remember or note. This is possibly the most user-unfriendly thing that has happenned to the Internet in recent times. Try listening to a URL on the radio, in a non english-like language! And then put the port number in there. It gets close to gibberish. URLs are wonderful. But those have not been designed for intelligent beings - they are meant for obedient hard-working computers. Expires: May 16, 1998 [Page 4]
Internet Draft November 16 1997 4. The solution: Use a Directory Service. The problems described above can be remedied if a Directory service is made available to look up, at the least, the advertised network services and corresponding URLs of organizations. The advantages of using the directory for service lookup are manifold. o User friendly naming [7] can be used: For example one may look up XYZ of ABC city of DEF country. This will fetch, among others, the organization XYZ-Services (P) Ltd., ABC city, DEF Country. o Approximate names or hints can be used: Even if one mis- spells a name - there is a fair probability of finding the target. A phonetic match could match Donuts Inc with Doughnuts Inc. o Multiple hits are allowed: Since the search is based on approximate keys several candidates are likely to appear. o Multilingual searches are allowed: Most of the directories support Multilingual keys and data. This is an essential requirement for a user-friendly interface. That would more accurately reflect the constitution of the Internet user- community. [Not all them use the roman alphabet]. Many organizations and persons have names that cannot be correctly spelt using roman literals. o Conflicts over domain name assignment will potentially reduce. The "Names" registered in the directory are not assigned by NICs or Domain Managers. Organization Names will be assigned by entities which have the resources and means to service the name assignment procedure in accordance with the laws of the land. 5. The Directory Deployment Strategy. The Directory Service solution has been around for quite some time[6]. The major problem in utilizing the services of a Directory was the lack of a full-fledged Directory Service. There were problems in deploying the Directory. The following are some of requirements that a directory service must meet to provide the expected services. o The directory must be distributed. A monolithic directory is not scalable. In the distributed environment of the Internet it is unlikely to work. o The data in the distributed directory must have some hierarchical organization to facilitate searches. o The searches should be fast. o The Directory must be ubiquitous. It must be accessible from Expires: May 16, 1998 [Page 5]
Internet Draft November 16 1997 anywhere on the Internet. o The Directory should have enough contents to make it a potential source of information for information seekers. This is the one of the most important factors that will bootstrap the directory contents by attracting seekers and advertisers. Most of the above requirements are met by the present protocols. The single stumbling block has been the contents of the directory. The poor contents of the Directory has failed to take it across the threshold where it can attract information seekers and publishers. To get data into the directory, automated means will have to be used. In the following we propose a strategy to mechanically generate contents for the directory. Generating contents for the directory. The startup directory should cover a majority of all organizations to be useful and to act as a proper seed. However, in the present context we focus on organizations that have an Internet connection and/or are offering some Internet service (WWW, FTP or whatever). The DNS is the primary source of pointers to such organizations and the services that are advertised. However, this information itself is not enough to start the directory service. As that will be an image of the DNS. With the domain-name as key, the other important pieces of information e.g. the organization's name and address can be fetched from the WHOIS server for the domain. This information provides a complete set of data to start the directory services to allow enquiries on the network services provided by an organization. The following algorithm builds directory objects for organizations and related services by using the pointers from the DNS and then looking up the pertinent WHOIS servers for complementary information. 1. start from a GIVEN DOMAIN. 2. retrieve the postal address and official name of the organization that represented by the domain, from the WHOIS server of the domain. 3. retrieve the service details from the DNS - look for SRV resource records - look for all A records in the domain which have well known prefixes (e.g. www.given.domain, ftp.given.domain) 4. look for NS records to retrieve (sub-)domains in GIVEN DOMAIN Expires: May 16, 1998 [Page 6]
Internet Draft November 16 1997 5. for each (sub-)domain repeat steps 1-5 with GIVEN DOMAIN = (sub-)domain. This recursive method will generate the objects that will populate the directory. Note that the information from step 2 is likely to be multilingual (e.g. English and Japanese at the WHOIS server of the Japanese Network Information Center). The Directory Tree. The toplevel domains which belong to countries or regions are good starting points for the above algorithm. That will build the country's subtree in the directory. Depending on the DNS organization - the country subtree may be further subdivided into regional-subtrees. The directory administration will need to be intimated about the new subtrees that are created. Organizations which will want to maintain their own independent subtree can very well do so by leaving a pointer in the parent (sub-)tree. 6. Acknowledgements. This draft is the product of discussions and deliberations carried out in the NetMan working group of Tohoku University. 7. References [1] CCITT Blue Book, "Data Communication Networks: Directory", Recommendations X.500-X.521, December 1988. [2] Yeong, W., Howes, T., and Kille, S., "Lightweight Directory Access Protocol", RFC 1777, Performance Systems International, University of Michigan, ISODE Consortium, March 1995. [3] Young, A., "Connection-less Lightweight X.500 Directory Access Protocol", RFC 1798, ISODE Consortium, June 1995. [4] P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995. [5] S. Williamson, M. Kosters, D. Blacka, J. Singh, K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, June, 1997. [6] Kille, S., Huizer, E., Cerf, V., Hobby, R., and S. Kent, "A Strategic Plan for Deploying an Internet X.500 Directory Service", RFC 1430, ISODE Consortium, SURFnet bv, Corporation for Expires: May 16, 1998 [Page 7]
Internet Draft November 16 1997 National Research Initiatives, University of California, Davis, Bolt, Beranek and Newman, February 1993. [7] S. Kille, "Using the OSI Directory to Achieve User Friendly Naming", RFC 1781 , ISODE Consortium, March 1995. Security Considerations In deploying the proposed mechanism, care will need to be taken to ensure the authenticity of the sources of information viz. the DNS servers and the WHOIS servers. It needs to be noted that information from these sources do not in generally carry any guarantee about the integrity or consistency of the contents. Clients availing of the directory services will need ensure the authenticity of the corresponding servers. Authors' Addresses Glenn Mansfield Cyber Solutions Inc. 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-32 Japan Phone: +81-22-303-4012 EMail: glenn@wide.ad.jp Kohei Ohta GSIS, Tohoku University Aoba-ku, Sendai Japan Phone: +81-22-217-7140 EMail: kohei@nemoto.ecei.tohoku.ac.jp Tomohiro Ika GSIS, Tohoku University, Aoba-ku, Sendai 989-32 Japan Phone: +81-22-217-7140 EMail: ika@nemoto.ecei.tohoku.ac.jp Expires: May 16, 1998 [Page 8]