RFC920 日本語訳
0920 Domain requirements. J. Postel, J.K. Reynolds. October 1984. (Format: TXT=27823 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Postel
Request for Comments: 920 J. Reynolds
ISI
October 1984
コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 920 J.レイノルズISI1984年10月
Domain Requirements
ドメイン要求性
Status of this Memo
このMemoの状態
This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA. Distribution of this memo is unlimited.
このメモはARPA-インターネットとDARPA研究団体に新しいドメインを確立する要件に関する施政方針です。 これはIABとDARPAの公式方針声明です。 このメモの分配は無制限です。
Introduction
序論
This memo restates and refines the requirements on establishing a Domain first described in RFC-881 [1]. It adds considerable detail to that discussion, and introduces the limited set of top level domains.
このメモは、最初にRFC-881[1]で説明されたDomainを設立することに関する要件を言い直して、洗練します。 それは、その議論にかなりの詳細を加えて、限られたセットのトップ・レベル・ドメインを紹介します。
The Purpose of Domains
ドメインの目的
Domains are administrative entities. The purpose and expected use of domains is to divide the name management required of a central administration and assign it to sub-administrations. There are no geographical, topological, or technological constraints on a domain. The hosts in a domain need not have common hardware or software, nor even common protocols. Most of the requirements and limitations on domains are designed to ensure responsible administration.
ドメインは管理実体です。 ドメインの目的と予想された使用は、中央の管理が要求された名前管理を分割して、サブ政権にそれを配属することです。 どんな地理的であるか、位相的であるか、技術的な規制もドメインにありません。 ドメインのホストには、一般的なハードウェアかソフトウェアと、一般的なプロトコルさえある必要はありません。 ドメインにおける要件と制限の大部分は、責任がある管理を確実にするように設計されています。
The domain system is a tree-structured global name space that has a few top level domains. The top level domains are subdivided into second level domains. The second level domains may be subdivided into third level domains, and so on.
ドメインシステムはいくつかのトップ・レベル・ドメインがある木で構造化されたグローバル名スペースです。 トップ・レベル・ドメインはセカンドレベルドメインに分筆されます。 セカンドレベルドメインは平らなドメイン3番目のなどに細分されるかもしれません。
The administration of a domain requires controlling the assignment of names within that domain and providing access to the names and name related information (such as addresses) to users both inside and outside the domain.
名前はそのドメインの中で課題を制御するのがドメインの管理は要求されます、そして、名前と名前へのアクセスを提供すると、情報(アドレスなどの)はドメインの中と、そして、ドメインの外でユーザに伝えられました。
Postel & Reynolds [Page 1]
ポステルとレイノルズ[1ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
General Purpose Domains
汎用のドメイン
While the initial domain name "ARPA" arises from the history of the development of this system and environment, in the future most of the top level names will be very general categories like "government", "education", or "commercial". The motivation is to provide an organization name that is free of undesirable semantics.
初期のドメイン名「アルパ」がこのシステムと環境の開発の歴史から起こる間、将来、最高平らな名前の大部分は「政府」、「教育」、または「コマーシャル」のように非常に一般的なカテゴリになるでしょう。 動機は望ましくない意味論を持っていない組織名を提供することです。
After a short period of initial experimentation, all current ARPA-Internet hosts will select some domain other than ARPA for their future use. The use of ARPA as a top level domain will eventually cease.
短期の初期の実験の後に、すべての現在のARPA-インターネット・ホストが彼らの今後の使用のためのARPA以外の何らかのドメインを選択するでしょう。 トップ・レベル・ドメインとしてのARPAの使用は結局、やむでしょう。
Initial Set of Top Level Domains
始発のトップ・レベル・ドメイン
The initial top level domain names are:
初期の最上位ドメイン名は以下の通りです。
Temporary
一時的
ARPA = The current ARPA-Internet hosts.
ARPAは現在のARPA-インターネット・ホストと等しいです。
Categories
カテゴリ
GOV = Government, any government related domains meeting the
second level requirements.
GOVは政府と等しく、どんな政府も2番目の平らな必要条件を満たすドメインを関係づけました。
EDU = Education, any education related domains meeting the
second level requirements.
EDUは教育と等しく、どんな教育も2番目の平らな必要条件を満たすドメインを関係づけました。
COM = Commercial, any commercial related domains meeting the
second level requirements.
COMはコマーシャルと等しく、2番目を満たすどんな商業関連するドメインも要件を平らにします。
MIL = Military, any military related domains meeting the
second level requirements.
MILは軍と等しく、2番目を満たすどんな軍事の関連するドメインも要件を平らにします。
ORG = Organization, any other domains meeting the second
level requirements.
ORGは組織と等しく、2番目を満たすいかなる他のドメインも要件を平らにします。
Countries
国
The English two letter code (alpha-2) identifying a country
according the the ISO Standard for "Codes for the
Representation of Names of Countries" [5].
ISO Standard「国の名前の表現のためのコード」[5]のために国を特定するイギリスの2レター・コード(アルファ-2)。
Postel & Reynolds [Page 2]
ポステルとレイノルズ[2ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
Multiorganizations
Multiorganizations
A multiorganization may be a top level domain if it is large,
and is composed of other organizations; particularly if the
multiorganization can not be easily classified into one of the
categories and is international in scope.
マルチ組織は、それが大きいならトップ・レベル・ドメインであるかもしれなく、他の組織で構成されます。 特に、マルチ組織が容易にカテゴリの1つに分類できないで、範囲で国際的であるなら。
Possible Examples of Domains
ドメインの可能な例
The following examples are fictions of the authors' creation, any similarity to the real world is coincidental.
以下の例が作者の作成のフィクションである、本当の世界へのどんな類似性も暗合的です。
The UC Domain
UCドメイン
It might be that a large state wide university with, say, nine
campuses and several laboratories may want to form a domain. Each
campus or major off-campus laboratory might then be a subdomain,
and within each subdomain, each department could be further
distinguished. This university might be a second level domain in
the education category.
ドメインを形成するのは、たとえば、9つのキャンパスといくつかの実験室がある広い大学が欲しいかもしれないそのa大きい州であるかもしれません。 そしてときにそれぞれのキャンパスか主要なオフキャンパス実験室がサブドメインであるかもしれません、そして、各サブドメインの中では、さらに各部は区別できました。 この大学は教育カテゴリにおいてセカンドレベルドメインであるかもしれません。
One might see domain style names for hosts in this domain like
these:
人はこのドメインのホストのためにこれらのようにドメインスタイル名を見るかもしれません:
LOCUS.CS.LA.UC.EDU
CCN.OAC.LA.UC.EDU
ERNIE.CS.CAL.UC.EDU
A.S1.LLNL.UC.EDU
A.LAND.LANL.UC.EDU
NMM.LBL.CAL.UC.EDU
LOCUS.CS.LA. UC.EDU CCN.OAC.LA. UC.EDU ERNIE.CS.CAL. UC.EDU A.S1.LLNL.UC.EDU A.LAND.LANL.UC.EDU NMM.LBL.CAL. UC.EDU
The MIT Domain
MITドメイン
Another large university may have many hosts using a variety of
machine types, some even using several families of protocols.
However, the administrators at this university may see no need for
the outside world to be aware of these internal differences. This
university might be a second level domain in the education
category.
別の大きい大学には、多くのホストがさまざまなマシンタイプを使用することでいるかもしれなくて、いくつかの同等の使用がプロトコルのいくつかのファミリーです。 しかしながら、この大学の管理者は、どんな必要性も外の世界がこれらの内部の違いを知っていないのを見るかもしれません。 この大学は教育カテゴリにおいてセカンドレベルドメインであるかもしれません。
One might see domain style names for hosts in this domain like
these:
人はこのドメインのホストのためにこれらのようにドメインスタイル名を見るかもしれません:
APIARY-1.MIT.EDU
BABY-BLUE.MIT.EDU
CEZANNE.MIT.EDU
DASH.MIT.EDU
養蜂場-1.MIT.EDU BABY-BLUE.MIT.EDU CEZANNE.MIT.EDU DASH.MIT.EDU
Postel & Reynolds [Page 3]
ポステルとレイノルズ[3ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
MULTICS.MIT.EDU
TAC.MIT.EDU
XX.MIT.EDU
MULTICS.MIT.EDU TAC.MIT.EDU XX.MIT.EDU
The CSNET Domain
CSNETドメイン
There may be a consortium of universities and industry research
laboratories called, say, "CSNET". This CSNET is not a network
per se, but rather a computer mail exchange using a variety of
protocols and network systems. Therefore, CSNET is not a network
in the sense of the ARPANET, or an Ethernet, or even the
ARPA-Internet, but rather a community. Yet it does, in fact, have
the key property needed to form a domain; it has a responsible
administration. This consortium might be large enough and might
have membership that cuts across the categories in such a way that
it qualifies under the "multiorganization rule" to be a top level
domain.
大学とたとえば、"CSNET"と呼ばれる産業研究所の共同体があるかもしれません。 このCSNETはそういうもののネットワークではなく、むしろさまざまなプロトコルとネットワーク・システムを使用するコンピュータメール交換です。したがって、CSNETはアルパネットの感覚、またはイーサネットにおけるネットワーク、またはARPA-インターネットではなくさえ、むしろ共同体です。 しかし、それには、事実上、ドメインを形成するのが必要である主要な特性があります。 それには、責任がある管理があります。 この共同体は、十分大きいかもしれなく、トップ・レベル・ドメインになるように「マルチ組織規則」の下で資格を得るような方法でカテゴリを横切る会員資格を持っているかもしれません。
One might see domain style names for hosts in this domain like
these:
人はこのドメインのホストのためにこれらのようにドメインスタイル名を見るかもしれません:
CIC.CSNET
EMORY.CSNET
GATECH.CSNET
HP-LABS.CSNET
SJ.IBM.CSNET
UDEL.CSNET
UWISC.CSNET
CIC.CSNET EMORY.CSNET GATECH.CSNET hp-LABS.CSNET SJ.IBM.CSNET UDEL.CSNET UWISC.CSNET
General Requirements on a Domain
ドメインに関する一般要件
There are several requirements that must be met to establish a domain. In general, it must be responsibly managed. There must be a responsible person to serve as an authoritative coordinator for domain related questions. There must be a robust domain name lookup service, it must be of at least a minimum size, and the domain must be registered with the central domain administrator (the Network Information Center (NIC) Domain Registrar).
ドメインを証明するために満たさなければならないいくつかの必要条件があります。 一般に、責任をもってそれを管理しなければなりません。 ドメインへの正式のコーディネータが質問を関係づけたので、役立つ責任者がいるに違いありません。 体力を要しているドメイン名ルックアップサービスがあるに違いありません、そして、それは少なくとも最小規模のものであるに違いありません、そして、主要なドメイン管理者(Networkインフォメーション・センター(NIC)ドメインRegistrar)にドメインを登録しなければなりません。
Responsible Person:
責任者:
An individual must be identified who has authority for the
administration of the names within the domain, and who seriously
takes on the responsibility for the behavior of the hosts in the
domain, plus their interactions with hosts outside the domain.
This person must have some technical expertise and the authority
within the domain to see that problems are fixed.
名前の管理のためにドメインの中で権限があって、そのドメインのホストの振舞い、およびホストとのドメインの外での彼らの相互作用のために真剣に責任を負う個人を、特定しなければなりません。 この人には、何らかの技術的専門知識と問題が固定されているのを確実にするドメインの中の権威がなければなりません。
Postel & Reynolds [Page 4]
ポステルとレイノルズ[4ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
If a host in a given domain somehow misbehaves in its interactions
with hosts outside the domain (e.g., consistently violates
protocols), the responsible person for the domain must be
competent and available to receive reports of problems, take
action on the reported problems, and follow through to eliminate
the problems.
与えられたドメインのホストがドメイン(例えば、一貫して、プロトコルに違反する)の外のホストとの相互作用でどうにかふらちな事をするなら、ドメインへの責任者は、有能、そして、問題のレポートを受け取って、報告された問題を実行して、問題を解決するために続けることができなければなりません。
Domain Servers:
ドメインサーバ:
A robust and reliable domain server must be provided. One way of
meeting this requirement is to provide at least two independent
domain servers for the domain. The database can, of course, be
the same. The database can be prepared and copied to each domain
server. But, the servers should be in separate machines on
independent power supplies, et cetera; basically as physically
independent as can be. They should have no common point of
failure.
強健で高信頼のドメインサーバを提供しなければなりません。 この必要条件を満たす1つの方法は少なくとも2つの独立しているドメインサーバをドメインに提供することです。 データベースはもちろん同じである場合があります。 それぞれのドメインサーバにデータベースを準備して、コピーできます。しかし、サーバが独立している電源などの別々のマシンにあるべきです。 基本的に肉体的に極めて独立しています。 彼らには、失敗のどんな一般的なポイントもあるべきではありません。
Some domains may find that providing a robust domain service can
most easily be done by cooperating with another domain where each
domain provides an additional server for the other.
いくつかのドメインによって、各ドメインが追加サーバをもう片方に提供する別のドメインに協力することによって最も容易に体力を要しているドメインサービスを提供できるのがわかるかもしれません。
In other situations, it may be desirable for a domain to arrange
for domain service to be provided by a third party, perhaps on
hosts located outside the domain.
他の状況で、ドメインが、ドメインサービスが第三者によって提供されるように手配するのは、望ましいかもしれません、恐らくドメインの外に位置するホストの上で。
One of the difficult problems in operating a domain server is the
acquisition and maintenance of the data. In this case, the data
are the host names and addresses. In some environments this
information changes fairly rapidly and keeping up-to-date data may
be difficult. This is one motivation for sub-domains. One may
wish to create sub-domains until the rate of change of the data in
a sub-domain domain server database is easily managed.
ドメインサーバを操作することにおける難問の1つは、データの獲得とメインテナンスです。 この場合、データは、ホスト名とアドレスです。 いくつかの環境で、この情報はかなり急速に変化します、そして、最新の資料を保つのは難しいかもしれません。 これはサブドメインに関する1つの動機です。 サブドメインドメインサーバデータベースのデータの増減率が容易に管理されるまで、サブドメインを作成したがっているかもしれません。
In the technical language of the domain server implementation the
data is divided into zones. Domains and zones are not necessarily
one-to-one. It may be reasonable for two or more domains to
combine their data in a single zone.
ドメインサーバ実装の技術的な言語で、データはゾーンに分割されます。 ドメインとゾーンは、必ず1〜1であるというわけではありません。 2つ以上のドメインがただ一つのゾーンでそれらのデータを結合するのは、妥当であるかもしれません。
The responsible person or an identified technical assistant must
understand in detail the procedures for operating a domain server,
including the management of master files and zones.
責任者か特定されたテクニカルアシスタントが詳細にドメインサーバを操作するための手順を理解しなければなりません、基本ファイルとゾーンの管理を含んでいて。
The operation of a domain server should not be taken on lightly.
There are some difficult problems in providing an adequate
service, primarily the problems in keeping the database up to
date, and keeping the service operating.
軽くドメインサーバの操作を帯びるべきではありません。 適切なサービスを提供するのにおいていくつかの難問があります、主としてデータベースが時代について行かせて、サービスを保つことにおける問題が作動して。
Postel & Reynolds [Page 5]
ポステルとレイノルズ[5ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
The concepts and implementation details of the domain server are
given in RFC-882 [2] and RFC-883 [3].
ドメインサーバの概念と実装詳細はRFC-882[2]とRFC-883[3]で明らかにされます。
Minimum Size:
最小規模:
The domain must be of at least a minimum size. There is no
requirement to form a domain because some set of hosts is above
the minimum size.
ドメインは少なくとも最小規模のものであるに違いありません。 最小規模より上には何らかのセットのホストがいるのでドメインを形成するという要件が全くありません。
Top level domains must be specially authorized. In general, they
will only be authorized for domains expected to have over 500
hosts.
特に、トップ・レベル・ドメインを認可しなければなりません。 一般に、それらは500人以上のホストがいると予想されたドメインに認可されるだけでしょう。
The general guideline for a second level domain is that it have
over 50 hosts. This is a very soft "requirement". It makes sense
that any major organization, such as a university or corporation,
be allowed as a second level domain -- even if it has just a few
hosts.
セカンドレベルドメインのための一般的ガイドラインはそれには50人以上のホストがいるということです。 これは非常に柔らかい「要件」です。 それにわずか数人のホストがいてもどんな主要な組織も大学や会社のようにセカンドレベルドメインとして許されているのは理解できます。
Registration:
登録:
Top level domains must be specially authorized and registered with
the NIC domain registrar.
NICドメインレジストラにトップ・レベル・ドメインを特に、認可されて、登録しなければなりません。
The administrator of a level N domain must register with the
registrar (or responsible person) of the level N-1 domain. This
upper level authority must be satisfied that the requirements are
met before authorization for the domain is granted.
平らなNドメインの管理者は平らなN-1ドメインの記録係(または、責任者)とともに記名しなければなりません。 ドメインへの承認を与える前に必要条件を満たすのをこの上側の平らな権威を満たさなければなりません。
The registration procedure involves answering specific questions
about the prospective domain. A prototype of what the NIC Domain
Registrar may ask for the registration of a second level domain is
shown below. These questions may change from time to time. It is
the responsibility of domain administrators to keep this
information current.
登録手順は、将来のドメインに関する具体的な質問に答えることを伴います。 NIC Domain Registrarがセカンドレベルドメインの登録のために尋ねるかもしれないことに関するプロトタイプは以下に示されます。 これらの質問は時々変化するかもしれません。 この現情報を保つのは、ドメイン管理者の責任です。
The administrator of a domain is required to make sure that host
and sub-domain names within that jurisdiction conform to the
standard name conventions and are unique within that domain.
ドメインの管理者が確実にそのホストを作らなければならなくて、その管轄の中のサブドメイン名は、コンベンションという標準の名前に従って、そのドメインの中でユニークです。
If sub-domains are set up, the administrator may wish to pass
along some of his authority and responsibility to a sub-domain
administrator. Even if sub-domains are established, the
responsible person for the top-level domain is ultimately
responsible for the whole tree of sub-domains and hosts.
サブドメインがセットアップされるなら、管理者は彼の権限と責任のいくつかをサブドメイン管理者に回したがっているかもしれません。 サブドメインが確立されても、最上位のドメインのための責任者は結局、サブドメインとホストの全体の木に責任があります。
This does not mean that a domain administrator has to know the
これは、ドメイン管理者が知らなければならないことを意味しません。
Postel & Reynolds [Page 6]
ポステルとレイノルズ[6ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
details of all the sub-domains and hosts to the Nth degree, but
simply that if a problem occurs he can get it fixed by calling on
the administrator of the sub-domain containing the problem.
Nth度合いへのすべてのサブドメインとホストの細部問題が起こるなら彼が問題を含むサブドメインの管理者の上に呼ぶことによってそれを絶対に修理させていたはずがないなら。
Top Level Domain Requirements
トップ・レベル・ドメイン要件
There are very few top level domains, each of these may have many second level domains.
ほんのわずかなトップ・レベル・ドメインがあって、それぞれのこれらには多くのセカンドレベルドメインがあるかもしれません。
An initial set of top level names has been identified. Each of these has an administrator and an agent.
1人の始発の最高平らな名前は特定されました。 それぞれのこれらには、管理者とエージェントがいます。
The top level domains:
トップ・レベル・ドメイン:
ARPA = The ARPA-Internet *** TEMPORARY ***
アルパはアルパインターネット***一時的な***と等しいです。
Administrator: DARPA
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
管理者: DARPAエージェント: ネットワーク情報センターメールボックス: HOSTMASTER@SRI-NIC.ARPA
GOV = Government
GOVは政府と等しいです。
Administrator: DARPA
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
管理者: DARPAエージェント: ネットワーク情報センターメールボックス: HOSTMASTER@SRI-NIC.ARPA
EDU = Education
EDUは教育と等しいです。
Administrator: DARPA
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
管理者: DARPAエージェント: ネットワーク情報センターメールボックス: HOSTMASTER@SRI-NIC.ARPA
COM = Commercial
COMはコマーシャルと等しいです。
Administrator: DARPA
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
管理者: DARPAエージェント: ネットワーク情報センターメールボックス: HOSTMASTER@SRI-NIC.ARPA
MIL = Military
ミル=軍
Administrator: DDN-PMO
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
管理者: DDN-PMOエージェント: ネットワーク情報センターメールボックス: HOSTMASTER@SRI-NIC.ARPA
Postel & Reynolds [Page 7]
ポステルとレイノルズ[7ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
ORG = Organization
ORGは組織と等しいです。
Administrator: DARPA
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
管理者: DARPAエージェント: ネットワーク情報センターメールボックス: HOSTMASTER@SRI-NIC.ARPA
Countries
国
The English two letter code (alpha-2) identifying a country
according the the ISO Standard for "Codes for the
Representation of Names of Countries" [5].
ISO Standard「国の名前の表現のためのコード」[5]のために国を特定するイギリスの2レター・コード(アルファ-2)。
As yet no country domains have been established. As they are
established information about the administrators and agents
will be made public, and will be listed in subsequent editions
of this memo.
まだ国のドメインは全く確立されていません。 それらが設立されるとき、管理者とエージェントの情報は、公表されて、このメモのその後の版にリストアップされるでしょう。
Multiorganizations
Multiorganizations
A multiorganization may be a top level domain if it is large,
and is composed of other organizations; particularly if the
multiorganization can not be easily classified into one of the
categories and is international in scope.
マルチ組織は、それが大きいならトップ・レベル・ドメインであるかもしれなく、他の組織で構成されます。 特に、マルチ組織が容易にカテゴリの1つに分類できないで、範囲で国際的であるなら。
As yet no multiorganization domains have been established. As
they are established information about the administrators and
agents will be made public, and will be listed in subsequent
editions of this memo.
まだマルチ組織ドメインは全く確立されていません。 それらが設立されるとき、管理者とエージェントの情報は、公表されて、このメモのその後の版にリストアップされるでしょう。
Note: The NIC is listed as the agent and registrar for all the
currently allowed top level domains. If there are other entities
that would be more appropriate agents and registrars for some or
all of these domains then it would be desirable to reassign the
responsibility.
以下に注意してください。 すべての現在許容された先端へのエージェントと記録係がドメインを平らにするとき、NICは記載されています。 これらのドメインのいくつかかすべてのための、より適切なエージェントと記録係である他の実体があれば、責任を再選任するのは望ましいでしょう。
Second Level Domain Requirements
セカンドレベルドメイン要件
Each top level domain may have many second level domains. Every second level domain must meet the general requirements on a domain specified above, and be registered with a top level domain administrator.
各トップ・レベル・ドメインには、多くのセカンドレベルドメインがあるかもしれません。 あらゆるセカンドレベルドメインを上で指定されたドメインで一般的な必要条件を満たして、トップ・レベル・ドメインの管理者に登録しなければなりません。
Postel & Reynolds [Page 8]
ポステルとレイノルズ[8ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
Third through Nth Level Domain Requirements
n番目の平らなドメイン要求性を通した3番目
Each second level domain may have many third level domains, etc. Every third level domain (through Nth level domain) must meet the requirements set by the administrator of the immediately higher level domain. Note that these may be more or less strict than the general requirements. One would expect the minimum size requirements to decrease at each level.
各セカンドレベルドメインには、多くの3番目の平らなドメインなどがあるかもしれません。 あらゆる3番目の平らなドメイン(Nthの平らなドメインを通した)がすぐにより高い平らなドメインの管理者で要件セットに会わなければなりません。 これらが一般的な要件より多少厳しいかもしれないことに注意してください。 人は各レベルで減少するという最小規模要件を予想するでしょう。
The ARPA Domain
アルパドメイン
At the time the implementation of the domain concept was begun it was thought that the set of hosts under the administrative authority of DARPA would make up a domain. Thus the initial domain selected was called ARPA. Now it is seen that there is no strong motivation for there to be a top level ARPA domain. The plan is for the current ARPA domain to go out of business as soon as possible. Hosts that are currently members of the ARPA domain should make arrangements to join another domain. It is likely that for experimental purposes there will be a second level domain called ARPA in the ORG domain (i.e., there will probably be an ARPA.ORG domain).
ドメイン概念の実装が始められたとき、DARPAの職務権限の下におけるホストのセットがドメインを作ると思われました。 したがって、選択された初期のドメインはARPAと呼ばれました。 今、先頭の平らなARPAドメインであるそこに関するどんな強い動機もないのがわかっています。 プランはできるだけ早く、現在のARPAドメインを倒産することになっています。 現在ARPAドメインのメンバーであるホストは、別のドメインに接合するために支度するべきです。 そこの実験目的のためのそれがORGドメインでARPAと呼ばれるセカンドレベルドメインになるのは(すなわち、たぶん、ARPA.ORGドメインがあるでしょう)、ありそうです。
The DDN Hosts
DDNホスト
DDN hosts that do not desire to participate in this domain naming system will continue to use the HOSTS.TXT data file maintained by the NIC for name to address translations. This file will be kept up to date for the DDN hosts. However, all DDN hosts will change their names from "host.ARPA" to (for example) "host.DDN.MIL" some time in the future. The schedule for changes required in DDN hosts will be established by the DDN-PMO.
このドメイン命名システムに参加することを望んでいないDDNホストは、名前が翻訳を扱うようにNICによって維持されたHOSTS.TXTデータファイルを使用し続けるでしょう。 このファイルはDDNホストに時代について行くでしょう。 しかしながら、すべてのDDNホストが将来、いつか、"host.ARPA"から(例えば、)"host.DDN.MIL"に改名するでしょう。 DDNホストで必要である変化のためのスケジュールはDDN-PMOによって確立されるでしょう。
Impact on Hosts
ホストの上で影響を与えてください。
What is a host administrator to do about all this?
このすべてに関してするホスト管理者は者ですか?
For existing hosts already operating in the ARPA-Internet, the
best advice is to sit tight for now. Take a few months to
consider the options, then select a domain to join. Plan
carefully for the impact that changing your host name will have on
both your local users and on their remote correspondents.
最も良いアドバイスはARPA-インターネットで既に働いている既存のホストに関しては当分きつい状態で座ることです。 数カ月を取って、オプションを考えて、次に、接合するためにドメインを選択してください。 慎重にあなたのホスト名を変えると両方の地元のユーザの上と、そして、彼らのリモート通信員の上に持たれている影響力の計画を立ててください。
For a new host, careful thought should be given (as discussed
below). Some guidance can be obtained by comparing notes on what
other hosts with similar administrative properties have done.
新しいホストに関しては、考慮を与えるべきです(以下で議論するように)。 同様の行政財産をもっている他のホストがしたことと情報交換することによって、何らかの指導を得ることができます。
The owner of a host may decide which domain to join, and the
そしてホストの所有者が、どのドメインを接合したらよいかを決めるかもしれない。
Postel & Reynolds [Page 9]
ポステルとレイノルズ[9ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
administrator of a domain may decide which hosts to accept into his domain. Thus the owner of a host and a domain administrator must come to an understanding about the host being in the domain. This is the foundation of responsible administration.
ドメインの管理者は、どのホストを彼のドメインに受け入れたらよいかを決めるかもしれません。 したがって、ホストとドメイン管理者の所有者はそのドメインにいるホストに関して理解に来なければなりません。 これは責任がある管理の基礎です。
For example, a host "XYZ" at MIT might possible be considered as a
candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or
XYZ.MIT.EDU.
例えば、考えられて、aはXYZ.ARPA.ORG、XYZ.CSNET、またはXYZ.MIT.EDUをいくらか一体どうならせる候補として可能なMIT力で"XYZ"を接待します。
The owner of host XYZ may choose which domain to join,
depending on which domain administrators are willing to have
him.
ホストXYZの所有者は、どのドメインを接合したらよいかを選ぶかもしれません、どのドメイン管理者が、彼がいても構わないと思っているかによって。
The domain is part of the host name. Thus if USC-ISIA.ARPA changes its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has changed its name. This means that any previous references to USC-ISIA.ARPA are now out of date. Such old references may include private host name to address tables, and any recorded information about mailboxes such as mailing lists, the headers of old messages, printed directories, and peoples' memories.
ドメインはホスト名の一部です。 したがって、USC-ISIA.ARPAがUSC-ISIA.DDN.MILになるようにドメイン提携をDDN.MILに変えるなら、それは改名しました。 これは、USC-ISIA.ARPAの前のどんな参照も現在時代遅れであることを意味します。 そのような古い参照は、テーブル、およびメーリングリスト(古いメッセージ、印刷されたディレクトリ、および民族の思い出のヘッダー)などのメールボックスに関するどんな記録情報も扱うために個人的なホスト名を含むかもしれません。
The experience of the DARPA community suggests that changing the name of a host is somewhat painful. It is recommended that careful thought be given to choosing a new name for a host - which includes selecting its place in the domain hierarchy.
DARPA共同体の経験は、ホストについて改称するのがいくらか苦痛であると示唆します。 ホスト(ドメイン階層構造で場所を選択するのを含んでいる)のために新しい名前を選ぶのに考慮を与えるのはお勧めです。
The Roles of the Network Information Center
ネットワークインフォメーション・センターの役割
The NIC plays two types of roles in the administration of domains. First, the NIC is the registrar of all top level domains. Second the NIC is the administrator of several top level domains (and the registrar for second level domains in these).
NICはドメインの管理における、2つのタイプの役割を果たします。 まず最初に、NICはすべてのトップ・レベル・ドメインの記録係です。 NICがいくつかのトップ・レベル・ドメイン(そして、これらのセカンドレベルドメインのための記録係)の管理者である秒。
Top Level Domain Registrar
トップ・レベル・ドメインの記録係
As the registrar for top level domains, the NIC is the contact
point for investigating the possibility of establishing a new top
level domain.
トップ・レベル・ドメインへの記録係として、NICは、新しいトップ・レベル・ドメインを確立する可能性を調査するための接点です。
Top Level Domain Administrator
トップ・レベル・ドメインの管理者
For the top level domains designated so far, the NIC is the
administrator of each of these domains. This means the NIC is
responsible for the management of these domains and the
registration of the second level domains or hosts (if at the
second level) in these domains.
今までのところ指定されているトップ・レベル・ドメインに、NICはそれぞれのこれらのドメインの管理者です。 これは、これらのドメインでNICがこれらのドメインの管理とセカンドレベルドメインかホストの登録に責任があることを(第2レベルで)意味します。
Postel & Reynolds [Page 10]
ポステルとレイノルズ[10ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
It may be reasonable for the administration of some of these
domains to be taken on by other authorities in the future. It is
certainly not desired that the NIC be the administrator of all top
level domains forever.
これらのドメインのいくつかの管理が将来他の当局によって取り組まれるのは、妥当であるかもしれません。 確かに、NICがいつまでもすべてのトップ・レベル・ドメインの管理者であることが望まれていません。
Prototypical Questions
Prototypical問題
To establish a domain, the following information must be provided to the NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
ドメインを証明するために、NIC Domain Registrar( HOSTMASTER@SRI-NIC.ARPA )に以下の情報を提供しなければなりません:
Note: The key people must have computer mail mailboxes and
NIC-Idents. If they do not at present, please remedy the
situation at once. A NIC-Ident may be established by contacting
NIC@SRI-NIC.ARPA.
以下に注意してください。 主要な人々はコンピュータメールのメールボックスとNIC-Identsを持たなければなりません。 彼らが現在のところないときにするなら、すぐに、事態を改善してください。 NIC-Identは、 NIC@SRI-NIC.ARPA に連絡することによって、設立されるかもしれません。
1) The name of the top level domain to join.
1) 接合するトップ・レベル・ドメインの名前。
For example: EDU
例えば: EDU
2) The name, title, mailing address, phone number, and organization of the administrative head of the organization. This is the contact point for administrative and policy questions about the domain. In the case of a research project, this should be the Principal Investigator. The online mailbox and NIC-Ident of this person should also be included.
2) 組織の管理代表の名前、タイトル、郵送先住所、電話番号、および組織。 これはドメインに関する管理と方針質問のための接点です。 研究計画の場合では、これは主任研究者であるべきです。 また、この人のオンラインメールボックスとNIC-Identは含まれるべきです。
For example:
例えば:
Administrator
管理者
Organization USC/Information Sciences Institute
Name Keith Uncapher
Title Executive Director
Mail Address USC/ISI
4676 Admiralty Way, Suite 1001
Marina del Rey, CA. 90292-6695
Phone Number 213-822-1511
Net Mailbox Uncapher@USC-ISIB.ARPA
NIC-Ident KU
組織USC/情報Sciences Institute NameキースUncapher TitleメールAddress USC/ISI4676海軍本部Way専務、Suite1001マリナデルレイ、カリフォルニア。 90292-6695 電話番号213-822-1511ネットメールボックス Uncapher@USC-ISIB.ARPA NIC-Ident KU
3) The name, title, mailing address, phone number, and organization of the domain technical contact. The online mailbox and NIC-Ident of the domain technical contact should also be included. This is the contact point for problems with the domain and for updating information about the domain. Also, the domain technical contact may be responsible for hosts in this domain.
3) ドメイン技術連絡担当者の名前、タイトル、郵送先住所、電話番号、および組織。 また、ドメイン技術連絡担当者のオンラインメールボックスとNIC-Identは含まれるべきです。 これは、ドメインに関する問題とドメインに関して情報をアップデートするための接点です。 また、ドメイン技術連絡担当者もこのドメインのホストに責任があるかもしれません。
Postel & Reynolds [Page 11]
ポステルとレイノルズ[11ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
For example:
例えば:
Technical Contact
技術連絡担当者
Organization USC/Information Sciences Institute
Name Craig Milo Rogers
Title Researcher
Mail Address USC/ISI
4676 Admiralty Way, Suite 1001
Marina del Rey, CA. 90292-6695
Phone Number 213-822-1511
Net Mailbox Rogers@USC-ISIB.ARPA
NIC-Ident CMR
組織USC/情報Sciences Institute NameクレイグミロロジャースTitle ResearcherメールAddress USC/ISI4676海軍本部Way、Suite1001マリナデルレイ、カリフォルニア。 90292-6695 電話番号213-822-1511ネットメールボックス Rogers@USC-ISIB.ARPA NIC-Ident CMR
4) The name, title, mailing address, phone number, and organization of the zone technical contact. The online mailbox and NIC-Ident of the zone technical contact should also be included. This is the contact point for problems with the zone and for updating information about the zone. In many cases the zone technical contact and the domain technical contact will be the same person.
4) ゾーンの技術連絡担当者の名前、タイトル、郵送先住所、電話番号、および組織。 また、ゾーンの技術連絡担当者のオンラインメールボックスとNIC-Identは含まれるべきです。 これは、ゾーンに関する問題とゾーンに関して情報をアップデートするための接点です。 多くの場合ゾーンの技術連絡担当者とドメイン技術連絡担当者は同じ人になるでしょう。
For example:
例えば:
Technical Contact
技術連絡担当者
Organization USC/Information Sciences Institute
Name Craig Milo Rogers
Title Researcher
Mail Address USC/ISI
4676 Admiralty Way, Suite 1001
Marina del Rey, CA. 90292-6695
Phone Number 213-822-1511
Net Mailbox Rogers@USC-ISIB.ARPA
NIC-Ident CMR
組織USC/情報Sciences Institute NameクレイグミロロジャースTitle ResearcherメールAddress USC/ISI4676海軍本部Way、Suite1001マリナデルレイ、カリフォルニア。 90292-6695 電話番号213-822-1511ネットメールボックス Rogers@USC-ISIB.ARPA NIC-Ident CMR
5) The name of the domain (up to 12 characters). This is the name that will be used in tables and lists associating the domain and the domain server addresses. [While technically domain names can be quite long (programmers beware), shorter names are easier for people to cope with.]
5) ドメイン(最大12のキャラクタ)の名前。 これはドメインとドメインサーバアドレスを関連づけながらテーブルとリストで使用される名前です。 [ドメイン名が技術的にかなり長い間であることができる(プログラマは注意します)、人々には、より短い名前は対処するのは、より簡単です。]
For example: ALPHA-BETA
例えば: アルファー-ベータ
6) A description of the servers that provides the domain service for translating name to address for hosts in this domain, and the date they will be operational.
6) このドメインのホストのために扱う名前を翻訳するためのサービス、および彼らが操作上になる日付をドメインに提供するサーバの記述。
Postel & Reynolds [Page 12]
ポステルとレイノルズ[12ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
A good way to answer this question is to say "Our server is
supplied by person or company X and does whatever their standard
issue server does".
この質問に答える早道は「私たちのサーバは、人か会社Xによって供給されて、それらの標準仕様サーバがするものなら何でもします。」と言うことです。
For example: Our server is a copy of the server operated by
the NIC, and will be installed and made operational on
1-November-84.
例えば: 1984年11月1日に私たちのサーバをNICによって操作されたサーバのコピーであり、インストールして、操作上にするでしょう。
7) A description of the server machines, including:
7) サーバマシンの記述、含み:
(a) hardware and software (using keywords from the Assigned
Numbers)
(a) ハードウェアとソフトウェア(Assigned民数記からのキーワードを使用します)
(b) addresses (what host on what net for each connected net)
(b) アドレス(それぞれのためのどんなネットがネットを接続したかの何というホスト)
For example:
例えば:
(a) hardware and software
(a) ハードウェアとソフトウェア
VAX-11/750 and UNIX, or
IBM-PC and MS-DOS, or
DEC-1090 and TOPS-20
VAX-11/750とUNIXかIBM-PCとMS-DOSか、12月-1090と最高の-20
(b) address
(b) アドレス
10.9.0.193 on ARPANET
10.9.0.193 アルパネットに関して
8) An estimate of the number of hosts that will be in the domain.
8) ホストの数の見積りに、それはそのドメインにいるでしょう。
(a) initially,
(b) within one year,
(c) two years, and
(d) five years.
(a) (b) (c) (d) 初めは、そして、1年、2年、および5年。
For example:
例えば:
(a) initially = 50
(b) one year = 100
(c) two years = 200
(d) five years = 500
(a) = 初めは、50(b)1年は200(d)5 100(c)2年=年=500と等しいです。
Postel & Reynolds [Page 13]
ポステルとレイノルズ[13ページ]
RFC 920 October 1984 Domain Requirements
RFC920 1984年10月ドメイン要求性
Acknowledgment
承認
We would like to thank the many people who contributed to this memo, including the participants in the Namedroppers Group, the ICCB, the PCCB, and especially the staff of the Network Information Center, particularly J. Feinler and K. Harrenstien.
このメモに貢献した多くの人々に感謝申し上げます、Networkインフォメーション・センター、特にJ.Feinler、およびK.HarrenstienのNamedroppers Group、ICCB、PCCB、および特にスタッフの関係者を含んでいて。
References
参照
[1] Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
Information Sciences Institute, November 1983.
[1] ポステルと、J.と、「ドメイン名プランとスケジュール」、RFC-881、科学が設けるUSC情報、11月1983
[2] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC-882, USC Information Sciences Institute, November 1983.
[2]Mockapetris、P.、「ドメイン名--、概念と施設、」、RFC-882、科学が設けるUSC情報、11月1983
[3] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC-883, USC Information Sciences Institute,
November 1983.
[3]Mockapetris、P.、「ドメイン名--、実装と仕様、」、RFC-883、科学が設けるUSC情報、11月1983
[4] Postel, J., "Domain Name System Implementation Schedule",
RFC-897, USC Information Sciences Institute, February 1984.
[4] ポステル、J.、「ドメインネームシステム遂行スケジュール」、RFC-897、科学が1984年2月に設けるUSC情報。
[5] ISO, "Codes for the Representation of Names of Countries",
ISO-3166, International Standards Organization, May 1981.
[5] ISO(「国の名前の表現のためのコード」、ISO-3166、世界規格組織)は1981がそうするかもしれません。
[6] Postel, J., "Domain Name System Implementation Schedule -
Revised", RFC-921, USC Information Sciences Institute, October
1984.
[6] ポステル、J.、「ドメインネームシステム遂行スケジュール--復習する」、RFC-921、科学が設けるUSC情報、10月1984
[7] Mockapetris, P., "The Domain Name System", Proceedings of the
IFIP 6.5 Working Conference on Computer Message Services,
Nottingham, England, May 1984. Also as ISI/RS-84-133,
June 1984.
[7] Mockapetris、P.、「ドメインネームシステム」(コンピュータメッセージサービス、ノッティンガム、イギリスにおけるIFIP6.5の働くコンファレンスの議事)は1984がそうするかもしれません。 ISI/RS-84-133、1984年6月としても。
[8] Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design
for Distributed Systems", Proceedings of the Seventh
International Conference on Computer Communication, October 30
to November 3 1984, Sidney, Australia. Also as ISI/RS-84-132,
June 1984.
コンピュータコミュニケーション、10月30日から1984年11月3日、シドニー、オーストラリアにおける第7国際会議の[8]MockapetrisとP.、J.ポステルとP.カートン、「分散システムのためのネームサーバデザイン」議事。 ISI/RS-84-132、1984年6月としても。
Postel & Reynolds [Page 14]
ポステルとレイノルズ[14ページ]
一覧
スポンサーリンク
