RFC1279 日本語訳
1279 X.500 and Domains. S.E. Hardcastle-Kille. November 1991. (Format: TXT=26669, PS=170029, PDF=142776 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S.E. Hardcastle-Kille
Requests for Comments 1279 University College London
November 1991
ネットワークワーキンググループ東南Hardcastle-Killeは1991年11月にコメント1279のためにユニバーシティ・カレッジロンドンを要求します。
X.500 and Domains
X.500とドメイン
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are
requested. Please refer to the current edition of the ``IAB
Official Protocol Standards'' for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
Abstract
このMemo Thisメモの状態はインターネットコミュニティのためにExperimentalプロトコルを定義します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。 要約
This RFCconsiders X.500 in relation to Internet and UK Domains.
A basic model of X.500 providing a higher level and more
descriptive naming structure is emphasised. In addition, a
mapping of domains onto X.500 is proposed, which gives a range of
new management and user facilities over and above those currently
available. This specification proposes an experimental new
mechanism to access and manage domain information on the Internet
and in the UK Academic Community. There is no current intention
to provide an operational replacement for DNS.
インターネットとイギリスのDomainsと関連したこのRFCconsiders X.500。 より高いレベルと、より描写的である命名構造を提供するX.500の基本型は強調されます。 さらに、X.500へのドメインに関するマッピング(それらの上と、そして、現在利用可能なそれらの上にさまざまな新しい管理と利用者機能を与える)は提案されます。 この仕様は、インターネットの上と、そして、イギリスのAcademic Communityのドメイン情報にアクセスして、管理するために実験新しいメカニズムを提案します。 DNSへの操作上の交換品を提供するというどんな現在の意志もありません。
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
1 The Domain Name System
1 ドメインネームシステム
The Domain (Nameserver) System (DNS) provides a hierarchical resource labelling system [Moc87a] [Moc87b] [Lar83]. Example domains are:
Domain(ネームサーバ)システム(DNS)は[Moc87b][Lar83]とシステム[Moc87a]をラベルする階層的なリソースを提供します。 例のドメインは以下の通りです。
MIT.EDU VENERA.ISI.EDU CS.UCL.AC.UK
MIT.EDU VENERA.ISI.EDU CS.UCL.AC.UK
Entries usually have a single name, although pointers to entries (not subtrees) may be provided by CNAME records. Information (resource records) is associated with each entry. Name components are typically chosen to be shortish (e.g., ``CS''). RFC 822 mailbox names are closely related [Cro82]. For example:
エントリーには、CNAME記録でエントリー(下位木でない)への指針を提供するかもしれませんが、通常、ただ一つの名前があります。 情報(リソース記録)は各エントリーに関連しています。 名前コンポーネントは、やや短く(例えば、「Cs」)なるように通常選ばれています。 RFC822メールボックス名は密接に関係づけられます[Cro82]。 例えば:
<S.Kille@CS.UCL.AC.UK>
<S.Kille@CS.UCL.AC.UK>。
The local-part of the RFC 822 mailbox can be considered as one level lower in the domain hierarchy.
1つのレベルであるとドメイン階層構造で、より低くRFC822メールボックスの地方の部分をみなすことができます。
2 X.500
2 X.500
The OSI Directory, usually known as X.500, provides a very general naming framework [CCI88]. A basic usage of X.500 is to provide Organisationally Structured Names. A Schema for this is defined within the standard. Name components will typically have longish values. This is an example directory name represented in Tabular form:
通常、X.500として知られているOSIディレクトリは非常に一般的な命名フレームワーク[CCI88]を提供します。 X.500の基本的な使用はOrganisationally Structured Namesを提供することです。 これのためのSchemaは規格の中で定義されます。 名前コンポーネントには、長めの値が通常あるでしょう。 これはTabularフォームに表された例のディレクトリ名です:
Country GB
Organisation University College London
Organisational Unit Computer Science
Common Name Stephen E. Hardcastle-Kille
国のGB機構ユニバーシティ・カレッジロンドンOrganisationalユニットコンピュータサイエンス俗称スティーブンE.Hardcastle-Kille
This can also be written in the ``User Friendly Name'' notation defined in [HK91]. This syntax is used for names in the rest of this document:
また、記法という[HK91]で定義された「ユーザフレンドリーな名前」でこれを書くことができます。 この構文はこのドキュメントの残りにおける名前に使用されます:
Stephen E. Hardcastle-Kille, Computer Science,
スティーブンE.Hardcastle-Kille、コンピュータサイエンス
Hardcastle-Kille Page 1
Hardcastle-Kille1ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
University College London, GB
ユニバーシティ・カレッジロンドン、GB
This type of structure is termed ``organisational X.500''. This is a subset of the general capabilities.
このタイプの構造は"organisational X.500"と呼ばれます。 これは一般的な能力の部分集合です。
3 The basic model
3 基本型
X.500 has as much relation to the DNS as DNS has to ARP. Paul
Mockapetris
X.500には、DNSとのDNSがARPに持っているのと同じくらいかなりの関係があります。 ポールMockapetris
This is, essentially, the position adopted here. The basic model is that organisational X.500 is providing a layer of naming at the level above domain names. These structured names can be considered to form a naming layer above domain names. There are the following key differences:
これは本質的にはここに採用された位置です。 基本型はorganisational X.500がレベルで命名の層をドメイン名の上に提供しているということです。 これらの構造化された名前がドメイン名を超えて命名層を形成すると考えることができます。 以下の主要な違いがあります:
o Organisational X.500 tends to use longer and more descriptive
values
o Organisational X.500は、より長くて、より描写的である値を使用する傾向があります。
o The organisational X.500 DIT is slightly shallower than the DNS
tree
o organisational X.500 DITはDNS木よりわずかに浅いです。
o X.500 has a richer information framework than DNS
o X.500には、DNSより豊かな情報フレームワークがあります。
These differences suggest that the following should NOT be done:
これらの違いは、以下が完了しているべきでないと示唆します:
o Represent X.500 information in the DNS
o DNSのX.500情報を表してください。
o Have an algorithmic mapping between the two hierarchies
o 2つの階層構造の間にアルゴリズムのマッピングを持ってください。
This note proposes to represent DNS information in the DIT, and to provide for a loose coupling between the two trees. This note does not propose an equivalencing of X.500 and Domains.
この注意は、DITのDNS情報を表して、2本の木の間の疎結合に備えるよう提案します。 この注意はX.500とDomainsのequivalencingを提案しません。
The proposed model is illustrated in Figure 1. Both an organisational and domain structure is represented in the DIT, by use of appropriate object classes and attribute types. A weak linkage is provided between the two parts of the tree by use of special attributes. Here, the linkage is 1:1, but it may be more complex for some parts of the organisational DIT or domain namespace. The linkage is achieved by use of special attributes, as described in Section 11.
提案されたモデルは図1で例証されます。 ともに、organisationalとドメイン構造はDITに適切なオブジェクトのクラスと属性タイプの使用で表されます。 特別な属性の使用で木の2つの部分の間に弱いリンケージを提供します。 ここで、リンケージは1:1ですが、organisational DITかドメイン名前空間のいくつかの部品には、それは、より複雑であるかもしれません。 リンケージはセクション11で説明されるように特別な属性の使用で達成されます。
Hardcastle-Kille Page 2
Hardcastle-Kille2ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
j jZ Z
j jZ Z
j j ZZ
jj Z Z
jjj ZZ
j j ZZ jj Z Z jjj ZZ
Domain Component=UK Country Name=GB
|
|
|
Domain Component=AC Organisation Name=Univeristy College London
ドメインコンポーネント=イギリス国名前=GB| | | ドメインコンポーネント=交流機構名はUniveristy大学ロンドンと等しいです。
* BB
ss BBB
* 掲示板ss BBB
Domain Component=UCL Org Unit Name=Computer Science
| *
ドメインコンポーネント=UCL Orgユニット名前=コンピュータサイエンス| *
|| ss
Domain Component=CS Common Name=Steve Kille
|| ss Domain Component=CS俗称=スティーブKille
| *
| ss
| * | ss
Domain Component=S.Kille
Figure 1: Example X.500 tree
ドメインコンポーネントはS.Kille数値1と等しいです: 例のX.500木
Hardcastle-Kille Page 3
Hardcastle-Kille3ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
4 Representing Domains in X.500
4 X.500のドメインを表すこと。
Domains are at the level below X.500 names of the form illustrated in the previous section. However, it is also possible to use X.500 in other ways. In particular, there are benefits from representing Domains in X.500. Note that this is very different to equivalencing, as no attempt is made to represent X.500 information within the domain scheme. There are the following potential advantages:
ドメインがレベルで前項で例証されたフォームのX.500名の下にあります。 しかしながら、また、他の方法でX.500を使用するのも可能です。 特に、X.500にDomainsを表すのからの利益があります。 これがequivalencingに非常に異なっていることに注意してください、ドメイン体系の中にX.500情報を表すのを試みを全くしないとき。 以下の潜在的利点があります:
o Domain Services (DNS and NRS) could be replaced with an OSI
service (some may not view this as an advantage). This is
particularly attractive for OSI services, where use of a non-OSI
directory may be inappropriate.
o ドメインServices(DNSとNRS)をOSIサービスに取り替えることができました(或るものはこれを利点であるとみなさないかもしれません)。 非OSIディレクトリの使用が不適当であるかもしれないところでOSIサービスには、これは特に魅力的です。
o For Internet sites, access to domain information (beyond MX
records) could be provided for systems registered remotely. For
UK Academic Community sites, access to domain information for
domains not registered in the NRS could be given. For sites
neither on the Internet nor in the UK Academic Community there
will usually be even more of an advantage, as they usually have
very limited information on domains.
o インターネット・サイトにおいて、ドメイン情報(MX記録を超えた)へのアクセスを離れて登録されたシステムに提供できました。 イギリスのAcademic Communityサイトにおいて、NRSに登録されなかったドメインのためのドメイン情報へのアクセスを与えることができました。 どちらもインターネットかイギリスのAcademic Communityのサイトには、通常、利点についてさらにあるでしょう、それらにドメインの非常に限られた情報が通常あるとき。
o Assuming that information is downloaded from an X.500 database
into a DNS or NRS system, the remote management facilities of
X.500 could be used. This is possible because of the extra
security features of X.500.
o 情報がX.500データベースからX.500のDNSかNRSシステム、リモート管理施設にダウンロードされると仮定するのを使用できました。 これはX.500の特別なセキュリティ機能のために可能です。
Note: For initial work, the converse situation of information
being mastered in Domain Databases and uploaded into the X.500
DIT is more likely.
以下に注意してください。 初期の仕事において、Domain Databasesでマスタリングされて、X.500 DITにアップロードされる情報の逆状況は、よりありそうです。
o User access to the domain data, and in particular searching, could
be provided. This would allow users to browse the domain
namespace, and to determine information associated with the
domains.
o ドメインデータ、特定のおよび探すことにおけるユーザアクセスを提供できました。 これで、ユーザは、ドメイン名前空間をブラウズして、ドメインに関連している情報を決定するでしょう。
o The X.500 framework would allow for additional management
information to be stored, and to relate the domain names into a
more complex structure of information. For example, this might
allow for the managers of a system to be identified, and
information on how to contact the manager.
o X.500フレームワークは、追加経営情報が情報の、より複雑な構造にドメイン名を保存されて、関係づけるのを許容するでしょう。 例えば、これは特定されるべきシステムのマネージャ、およびどうマネージャに連絡するかの情報を考慮するかもしれません。
Hardcastle-Kille Page 4
Hardcastle-Kille4ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
o A facility to map RFC 822 mailbox into a Directory Name (and thus
access other user information on the basis of this key) could be
provided. This may be useful for the user to determine
information about a message originator.
o ディレクトリName(その結果、このキーに基づいて他のユーザー情報にアクセスする)にRFC822メールボックスを写像する施設を提供できました。 ユーザがメッセージ創始者の情報を決定するように、これは役に立つかもしれません。
o This technique may be useful to facilitate introduction of
security, as it will enable certificates to be associated with
domains and mailboxes. This may be very useful for the privacy
enchanced mail work [Lin89].
o このテクニックはセキュリティの導入を容易にするために役に立つかもしれません、証明書がドメインとメールボックスに関連しているのを可能にするとき。 これは非常にプライバシーのenchancedメール仕事[Lin89]の役に立つかもしれません。
5 Representing Domain Names
5 ドメイン名を表すこと。
A new attribute syntax is defined:
新しい属性構文は定義されます:
CaseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
IA5String
MATCHES FOR EQUALITY SUBSTRINGS ORDERING
CaseIgnoreIA5StringSyntax IA5Stringが平等サブストリングのために合っている属性構文注文
A new attribute and two new object classes are defined:
新しい属性と2つの新しいオブジェクトのクラスが定義されます:
DomainComponent ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax
SINGLE VALUE
DomainComponentは属性構文caseIgnoreIA5StringSyntaxと共にただ一つの値を結果と考えます。
Domain OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN -DomainComponent"
MAY CONTAIN -AssociatedName,
organizationName,
organizationalAttributeSet,
manager"
「ドメインOBJECT-CLASS SUBCLASS OF先端がそうしなければならない、CONTAIN -DomainComponent、」 5月のCONTAIN -AssociatedName、organizationName、organizationalAttributeSet、マネージャ、」
RFC822Mailbox OBJECT-CLASS
SUBCLASS OF Domain
MAY CONTAIN -commonName,
surname,
description,
telephoneNumber,
postalAttributeSet,
telecommunicationAttributeSet "
「RFC822Mailbox OBJECT-CLASS SUBCLASS OF Domain5月のCONTAIN -commonName、姓、記述、telephoneNumber、postalAttributeSet、telecommunicationAttributeSet」
Hardcastle-Kille Page 5
Hardcastle-Kille5ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
Note that the attribute AssociatedName is defined in Section 11. The manager attribute is defined in the COSINE and Internet naming architecture [BHK91]. It allows a manager to be associated with the domain, which is useful where the manager of the domain is different to the manager of the object defined by the AssociatedName. This will allow any domain to be represented in an X.500 hierarchy. The local part of an RFC 822 mailbox is treated as a special sort of domain component, and so these can be represented in the tree as a natural extension of the hierarchy. For example, consider the mailbox S.Kille@cs.ucl.ac.uk. This will lead to the following structure in the DIT:
属性AssociatedNameがセクション11で定義されることに注意してください。 マネージャ属性は、[BHK91]とアーキテクチャを命名しながら、COSINEとインターネットで定義されます。 それは、マネージャがドメインに関連しているのを許容します。(ドメインはAssociatedNameによって定義されたオブジェクトのマネージャにとって、ドメインのマネージャが異なっているところで役に立ちます)。 これは、どんなドメインもX.500階層構造で表されるのを許容するでしょう。 RFC822メールボックスの地方の部分が特殊活字のドメインコンポーネントとして扱われるので、階層構造の自然な拡大として木にこれらを表すことができます。 例えば、メールボックスが S.Kille@cs.ucl.ac.uk であると考えてください。 これはDITの以下の構造に通じるでしょう:
___________________________________________
|_Object_Class__|RDN_Type________|RDN_Value_|
| Domain |DomainComponent |UK |
| Domain |DomainComponent |AC |
| Domain |DomainComponent |UCL |
| Domain |DomainComponent |CS |
|_RFC822Mailbox_|DomainComponent_|S.Kille__ |
___________________________________________ |_オブジェクト_クラス__|RDN_タイプ________|RDN_値の_| | ドメイン|DomainComponent|イギリス| | ドメイン|DomainComponent|西暦| | ドメイン|DomainComponent|UCL| | ドメイン|DomainComponent|Cs| |_RFC822Mailbox_|DomainComponent_|S.Kille__|
This can be represented in User Friendly Name format as:
以下としてUser Friendly Name形式でこれを表すことができます。
DomainComponent=S.Kille, DomainComponent=CS, DomainComponent=UCL, DomainComponent=AC, DomainComponent=UK
DomainComponentはS.Killeと等しく、DomainComponent=UCL、DomainComponentはCsと等しく、DomainComponentは西暦と等しく、DomainComponentはイギリスと等しいです。
Note that the RFC822Mailbox Object Class is a subclass of Domain. Some attributes are allowed to be associated with these objects. There may be other additional management attributes which it is useful to define (e.g., Machine Type, Owner, Location etc.). This allows some information which truly belongs to the domain to be represented there. It also allows for further information to be associated with the domain/mailbox when there is not a relevant part of the organisationally structure DIT to be pointed at. When there is an associated part of the DIT, information from that part of the DIT should not be duplicated in the domain entry.
RFC822Mailbox Object ClassがDomainのサブクラスであることに注意してください。 いくつかの属性がこれらのオブジェクトに関連させているのが許容されています。 定義するのが役に立つ他の追加管理属性(例えば、Machine Type、Location Ownerなど)があるかもしれません。 これは、本当に、ドメインに属す何らかの情報がそこに表されるのを許容します。 また、指し示されるためにorganisationally構造DITの関連部分がないとき、それは、詳細がドメイン/メールボックスに関連しているのを許容します。 DITの関連部分があるとき、ドメインエントリーにDITのその部分からの情報をコピーするべきではありません。
6 Wildcards
6個のワイルドカード
Wildcards are supported by having "*" as a special domain component name. If there is a need to emulate wildcard matching using the directory, the following algorithm must be employed. For example, the
ワイルドカードは、特別なドメインコンポーネント名として「*」を持っていることによって、支えられます。 ディレクトリを使用することでワイルドカードマッチングを見習う必要があれば、以下のアルゴリズムを使わなければなりません。 例えば
Hardcastle-Kille Page 6
Hardcastle-Kille6ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
wildcard entry for *.*.PODUNK.COM would be represented in the DIT as:
**.PODUNK.COMのためのワイルドカードエントリーは以下としてDITに表されるでしょう。
DomainComponent=*, DomainComponent=*,
DomainComponent=MIT, DomainComponent=COM
DomainComponent=COM、DomainComponentは*と等しく、DomainComponentは*と等しく、DomainComponentはMITと等しいです。
If A.B.PODUNK.COM is looked up in the directory, the query will fail and indicate that two components are matched. A substitution should be made, and *.*.PODUNK.COM looked up explicitly to identify the associated information.
A. B. PODUNK.COMがディレクトリで調べられると、質問は、2つのコンポーネントが取り組んでいるのを失敗して、示すでしょう。 代替をするべきでした、そして、**.PODUNK.COMは関連情報を特定するために明らかに見上げました。
7 DNS Information
7 DNS情報
DNS information can be associated with an entry in the DIT. It is important that this is done in a manner which is exactly equivalent to the information stored in the DNS. This will allow the DIT to have information loaded from the DNS or vice versa. All (authoritative) records associated with a domain will be stored in the DIT. There is no attempt made by the OSI Directory to emulate DNS caching or TTL handling. It is assumed that the master entries are maintained by use of DNS Zone Transfer (or equivalent), and that they can be treated as authoritative. There is a need to define an attribute syntax which represents a DNS record. This then allows DNS records to be stored in the DIT. There are three possible encodings of this record:
DNS情報をDITのエントリーに関連づけることができます。 まさにDNSに保存された情報に同等な方法でこれをするのは重要です。 これで、DITはDNSから情報をロードさせることができるでしょうか、逆もまた同様です。 ドメインに関連しているすべての(正式)の記録がDITに保存されるでしょう。 OSIディレクトリによってDNSキャッシュかTTL取り扱いを見習うのがされた試みが全くありません。 DNS Zone Transfer(または、同等物)の使用でマスターエントリーを維持して、正式であるとしてそれらを扱うことができると思われます。 DNS記録を表す属性構文を定義する必要があります。 そして、これは、DNS記録がDITに保存されるのを許容します。 この記録の3可能なencodingsがあります:
ASN.1 Encoded This is the most natural approach in terms of X.500.
However, it would require all users of this service to handle the
new syntax, which would be awkward. There is a problem with
handling the resource format in a general manner.
ASN.1Encoded ThisはX.500に関する最も自然なアプローチです。 しかしながら、それは、新しい構文を扱うためにすべてのユーザにこのサービスを要求するでしょう。(構文は厄介でしょう)。 一般的な方法でリソース形式を扱うことに関する問題があります。
DNS Binary Encoded Use the formally defined record syntax. This
would be convenient for access to the data by DNS related
software, but would be an awkward encoding for independent X.500
DUAs.
DNS Binary Encoded Use、正式に定義された記録的な構文。 これは、DNSの関連するソフトウェアでデータへのアクセスに便利でしょうが、独立しているX.500 DUAsのための無器用なコード化でしょう。
Text encoded Use of a text encoding derived from the DNS
specifications. This is straightforward to map onto DNS protocol,
and easy to support in a naive X.500 DUA. This approach is chosen.
テキストはDNS仕様から得られたテキストコード化のUseをコード化しました。 これは、DNSプロトコルに写像するために簡単であって、ナイーブなX.500 DUAでサポートしやすいです。 このアプローチは選ばれています。
The syntax is defined in IA5 characters. The BNF of the record uses the definitions of section 5.1 of RFC 1035. It is
構文はIA5キャラクタで定義されます。 記録のBNFはRFC1035のセクション5.1の定義を使用します。 それはそうです。
Hardcastle-Kille Page 7
Hardcastle-Kille7ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
<rr> [ ";" <comment> ]
<rr>。[「」、;、<コメント>]
Three examples of this (for domain C.ISI.EDU) might be:
この(ドメインC. ISI.EDUへの)3つの例は以下の通りです。
500 A 10.1.0.52 ; Basic address record IN 600 MX 10 VENERA.ISI.EDU. ; MX record 600 IN MX 10 VENERA.ISI.EDU. ; MX record - other order
500、A10.1.0、.52。 基本的なアドレス記録的なIN600Mx10VENERA.ISI.EDU。 ; MX記録的な600IN Mx10VENERA.ISI.EDU。 ; MX記録--他のオーダー
Note that:
以下のことに注意してください。
o The class and TTL may be in either order (following RFC 1035)
o クラスとTTLがオーダーにあるかもしれません。(次のRFC1035)
o The class defaults to IN
o クラスはINをデフォルトとします。
o Domains must always be fully specified (i.e., master file
abbreviate rules are not used).
o ドメインを完全にいつも指定しなければなりません(すなわち、基本ファイルは使用されない規則を簡略化します)。
o The TTL for a record must always be present (this saves looking at
the parent entry to find the SOA record).
o 記録のためのTTLはいつも存在していなければなりません(これはSOA記録を見つけるために親エントリーを見ながら、節約されます)。
o Records (e.g., SOA) may be multiline. Lines should be separated
with the two IA5 characters <CR><LF>.
o 記録(例えば、SOA)はマルチラインであるかもしれません。 線は2IA5キャラクタ<CR><LF>で切り離されるべきです。
CNAME records are mapped symmetrically onto Directory Aliases.
CNAME記録は対称的にディレクトリAliasesに写像されます。
This is now defined in terms of attribute and object class definitions. A single record type is defined, as opposed to one attribute type per record type. This allows the definition to not require extension when new DNS Record types are define. However, there is some loss of efficiency if only a single record type is needed, as filtering must be done by the DUA. Similarly, no distinction is made on the basis of DNS class. This means that if there are two class hierarchies, that they must be represented in a single DIT, and that information for different classes must be separated by DUA filtering.
これは現在、属性とオブジェクトクラス定義で定義されます。 ただ一つのレコード種類は1レコード種類あたり1人の属性タイプと対照的に定義されます。 定義はこれで、新しいDNS Recordタイプがそうである拡大を必要とすることができません。定義します。 しかしながら、ただ一つのレコード種類だけが必要であるなら、効率のいくらかの減退があります、DUAがフィルタリングを完了していなければならないように。 同様に、DNSのクラスに基づいて区別を全くしません。 2つのクラス階層構造があれば、これはそれを意味して、DUAフィルタリングで独身のDIT、および異なったクラスのためのその情報にそれらを表さなければならないのを切り離さなければなりません。
DNSDomain OBJECT-CLASS
SUBCLASS OF Domain
MAY CONTAIN -
DNSRecord "
「ドメインのDNSDomainオブジェクトクラスサブクラスは含むかもしれません--DNSRecord」
Hardcastle-Kille Page 8
Hardcastle-Kille8ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
DNSRecord ATTRIBUTE
ATTRIBUTE-SYNTAX IA5String
MATCHES FOR EQUALITY
平等のためのDNSRecord属性属性構文IA5Stringマッチ
Lookup of a domain is achieved by translating it algorithmically to a Distinguished Name (DN), and reading back attributes desired. This information can be managed and searched in a straightforward fashion.
ドメインのルックアップは、algorithmicallyにそれを翻訳することによって、逆属性が望んでいたDistinguished Name(DN)、および読みように達成されます。 簡単なやり方でこの情報を管理して、捜すことができます。
The information may also be downloaded into a DNS database. This should be done by use of zone transfer. A tool to perform zone transfer (in both directions) between a DNS Server and a DSA would seem to be both straightforward and useful. This would be a key tool in a transition to X.500 based management of the DNS. It would also allow a large part of the DNS namespace to be rapidly made available in an X.500 pilot. Inverse information can be derived by the usual IN-ADDR domain, which will be represented in the same manner in the DIT.
また、DNSデータベースに情報をダウンロードするかもしれません。 ゾーン転送の使用でこれをするべきです。 DNS ServerとDSAの間でゾーン転送を実行する(両方の方向に)ツールは簡単であって、かつ役に立つように思えるでしょう。 これはDNSのX.500のベースの管理への変遷で主要なツールでしょう。 また、それで、DNS名前空間のかなりの部分はX.500パイロットで急速に利用可能にするでしょう。 普通のIN-ADDRドメインは逆さの情報を引き出すことができます。(それは、DITの同じ方法で表されるでしょう)。
8 NRS Information
8 NRS情報
Information associated with the UK NRS (Name Registration Scheme) can be handled in a similar manner [Lar83]. This is being developed in a separate document by Alan Turland.
同じように[Lar83]UK NRS(名前Registration Scheme)に関連している情報を扱うことができます。 これはアランTurlandによる別々のドキュメントで開発されています。
9 Application Entity Titles
9 アプリケーション実体タイトル
In many cases, Application entities will be closely related to domains. In some cases, it may be appropriate to give Application Entities names which are related to the DNS part of the DIT. In this case, the Domain Name will be used to identify the application, and the entry for the domain will also be of object class Application Process. The children of this entry will identify Application Entities, with names such as ``FTAM Service''.
多くの場合、Application実体は密接にドメインに関連するでしょう。 いくつかの場合、DITのDNS部分に関連する名前をApplication Entitiesに与えるのは適切であるかもしれません。 この場合、Domain Nameはアプリケーションを特定するのに使用されるでしょう、そして、また、ドメインのためのエントリーはオブジェクトのクラスApplication Processのものになるでしょう。 このエントリーの子供は「FTAMサービス」などの名前でApplication Entitiesを特定するでしょう。
10 Networks
10のネットワーク
It is clearly useful to represent networks within the DIT. A short note on how to do this is given here. It is likely that this specification will later be evolved in a separate document. This
DITの中でネットワークを代表するのは明確に役に立ちます。 どうこれをするかに関する短いメモをここに与えます。 この仕様は後で別々のドキュメントで発展されそうでしょう。 これ
Hardcastle-Kille Page 9
Hardcastle-Kille9ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
defines an Object Class for a general network, and shows how it can be subclassed to define technology specific networks.
一般的なネットワークのためにObject Classを定義して、技術の特定のネットワークを定義するためにどうそれを副分類できるかを示しています。
Network OBJECT-CLASS
SUBCLASS OF TOP
MAY CONTAIN -
Manager,
Locality,
Description "
「先端のサブクラスが含むかもしれないオブジェクトクラスをネットワークでつないでください--マネージャ、場所、記述」
IPNetwork OBJECT-CLASS
SUBCLASS OF Network
MUST CONTAIN -AssociatedDomain"
「ネットワークのIPNetworkオブジェクトクラスサブクラスは-AssociatedDomainを含まなければなりません」
The Network Object Class allows networks to be defined, and for useful attributes to be associated with the entry. A network will often appear in more than one organisational structure, and this linkage should be achieved by use of aliases. This grouping can facilitate management of networks. The subclass IPNetwork mandates linkage into the DNS part of the DIT. This will be represented in the DIT using the structures of RFC 1101 [Moc89]. Both of the domains which identify the network should be represented in the Object Class. For example, a network might have the (user friendly) name:
Network Object Classは、エントリーに定義されて、役に立つ属性が関連しているようにネットワークを許容します。 ネットワークは1つ以上のorganisational構造にしばしば現れるでしょう、そして、このリンケージは別名の使用で達成されるべきです。 この組分けはネットワークの経営を容易にすることができます。 サブクラスIPNetworkはDITのDNS部分にリンケージを強制します。 これは、DITにRFC1101[Moc89]の構造を使用することで表されるでしょう。 ネットワークを特定するドメインの両方がObject Classに表されるべきです。 例えば、ネットワークには、(ユーザフレンドリー)の名前があるかもしれません:
UCL-Ethernet, University College London, GB
UCL-イーサネット、ユニバーシティ・カレッジロンドン、GB
This would have associated domains 0.0.40.128.IN-ADDR.ARPA and UCL-ETHERNET.UCL.AC.UK. These would both have the analogous DIT representations. For example:
これはドメインの0.0.40.128.IN-ADDR.ARPAとUCL-ETHERNET.UCL.AC.UKを関連づけたでしょう。 これらには、類似のDIT表現がともにあるでしょう。 例えば:
DomainComponent=0, DomainComponent=0, DomainComponent=40, DomainComponent=128, DomainComponent=IN-ADDR, DomainComponent=ARPA
DomainComponent=0、DomainComponent=0、DomainComponent=40、DomainComponent=128、ADDRのDomainComponent=、DomainComponent=アルパ
11 Linkage
11 リンケージ
There is a need to associate the organisational X.500 DIT and the DNS tree. The objects represented are different (Domain 6= Organisation; Person 6= RFC 822 Mailbox). Therefore aliasing is not an appropriate linkage. However, in many cases, there is a linkage which is rather
organisational X.500 DITとDNS木を関連づける必要があります。 表されたオブジェクトは異なっています(ドメイン6=機構; 人6=RFC822Mailbox)。 したがって、エイリアシングは適切なリンケージではありません。 しかしながら、多くの場合、むしろそうであるリンケージがあります。
Hardcastle-Kille Page 10
Hardcastle-Kille10ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
stronger than that implied by the seeAlso attribute. Therefore, we define new attributes, which represent this stronger cross-linkage. The same mechanism can be used to link a domains with an Application Entity or an Application Process. Links from the organisational X.500 DIT to the DNS tree are provided by a new attribute, which could be present in Organisation or Organisational Unit entries.
seeAlso属性によって含意されたそれより強いです。 したがって、私たちは新しい属性を定義します。(属性はこのより強い架橋処理を表します)。 Application EntityかApplication Processにドメインをリンクするのに同じメカニズムを使用できます。 新しい属性でorganisational X.500 DITからDNS木へのリンクを提供します。(それは、OrganisationかOrganisational Unitエントリーに存在しているかもしれません)。
ObjectWithAssociatedDomain OBJECT-CLASS SUBCLASS OF top MUST CONTAIN -AssociatedDomain"
「ObjectWithAssociatedDomain OBJECT-CLASS SUBCLASS OF先端がそうしなければならない、CONTAIN -AssociatedDomain、」
AssociatedDomain ATTRIBUTE WITH ATTRIBUTE-SYNTAX ia5StringSyntax
属性構文ia5StringSyntaxがあるAssociatedDomain属性
For example, the organisational entry:
例えば、organisationalエントリー:
University College London, GB
ユニバーシティ・カレッジロンドン、GB
would have an attribute:
属性を持っているでしょう:
AssociatedDomain = UCL.AC.UK
AssociatedDomainはUCL.AC.UKと等しいです。
Similarly, an RFC 822 mailbox attribute is used to link entries of Person Object Class to their associated DNS entry. This attribute is defined in the Cosine and Internet Naming Architecture [BHK91]. Conversely, there are pointers from the DNS represented tree into the organisational X.500 DIT:
同様に、RFC822メールボックス属性は、彼らの関連DNSエントリーにPerson Object Classのエントリーをリンクするのに使用されます。 この属性はCosineとインターネットNaming Architecture[BHK91]で定義されます。 あります。指針はDNSから木をorganisational X.500 DITに表しました:
AssociatedName ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
属性構文distinguishedNameSyntaxがあるAssociatedName属性
This attribute is associated with the Domain object class.
この属性はDomainオブジェクトのクラスに関連しています。
This entry is used to provide linkage from the DNS X.500 Hierarchy into the organisational X.500 hierarchy. Where such entries do not exist, attributes in the DNS entry (such as phone number) may be used. It is recommended that information is not duplicated. The preferred setup is for the DNS attributes to be rather skeletal, with pointers into the organisational X.500 DIT.
このエントリーは、リンケージをDNS X.500 Hierarchyからorganisational X.500階層構造に供給するのに使用されます。 そのようなエントリーが存在していないところでは、DNSエントリー(電話番号などの)における属性は使用されるかもしれません。 情報がコピーされないのは、お勧めです。 都合のよいセットアップはDNS属性が指針でorganisational X.500 DITにかなり骨格であることです。
Hardcastle-Kille Page 11
Hardcastle-Kille11ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
For example, the domain UCL.AC.UK would be represented in the DIT as:
例えば、ドメインUCL.AC.UKは以下としてDITに表されるでしょう。
DomainComponent=UCL, DomainComponent=AC,
DomainComponent=UK
DomainComponent=UCL、DomainComponent=西暦、DomainComponent=イギリス
This entry would have in it an AssociatedName attribute with value:
このエントリーはそれに値があるAssociatedName属性を持っているでしょう:
University College London, GB
ユニバーシティ・カレッジロンドン、GB
This example shows a simple case with 1:1 linkage. There are cases where a domain might be associated with multiple organisations, or an organisation with multiple domains.
この例は1:1リンケージに伴う簡単なケースを示しています。 ケースがドメインが複数のドメインで複数の機構、または機構に関連しているかもしれないところにあります。
12 Conclusions and proposals for evaluation
評価のための12の結論と提案
Experiments should be undertaken to determine the practicality and utility of this scheme, in a pilot environment. A possible approach to this experimentation is described in Appendix A. Object Identifiers have been assigned for this purpose in the Cosine and Internet Naming Architecture [BHK91].
実験は、実用性とユーティリティを決定するためにパイロット環境におけるこの体系について引き受けられるべきです。 可能なアプローチはA.Object IdentifiersがCosineとインターネットNaming Architecture[BHK91]でこのために割り当てられたAppendixにこの実験に説明されます。
References
参照
[BHK91] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet
X.500 schema. Request for Comments RFC 1274, Department of
Computer Science, University College London, November 1991.
[BHK91] P.バーカーと東南Hardcastle-Kille。 COSINEとインターネットX.500図式。 コメントには、1991年11月にRFC1274、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドンを要求してください。
[CCI88] The Directory --- overview of concepts, models and services,
December 1988. CCITT X.500 Series Recommendations.
[CCI88] ディレクトリ--- 1988年12月の概念の、そして、モデルの、そして、サービスの概要。 CCITT X.500シリーズ勧告。
[Cro82] D.H. Crocker. Standard of the format of ARPA internet text
messages. Request for Comments 822, University of Delaware,
August 1982.
[Cro82]D.H.クロッカー。 ARPAインターネットテキスト・メッセージの形式の規格。 コメントには、1982年8月に822、デラウエア大学を要求してください。
[HK91] S.E. Hardcastle-Kille. Using the OSI directory to achieve
user friendly naming. Request for Comments in preparation,
Department of Computer Science, University College London,
November 1991.
[HK91]東南Hardcastle-Kille。 ユーザフレンドリーな命名を達成するのにOSIディレクトリを使用します。 準備におけるComments、コンピュータの部には、1991年11月にScience、ユニバーシティ・カレッジロンドンを要求してください。
Hardcastle-Kille Page 12
Hardcastle-Kille12ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
[Lar83] J. Larmouth. JNT name registration technical guide, April
1983.
[Lar83]J.Larmouth。 JNTは技術ガイド、1983年4月と登録を命名します。
[Lin89] J. Linn. Privacy Enhancement for Internet Electronic Mail:
Part 1 --- Message Encipherment and Authentication
Procedures. Request for Comments 1113, Bolt, Beranek, and
Newman, August 1989.
[Lin89]J.リン。 インターネット電子メールのためのプライバシー増進: 第1部--- メッセージ暗号文と認証手順。 コメント1113、ボルト、Beranek、およびニューマン、1989年8月に、要求します。
[Moc87a] P. Mockapetris. Domain names - concepts and facilities.
Request for Comments RFC 1034, USC/Information Sciences
Institute, November 1987.
[Moc87a]P.Mockapetris。 ドメイン名--概念と施設。 コメントには、RFC1034、科学が1987年11月に設けるUSC/情報を要求してください。
[Moc87b] P. Mockapetris. Domain names - implementation and
specification. Request for Comments RFC 1035,
USC/Information Sciences Institute, November 1987.
[Moc87b]P.Mockapetris。 ドメイン名--実装と仕様。 コメントには、RFC1035、科学が1987年11月に設けるUSC/情報を要求してください。
[Moc89] P. Mockapetris. DNS encoding of network names and other
types. Request for Comments RFC 1101, USC/Information
Sciences Institute, April 1989.
[Moc89]P.Mockapetris。 ネットワーク名と他のタイプのDNSコード化。 コメントには、RFC1101、科学が1989年4月に設けるUSC/情報を要求してください。
13 Security Considerations
13 セキュリティ問題
This memo does not directly address security issues. However, due to the facilities of X.500, this proposal could lead to a more secure way to access and manage domain information.
このメモは、セキュリティが問題であると直接扱いません。 しかしながら、X.500の施設のため、この提案はドメイン情報にアクセスして、管理するより安全な方法につながるかもしれません。
14 Author's Address
14作者のアドレス
Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
スティーブHardcastle-Killeコンピュータサイエンス学部ユニバーシティ・カレッジロンドンWC1E 6BTイギリスガウアー・ストリート
Phone: +44-71-380-7294
以下に電話をしてください。 +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
メール: S.Kille@CS.UCL.AC.UK
Hardcastle-Kille Page 13
Hardcastle-Kille13ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
A Possible Deployment Approach
可能な展開アプローチ
This appendix notes a possible approach to deploying an experiment to evaluate this mechanism. The following components of a possible experiment are noted.
この付録はこのメカニズムを評価するために実験を配布することへの可能なアプローチに注意します。 可能な実験の以下の成分は注意されます。
1. User tool. This will take a domain or mailbox as input. This
will be looked up in the DIT. This tool should be capable of:
1. ユーザツール。 これは入力されるようにドメインかメールボックスを取るでしょう。 これはDITで調べられるでしょう。 このツールはそうすることができるべきです:。
o Attempting to correct user input
o ユーザ入力を修正するのを試みます。
o Helping browsing
o ブラウズするのを助けます。
o Looking up information associated with the domain (or mailbox)
and associated name, in particular the manager (of both domain
and associated name) and information on the manager (e.g.,
phone number and mailbox).
o 特にマネージャ(例えば、電話番号とメールボックス)のドメイン(または、メールボックス)と関連名前に関連している情報、マネージャ(ドメインと関連名前の両方の)、および情報を訪ねます。
o Supply DNS records
o 供給DNS記録
o Handle IN-ADDR.ARPA inverse lookups if supplied with an IP
Address
o IP Addressを供給するなら、IN-ADDR.ARPAの逆さのルックアップを扱ってください。
o Look up networks
o ネットワークを調べてください。
2. A procedural library to allow user interfaces to make easy use of
these facilities.
2. ユーザを許容する手続き上のライブラリは、これらの簡単な使用を施設にするように連結します。
3. Zone transfer tool. This will use the zone transfer protocol to
transfer information between a DSA and Domain Nameserver. When
writing to the DSA, attributes in an entry which are not DNS
records should remain untouched.
3. ゾーン転送ツール。 これは、DSAとDomain Nameserverの間に情報を移すのにゾーン転送プロトコルを使用するでしょう。DSAに書くとき、エントリーにおけるDNS記録でない属性は触れないままで残るべきです。
4. Linkage patching tool. When the organisational DIT is
established, associated domain pointers are usually inserted. A
tool can be written to search the DIT and insert the reverse
pointers.
4. ツールにパッチするリンケージ。 organisational DITが設立されるとき、通常、関連ドメイン指針は挿入されます。 DITを捜して、逆の指針を挿入するためにツールを書くことができます。
5. DNS Manager Tool. This will allow user addition of additional
information into the DNS part of the DIT. A standard DUA can
probably be used for this.
5. DNSマネージャツール。 これはDITのDNS部分に追加情報のユーザ追加を許容するでしょう。 これにたぶん標準のDUAを使用できます。
Hardcastle-Kille Page 14
Hardcastle-Kille14ページ
RFC 1279 X.500 and Domains November 1991
RFC1279X.500とドメイン1991年11月
6. Mailbox download tool. This will allow download of local
mailboxes, with pointers to the user entries.
6. メールボックスダウンロードツール。 これは指針がある地方のメールボックスのダウンロードをユーザエントリーに許容するでしょう。
7. Emulation DNS Server, using the Directory as a database. The
server should maintain a permanent connection to its local DSA. As
there is no OSI bind, the response of this server can be at least
as fast as a normal DNS server. There can be two variants of this
server.
7. データベースとしてディレクトリを使用するエミュレーションDNS Server。 サーバは地方のDSAに永久接続を維持するべきです。 OSIひもが全くないとき、このサーバの応答は正常なDNSサーバと少なくとも同じくらい速いことができます。このサーバの2つの異形があることができます。
(a) Using a local DSA as a local database but using DNS
distributed operations.
(a) ローカルのデータベースとして地方のDSAを使用しますが、DNSを使用すると、操作は広げられました。
(b) Do all lookups in the directory (using Directory Distributed
Operations).
(b) ディレクトリのすべてのルックアップをしてください(ディレクトリDistributed Operationsを使用して)。
An initial experiment is straightforward. The Zone Transfer Tool (3) can be used to download a large part of the DNS space into a single DSA (there will be some restrictions, as parts of the DNS hierarchy do not permit zone transfer). This can be used repeatedly to maintain the information. The linkage patching tool (4) can be used to put in pointers to parts of the DIT. The user tool can then be used (by all sites participation the the directory pilot) to look up domain information. This will allow the utility of the approach to be evaluated. The manager tool (5) will allow extra information to be added to parts of the DNS tree.
初期の実験は簡単です。 DNSスペースのかなりの部分を独身のDSAにダウンロードするのにZone Transfer Tool(3)を使用できます(いくつかの制限があるでしょう、DNS階層構造の部分がゾーン転送を可能にしないとき)。 情報を保守するのに繰り返してこれを使用できます。 DITの部分に指針を入れるのにツール(4)にパッチするリンケージは使用できます。 そして、ドメイン情報を調べるのにユーザツールを使用できます(すべてのサイト参加によるディレクトリのパイロット)。 これは、アプローチに関するユーティリティが評価されるのを許容するでしょう。 マネージャツール(5)で、その他の情報はDNS木の部分に加えるでしょう。
The next stage will be to distribute the DNS part of the DIT over multiple DSAs using Directory distribution techniques. The emulation DNS Server (7) will be useful to ensure that equivalent functionality is being offered by the Directory. It can also be used to examine performance differences. A final step is to master some parts of the DNS hierarchy in the DIT. Because of the zone transfer technique, this will be entirely transparent to the DNS user. Management benefits can then be examined.
次のステージはディレクトリ分配技法を使用することで複数のDSAsの上にDITのDNS部分を分配することでしょう。 エミュレーションDNS Server(7)は、同等な機能性がディレクトリによって提供されているのを保証するために役に立ちます。 また、性能差を調べるのにそれを使用できます。 最終的なステップはDITのDNS階層構造のいくつかの部分をマスタリングすることです。 ゾーン移動法のために、これはDNSユーザにとって完全に透明になるでしょう。 そして、管理利益を調べることができます。
Hardcastle-Kille Page 15
Hardcastle-Kille15ページ
一覧
スポンサーリンク
