Networking Group                      Glenn Mansfield []
INTERNET-DRAFT                                      Cyber Solutions Inc.
draft-glenn-dns-dir-00.txt   Kohei Ohta []
                                                       Tohoku University
                             Tomohiro Ika []
                                                       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,,, or
   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, 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


         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

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

      Phone: +81-22-303-4012

      Kohei Ohta
      GSIS, Tohoku University
      Aoba-ku, Sendai

      Phone: +81-22-217-7140

      Tomohiro Ika
      GSIS, Tohoku University,
      Aoba-ku, Sendai 989-32

      Phone: +81-22-217-7140

Expires: May 16, 1998                                           [Page 8]