Request for Comments: 3663 VeriSign, Inc.
Category: Experimental December 2003
Domain Administrative Data
in Lightweight Directory Access Protocol (LDAP)
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Domain registration data has typically been exposed to the general
public via Nicname/Whois for administrative purposes. This document
describes the Referral Lightweight Directory Access Protocol (LDAP)
Service, an experimental service using LDAP and well-known LDAP types
to make domain administrative data available.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Historical Directory Services for Domain Registration
Data . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivations. . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Abbreviations Used . . . . . . . . . . . . . . . . . . . 4
2. Service Description. . . . . . . . . . . . . . . . . . . . . . 4
3. Registry LDAP Service. . . . . . . . . . . . . . . . . . . . . 6
3.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 6
3.1.2. Allowed Searches . . . . . . . . . . . . . . . . 7
3.1.3. Access Control . . . . . . . . . . . . . . . . . 7
3.2. Name Server DIT. . . . . . . . . . . . . . . . . . . . . 8
3.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 8
3.2.2. Allowed Searches . . . . . . . . . . . . . . . . 8
3.3. Registrar Referral DIT . . . . . . . . . . . . . . . . . 9
3.3.1. DIT Structure. . . . . . . . . . . . . . . . . . 9
4. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . . 10
4.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 10
4.1.2. Allowed Searches . . . . . . . . . . . . . . . . 11
4.1.3. Access Control . . . . . . . . . . . . . . . . . 11
4.2. Name Server and Contact DIT. . . . . . . . . . . . . . . 12
4.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 12
4.2.2. Allowed Searches . . . . . . . . . . . . . . . . 13
5. Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Intra-Server Referrals . . . . . . . . . . . . . . . . . 14
6.2. Inter-Server Referrals . . . . . . . . . . . . . . . . . 15
6.3. Common DIT . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Universal Client . . . . . . . . . . . . . . . . . . . . 16
6.5. Targeting Searches by Tier . . . . . . . . . . . . . . . 16
6.6. Data Mining. . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
8. Internationalization Considerations. . . . . . . . . . . . . . 16
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
10. Intellectual Property Statement. . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Other Work. . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
Author’s Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
This document describes the Referral Lightweight Directory Access
Protocol (LDAP) Service, an experimental 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 for the
administrative needs of the domain registration data and information.
Due to problems with implementations of X.500 server software, a
server based on the Nicname/Whois [1] protocol was temporarily
erected.
In 1994, the Rwhois [3] protocol was introduced to enhance the
Nicname/Whois protocol. This directory service never gained wide
acceptance for use with domain data.
Presently, ICANN requires the operation of Nicname/Whois servers by
registries and registrars of generic Top-Level Domains (TLD’s).
1.2. Motivations
With the recent split in functional responsibilities between
registries and registrars, the constant misuse and data-mining of
domain registration data, and the difficulties with machine-
readability of Nicname/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 structured queries and well-known and 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. The decision was also made to restrict
the use of LDAP to features most readily available in common
implementations. Therefore, a goal was set to not define any new
object classes, syntaxes, or matching rules.
The experiment was successful in exploring how LDAP might be used in
this context and demonstrating the level of customization required
for an operational service. Conclusions and observations about this
experiment are outlined in Section 6.
1.3. Abbreviations Used
The following abbreviations are used to describe the nature of this
experiment:
TLD: Top-Level Domain. Refers to the domain names just beneath
the root in the Domain Name System. This experiment used the
TLD’s .com, .net, .org, and .edu.
SLD: Second-Level Domain. Refers to the domain names just beneath
a TLD in the Domain Name System. An example of such a domain name
would be "example.com".
DIT: Directory Information Tree. One of many hierarchies of data
entries in an LDAP server.
DN: Distinguished Name. The unique name of an entry in a DIT.
cn: common name. See RFC 2256 [7].
dc: domain component. See RFC 2247 [4].
uid: user id. See RFC 2798 [9].
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 Trees
(DIT’s).
o The Top-Level Domain DIT’s follow the DNS hierarchy for domains
(e.g., 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 (e.g.,
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 a
Distinguished Name (DN) and password. Should registries and
registrars uniformly adopt LDAP as a means to disseminate domain
registration data, standardization of these DN’s would need to be
undertaken based on each type of user base.
3. Registry LDAP Service
3.1. TLD DIT
3.1.1. DIT Structure
The registry TLD DIT has the following structural hierarchy:
TLD (e.g., dc=net)
|
|
-------------------------------------
| |
SLD (e.g., dc=foo,dc=net) SLD (e.g., dc=bar,dc=net)
| |
--------------------- ---------------------
| | | | | |
name server | | name server | |
(e.g., | | (e.g., | |
cn=nameserver1, | | cn=nameserver1, | |
dc=foo,dc=net ) | | dc=bar,dc=net ) | |
| | | |
name server | name server |
(e.g., | (e.g., |
cn=nameserver2, | cn=nameserver2, |
dc=foo,dc=net ) | dc=bar,dc=net ) |
| |
registrar referral registrar referral
(e.g., (e.g.,
cn=registrar, cn=registrar,
dc=foo,dc=net ) dc=bar,dc=net )
Figure 1: Registry DIT Overview
The root of a TLD DIT is an entry of objectclass domain as specified
by RFC 2247 [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 RFC 2247 [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.
Name server entries are of objectclass ipHost as specified by RFC
2307 [8]. The distinguished names of these name server entries are
algorithmically calculated, where the first component is the word
"nameserver" concatenated with an index number of the name server
entry and the remaining components are 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. 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 that the
referral falls beneath in this DIT.
3.1.2. Allowed Searches
Because of the vast number 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 RFC 2252 [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)
Figure 2: Registry DIT Overview
The root of a name server DIT is an entry of objectclass organization
as specified by RFC 1617 [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 RFC 2307 [8].
3.2.2. Allowed Searches
Because of the vast number of entries contained within this DIT, only
certain types of searches are allowed. Allowing any search
expressible via LDAP would lead to searches 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
Figure 3: Registry Referral DIT Overview
The root of the registrar referral DIT is an entry of objectclass
organization, as specified by RFC 1617 [2]. It has no significance
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 RFC 2247 [4].
Underneath each TLD entry, the third tier contains referrals to the
appropriate TLD DIT of each registrar.
4. Registrar LDAP Service
4.1. TLD DIT
4.1.1. DIT Structure
The registrar TLD DIT, which is similar to the registry TLD DIT, has
the following structural hierarchy:
TLD (e.g., dc=net)
|
|
------------------------------------------------
| | |
SLD (e.g., dc=foo,dc=net) : :
| : :
---------------------------------------------
| | |
| | |
name server contact referral to
(e.g., cn=nameserver1, (e.g., cn=contact1, registrant
dc=foo,dc=net ) dc=foo,dc=net )
|
|
name server contact
(e.g., cn=contact,
cn=nameserver1,
dc=foo,dc=net )
Figure 4: Registrar DIT Overview
The root of a TLD DIT is an entry of objectclass domain, as specified
by RFC 2247 [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 RFC 2247 [4].
The third tier contains entries specific to each second-level domain.
The entries at this level are as follows:
o Name server entries are of objectclass ipHost, as specified by RFC
2307 [8]. The distinguished names of these name server entries
are algorithmically calculated where the first component is the
word "nameserver" concatenated with an index number of the name
server entry and the remaining components are 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
RFC 2798 [9]. The distinguished names of these contact entries
are algorithmically calculated, where the first component is the
word "contact" concatenated with an index number of the contact
and the remaining components are 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 RFC 2798
[9].
4.1.2. Allowed Searches
Because of the vast number of entries contained within this DIT, only
certain types of searches are allowed. Allowing any search
expressible via LDAP would lead to searches 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 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 has 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