RFC3663 日本語訳
3663 Domain Administrative Data in Lightweight Directory AccessProtocol (LDAP). A. Newton. December 2003. (Format: TXT=42260 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Newton Request for Comments: 3663 VeriSign, Inc. Category: Experimental December 2003
コメントを求めるワーキンググループA.ニュートンの要求をネットワークでつないでください: 3663年のベリサインInc.カテゴリ: 実験的な2003年12月
Domain Administrative Data
in Lightweight Directory Access Protocol (LDAP)
ライトウェイト・ディレクトリ・アクセス・プロトコルのドメインの管理データ(LDAP)
Status of this Memo
この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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(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.
ドメインの取得データは管理目的のためのNicname/Whoisを通して一般に通常暴露されました。 このドキュメントはReferralライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)サービス(ドメインの管理データを利用可能にするのにLDAPとよく知られるLDAPタイプを使用する実験的なサービス)について説明します。
Newton Experimental [Page 1] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[1ページ]RFC3663のドメインの管理データ
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 ドメインの取得データ. . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2のための歴史的なディレクトリサービス。 動機。 . . . . . . . . . . . . . . . . . . . . . . 3 1.3. 略語は.4 2を使用しました。 記述を修理してください。 . . . . . . . . . . . . . . . . . . . . . 4 3. 登録LDAPサービス。 . . . . . . . . . . . . . . . . . . . . 6 3.1. TLDデイット。 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. デイット構造。 . . . . . . . . . . . . . . . . . 6 3.1.2. 検索. . . . . . . . . . . . . . . . 7 3.1は.3に許されました。 コントロール. . . . . . . . . . . . . . . . . 7 3.2にアクセスしてください。 ネームサーバデイット。 . . . . . . . . . . . . . . . . . . . . 8 3.2.1. デイット構造。 . . . . . . . . . . . . . . . . . 8 3.2.2. 検索. . . . . . . . . . . . . . . . 8 3.3を許しました。 記録係紹介デイット. . . . . . . . . . . . . . . . . 9 3.3.1。 デイット構造。 . . . . . . . . . . . . . . . . . 9 4. 記録係LDAPは.104.1を修理します。 TLDデイット。 . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. デイット構造。 . . . . . . . . . . . . . . . . . 10 4.1.2. 検索. . . . . . . . . . . . . . . . 11 4.1は.3に許されました。 コントロール. . . . . . . . . . . . . . . . . 11 4.2にアクセスしてください。 ネームサーバと連絡デイット。 . . . . . . . . . . . . . . 12 4.2.1. デイット構造。 . . . . . . . . . . . . . . . . . 12 4.2.2. 検索. . . . . . . . . . . . . . . . 13 5を許しました。 クライアント。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. レッスンは学びました。 . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. イントラサーバ紹介. . . . . . . . . . . . . . . . . 14 6.2。 相互サーバ紹介. . . . . . . . . . . . . . . . . 15 6.3。 一般的なデイット. . . . . . . . . . . . . . . . . . . . . . . 15 6.4。 普遍的なクライアント. . . . . . . . . . . . . . . . . . . . 16 6.5。 狙いは層. . . . . . . . . . . . . . . 16 6.6のそばで探されます。 データマイニング。 . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 16 8. 国際化問題。 . . . . . . . . . . . . . 16 9. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 17 10. 知的所有権声明。 . . . . . . . . . . . . . . . 17 11. 引用規格. . . . . . . . . . . . . . . . . . . . . 18付録A.他の仕事。 . . . . . . . . . . . . . . . . . . . . . 19 付録B.承認. . . . . . . . . . . . . . . . . . . 19作者のアドレスの.20の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 21
Newton Experimental [Page 2] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[2ページ]RFC3663のドメインの管理データ
1. Introduction
1. 序論
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.
このドキュメントは、使用のためのReferralライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)サービス、LDAPの使用について調査するためにベリサインInc.によって始められた実験的な計画、およびLDAP関連の技術を管理ドメインの取得情報のディレクトリサービスと説明します。
1.1. Historical Directory Services for Domain Registration Data
1.1. ドメインの取得データのための歴史的なディレクトリサービス
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.
InterNICにおいて当初の科学基金契約はドメインの取得データと情報の管理必要性のために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はジェネリックTop-レベルDomains(TLDのもの)の登録と記録係によるNicname/Whoisサーバの操作を必要とします。
1.2. Motivations
1.2. 動機
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出力のマシン読み易さにおける困難のために、Referral LDAP Serviceの作成には、以下の動機がありました:
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の使用を一般的な実装で容易に最も利用可能な特徴に制限するのを決定をしました。 したがって、目標は、どんな新しいオブジェクトのクラス、構文も定義しないように設定されたか、または規則を合わせたことです。
Newton Experimental [Page 3] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[3ページ]RFC3663のドメインの管理データ
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に概説されています。
1.3. Abbreviations Used
1.3. 使用される略語
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サーバのデータエントリーの多くの階層構造の1つ。
DN: Distinguished Name. The unique name of an entry in a DIT.
DN: 分類名。 DITのエントリーのユニークな名前。
cn: common name. See RFC 2256 [7].
cn: 一般名。 RFC2256[7]を見てください。
dc: domain component. See RFC 2247 [4].
dc: ドメインコンポーネント。 RFC2247[4]を見てください。
uid: user id. See RFC 2798 [9].
uid: ユーザイド。 RFC2798[9]を見てください。
2. Service Description
2. サービス記述
The service is composed of three distinct server types: a registry LDAP server, registrar LDAP servers, and registrant LDAP servers.
サービスは3つの異なったサーバタイプで構成されます: 登録LDAPサーバ、記録係LDAPサーバ、および記入者LDAPサーバ。
The registry LDAP server contains three Directory Information Trees (DIT's).
登録LDAPサーバは3ディレクトリ情報Trees(DITのもの)を含んでいます。
o The Top-Level Domain DIT's follow the DNS hierarchy for domains
(e.g., dc=foo,dc=com).
o Top平らなDomain DITのものはドメイン(例えば、dc=foo、dc=com)へのDNS階層構造に従います。
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ベースの)のそれぞれのTLD DITに供給します。
Newton Experimental [Page 4] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[4ページ]RFC3663のドメインの管理データ
The registrar LDAP server contains two types of DIT's.
記録係LDAPサーバはDITの2つのタイプを含んでいます。
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はドメイン(例えば、dc=foo、dc=com)へのDNS階層構造に従って、登録の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.
このサービスのためのアクセスコントロールは単にDistinguished Name(DN)とパスワードを使用するデモンストレーションです。 登録と記録係がドメインの取得データを広める手段として一様にLDAPを採用するなら、これらのDNの規格化は、それぞれのタイプのユーザベースに基づいて引き受けられる必要があるでしょう。
Newton Experimental [Page 5] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[5ページ]RFC3663のドメインの管理データ
3. Registry LDAP Service
3. 登録LDAPサービス
3.1. TLD DIT
3.1. TLDデイット
3.1.1. DIT Structure
3.1.1. デイット構造
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(例えばdcはネットと等しいです)| | ------------------------------------- | | SLD(例えば、dc=foo、dc=ネット)SLD(例えばdcはバーと等しく、dcはネットと等しいです)| | --------------------- --------------------- | | | | | | ネームサーバ| | ネームサーバ| | (| | (| | | 例えば、cn=nameserver1、| | cn=nameserver1、| dc=foo、dc=ネット)| 例えば、| dc=バー、dc=ネット) | | | | | | ネームサーバ| ネームサーバ| (| (| 例えば、cn=nameserver2、| cn=nameserver2、| dc=foo、dc=ネット)| 例えば、dc=バー、dc=ネット) | | | 記録係紹介記録係紹介(例えば(例えば、cn=記録係、cn=記録係(dc=foo)dc=ネット)、dc=バー、dc=ネット)
Figure 1: Registry DIT Overview
図1: 登録デイット概要
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の根は、指定されるとしてのRFC2247[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の2番目の層はセカンドレベルドメインを表します。 それぞれのこれらのエントリーは指定されるとしてのRFC2247[4]によるobjectclassドメインのものです。 これらのエントリーでの記述属性はしばしばこれらのドメインが登録された記録係の名前を与える説明文を含んでいます。
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
3番目の層は各セカンドレベルドメインに特定のエントリーを含んでいます。 ネームサーバエントリーは指定されるとしてのRFC2307[8]によるobjectclass ipHostのものです。 これらのネームサーバエントリーの分類名は最初のコンポーネントが単語であるところでalgorithmicallyに計算されます。
Newton Experimental [Page 6] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[6ページ]RFC3663のドメインの管理データ
"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.
ネームサーバエントリーの指数で連結された「ネームサーバ」と残っているコンポーネントは適切なドメイン名です。 仕様が全くありません。それがインデックスであるかもしれないのにネームサーバエントリーの値にそれを除いて、割り当てられた関連するのは、クライアントセッションに関してユニークであって、一貫しています。 また、この層は登録から記録係までの紹介を含んでいます。 この紹介は紹介がこのDITで信頼するドメイン名に対応する適切な記録係LDAPサーバにおけるエントリーへのダイレクト紹介です。
3.1.2. Allowed Searches
3.1.2. 許容検索
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 1レベルが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 基地、1レベル、およびどんなセカンドレベルドメイン名(2番目の層)において以下に基づいた下位木検索。
3.1.3. Access Control
3.1.3. アクセス制御
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は1つのアクセスコントロールしかタイプさせません。 また、クライアントが「cnは商標と等しいこと」のDNと「弁護士」に関するパスワードで付くとき、セカンドレベルドメインエントリーはタイプGeneralized Timeにはある"createddate"と"registrationexpirationdate"の加えられた属性があるextensibleObjectのobjectclassを帯びます、RFC2252[6]によって指定されるように。
Newton Experimental [Page 7] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[7ページ]RFC3663のドメインの管理データ
3.2. Name Server DIT
3.2. ネームサーバデイット
3.2.1. DIT Structure
3.2.1. デイット構造
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)| | ------------------------------------- | | | ネームサーバネームサーバネームサーバ(cn=ns1.foo.net)(cn=ns.bar.com)(cn=named.acme.org)
Figure 2: Registry DIT Overview
図2: 登録デイット概要
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の根は指定されるとしてのRFC1617[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の2番目の層はネームサーバを表します。 それぞれのこれらのエントリーはRFC2307[8]によって指定されるようにobjectclass ipHostのものです。
3.2.2. Allowed Searches
3.2.2. 許容検索
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 1レベルと下位木は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 基地、1レベル、およびどんなネームサーバエントリーにも拠点を置く下位木検索。
Newton Experimental [Page 8] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[8ページ]RFC3663のドメインの管理データ
3.3. Registrar Referral DIT
3.3. 記録係紹介デイット
3.3.1. DIT Structure
3.3.1. デイット構造
The registry registrar-referral DIT has the following structural hierarchy:
登録記録係紹介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
(o=tlds)| | ------------------------------- | | | | tld tld tld tld(dcはネットと等しいです)(dc=com)(dc=org)(dc=edu)| | | | : : | : : : | : | --------------------------- | | | 記録係1人の記録係の2記録係n dc=org DIT dc=org DIT dc=org DITへの紹介への紹介への紹介
Figure 3: Registry Referral DIT Overview
図3: 登録紹介デイット概要
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の根はRFC1617[2]によって指定されるようにobjectclass組織のエントリーです。 それには、この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の2番目の層は最上位のドメインを表します。 それぞれのこれらのエントリーはRFC2247[4]によって指定されるようにobjectclassドメインのものです。
Underneath each TLD entry, the third tier contains referrals to the appropriate TLD DIT of each registrar.
それぞれのTLDエントリーの下では、3番目の層はそれぞれの記録係の適切なTLD DITに紹介を保管しています。
Newton Experimental [Page 9] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[9ページ]RFC3663のドメインの管理データ
4. Registrar LDAP Service
4. 記録係LDAPサービス
4.1. TLD DIT
4.1. TLDデイット
4.1.1. DIT Structure
4.1.1. デイット構造
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(例えばdcはネットと等しいです)| | ------------------------------------------------ | | | SLD(例えば、dc=foo、dc=ネット): : | : : --------------------------------------------- | | | | | | (例えば、cn=nameserver1、(例えば、cn=contact1、記入者dc=foo、dc=ネット)dc=foo、dc=ネット)へのネームサーバ接触紹介| | ネームサーバ接触(例えば、cn=接触、cn=nameserver1、dc=foo、dc=ネット)
Figure 4: Registrar DIT Overview
図4: 記録係デイット概要
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の根は、RFC2247[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の2番目の層はセカンドレベルドメインを表します。 それぞれのこれらのエントリーはRFC2247[4]によって指定されるようにobjectclassドメインのものです。
The third tier contains entries specific to each second-level domain. The entries at this level are as follows:
3番目の層は各セカンドレベルドメインに特定のエントリーを含んでいます。 このレベルにおけるエントリーは以下の通りです:
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 ネームサーバエントリーはRFC2307[8]によって指定されるようにobjectclass ipHostのものです。 これらのネームサーバエントリーの分類名は最初のコンポーネントが「ネームサーバ」というネームサーバエントリーの指数で連結された言葉であり、残っているコンポーネントが適切なドメイン名であるところでalgorithmicallyに計算されます。 仕様が全くありません。それがインデックスであるかもしれないのにネームサーバエントリーの値にそれを除いて、割り当てられた関連するのは、クライアントセッションに関してユニークであって、一貫しています。
Newton Experimental [Page 10] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[10ページ]RFC3663のドメインの管理データ
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 接射はRFC2798[9]によって指定されるようにobjectclass inetOrgPersonのものです。 これらの接射の分類名はalgorithmicallyに計算されます、最初のコンポーネントが接触の指数で連結された「接触」と残っているコンポーネントが適切なドメイン名であるという単語であるところで。 仕様が全くありません。それがインデックスであるかもしれないのに接射の値にそれを除いて、割り当てられた関連するのは、クライアントセッションに関してユニークであって、一貫しています。 エントリーの記述属性は接触がドメインに関連する役割を含んでいます。 これらの役割は、「アドミン接触」、「技術連絡担当者」、および「支払窓口」として特定されて、順不同に現れるかもしれません。
o Finally, this third tier contains the referral from the registrar
to the registrant.
o 最終的に、この3番目の層は記録係から記入者までの紹介を含んでいます。
The fourth tier only contains name server contact entries. These entries are of objectclass inetOrgPerson, as specified by RFC 2798 [9].
4番目の層はネームサーバ接射を含むだけです。 これらのエントリーはRFC2798[9]によって指定されるようにobjectclass inetOrgPersonのものです。
4.1.2. Allowed Searches
4.1.2. 許容検索
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 1レベルが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 基地、1レベル、およびどんなセカンドレベルドメイン名(2番目の層)において以下に基づいた下位木検索。
4.1.3. Access Control
4.1.3. アクセス制御
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には、2つのアクセス制御タイプがあります。 匿名で付くとき、クライアントはセカンドレベルドメインエントリーのdc、o、およびc属性を見るだけです。 クライアントが「cnは商標と等しいこと」のDNと「弁護士」に関するパスワードで付くとき、それらに値があるなら、通常、objectclassドメインのエントリーのときに利用可能な他の属性のすべてが目に見えます。 さらに、クライアントが「パスワード」に関する接触とパスワードのDNと共に付くなら、ひものDNが関係を持っているセカンドレベルドメインエントリーへのすべての属性が目に見えます。
Newton Experimental [Page 11] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[11ページ]RFC3663のドメインの管理データ
4.2. Name Server and Contact DIT
4.2. ネームサーバと連絡デイット
4.2.1. DIT Structure
4.2.1. デイット構造
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)| | -------------------------------------- | | Name Servers(=が連絡するou)(ouはネームサーバと等しい)に連絡します。| | ----------------- ------------------------ | | | | | | 接触: : ネームサーバ: : (uid=ハンドル) : : (cn=ハンドル) : : | ネームサーバ接触(cn=contact1)
Figure 5: Registrar DIT Overview
図5: 記録係デイット概要
The first tier of the name server and contact DIT is an entry of objectclass organization, as specified by RFC 1617 [2].
ネームサーバと接触DITの最初の層はobjectclass組織のエントリーです、RFC1617[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の2番目の層は2つのエントリーを含んでいます、RFC2256[7]によって指定されるように。それはそれぞれobjectclass organizationalUnitのものです。 1つのエントリーが接触を含む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.
接触organizationalUnitエントリーの下のエントリーは、objectclass 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.
ネームサーバorganizationalUnitエントリーの下のエントリーは、objectclass ipHostがあって、記録係に登録されたネームサーバを表します。 それらのRDNはcn属性で構成されます。 cn属性の値は、選任された記録係であるユニークな識別子かハンドルです。 それぞれのネームサーバエントリーには、objectclass inetOrgPersonの子供エントリーが任意にあるかもしれません。 これらのエントリーは彼らが信頼するネームサーバの接触を表します。
Newton Experimental [Page 12] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[12ページ]RFC3663のドメインの管理データ
4.2.2. Allowed Searches
4.2.2. 許容検索
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の根での検索を1つ平らにして、基礎づけてください。
o Sub-tree searches at the root of the DIT using cn and uid
attributes as a filter.
o 下位木は、DITの根でフィルタとしてcnとuid属性を使用することで探されます。
o Base searches at either entry of the second tier.
o 2番目の層のエントリーに検索の拠点を置いてください。
o One-level and sub-tree searches at either entry of the second
tier, using cn or uid attributes as a filter.
o 1レベルとcnを使用する2番目の層のエントリーかフィルタとしてのuid属性のどちらかにおける下位木検索。
o Base, one-level, and sub-tree searches based at any contact or
name server entry and below.
o 基地、1レベル、およびどんな接触やネームサーバエントリーにおいて以下に拠点を置いた下位木検索。
5. Clients
5. クライアント
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クライアントライブラリをダイレクトに利用するクライアントのドメインであると考えられました。 これらのタイプの3人のクライアントが生産されました: ウェブベースのクライアント、クロスプラットフォームの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
ウェブベースのクライアントが基本的な技術とネットワークモデルに関してLDAPかNicname/Whoisに詳しくないユーザのために多くの混乱を引き起こしたのが見つけられました。 したがって、多くのユーザが、中間的LDAPプロトコルでウェブベースのクライアントがデータへの唯一のインタフェースであると信じて、気づかなかったか、または混乱させました。 さらに、それはユーザに言い表すのが難しかったです。
Newton Experimental [Page 13] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[13ページ]RFC3663のドメインの管理データ
registry-registrar-registrant service model in adequate terms from search results where the results could be rendered properly among the various common web browsers.
検索からの適切な用語による登録記録係記入者サービスモデルは結果が様々な一般的なウェブブラウザの中で適切にレンダリングされるかもしれないところで結果になります。
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ベースのクライアントの場合では、リナックスとWindowsプラットホームは目標として選ばれた)の両方。 LDAPクライアントライブラリは、かなりできると立証された両方のクライアントに選んで、入れ子にされた質問を行うために必要なレベルのコントロールを提供して、紹介追跡を進めました。 最初にの過去の経験に基づく両方のクライアントの工事への期待はCベースのクライアントがJavaのクライアントよりよく働くだけではなく、より良い外観を持ってもいるだろうということでした。 性能のどんな知覚できる違いもなかったとき、これらの仮定はほんとうは、不正確でした、そして、しばしばJavaのクライアントの外観を対応者よりはるかに優れさせると考えられました。 さらに、Javaのクライアントは作成するはるかに少ない時間を必要としました。 両方のクライアントはオープンソースライセンスに関する諸条件で手があいています。 それらの人気の正確な寸法を持っているのが不可能ですが、モニターとフィードバックで、ウェブベースのクライアントにははるかに大きい使用があったと知覚されました。
6. Lessons Learned
6. レッスンは学びました。
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.
現在で一般的に意見のこの実験的なサービスを操縦する経験、サービスの使用者からの反応、概評、および観測に基づいて、以下の項目は注意されました。
6.1. Intra-Server Referrals
6.1. イントラサーバ紹介
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億1500万個以上のオブジェクトに本書では爆発させるでしょう。
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の接触ところの間で紹介の重い使用をしました。 '別名'objectclassの使用は、ロードバランシングにサーバ(すなわち、ネームサーバのために別々のサーバ、および別々のサーバに各TLD DITを置いて、接触DITのもの)の向こう側に紹介を使用するという望みで考えられましたが、除外されました。 しかしながら、'ldapsearch'コマンドによる初期のテストは紹介とそれらがどう管理されたかに関する解釈で矛盾を見つけました。 結果が実装の間で矛盾していただけではなく、これらのクライアントの多くが紹介輪に容易に捕らえられるでしょう。
Newton Experimental [Page 14] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[14ページ]RFC3663のドメインの管理データ
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構造と衝突した別名に関して、ある制限を課すと学習されました。 結局カスタム設計されたバックエンドがしかし、大きいデータセット、居住されたドメインが容易に使用できた以下のための、より小さいデータセットでどんなサーバによっても必要とされると感じられた、オフである、棚の実装。
6.2. Inter-Server Referrals
6.2. 相互サーバ紹介
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.
登録と記録係の間で操作上の責任に分裂を提供する総合的にサービスのモデルは紹介の使用を必要としました(すなわち、2つのサーバは、同じ組織によって運用されないで、またしたがって、たぶん同じ物理的なマシンかネットワークに共存していないでしょう)。 クライアントに返されたデータを制限する必要性と紹介が優先するのから返す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=tlds)。 しかしながら、これらの場合ではさえ、いくつかの紹介がサイズ限界のため返されないのは、可能でした。 この場合、それは、LDAPの限界よりむしろ結果が設定した50紹介のフェルト、サイズ限界のための多くの場合デフォルトであり、クライアントでどんな実用にも大き過ぎ、一般に、質問分配の失敗でした。
6.3. Common DIT
6.3. 一般的なデイット
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
ソフトウェア開発の本質のために、グラフィカル、そして、ウェブクライアントはサーバソフトウェアの開発の後に開発されました。 'ldapsearch'クライアントはテストと開発にサーバソフトウェア作成の間、使用されました。 以上の作成がクライアントを進めたとき、初めて、一定のDIT命名のデザイン決定をするべきであると発見されました。 技術的に、これはわずかに良いソフトウェア変調と再使用を考慮したでしょう。 さらに、会社名のDIT構造の使用は別のドメイン登録の簡単な統合を許容しませんでした、登録記録係モデルのように。 唯一でない、でなければならないクライアントは
Newton Experimental [Page 15] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[15ページ]RFC3663のドメインの管理データ
reconfigured for each new registry operator, but this would most likely have social implications as well.
これだけには、それぞれの新しい登録オペレータのために再構成されていて、また、社会的な意味がたぶんあるでしょう。
6.4. Universal Client
6.4. 普遍的なクライアント
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構造と使用されるschemasに関するアルゴリズムの知識を必要としました。 別のDITか図式でLDAPサービスに対してグラフィカルなクライアントを使用できませんでした。 したがって、ジェネリックか普遍的なクライアント(すべてのLDAPアプリケーションに使用できたもの)が、サービスで提供されたデータは完全に利用できないでしょうし、また一般ユーザーによる操作には、はるかに複雑過ぎるでしょう。
6.5. Targeting Searches by Tier
6.5. 層のそばで検索を狙います。
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.
このサービスのためのネットワークモデルは3つの層に分割されました: 登録、記録係、および記入者。 これにもかかわらず、すべての検索が、レベルが選んだ層をターゲットにすることができた検索のために登録でオーバーヘッドを引き起こし始める必要がありました。 このサービスはこの問題にソリューションを実現しませんでした、クライアントが原因となるLDAPサーバを見つけるのを許容するのにDNSでのSRV、そして/または、NAPTR記録を使用するのなどように。
6.6. Data Mining
6.6. データマイニング
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サーバの多くのオペレータが、この習慣がデータマイニングであり、しばしば特に辞書攻撃とそれを呼ぶと考えることに注意されるべきです。
7. IANA Considerations
7. IANA問題
There are no applicable IANA considerations presented in this document.
本書では提示されたどんな適切なIANA問題もありません。
8. Internationalization Considerations
8. 国際化問題
The domain administrative data in this service did not cover Internationalized Domain Names (IDN's).
このサービスにおけるドメインの管理データはInternationalized Domain Names(IDNのもの)をカバーしませんでした。
Newton Experimental [Page 16] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[16ページ]RFC3663のドメインの管理データ
9. Security Considerations
9. セキュリティ問題
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 この実験的な展開に、これらのメカニズムが適切であった間、実稼動環境には、それらは適切でないだろう、インターネットで展開を熟考するもののためのモデルとしてそれらをみなすべきではありません。
10. Intellectual Property Statement
10. 知的所有権声明
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
Newton Experimental [Page 17] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[17ページ]RFC3663のドメインの管理データ
11. Normative References
11. 引用規格
[1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
954, October 1985.
[1]HarrenstienとK.とスタールとM.とE.Feinler、「NICNAME/WHOIS」、RFC954、1985年10月。
[2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and
Structuring Guidelines for X.500 Directory Pilots", RFC 1617,
May 1994.
[2] バーカー、P.、Kille、S.、およびT.Lenggenhager(「X.500ディレクトリのパイロットのためにガイドラインを命名して、構造化する」RFC1617)は1994がそうするかもしれません。
[3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
June 1997.
[3] ウィリアムソン、S.、Kosters、M.、Blacka、D.、シン、J.、およびK.Zeilstra、「紹介Whois(RWhois)はV1.5"について議定書の中で述べます、RFC2167、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.とウォールとM.とグリムスターとA.とヒューバーとR.とS.Sataluri、「LDAP/X.500分類名にドメインを使用します」、RFC2247、1998年1月。
[5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[5] ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 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] ウォール、M.、Coulbeck、A.、ハウズ、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] ウォール、M.、「LDAPv3"、RFC2256、1997年12月との使用のためのX.500(96)ユーザSchemaのSummary。」
[8] Howard, L., "An Approach for Using LDAP as a Network Information
Service", RFC 2307, March 1998.
1998年3月の[8] ハワード、L.、「ネットワーク情報サービスとしてLDAPを使用するためのアプローチ」RFC2307。
[9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class",
RFC 2798, April 2000.
[9] スミス、M.、「inetOrgPerson LDAPオブジェクトのクラスの定義」、RFC2798、2000年4月。
Newton Experimental [Page 18] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[18ページ]RFC3663のドメインの管理データ
Appendix A. Other Work
付録A.他の仕事
In addition to the deployment of servers and development of clients, VeriSign conducted two sub-projects related to this experiment.
サーバの展開とクライアントの進化に加えて、ベリサインはこの実験に関連する2つのサブプロジェクトを行いました。
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へのゲートウェイでした。 プロジェクトの目標は記録係による使用が彼らのNicname/Whoisサーバの正面で配布するLDAPサーバを作成することでした。 このゲートウェイは、LDAPに要求を取って、Nicname/Whois要求にそれらを翻訳して、ポート43の上で配布された特定のNicname/Whoisサーバに要求を出して、応答を解釈して、結果セットをLDAPに返すでしょう。 Nicname/Whois結果セットの不特定の本質のために、ゲートウェイが明確に3人の異なった記録係の出力だけを認識するようにプログラムされました。 このゲートウェイはドメインルックアップと限られた検索を許すことができるくらい貴重であると判明しましたが、それは一貫した接触ルックアップ、ネームサーバルックアップ、または記入者紹介を提供できませんでした。 また、オープンソースライセンスに関する諸条件でこのソフトウェアを公的に利用可能にしました。
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サーバで2番目のプロジェクトは記入者の非公式の調査でした。 これがcom、ネット、org、およびeduゾーンファイルを使用して、LDAPサーバの存在がないかどうかポート389の上でドメインの名前を使用することでテストすることによって、行われました、そのドメインの"ldap"、およびそのドメインの"dir"というホストというホスト(例えば、"foo.com"、"ldap.foo.com"、および"dir.foo.com")。 この調査は、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特有のEntry(DSE)の輪郭を描くことによって、調査によって、サーバのおよそ90%がベンダーAによって提供された実装であり、サーバの9%がベンダーBによって提供された実装であり、サーバの1%が他のベンダーによって提供された実装であることがわかりました。 質問されたベンダーAによって提供された実装であることを決定しているサーバでは、10%だけに関するそれが公衆データを含んだように(また、これは他の90%によって公的に質問されることを意図しなかったという仮定に通じました)見えました。 質問されたベンダーBによって提供された実装であることを決定しているサーバでは、ほとんどすべてが公衆データを含んだように見えます。
Appendix B. Acknowledgments
付録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.
このプロジェクトのための重要な分析、デザイン、および実装がブラッドMcMillen、デヴィッドBlacka、アンナ・チャン、およびマイケルSchiraldiによって行われました。 マークKostersとレスリーDaigleは、このプロジェクト、プロジェクトの目標、およびこのドキュメントを再検討することによって、指導を提供しました。
Newton Experimental [Page 19] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[19ページ]RFC3663のドメインの管理データ
Author's Address
作者のアドレス
Andrew Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
アンドリューニュートンベリサインInc.21345屋根の頂円の英貨、ヴァージニア20166米国
Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com; anewton@ecotroph.net
以下に電話をしてください。 +1 3382年の703 948メール: anewton@verisignlabs.com; anewton@ecotroph.net
Newton Experimental [Page 20] RFC 3663 Domain Administrative Data in LDAP December 2003
LDAP2003年12月のニュートン実験的な[20ページ]RFC3663のドメインの管理データ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Newton Experimental [Page 21]
ニュートンExperimentalです。[21ページ]
一覧
スポンサーリンク
