Network Working Group A.L. Newton
Internet-Draft VeriSign, Inc.
Expires: January 10, 2002 July 12, 2001
Whois Domain Data in LDAP
draft-newton-ldap-whois-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Domain registration data has typically been exposed to the general
public via whois for administrative purposes. This document
discusses the application of LDAP and well-known LDAP types to make
available Domain registration data.
Newton Expires January 10, 2002 [Page 1]
Internet-Draft whois-in-ldap July 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Historical Directory Services for Domain Registration Data . 3
1.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Service Description . . . . . . . . . . . . . . . . . . . . 4
3. Registry LDAP Service . . . . . . . . . . . . . . . . . . . 5
3.1 TLD DIT . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3 Access Control . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Name Server DIT . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Registrar Referral DIT . . . . . . . . . . . . . . . . . . . 7
3.3.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 7
4. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . 9
4.1 TLD DIT . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 10
4.1.3 Access Control . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Name Server and Contact DIT . . . . . . . . . . . . . . . . 11
4.2.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
6. Internationalization Considerations . . . . . . . . . . . . 14
7. Security Consideratons . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
Newton Expires January 10, 2002 [Page 2]
Internet-Draft whois-in-ldap July 2001
1. Introduction
This document describes the Referral LDAP Service, a pilot project
launched by VeriSign, Inc., to explore the use of LDAP and
LDAP-related technologies for use as a directory service of
administrative domain registration information.
1.1 Historical Directory Services for Domain Registration Data
The original National Science Foundation contract for the InterNIC
called for the creation of an X.500 directory service to allow for
administrative needs of the domain registration data and
information. Due to problems with implementations of X.500 server
software, a server based on the whois[1] protocol was temporarily
erected.
In 1994, the rwhois[3] protocol was introduced to enhance the whois
protocol. This directory service never gained wide acceptance.
At present, ICANN requires the operation of whois servers by
registries and registrars of generic top-level domains.
1.2 Motivations
With the recent split in functional responsibilities between
registries and registrars, the constant miss-use and data-mining of
domain registration data, and the difficulties with
machine-readability of whois output, the creation of the Referral
LDAP Service had the following motivations:
o Use a mechanism native to the directory protocol to refer clients
from inquiries about specific domains made at a registry to the
appropriate domain within the appropriate directory service at a
registrar.
o Limit access to domain data based on authentication of the client.
o Provide for structured queries and well-defined structured
results.
o Use a directory service technology already in general use.
Given these general criteria, LDAP[5] was selected as the protocol
for this directory service.
Newton Expires January 10, 2002 [Page 3]
Internet-Draft whois-in-ldap July 2001
2. Service Description
The service is composed of three distinct server types: a registry
LDAP server, registrar LDAP servers, and registrant LDAP servers.
The registry LDAP server contains three Directory Information Tree's
(DIT).
o The Top-Level Domain (TLD) DIT's follows the DNS hierarchy for
domains (i.e. dc=foo,dc=com).
o The name server DIT allows a view of the name servers, many of
which serve multiple domains.
o The registrar-referral DIT provides referrals from the registry
into the respective TLD DIT of the registrars (on a TLD basis).
The registrar LDAP server contains two types of DIT's.
o The TLD DIT follows the DNS hierarchy for domains (i.e.
dc=foo,dc=com) and parallels the TLD DIT of the registry.
o The name server and contact DIT allow a view of the name servers
and contacts, many of which are associated and serve multiple
domains.
There is no specification on the DIT or schema for the registrant
LDAP server. Referrals from the registrar server to the registrant
server are provided solely for the purpose of allowing the
registrant direct control over extra administrative information as
it relates to a particular domain.
Access control for this service is merely a demonstration of using
simple bind DN and password authentication. Should registries and
registrars uniformly adopt LDAP as a means to disseminate domain
registration data, standardization of the bind DN's would need to be
undertaken based on each type of user base.
Newton Expires January 10, 2002 [Page 4]
Internet-Draft whois-in-ldap July 2001
3. Registry LDAP Service
3.1 TLD DIT
3.1.1 DIT Structure
The registry TLD DIT has the following structural hierarchy.
TLD (i.e. dc=net)
|
|
-------------------------------------
| |
SLD (i.e. dc=foo,dc=net) SLD (i.e. dc=bar,dc=net)
| |
--------------------- ---------------------
| | | | | |
name server | | name server | |
(i.e. | | (i.e. | |
cn=nameserver1, | | cn=nameserver1, | |
dc=foo,dc=net ) | | dc=bar,dc=net ) | |
| | | |
name server | name server |
(i.e. | (i.e. |
cn=nameserver2, | cn=nameserver2, |
dc=foo,dc=net ) | dc=bar,dc=net ) |
| |
registrar referral registrar referral
(i.e. (i.e.
cn=registrar, cn=registrar,
dc=foo,dc=net ) dc=bar,dc=net )
The root of a TLD DIT is an entry of objectclass domain as specified
by RFC2247[4] and represents a top-level domain.
The second tier of the DIT represents second-level domains. Each of
these entries is of objectclass domain as specified by RFC2247[4].
The description attribute on these entries often contains
descriptive text giving the name of the registrar through which
these domains have been registered.
The third tier contains entries specific to each second-level domain
for which they fall under. Name server entries are of objectclass
ipHost as specified by RFC2307[8]. The distinguished names of these
name server entries are algorithmicly calculated where the first
component is the word "nameserver" concatenated with an index number
of the name server entry and the remaining components being the
appropriate domain names. There is no specification relating the
Newton Expires January 10, 2002 [Page 5]
Internet-Draft whois-in-ldap July 2001
value of the name server entry to the index it may be assigned other
than it is unique and consistent with respect to the client session.
This tier also contains the referral from the registry to the
registrar. This referral is a direct referral to the entry in the
appropriate registrar LDAP server corresponding to the domain name
which the referral falls beneath in this DIT.
3.1.2 Allowed Searches
Because of the vast amount of entries contained within this DIT,
only certain types of searches are allowed. Allowing any search
expressible via LDAP would lead to expensive searches that would be
far too costly for a publicly available service. The searches
allowed are as follows.
o One-level scoped searches based at the root of the DIT. Substring
matching is allowed on dc attributes, but the substring must be
at least be 3 characters in length.
o Base search based at the root of the DIT.
o Base, one-level, and sub-tree searches based at any second level
domain name (the second tier) and below.
3.1.3 Access Control
The registry TLD DIT only has one access control type. When a client
binds with a DN of "cn=trademark" and password of "attorney", the
second-level domain entries also take on an objectclass of
extensibleObject with the added attributes of "createddate" and
"registrationexpirationdate", which are of type Generalized Time as
specified by RFC2252[6].
3.2 Name Server DIT
3.2.1 DIT Structure
The registry name server DIT has the following structural hierarchy.
(o=nsiregistry.com)
|
|
-------------------------------------
| | |
name server name server name server
(cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org)
The root of a name server DIT is an entry of objectclass
Newton Expires January 10, 2002 [Page 6]
Internet-Draft whois-in-ldap July 2001
organization as specified by RFC1617[2]. It has no significance
other than to serve as the root of the DIT.
The second tier of this DIT represents name servers. Each of these
entries is of objectclass ipHost as specified by RFC2307[8].
3.2.2 Allowed Searches
Because of the vast amount of entries contained within this DIT,
only certain types of searches are allowed. Allowing any search
expressible via LDAP would lead to expensive searches that would be
far too costly for a publicly available service. The searches
allowed are as follows.
o One-level and sub-tree scoped searches based at the root of the
DIT if a filter on the cn attribute is provided.
o Base search based at the root of the DIT.
o Base, one-level, and sub-tree searches based at any name server
entry.
3.3 Registrar Referral DIT
3.3.1 DIT Structure
The registry registrar-referral DIT has the following structural
hierarchy.
(o=tlds)
|
|
-------------------------------
| | | |
tld tld tld tld
(dc=net) (dc=com) (dc=org) (dc=edu)
| | | |
: : | :
: : | :
|
---------------------------
| | |
referral to referral to referral to
registrar 1 registrar 2 registrar n
dc=org DIT dc=org DIT dc=org DIT
The root of the registrar referral DIT is an entry of objectclass
organization as specified by RFC1617[2]. It has no significance
Newton Expires January 10, 2002 [Page 7]
Internet-Draft whois-in-ldap July 2001
other than to serve as the root of this DIT.
The second tier of this DIT represents top-level domains. Each of
these entries is of objectclass domain as specified by RFC2247[4].
Underneath each TLD entry, the third tier contains referrals to the
appropriate TLD DIT of each registrar.
Newton Expires January 10, 2002 [Page 8]
Internet-Draft whois-in-ldap July 2001
4. Registrar LDAP Service
4.1 TLD DIT
4.1.1 DIT Structure
The registrar TLD DIT's, which is similar to the registry TLD DIT's,
has the following structural hierarchy.
TLD (i.e. dc=net)
|
|
------------------------------------------------
| | |
SLD (i.e. dc=foo,dc=net) : :
| : :
---------------------------------------------
| | |
| | |
name server contact referral to
(i.e. cn=nameserver1, (i.e. cn=contact1, registrant
dc=foo,dc=net ) dc=foo,dc=net )
|
|
name server contact
(i.e. cn=contact,
cn=nameserver1,
dc=foo,dc=net )
The root of a TLD DIT is an entry of objectclass domain as specified
by RFC2247[4] and represents a top-level domain.
The second tier of the DIT represents second-level domains. Each of
these entries is of objectclass domain as specified by RFC2247[4].
The third tier contains entries specific to each second-level domain
for which they fall under. The entries at this level are as follows:
o Name server entries are of objectclass ipHost as specified by
RFC2307[8]. The distinguished names of these name server entries
are algorithmicly calculated where the first component is the
word "nameserver" concatenated with an index number of the name
server entry and the remaining components being the appropriate
domain names. There is no specification relating the value of the
name server entry to the index it may be assigned other than it
is unique and consistent with respect to the client session.
o Contact entries are of objectclass inetOrgPerson as specified by
Newton Expires January 10, 2002 [Page 9]
Internet-Draft whois-in-ldap July 2001
RFC2798[9]. The distinguished names of these contact entries are
algorithmicly calculated where the first component is the word
"contact" concatenated with an index number of the contact and
the remaining components being the appropriate domain names.
There is no specification relating the value of the contact entry
to the index it may be assigned other than it is unique and
consistent with respect to the client session. The description
attribute of the entry contains the role for which a contact is
related to a domain. These roles are identified as "Admin
Contact", "Technical Contact", and "Billing Contact", and may
appear in any order.
o Finally, this third tier contains the referral from the registrar
to the registrant.
The fourth tier only contains name server contact entries. These
entries are of objectclass inetOrgPerson as specified by RFC2798[9].
4.1.2 Allowed Searches
Because of the vast amount of entries contained within this DIT,
only certain types of searches are allowed. Allowing any search
expressible via LDAP would lead to expensive searches that would be
far too costly for a publicly available service. The searches
allowed are as follows.
o One-level scoped searches based at the root of the DIT. Substring
matching is allowed on dc and o attributes, but the substring
must be at least be 3 characters in length.
o Base search based at the root of the DIT.
o Base, one-level, and sub-tree searches based at any second level
domain name (the second tier) and below.
4.1.3 Access Control
The registrar TLD DIT's have two access control types. When binding
anonymously, a client only sees dc, o, and c attributes of the
second-level domain entries. When a client binds with a DN of
"cn=trademark" and password of "attorney", all of the other
attributes normally available on entries of objectclass domain are
visible if they have values. In addition, if a client binds with the
DN of a contact and password of "password", all attributes for
second-level domain entries for which the bind DN has a relation are
visible.
Newton Expires January 10, 2002 [Page 10]
Internet-Draft whois-in-ldap July 2001
4.2 Name Server and Contact DIT
4.2.1 DIT Structure
The registrar name server and contact DIT has the following
structural hierarchy.
(o=nsi.com)
|
|
--------------------------------------
| |
Contacts Name Servers
(ou=contacts) (ou=name servers)
| |
----------------- ------------------------
| | | | | |
Contact : : Name Server : :
(uid=handle) : : (cn=handle) : :
|
Name Server
Contact
(cn=contact1)
The first tier of the name server and contact DIT is an entry of
objectclass organization as specified by RFC1617[2].
The second tier of the DIT contains two entries, each of which is of
objectclass organizationalUnit as specified by RFC2256[7]. One entry
represents the part of the DIT containing contacts and the other
entry represents the part of the DIT containing name servers.
Entries underneath the contacts organizationalUnit entry are of
objectclass inetOrgPerson and represent contacts registered with the
registrar. Their RDN is composed of the uid attribute. The uid
attribute's value is a unique identifier or handle that is registrar
assigned.
Entries underneath the name server organizationalUnit entry are of
objectclass ipHost and represent name servers registered with the
registrar. Their RDN is composed of the cn attribute. The cn
attribute's value is a unique identifier or handle that is registrar
assigned. Each name server entry may optionally have children
entries of objectclass inetOrgPerson. These entries represent the
contacts of the name server they fall beneath.
Newton Expires January 10, 2002 [Page 11]
Internet-Draft whois-in-ldap July 2001
4.2.2 Allowed Searches
Because of the vast amount of entries contained within this DIT,
only certain types of searches are allowed. Allowing any search
expressible via LDAP would lead to expensive searches that would be
far too costly for a publicly available service. The searches
allowed are as follows.
o One-level and base searches at the root of the DIT.
o Sub-tree searches at the root of the DIT using cn and uid
attributes as a filter.
o Base searches at the either entry of the second tier.
o One-level and sub-tree searches at either entry of the second
tier using cn or uid attributes as a filter.
o Base, one-level, and sub-tree searches based at any contact or
name server entry and below.
Newton Expires January 10, 2002 [Page 12]
Internet-Draft whois-in-ldap July 2001
5. IANA Considerations
There are no IANA considerations beyond those need by LDAP[5].
Newton Expires January 10, 2002 [Page 13]
Internet-Draft whois-in-ldap July 2001
6. Internationalization Considerations
There are no internationalization considerations beyond those needed
by LDAP[5].
Newton Expires January 10, 2002 [Page 14]
Internet-Draft whois-in-ldap July 2001
7. Security Consideratons
There are no security considerations beyond those need by LDAP[5].
Newton Expires January 10, 2002 [Page 15]
Internet-Draft whois-in-ldap July 2001
References
[1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
954, October 1985.
[2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and
Structuring Guidelines for X.500 Directory Pilots", RFC 1617,
May 1994.
[3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
June 1997.
[4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri,
"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
January 1998.
[5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[7] Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
[8] Howard, L., "An Approach for Using LDAP as a Network
Information Service", RFC 2307, March 1998.
[9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class",
RFC 2798, April 2000.
Author's Address
Andrew L. Newton
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@research.netsol.com
URI: http://www.research.netsol.com/
Newton Expires January 10, 2002 [Page 16]
Internet-Draft whois-in-ldap July 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Newton Expires January 10, 2002 [Page 17]