Network Working Group A. Newton
Request for Comments: 3663 VeriSign, Inc.
Category: Experimental December 2003
Network Working Group A. Newton
Request for Comments: 3663 VeriSign, Inc.
Category: Experimental December 2003
Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)
轻量级目录访问协议（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.
版权所有（C）互联网协会（2003年）。版权所有。
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.
出于管理目的，域注册数据通常通过Nicname/Whois向公众公开。本文档描述了引用轻型目录访问协议（LDAP）服务，这是一项实验性服务，使用LDAP和众所周知的LDAP类型使域管理数据可用。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
本文档描述了引用轻型目录访问协议（LDAP）服务，这是VeriSign，Inc.发起的一个实验项目，旨在探索LDAP和LDAP相关技术的使用，以用作管理域注册信息的目录服务。
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.
美国国家科学基金会的原国家科学基金会的合同要求建立一个X.500目录服务，用于管理域注册数据和信息的需求。由于X.500服务器软件的实现存在问题，临时建立了基于Nicname/Whois[1]协议的服务器。
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.
1994年，引入了Rwhois[3]协议，以增强Nicname/Whois协议。此目录服务从未得到广泛接受，用于域数据。
Presently, ICANN requires the operation of Nicname/Whois servers by registries and registrars of generic Top-Level Domains (TLD's).
目前，ICANN要求通用顶级域（TLD）的注册机构和注册机构操作Nicname/Whois服务器。
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:
由于最近注册中心和注册中心之间职能职责的分离，域名注册数据的不断滥用和数据挖掘，以及Nicname/Whois输出的机器可读性方面的困难，创建参考LDAP服务的动机如下：
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 使用目录协议固有的机制将客户机从注册表中对特定域的查询转介到注册器中相应目录服务中的相应域。
o Limit access to domain data based on authentication of the client.
o 基于客户端的身份验证限制对域数据的访问。
o Provide structured queries and well-known and structured results.
o 提供结构化查询和众所周知的结构化结果。
o Use a directory service technology already in general use.
o 使用已普遍使用的目录服务技术。
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.
根据这些通用标准，选择LDAP[5]作为此目录服务的协议。还决定将LDAP的使用限制在常见实现中最容易获得的功能上。因此，我们的目标是不定义任何新的对象类、语法或匹配规则。
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.
该实验成功地探索了在这种环境下如何使用LDAP，并演示了操作服务所需的定制级别。第6节概述了本实验的结论和观察结果。
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.
TLD：顶级域。指域名系统中根目录下的域名。这个实验使用TLD的.com、.net、.org和.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".
SLD：二级域。指域名系统中TLD下方的域名。这种域名的一个例子是“example.com”。
DIT: Directory Information Tree. One of many hierarchies of data entries in an LDAP server.
目录信息树。LDAP服务器中许多数据项的层次结构之一。
DN: Distinguished Name. The unique name of an entry in a DIT.
DN：可分辨名称。DIT中条目的唯一名称。
cn: common name. See RFC 2256 [7].
cn：通用名称。见RFC 2256[7]。
dc: domain component. See RFC 2247 [4].
dc：域组件。见RFC 2247[4]。
uid: user id. See RFC 2798 [9].
uid：用户id。请参阅RFC 2798[9]。
The service is composed of three distinct server types: a registry LDAP server, registrar LDAP servers, and registrant LDAP servers.
该服务由三种不同的服务器类型组成：注册LDAP服务器、注册LDAP服务器和注册LDAP服务器。
The registry LDAP server contains three Directory Information Trees (DIT's).
注册表LDAP服务器包含三个目录信息树（DIT）。
o The Top-Level Domain DIT's follow the DNS hierarchy for domains (e.g., dc=foo,dc=com).
o 顶级域DIT遵循域的DNS层次结构（例如，dc=foo，dc=com）。
o The name server DIT allows a view of the name servers, many of which serve multiple domains.
o 名称服务器DIT允许查看名称服务器，其中许多服务器服务于多个域。
o The registrar-referral DIT provides referrals from the registry into the respective TLD DIT of the registrars (on a TLD basis).
o 注册商转介DIT提供从注册中心到注册商各自TLD DIT的转介（基于TLD）。
The registrar LDAP server contains two types of DIT's.
注册器LDAP服务器包含两种类型的DIT。
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 TLD DIT遵循域的DNS层次结构（例如，dc=foo，dc=com），并与注册表的TLD DIT并行。
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.
o 名称服务器和联系人DIT允许查看名称服务器和联系人，其中许多服务器和联系人关联并服务于多个域。
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.
注册者LDAP服务器的DIT或架构没有任何规范。从注册服务器到注册服务器的转介仅用于允许注册人直接控制与特定域相关的额外管理信息。
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.
此服务的访问控制只是使用可分辨名称（DN）和密码的演示。如果注册机构和注册机构统一采用LDAP作为传播域注册数据的手段，则需要根据每种类型的用户群对这些DN进行标准化。
The registry TLD DIT has the following structural hierarchy:
注册表TLD DIT具有以下结构层次结构：
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 )
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
图1：注册表DIT概述
The root of a TLD DIT is an entry of objectclass domain as specified by RFC 2247 [4] and represents a top-level domain.
TLD DIT的根是RFC 2247[4]指定的objectclass域的条目，表示顶级域。
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.
DIT的第二层表示二级域。这些条目中的每个条目都属于RFC 2247[4]指定的objectclass域。这些条目上的description属性通常包含描述性文本，给出注册这些域的注册者的名称。
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
第三层包含特定于每个二级域的条目。名称服务器条目属于RFC 2307[8]指定的对象类ipHost。这些名称服务器条目的可分辨名称是通过算法计算的，其中第一个组件是单词
"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.
“nameserver”与名称服务器条目的索引号连接，其余组件是相应的域名。没有将名称服务器项的值与可能分配给它的索引相关联的规范，除非它是唯一的且与客户端会话一致。这一层还包含从登记处到登记处的转介。此引用是对相应注册器LDAP服务器中的条目的直接引用，对应于此DIT中引用所属的域名。
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:
由于此DIT中包含大量条目，因此只允许某些类型的搜索。允许任何可通过LDAP表达的搜索将导致昂贵的搜索，而对于一个公开可用的服务来说，这将是非常昂贵的。可进行的搜查如下：
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 基于DIT根目录的一级范围搜索。dc属性上允许子字符串匹配，但子字符串长度必须至少为3个字符。
o Base search based at the root of the DIT.
o 基于DIT根目录的基本搜索。
o Base, one-level, and sub-tree searches based at any second level domain name (the second tier) and below.
o 基于任何二级域名（第二层）及其以下的基本、一级和子树搜索。
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].
注册表TLD DIT只有一种访问控制类型。当客户机绑定了DN“cn=trademark”和密码“authority”时，第二级域条目也会采用objectclass的extensibleObject，并添加了属性“createddate”和“registrationexpirationdate”，这是RFC 2252[6]指定的广义时间类型。
The registry name server DIT has the following structural hierarchy:
注册表名服务器DIT具有以下结构层次结构：
(o=nsiregistry.com)
|
|
-------------------------------------
| | |
name server name server name server
(cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org)
(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
图2：注册表DIT概述
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.
名称服务器DIT的根目录是RFC 1617[2]指定的objectclass组织的条目。它除了作为DIT的根之外没有其他意义。
The second tier of this DIT represents name servers. Each of these entries is of objectclass ipHost, as specified by RFC 2307 [8].
此DIT的第二层表示名称服务器。根据RFC 2307[8]的规定，这些条目中的每个条目都属于对象类ipHost。
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:
由于此DIT中包含大量条目，因此只允许某些类型的搜索。允许任何可通过LDAP表达的搜索将导致搜索对于公开可用的服务来说过于昂贵。可进行的搜查如下：
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 如果在cn属性上提供了筛选器，则基于DIT的根进行一级和子树范围的搜索。
o Base search based at the root of the DIT.
o 基于DIT根目录的基本搜索。
o Base, one-level, and sub-tree searches based at any name server entry.
o 基于任何名称服务器条目的基本、一级和子树搜索。
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
(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
图3：注册表引用DIT概述
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.
注册器引用DIT的根目录是对象类组织的条目，如RFC 1617[2]所指定。它除了作为这个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].
此DIT的第二层表示顶级域。根据RFC 2247[4]的规定，这些条目中的每一个都属于objectclass域。
Underneath each TLD entry, the third tier contains referrals to the appropriate TLD DIT of each registrar.
在每个TLD条目下面，第三层包含对每个注册器的适当TLD DIT的引用。
The registrar TLD DIT, which is similar to the registry TLD DIT, has the following structural hierarchy:
注册商TLD DIT类似于注册商TLD DIT，具有以下结构层次结构：
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 )
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
图4：注册器DIT概述
The root of a TLD DIT is an entry of objectclass domain, as specified by RFC 2247 [4] and represents a top-level domain.
TLD DIT的根是由RFC 2247[4]指定的objectclass域的条目，表示顶级域。
The second tier of the DIT represents second-level domains. Each of these entries is of objectclass domain, as specified by RFC 2247 [4].
DIT的第二层表示二级域。根据RFC 2247[4]的规定，这些条目中的每一个都属于objectclass域。
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 按照RFC 2307[8]的规定，名称服务器条目属于对象类ipHost。这些名称服务器项的可分辨名称通过算法计算，其中第一个组件是单词“nameserver”，与名称服务器项的索引号连接，其余组件是适当的域名。没有将名称服务器项的值与可能分配给它的索引相关联的规范，除非它是唯一的且与客户端会话一致。
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 根据RFC 2798[9]的规定，联系人条目属于对象类inetOrgPerson。通过算法计算这些联系人条目的可分辨名称，其中第一个组件是单词“contact”，与联系人的索引号连接，其余组件是适当的域名。联系人条目的值与可能分配给它的索引之间没有相关的规范，除非它是唯一的且与客户端会话一致。条目的description属性包含联系人与域相关的角色。这些角色被标识为“管理员联系人”、“技术联系人”和“账单联系人”，可以以任何顺序出现。
o Finally, this third tier contains the referral from the registrar to the registrant.
o 最后，第三层包含注册人向注册人的转介。
The fourth tier only contains name server contact entries. These entries are of objectclass inetOrgPerson, as specified by RFC 2798 [9].
第四层仅包含名称服务器联系人条目。这些条目属于RFC 2798[9]指定的对象类inetOrgPerson。
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:
由于此DIT中包含大量条目，因此只允许某些类型的搜索。允许任何可通过LDAP表达的搜索将导致搜索对于公开可用的服务来说过于昂贵。可进行的搜查如下：
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 基于DIT根目录的一级范围搜索。dc和o属性上允许子字符串匹配，但子字符串长度必须至少为3个字符。
o Base search based at the root of the DIT.
o 基于DIT根目录的基本搜索。
o Base, one-level, and sub-tree searches based at any second level domain name (the second tier) and below.
o 基于任何二级域名（第二层）及其以下的基本、一级和子树搜索。
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 second-level domain entries for which the bind DN has a relation are visible.
注册器TLD DIT有两种访问控制类型。当匿名绑定时，客户端只看到二级域条目的dc、o和c属性。当客户端绑定DN为“cn=trademark”且密码为“律师”时，objectclass域条目上通常可用的所有其他属性（如果它们具有值）都是可见的。此外，如果客户端使用联系人的DN和密码“password”绑定，则绑定DN具有关系的二级域条目的所有属性都可见。
The registrar name server and contact DIT has the following structural hierarchy:
注册器名称服务器和联系人DIT具有以下结构层次结构：
(o=nsi.com)
|
|
--------------------------------------
| |
Contacts Name Servers
(ou=contacts) (ou=name servers)
| |
----------------- ------------------------
| | | | | |
Contact : : Name Server : :
(uid=handle) : : (cn=handle) : :
|
Name Server
Contact
(cn=contact1)
(o=nsi.com)
|
|
--------------------------------------
| |
Contacts Name Servers
(ou=contacts) (ou=name servers)
| |
----------------- ------------------------
| | | | | |
Contact : : Name Server : :
(uid=handle) : : (cn=handle) : :
|
Name Server
Contact
(cn=contact1)
Figure 5: Registrar DIT Overview
图5：注册器DIT概述
The first tier of the name server and contact DIT is an entry of objectclass organization, as specified by RFC 1617 [2].
名称服务器和联系人DIT的第一层是对象类组织的条目，如RFC 1617[2]所指定。
The second tier of the DIT contains two entries, each of which is of objectclass organizationalUnit, as specified by RFC 2256 [7]. One entry represents the part of the DIT containing contacts and the other entry represents the part of the DIT containing name servers.
DIT的第二层包含两个条目，每个条目都是由RFC 2256[7]指定的objectclass organizationalUnit。一个条目表示包含联系人的DIT部分，另一个条目表示包含名称服务器的DIT部分。
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.
contacts organizationalUnit条目下的条目属于对象类inetOrgPerson，表示向注册器注册的联系人。它们的RDN由uid属性组成。uid属性的值是注册器分配的唯一标识符或句柄。
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.
name server organizationalUnit条目下面的条目属于objectclass ipHost，表示注册到注册器的名称服务器。它们的RDN由cn属性组成。cn属性的值是注册器分配的唯一标识符或句柄。每个名称服务器条目可以选择性地具有objectclass inetOrgPerson的子条目。这些条目表示它们所属的名称服务器的联系人。
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:
由于此DIT中包含大量条目，因此只允许某些类型的搜索。允许任何可通过LDAP表达的搜索将导致搜索对于公开可用的服务来说过于昂贵。可进行的搜查如下：
o One-level and base searches at the root of the DIT.
o 在DIT的根目录下进行一级和基本搜索。
o Sub-tree searches at the root of the DIT using cn and uid attributes as a filter.
o 使用cn和uid属性作为筛选器在DIT的根目录下进行子树搜索。
o Base searches at either entry of the second tier.
o 在第二层的任意一个条目上进行基本搜索。
o One-level and sub-tree searches at either entry of the second tier, using cn or uid attributes as a filter.
o 使用cn或uid属性作为筛选器，在第二层的任一条目上进行一级和子树搜索。
o Base, one-level, and sub-tree searches based at any contact or name server entry and below.
o 基于任何联系人或姓名服务器条目及其以下的基本、一级和子树搜索。
Early scoping and analysis of this project were based on the use of output from command line clients, specifically the "ldapsearch" command present with many implementations of LDAP servers. Our survey of this tool, available from many vendors, showed that referral chasing was difficult to control or predict, and the behavior between these implementations with respect to referral chasing was inconsistent.
该项目的早期范围界定和分析基于使用命令行客户端的输出，特别是许多LDAP服务器实现中的“ldapsearch”命令。我们对该工具的调查（可从许多供应商处获得）表明，转介追踪很难控制或预测，而且这些实现之间关于转介追踪的行为不一致。
Based on the limited nature of the expressive capabilities present with just command line tools, searches involving nested queries or advanced referral chasing were deemed the domain of clients making direct use of LDAP client libraries. Three of these types of clients were produced: a web-based client, a cross-platform C-based client, and a Java client. No significant deficiencies or problems were found with the LDAP client libraries in the construction of these clients, and the level of control provided by their programming interfaces was adequate to create the necessary searches. Instead, most of the problems encountered with these clients were based on usability concerns.
基于仅使用命令行工具的表达能力的有限性，涉及嵌套查询或高级查询的搜索被认为是直接使用LDAP客户端库的客户端的领域。产生了其中三种类型的客户机：基于web的客户机、基于跨平台C的客户机和Java客户机。在构建这些客户端时，未发现LDAP客户端库存在重大缺陷或问题，并且其编程接口提供的控制级别足以创建必要的搜索。相反，这些客户端遇到的大多数问题都是基于可用性方面的考虑。
It was found that the web-based client caused a great amount of confusion for users not familiar with LDAP or Nicname/Whois with respect to the underlying technology and the network model. Thus, many users believed the web-based client to be the only interface to the data and were unaware or confused by the intermediate LDAP protocol. In addition, it was difficult to express to users the
发现基于web的客户端给不熟悉LDAP或Nicname/Whois的用户在底层技术和网络模型方面造成了大量混乱。因此，许多用户认为基于web的客户端是数据的唯一接口，并且不知道中间LDAP协议或对其感到困惑。此外，很难向用户表达
registry-registrar-registrant service model in adequate terms from search results where the results could be rendered properly among the various common web browsers.
registry Registrator registrant服务模型充分利用搜索结果，结果可以在各种常见web浏览器中正确呈现。
Both the C and Java based clients were built to be both graphical and cross-platform (in the case of the C-based client, the Linux and Windows platforms were chosen as targets). The LDAP client libraries chosen for both clients proved to be quite capable and offered the necessary levels of control for conducting nested queries and advanced referral chasing. Expectations at the outset for construction of both clients, based on past experience, were that the C-based client would not only perform better than the Java client but also have a better appearance. In reality, these assumptions were incorrect as there was no perceivable difference in performance and the look of the Java client was often considered to be far superior to its counter-part. In addition, the Java client required much less time to create. Both clients are available under the terms of an open source license. Though it is impossible to have accurate measurements of their popularity, through monitoring and feedback it was perceived that the web-based client had far greater use.
基于C和Java的客户端都是图形化和跨平台的（在基于C的客户端中，Linux和Windows平台被选为目标）。为这两个客户机选择的LDAP客户机库被证明是非常有能力的，并且为执行嵌套查询和高级查询提供了必要的控制级别。基于过去的经验，在开始构建这两个客户机时，人们期望基于C的客户机不仅比Java客户机性能更好，而且外观也更好。事实上，这些假设是不正确的，因为在性能上没有明显的差异，Java客户机的外观通常被认为远远优于它的对手。此外，Java客户机所需的创建时间要少得多。这两个客户端都是根据开源许可证的条款提供的。虽然不可能准确地衡量他们的受欢迎程度，但通过监控和反馈，人们认为基于web的客户端的使用率要高得多。
Based on the experience of piloting this experimental service, feedback from users of the service, and general comments and observations of current and common opinions, the following items have been noted.
根据试点这项试验性服务的经验、服务用户的反馈以及对当前和常见意见的一般评论和观察，注意到以下事项。
Original analysis of the data set to be used revealed a high degree of relationships between name servers, contacts, and domains. Storing the data in non-normalized form according to the DIT outlined in this document would make an original relational dataset of roughly 20 million objects explode to over 115 million objects.
对要使用的数据集的原始分析揭示了名称服务器、联系人和域之间的高度关系。根据本文概述的DIT以非规范化形式存储数据将使一个包含大约2000万个对象的原始关系数据集爆炸到超过1.15亿个对象。
To combat this problem, the first pass at defining the DIT's made heavy use of referrals between the TLD DIT's and the name server and contact DIT's. The use of the 'alias' objectclass was considered but ruled out in hopes of using referrals for load balancing across servers (i.e., placing each TLD DIT on a separate server, and separate servers for the name server and contact DIT's). However, initial testing with the 'ldapsearch' command found inconsistencies with the interpretation of the referrals and how they were managed. Not only were the results inconsistent between implementations, but many of these clients would easily get caught in referral loops.
为了解决这个问题，定义DIT的第一步大量使用TLD DIT和名称服务器之间的引用，并联系DIT。考虑了使用“alias”objectclass，但排除了使用它的可能性，希望通过引用实现服务器间的负载平衡（即，将每个TLD DIT放在单独的服务器上，并将名称服务器和联系DIT的服务器分开）。然而，使用“ldapsearch”命令进行的初步测试发现，对转介的解释和管理方式不一致。不仅实现之间的结果不一致，而且这些客户机中的许多都很容易陷入引用循环。
The final solution to the problem was to create a customized back-end data store containing the data in a normalized form. This gave the client the appearance of having a non-normalized data set which required no intra-server referrals. Aliases may have been a better solution, however our interpretation of their output with implementations of the 'ldapsearch' tool was not satisfactory. It was also later learned that some LDAP server implementations place certain restrictions on aliases that would have conflicted with our overall DIT structure. In the end, it was felt that a customized back-end would be required by any server with a large data-set, but smaller data-sets for less populated domains could easily use off-the-shelf implementations.
该问题的最终解决方案是创建一个定制的后端数据存储，其中包含规范化形式的数据。这给了客户端一种不需要服务器内部引用的非规范化数据集的外观。别名可能是一个更好的解决方案，但是我们使用“ldapsearch”工具对其输出的解释并不令人满意。后来还了解到，一些LDAP服务器实现对别名设置了某些限制，这些限制可能与我们的整体DIT结构相冲突。最后，有人认为，任何具有大型数据集的服务器都需要定制的后端，但对于人口较少的域，较小的数据集可以很容易地使用现成的实现。
The modeling of the overall service to provide the split in operational responsibility between registry and registrar required the use of referrals (i.e., the two servers would not be operated by the same organization, therefore would most likely not co-exist on the same physical machine or network). The chief problem with LDAP referrals returned for this purpose grew out of the need to limit data returned to the client and the priority given to referrals. It was quite easy to cause a sub-tree query at certain levels, for instance a TLD level, to return nothing but referrals. This was true because referrals would be returned out of the scope of the supplied search filter and therefore would fill the result set to its limit, normally set to 50 entries.
为在登记处和登记处之间划分业务责任而对整个服务进行建模需要使用转介（即，两台服务器不会由同一组织操作，因此很可能不会在同一台物理机器或网络上共存）。为此目的返回的LDAP引用的主要问题源于需要限制返回给客户端的数据以及对引用的优先级。很容易导致特定级别（例如TLD级别）的子树查询只返回引用。这是正确的，因为引用将返回到所提供的搜索筛选器范围之外，因此将填充结果集到其限制，通常设置为50个条目。
In certain use cases, a result set with nothing but referrals was desired (e.g., o=tlds). However, even in these cases it was possible for some referrals to not be returned due to the size limit. In this case, it was felt that a result set of 50 referrals, the default for the size limit in most cases, was too large for any practical use by a client and was a failing of query distribution in general rather than a limitation of LDAP.
在某些用例中，需要一个只包含引用的结果集（例如，o=TLD）。然而，即使在这些情况下，由于大小限制，也有可能无法返回一些推荐。在本例中，有人认为50个引用的结果集（大多数情况下是大小限制的默认值）对于客户端的任何实际使用来说都太大了，这通常是查询分发的失败，而不是LDAP的限制。
Because of the nature of software development, the graphical and web clients were developed after the development of the server software. The 'ldapsearch' client was used for testing and development during server software creation. It was not until the creation of more advanced clients that it was discovered that the design decision of uniform DIT naming should have been made. Technically, this would have allowed for slightly better software modularization and re-use. In addition, the use of a company name in the DIT structure did not allow the easy integration of another domain registry, as in the registry-registrar model. Not only would clients have to be
由于软件开发的性质，图形和web客户端是在服务器软件开发之后开发的。“ldapsearch”客户端用于服务器软件创建期间的测试和开发。直到创建了更高级的客户端，人们才发现应该做出统一DIT命名的设计决策。从技术上讲，这将允许稍微更好的软件模块化和重用。此外，在DIT结构中使用公司名称不允许像在registry Registrator模型中那样轻松集成另一个域注册表。不仅客户必须是
reconfigured for each new registry operator, but this would most likely have social implications as well.
为每个新的注册操作员重新配置，但这很可能也会产生社会影响。
The construction of the clients revealed yet another misconception. Though this project used a generic directory service technology, the clients required a high-degree of algorithmic knowledge about the DIT structure and schemas being used. The graphical clients could not be used against an LDAP service with another DIT or schema. Therefore, a generic or universal client, one that could be used for all LDAP applications, would either not be able to make full use of the data provided by the service or would be far too complex for operation by the average user.
客户的构造揭示了另一个误解。尽管该项目使用了一种通用目录服务技术，但客户机需要关于所使用的DIT结构和模式的高度算法知识。无法针对具有其他DIT或架构的LDAP服务使用图形客户端。因此，可以用于所有LDAP应用程序的通用或通用客户机可能无法充分利用服务提供的数据，或者对于普通用户来说过于复杂。
The network model for this service was divided into three tiers: registry, registrar, and registrant. Despite this, all searches needed to start at the registry level causing overhead for searches that could be targeted at a select tier. This service did not implement a solution to this problem, such as using SRV and/or NAPTR records in DNS to allow a client to find a responsible LDAP server.
此服务的网络模型分为三层：注册中心、注册中心和注册人。尽管如此，所有搜索都需要从注册表级别开始，这会导致针对选定层的搜索的开销。此服务未实现此问题的解决方案，例如在DNS中使用SRV和/或NAPTR记录以允许客户端查找负责的LDAP服务器。
Section 3.1.2 and Section 4.1.2 describe the searches allowed by this service. However, the most common question asked by users of the service revolved around getting around these restrictions. Because browsing at the TLD level was not permitted, many users asked about the feasibility of using recursive dictionary queries to circumvent the search restrictions.
第3.1.2节和第4.1.2节描述了该服务允许的搜索。然而，该服务用户最常见的问题是绕过这些限制。由于不允许在TLD级别浏览，许多用户询问使用递归字典查询来规避搜索限制的可行性。
It should be noted that many operators of Nicname/Whois server consider this practice to be data mining and often refer to it specifically as a dictionary attack.
应该注意的是，Nicname的许多运营商/ WHOIS服务器认为这种做法是数据挖掘，通常指的是字典攻击。
There are no applicable IANA considerations presented in this document.
本文件中没有适用的IANA注意事项。
The domain administrative data in this service did not cover Internationalized Domain Names (IDN's).
此服务中的域管理数据不包括国际化域名（IDN）。
This experiment did not endeavor to use security mechanisms beyond those readily available in LDAP [5]. Section 3.1.3 and Section 4.1.3 describe the various access controls used within the scope of the defined security mechanisms. While these mechanisms were adequate for this experimental deployment, they would not be adequate for a production environment, and they should not be taken as a model for those contemplating deployment on the Internet.
这个实验并没有试图使用LDAP中可用的安全机制之外的安全机制[5]。第3.1.3节和第4.1.3节描述了定义的安全机制范围内使用的各种访问控制。虽然这些机制对于这个实验性部署来说已经足够了，但是对于生产环境来说，它们是不够的，并且不应该将它们作为那些考虑在互联网上部署的人的模型。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
[1] K.Harrenstien，Stahl，M.和E.Feinler，“NICNAME/WHOIS”，RFC 954，1985年10月。
[2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and Structuring Guidelines for X.500 Directory Pilots", RFC 1617, May 1994.
[2] Barker，P.，Kille，S.和T.Lenggenhager，“X.500目录飞行员的命名和结构指南”，RFC 1617，1994年5月。
[3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, June 1997.
[3] Williamson，S.，Kosters，M.，Blacka，D.，Singh，J.和K.Zeilstra，“转诊Whois（RWhois）协议V1.5”，RFC 2167，1997年6月。
[4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, January 1998.
[4] Kille，S.，Wahl，M.，Grimstad，A.，Huber，R.和S.Sataluri，“使用LDAP/X.500可分辨名称中的域”，RFC 2247，1998年1月。
[5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[5] Wahl，M.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[6] Wahl，M.，Coulbeck，A.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）：属性语法定义”，RFC2252，1997年12月。
[7] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
[7] Wahl，M.，“与LDAPv3一起使用的X.500（96）用户模式摘要”，RFC 2256，1997年12月。
[8] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998.
[8] Howard，L.，“使用LDAP作为网络信息服务的方法”，RFC 2307，1998年3月。
[9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, April 2000.
[9] Smith，M.，“inetOrgPerson LDAP对象类的定义”，RFC 2798，2000年4月。
In addition to the deployment of servers and development of clients, VeriSign conducted two sub-projects related to this experiment.
除了部署服务器和开发客户机之外，VeriSign还进行了两个与此实验相关的子项目。
The first project was a Nicname/Whois-to-LDAP gateway. The goal of the project was to create an LDAP server for use by registrars to deploy in front of their Nicname/Whois servers. This gateway would take LDAP requests, translate them to Nicname/Whois requests, issue the request to a specific Nicname/Whois server deployed on port 43, interpret the response, and return LDAP result sets. Because of the unspecified nature of Nicname/Whois result sets, the gateway was programmed to specifically recognize only the output of three distinct registrars. While this gateway proved valuable enough to allow domain lookups and limited searches, it was unable to provide consistent contact lookups, nameserver lookups, or registrant referrals. This software was also made publicly available under the terms of an open source license.
第一个项目是Nicname/Whois到LDAP网关。该项目的目标是创建一个LDAP服务器，供注册商在其Nicname/Whois服务器前部署使用。此网关将接收LDAP请求，将其转换为Nicname/Whois请求，向部署在端口43上的特定Nicname/Whois服务器发出请求，解释响应，并返回LDAP结果集。由于Nicname/Whois结果集的未指定性质，网关编程为仅识别三个不同注册器的输出。虽然该网关被证明具有足够的价值，可以进行域查找和有限的搜索，但它无法提供一致的联系人查找、名称服务器查找或注册人推荐。该软件还根据开放源代码许可证的条款公开提供。
The second project was an informal survey of registrants with deployed LDAP servers. This was conducted by using the com, net, org, and edu zone files and testing for the existence of an LDAP server on port 389 using the name of the domain, a host named "ldap" in the domain, and a host named "dir" in the domain (e.g., "foo.com", "ldap.foo.com", and "dir.foo.com"). This survey did not attempt to resolve LDAP services using SRV records in DNS.
第二个项目是对部署了LDAP服务器的注册者进行非正式调查。这是通过使用com、net、org和edu区域文件进行的，并使用域名称、域中名为“LDAP”的主机和域中名为“dir”的主机（例如，“foo.com”、“LDAP.foo.com”和“dir.foo.com”）测试端口389上是否存在LDAP服务器。此调查未尝试使用DNS中的SRV记录解析LDAP服务。
The result of this survey found that roughly 0.5% of active domains had an LDAP server. By profiling a server's root DSA-specific Entry (DSE), the survey found that about 90% of the servers were implementations provided by vendor A, 9% of the servers were implementations provided by vendor B, and 1% of the servers were implementations provided by other vendors. Of the servers queried that were determined to be implementations provided by vendor A, it appeared that about only 10% contained public data (this also led to the assumption that the other 90% were not intended to be publicly queried). Of the servers queried that were determined to be implementations provided by vendor B, it appears that nearly all contained public data.
这项调查的结果发现，大约0.5%的活动域具有LDAP服务器。通过分析服务器的根DSA特定条目（DSE），调查发现约90%的服务器是由供应商a提供的实现，9%的服务器是由供应商B提供的实现，1%的服务器是由其他供应商提供的实现。在确定为供应商A提供的实现的被查询服务器中，似乎只有10%包含公共数据（这也导致了另外90%不打算被公开查询的假设）。在确定为供应商B提供的实现的查询服务器中，似乎几乎所有服务器都包含公共数据。
Significant analysis, design, and implementation for this project were conducted by Brad McMillen, David Blacka, Anna Zhang, and Michael Schiraldi. Mark Kosters and Leslie Daigle provided guidance by reviewing this project, the project's goals, and this document.
该项目的重要分析、设计和实施由Brad McMillen、David Black、Anna Zhang和Michael Schiraldi进行。Mark Kosters和Leslie Daigle通过审查本项目、项目目标和本文件提供了指导。
Author's Address
作者地址
Andrew Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
Andrew Newton VeriSign，Inc.美国弗吉尼亚州斯特林Ridgetop Circle 21345，邮编20166
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; anewton@ecotroph.net
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; anewton@ecotroph.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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.
RFC编辑功能的资金目前由互联网协会提供。