Internet DRAFT - draft-glenn-dns-dir
draft-glenn-dns-dir
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]
