RFC921 日本語訳
0921 Domain name system implementation schedule - revised. J. Postel. October 1984. (Format: TXT=23318 bytes) (Updates RFC0897) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Jon Postel
Request for Comments: 921 ISI
October 1984
Updates: RFC 897, RFC 881
コメントを求めるワーキンググループジョンポステルRequestをネットワークでつないでください: 921 ISI1984年10月は以下をアップデートします。 RFC897、RFC881
Domain Name System Implementation Schedule - Revised
ドメインネームシステム遂行スケジュール--復習します。
Status of this Memo
このMemoの状態
This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is an update of RFC-881, and RFC-897. This is an official policy statement of the IAB and the DARPA. Distribution of this memo is unlimited.
このメモはインターネットのDomain様式Naming Systemの実装に関する施政方針です。 このメモはRFC-881、およびRFC-897の最新版です。 これはIABとDARPAの公式方針声明です。 このメモの分配は無制限です。
The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The explanation of how this system works is to be found in the references.
このメモの意図はDomain様式Naming Systemのために実装のためのスケジュールを詳しく述べることです。 このシステムがどう動作するかに関する説明は参照で見つけられることです。
The Current Situation
現在の状況
There are three aspects to the domain style naming system, (1) the names themselves, (2) the method of translating names to addresses, and (3) the relationship between the Internet and the rest of the world.
(2) ドメインスタイルへのシステム、(1)を名前自体と命名する3つの局面があって、翻訳するメソッドはインターネットと他の国々との関係をアドレス、および(3)と命名します。
Names
名前
The names are being changed from simple names, or globally unique
strings, to structured names, where each component name is unique
only with respect to the superior component name.
単純名、またはグローバルにユニークなストリングから名前を変えています、構造化された名前に。そこでは、それぞれのコンポーネント名が優れたコンポーネント名だけに関してユニークです。
Simple Names
単純名
Until recently, hosts in the DARPA research and DDN operational
communities were assigned names in a flat or global name space
of character strings. There are some limits on these names.
They must start with a letter, end with a letter or digit and
have only letters or digits or hyphen as interior characters.
Case is not significant.
最近まで、名前は文字列の平坦であるかグローバルな名前スペースでDARPA研究とDDNの操作上の共同体のホストに割り当てられました。 いくつかの限界がこれらの名前にあります。 彼らは、文字から始まって、手紙かケタで終わって、内部のキャラクタとして文字、ケタまたはハイフンしか持ってはいけません。 ケースは重要ではありません。
For example: USC-ISIF
例えば: USC-ISIF
Hierarchical Names
階層的な名前
Because of the growth of the Internet, structured names (or
domain style names) have been introduced. Each element of the
structured name will be a character string (with the same
constraints that previously applied to the simple names). The
インターネットの成長のために、構造化された名前(または、ドメインスタイル名)は紹介されました。 構造化された名前の各原理は文字列(以前に単純名に適用された同じ規制がある)でしょう。 The
Postel [Page 1]
ポステル[1ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
elements (or components) of the structured names are separated
with periods, and the elements are written from the most
specific on the left to the most general on the right.
構造化された名前の原理(または、コンポーネント)は期間で切り離されます、そして、要素は右に左で最も特定であるのから最も多くの一般まで書かれています。
For example: USC-ISIF.ARPA
例えば: USC-ISIF.ARPA
The Initial and Temporary Domain
初期的、そして、一時的なドメイン
The introduction of these hierarchical names has been very
limited. Every current name in this new system has the form
"old-simple-name.ARPA". That is, the all the hosts are in a
domain called "ARPA". This is a temporary situation. The
current intention is for the ARPA domain to cease to exist.
This means that all hosts will change their names as the domain
style names come into full use.
これらの階層的な名前の導入は非常に限られています。 この新しいシステムのあらゆる現在の名前には、フォーム「古い簡単なname.ARPA」があります。 すなわち、すべてのホストが「アルパ」と呼ばれるドメインにいます。 これは一時的な状況です。 現在の意志はARPAドメインが消滅することです。 これは、ドメインスタイル名が完全利用に入るのに従ってすべてのホストが改名することを意味します。
Name to Address Lookup
ルックアップを扱う名前
Every host in the Internet is expected to have a way of
translating the name of any other host into its Internet address.
インターネットのすべてのホストにはいかなる他のホストの名前もインターネット・アドレスに翻訳する方法があると予想されます。
By and large, the name to address translation is done by looking
up the information in a table of all hosts.
概して、すべてのホストのテーブルの情報を調べることによって、アドレス変換への名前をします。
The maintenance of this table is centralized at the Network
Information Center (NIC). Each host is expected to obtain a
current copy of the table on a timely basis. This table is called
"HOSTS.TXT" [8] and is normally accessed via the Hostnames
Server [9].
このテーブルのメインテナンスはNetworkインフォメーション・センター(NIC)に集結されます。 各ホストがタイムリーベースでテーブルの現在のコピーを入手すると予想されます。 このテーブルは、"HOSTS.TXT"[8]と呼ばれて、ホスト名サーバ[9]で通常、アクセスされます。
Interface to the World
世界に連結してください。
A great deal of mail moves between the Internet and other
"systems" that somehow transport mail among computers. This is
currently done by hiding some sort of "other-system" addressing
information in the local-part of the mail address and using a
mail-relay host in the host-part of the mailbox.
多くのメールがコンピュータの中でどうにかメールを輸送するインターネットと他の「システム」の間で移行します。 現在、郵便の宛先の地方の部分にある種の「他のシステム」アドレス指定情報を隠して、メールボックスのホスト部分でメール中継ホストを使用することによって、これをします。
For example,
例えば
OBERST%EDUCOM.MAILNET@MIT-MULTICS.ARPA
EDMISTON.CIC@CSNET-RELAY.ARPA
OBERST%EDUCOM.MAILNET@MIT-MULTICS.ARPA EDMISTON.CIC@CSNET-RELAY.ARPA
Postel [Page 2]
ポステル[2ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
The Future Situation
将来の状況
Names
名前
Hierarchical Names
階層的な名前
The use of the hierarchical names will be greatly expanded
according to the rules established in the "Domain Requirements"
memo (RFC-920) [5].
「ドメイン要求性」というメモ(RFC-920)[5]に確立された規則に従って、階層的な名前の使用は大いに広げられるでしょう。
For example: F.ISI.USC.EDU
例えば: F.ISI.USC.EDU
There are several levels of development for use of the domain
style names.
開発のいくつかのレベルがドメインスタイル名の使用のためにあります。
First, there is the current simple substitution of the domain
style names for the old style host names. At this stage all
domain style names directly translate to host addresses (using the
NIC tables) and all domain style names have two components. The
mail system uses addresses of the form "local-part@host", where
host is a domain style host name.
まず最初に、古いスタイルホスト名のためのドメインスタイル名の現在の簡単な代替があります。 現在のところ、すべてのドメインスタイル名が直接ホスト・アドレスに翻訳されます、そして、(NICテーブルを使用して)すべてのドメインスタイル名には、2つのコンポーネントがあります。 メールシステムはホストがドメインスタイルホスト名であるフォーム" local-part@host "のアドレスを使用します。
For example: USC-ISIF.ARPA and Postel@USC-ISIF.ARPA
例えば: USC-ISIF.ARPAと Postel@USC-ISIF.ARPA
Here we expect that "USC-ISIF.ARPA" is the name of an Internet
host and that we can send mail for "Postel" to the SMTP port on
that host. It may be that some backward host can still fake it
by ignoring the ".ARPA" and looking up an address for
"USC-ISIF" in some old style file.
ここで、私たちは"USC-ISIF.ARPA"がインターネット・ホストの名前であり、そのホストの上のSMTPポートに「ポステル」へのメールを送ることができると予想します。 多分、遅れているホストは、何らかの古いスタイルファイルで".ARPA"を無視して、"USC-ISIF"のためのアドレスを調べることによって、まだそれを見せかけることができます。
Second, there is an extension to more name components and more top
level domains. The mail system still uses addresses of the form
"local-part@host", where host is a domain style host name.
2番目に、より多くの名前コンポーネントと、より多くのトップ・レベル・ドメインへの拡大があります。 メールシステムはまだホストがドメインスタイルホスト名であるフォーム" local-part@host "のアドレスを使用しています。
For example: F.ISI.USC.EDU and Postel@F.ISI.USC.EDU
例えば: F.ISI.USC.EDUと Postel@F.ISI.USC.EDU
Here we expect that "F.ISI.USC.EDU" is the name of an Internet
host and that we can send mail for "Postel" to the SMTP port on
that host. It is likely that the NIC will enter these new
domain style names in the centrally maintained table (i.e.,
HOSTS.TXT) during the transition period. It is unlikely that a
backward host can hack this at all.
ここで、私たちは「F.ISI.USC.EDU」がインターネット・ホストの名前であり、そのホストの上のSMTPポートに「ポステル」へのメールを送ることができると予想します。 NICは過渡期の間、中心で維持されたテーブル(すなわち、HOSTS.TXT)のこれらの新しいドメインスタイル名を入れそうでしょう。 遅れているホストがこれを全くハックできるのは、ありそうもないです。
Third, there is an extension to domain style names that may
represent only organizations or administrative entities. Finding
a host that acts for such entities may require a level of
3番目に、組織か管理実体だけを代表するかもしれないドメインスタイル名への拡大があります。 そのような実体のための行為がレベルを必要とするかもしれないホストを見つけます。
Postel [Page 3]
ポステル[3ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
indirection in the search. The mail system may use
"local-part@domain-name", where the "domain-name" identifies a
host (as before) or an organization.
検索における間接指定。 メールシステムは" local-part@domain-name "を使用するかもしれません。そこでは、「ドメイン名」がホスト(従来と同様)か組織を特定します。
For example: USC-ISI.EDU and Postel@USC-ISI.EDU
例えば: USC-ISI.EDUと Postel@USC-ISI.EDU
Here we don't count on "USC-ISI. EDU" being the name of an
Internet host. When we want to send mail to "Postel" we ask
the domain name server about sending mail to "USC-ISI.EDU".
The server will tell us the name (and address) of a real
Internet host that handles mail on this organizations behalf,
for example, "F.ISI.USC.EDU = 10.2.0.52". We then send mail
for "Postel@USC-ISI.EDU" to the SMTP port on F.ISI.USC.EDU.
ここで、私たちは"USC-ISI"を頼りにしません。 インターネット・ホストの名前である"EDU"。 「ポステル」にメールを送りたいと思うとき、私たちは送付メールに関するドメイン名サーバを"USC-ISI.EDU"に招きます。 サーバがこれ組織に代わって例えばメールを扱う本当のインターネット・ホストの名前(そして、アドレス)を私たちに言う、「F.ISI.USC.EDU=10.2.0、0.52インチ」 そして、私たちはF.ISI.USC.EDUの上のSMTPポートに" Postel@USC-ISI.EDU "のためのメールを送ります。
Name to Address Lookup
ルックアップを扱う名前
Every host in the Internet will be expected to have a way of
translating the name of any other host into its Internet address.
インターネットのすべてのホストにはいかなる他のホストの名前もインターネット・アドレスに翻訳する方法があると予想されるでしょう。
By and large, the name to address translation will be done by
interacting with a lookup server. There will be a number of
servers that each hold a portion of the name to address
information.
概して、ルックアップサーバと対話することによって、アドレス変換への名前をするでしょう。情報を扱うためにそれぞれ名前の部分を保持する多くのサーバがあるでしょう。
The maintenance of the translation data base will be subdivided
and distributed.
翻訳データベースのメインテナンスは、細分されて、広げられるでしょう。
The design and implementation details for this service are given
in RFC-882 [2] and RFC-883 [3].
このサービスのための設計と実装詳細はRFC-882[2]とRFC-883[3]に述べられます。
Interface to the World
世界に連結してください。
Mail will continue to move between the Internet and other
"systems". This may be done by designating some sort of
"other-system" representative organization in the domain server
data bases that can indirect mail to a mail-relay host.
郵便配達人は、インターネットと他の「システム」の間で移行し続けるでしょう。 代表しているドメインサーバデータベースにおけるそうすることができるある種の「他のシステム」組織を間接的なメールに指定することによって、メール中継ホストにこれをするかもしれません。
For example,
例えば
Oberst@EDUCOM.MAILNET
Oberst@EDUCOM.MAILNET
When we want to send mail to "Oberst" we ask the domain name
server about sending mail to "EDUCOM.MAILNET". The server will
tell us the name (and address) of a real Internet host that
handles mail on this organizations behalf, for example,
"MIT-MULTICS.ARPA = 10.0.0.6". We then send mail for
"Oberst@EDUCOM.MAILNET" to the SMTP port on MIT-MULTICS.ARPA.
"Oberst"にメールを送りたいと思うとき、私たちは送付メールに関するドメイン名サーバを"EDUCOM.MAILNET"に招きます。 サーバがこれ組織に代わって例えばメールを扱う本当のインターネット・ホストの名前(そして、アドレス)を私たちに言う、「MIT-MULTICS.ARPA=10.0.0、0.6インチ」 そして、私たちはMIT-MULTICS.ARPAの上のSMTPポートに" Oberst@EDUCOM.MAILNET "のためのメールを送ります。
Postel [Page 4]
ポステル[4ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
For example,
例えば
Edmiston@CIC.CSNET
Edmiston@CIC.CSNET
When we want to send mail to "Edmiston" we ask the domain name
server about sending mail to "CIC.CSNET". The server will tell
us the name (and address) of a real Internet host that handles
mail on this organizations behalf, for example,
"CSNET-RELAY.ARPA = 10.4.0.5". We then send mail for
"Edmiston@CIC.CSNET" to the SMTP port on CSNET-RELAY.ARPA.
「エドミストン」にメールを送りたいと思うとき、私たちは送付メールに関するドメイン名サーバを"CIC.CSNET"に招きます。 サーバがこれ組織に代わって例えばメールを扱う本当のインターネット・ホストの名前(そして、アドレス)を私たちに言う、「CSNET-RELAY.ARPAが等しい、10.4 .0 0.5インチ」 そして、私たちは" Edmiston@CIC.CSNET "のためのメールをCSNET-RELAY.ARPAの上のSMTPポートに送ります。
The Transition Situation
変遷状況
Actually, the situation is a bit more complicated, of course. Hosts are already using domain style names under the constraint that their domain style name is exactly their old style name with the string ".ARPA" appended. The first transition step is to ensure that all hosts do this, and then to eliminate the use of old style names altogether.
実際に、状況がもう少し複雑である、もちろん。 ホストは既にそれらのドメインスタイル名がまさに追加するストリング".ARPA"のそれらの古いスタイル名であるという規制でドメインスタイル名を使用しています。 前縁ステップは、すべてのホストがこれをするのを保証して、そして、全体で古いスタイル名の使用をなくします。
Please note carefully that two types of changes are being made:
2つのタイプの変更は慎重に行われています:
One is a change in the support mechanism for translating a host
name to an internet address,
1つはインターネットアドレスにホスト名を翻訳するためのサポートメカニズムで変化です。
that is from using local copies of a full centrally maintained
table to dynamically accessing a distributed set of servers
each posesing a portion of a data base maintained in a
distributed fashion.
完全な中心で維持されたテーブルの地方のコピーを使用するのから分配されたファッションで維持されたデータベースの一部をposesingしながらダイナミックにそれぞれ分散セットのサーバにアクセスするまで、それはいます。
The other is a change in the host names themselves,
もう片方がホスト名自体で変化です。
from a flat global space of unstructured strings to a
hierarchical structure of names.
不統一なストリングの平坦なグローバルなスペースから名前の階層構造まで。
There are two steps to the transition plan.
変遷プランへの2ステップがあります。
First, change from old names to domain style names.
まず最初に、旧名からドメインスタイル名に変化してください。
Second, change from using central tables to using name servers.
ネームサーバを使用することによって、2番目に、変化してください。
There are two communities that are taking slightly different courses in this transition. The DARPA research community is making the full transition. The DDN operational community is making the change in naming on the same schedule, but is not requiring hosts in the DDN operational community make the change to using servers at the same
この変遷にはわずかに異なったコースを取っている2つの共同体があります。 DARPA研究団体は完全な変遷をしています。 DDNの操作上の共同体は同じスケジュールで命名の変更を行っていますが、操作上の共同体が作るDDNでホストを必要とするのは、同じくらいでサーバを使用することへの変化ではありませんか?
Postel [Page 5]
ポステル[5ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
time (they can if they want to). The DDN PMO will establish a schedule for that change at a later time. The NIC will maintain a central table of all DDN operational hosts.
時間(彼らがそうしたいなら、それらはそうすることができます)。 DDN PMOは後でその変化のためのスケジュールを確立するでしょう。 NICはすべてのDDNの操作上のホストの中央のテーブルを維持するでしょう。
Interface to the World
世界に連結してください。
The interchange of mail with "other-systems" will have to continue
pretty much as it has (except that RELAY-HOST is RELAY-HOST.ARPA)
until organization names can be used. Then representative
organizations can be designated for each "other-system" in the
domain server data bases that will then specify a mail-relay host.
「他のシステム」によるメールの置き換えはほとんど続いたように(RELAY-HOSTがRELAY-HOST.ARPAであるのを除いて)組織名を使用できるまで続かなければならないでしょう。 そして、次にメール中継ホストを指定するドメインサーバデータベースの中の各「他のシステム」のために代表している組織を指定できます。
All Hosts Change Names
すべてのホストが名前を変えます。
The impact of introducing the domain style names is that all hosts change their names at least once. Hosts that move to new domains or subdomains may change their names several times.
ドメインスタイル名を紹介する影響はすべてのホストが少なくとも一度改名するということです。 新しいドメインかサブドメインに移行するホストは何度か改名するかもしれません。
Hosts have an official (or primary) name and possibly several nicknames. When mail is sent from a host, the official name is used in the mail header address fields.
ホストには、公式の、そして、(プライマリ)の名前とことによるといくつかのあだ名があります。 ホストからメールを送るとき、メールヘッダアドレス・フィールドで正式名称を使用します。
Suppose, that in the old days before domains were thought of, a host changed its name. What is the impact on users of changing the name of a host?
ドメインの前の昔のそれが考えられて、ホストが改名したと仮定してください。 ホストの名前を変えるユーザの上の影響は何ですか?
Mail that was sent before the name was changed can not be answered
using mail program commands that automatically fill in the return
address. While it may be possible to use special tricks to fix up
the "From" or the "To" users addresses, the "Cc" addresses are
very difficult to correct.
自動的に返送先に記入するメールプログラム命令を使用することで名前を変える前に送ったメールに答えることができません。 “From"か“To"ユーザアドレスを修理するのに特別なトリックを使用するのが可能であるかもしれませんが、「cc」というアドレスは修正するのが非常に難しいです。
Suppose one host changed its name from FOO to BAR. Mail that
was sent from FRED@FOO to JOE@ABC can not be answered unless
the change of name is known to the user or the mail program at
ABC and the host name BAR substituted for FOO. Mail that is
sent to JOE@ABC from SAM@DEF with a cc to FRED@FOO can not be
answered easily.
1人のホストがFOOからBARに改名したと仮定してください。 名義変更がABCとFOOに代入されたホスト名BARでユーザかメールプログラムに知られていない場合、 FRED@FOO から JOE@ABC に送られたメールに答えることができません。 容易にccがある SAM@DEF から FRED@FOO まで JOE@ABC に送られるメールに答えることができません。
Any mailing lists that have mailboxes with the host that changed
names will now have incorrect entries.
名前を変えたホストがいるメールボックスを持っているどんなメーリングリストも現在、不正確なエントリーを持つでしょう。
The point is that while the host that changed names may be able to use special tricks for a while to fix things up for the users, it is difficult for other hosts to do this.
ポイントは名前を変えたホストがユーザのためにものを修理するのにしばらく特別なトリックを使用できるかもしれませんが、他のホストがこれをするのが、難しいということです。
Postel [Page 6]
ポステル[6ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
A general trick is to make the old name a nickname for the host for some period of time.
一般的なトリックはホストのためにいつかの期間の間、旧名をあだ名にすることです。
The introduction of domain style names means that all hosts change their names essentially at the same time.
ドメインスタイル名の導入は、すべてのホストが同時に本質的には改名することを意味します。
To lessen the havoc, there will be a period of time when both the old and the new names are allowed. That is, the old names will be nicknames for a while.
大破壊を少なくするために、老人と新しい名前の両方が許容されている期間があるでしょう。 すなわち、旧名はしばらく、あだ名になるでしょう。
Primary Names
プライマリ名前
Currently, host have an official or primary names and may have several nicknames. For example,
現在、ホストは、職員かプライマリ名前を持っていて、いくつかのあだ名を持っているかもしれません。 例えば
Primary Name Nicknames
プライマリ名前あだ名
USC-ISIF.ARPA USC-ISIF ISIF
USC-ISIF.ARPA USC-ISIF ISIF
ADA-VAX.ARPA ADA-VAX ISI-VAXB AJPO VAXB
Ada-VAX.ARPA Ada-バックスISI-VAXB AJPO VAXB
The data base is such than given any of the names for a host one can find the address, and given the address one can find the primary name.
ホスト1のための名前の与えられたどれかが、アドレスであることを見つけることができて、1つがプライマリ名前を見つけることができるアドレスを考えて、データベースはそのようなものです。
In the new domain style name system this property must be maintained. That is, given the Internet address of a host one must be able to find the primary name of that host. This calls for careful management of the distributed database by those in charge of the domains and zones.
システムという新しいドメインスタイル名では、この特性を維持しなければなりません。 すなわち、ホストのインターネット・アドレスを考えて、そのホストのプライマリ名前を見つけることができなければなりません。 これはドメインとゾーンを担当してそれらによる分散データベースの慎重な管理を求めます。
Postel [Page 7]
ポステル[7ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
The Revised Time Table
改訂されたタイムテーブル
There are three major phases to the implementation of the domain names system: (1) putting the machinery in place (servers, resolvers), (2) getting the data base installed, (3) changing the user programs (mailers, etc.).
ドメイン名システムの実装への3つの主要なフェーズがあります: (1) (2) 適所(サーバ、レゾルバ)に機械を置いて、(3) ユーザ・プログラム(郵送者など)を変えて、データベースを得るのはインストールされました。
The machinery is now (at last) well along, there is a server for
TOPS-20, and two different servers for Unix. The data base now
contains the ARPA domain and is initialized for the other top
level domains. Little has been done to change user programs to
use the new procedures.
機械が(ついに)現在ずっと良い、TOPS-20のためのサーバ、およびUnixのための2つの異なったサーバがあります。 データベースは、現在、ARPAドメインを含んで、他のトップ・レベル・ドメインに初期化されます。 少ししか、新しい手順を用いるためにユーザ・プログラムを変えるために、していません。
Done
します。
Service Design and Specification: The design and specification
for the protocol and data base were published (RFC-882, RFC-883).
デザインと仕様を修理してください: プロトコルとデータベースのためのデザインと仕様は発表されました(RFC-882、RFC-883)。
Domain Requirements Specification: The requirements for
establishing a new domain are published as an RFC (RFC-920).
ドメイン要求性仕様: 新しいドメインを確立するための要件はRFC(RFC-920)として発表されます。
Domain Style Names in Table: Hosts are using their domain style
names as their official and primary names. The standard table of
host names contains domain style names as the official and primary
name.
テーブルのドメイン様式名: ホストはそれらの公式の、そして、プライマリの名前として彼らのドメインスタイル名を使用しています。 ホスト名の標準のテーブルは公式の、そして、プライマリの名前としてドメインスタイル名を含んでいます。
Servers for ARPA Domain: Several domain name servers are in
operation to supply host name to internet address translations,
one of these servers is at the NIC.
アルパドメインへのサーバ: いくつかのドメイン名サーバがインターネットアドレス変換にホスト名を供給するために稼働中であり、これらのサーバの1つがNICにあります。
15 Dec 84 Domain Table
1984年12月15日のドメインテーブル
A master table of top level domain names and their associated
servers is established at the NIC. Probably this information will
be added to the HOSTS.TXT file as a new entry type.
最上位ドメイン名とそれらの関連サーバのマスターテーブルはNICに設立されます。 たぶん、この情報は新しいエントリータイプとしてHOSTS.TXTファイルに追加されるでしょう。
15 Jan 85 Begin New Domain Registration
1985年1月15日は新しいドメインの取得を始めます。
New domains may register according to the procedures and
restrictions described in RFC-920 [5].
RFC-920[5]で説明された手順と制限に従って、新しいドメインは登録されるかもしれません。
15 Feb 85 Major Machinery Completed
主要な機械が終了した1985年2月15日
The principal servers are up and running, there are resolvers
programmed and tested for the most popular systems (Unix 4.2bsd,
TOPS-20).
主要なサーバが活動している、最もポピュラーなシステム(unix4.2bsd、TOPS-20)がないかどうかプログラムされて、テストされたレゾルバがあります。
Postel [Page 8]
ポステル[8ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
15 May 85 Significant Use of Resolvers and Servers
レゾルバとサーバの1985年5月15日の重要な使用
Programs (e.g., Mailers, Telnet, FTP) begin regular use of the new
mechanisms (resolvers and servers). This may be done by changing
the programs to act as resolvers themselves and call on servers
directly, or to provide system calls that include the resolver
function to replace old system calls that accessed the host table.
プログラム(例えば、Mailers、Telnet、FTP)は新しいメカニズム(レゾルバとサーバ)の定期的な使用を始めます。 レゾルバ自身として機能して、直接サーバを訪問するか、またはホストテーブルにアクセスした古いシステムコールを取り替えるためにレゾルバ機能を含んでいるシステムコールを提供するためにプログラムを変えることによって、これをするかもしれません。
15 Jul 85 Implementation of the Domain Naming System Completed
命名システムが完成したドメインの1985年7月15日の実装
The goal is to complete the switch over to the domain style names
and the use of the servers by this date. All programs that
translate host name to Internet addresses should now use
procedures based on the use of the domain style names system of
resolvers and servers and the distributed data base.
目標はこの日付けまでにドメインスタイル名とサーバの使用にスイッチを完成することです。 翻訳されるすべてのプログラムがドメインスタイルの使用がレゾルバのシステム、サーバ、および分散形データベースを命名するアドレスが現在基づく手順を用いるべきであるインターネットに名前をホスティングします。
15 Sep 85 Decommission Host Table
1985年9月15日はホストにテーブルの使用を中止します。
At this point the master host table maintained by the NIC need no
longer be complete for the DARPA research community. A full table
of the DDN operational hosts will be maintained by the NIC.
ここに、DARPA研究団体には、NICによって維持されたマスターホストテーブルがもう完全である必要はありません。 DDNの操作上のホストの完全なテーブルはNICによって維持されるでしょう。
15 Oct 85 DDN Plan for Domains Name Service
1985年10月15日DDNはドメイン名前サービスの計画を立てます。
The DDN PMO may establish a plan for the future support of name to
address translations in the DDN community.
DDN PMOは名前の今後のサポートがDDN共同体で翻訳を扱う計画を確立するかもしれません。
Postel [Page 9]
ポステル[9ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
Appendix : The Old Time Table
付録: 昔テーブル
Here we present the time table from the previous schedule (RFC-897) with some comments on what was and was not accomplished.
ここで、私たちはいくつかのコメントがあるあって、達成されなかったことに関する前のスケジュール(RFC-897)からタイムテーブルを贈ります。
-- Nov 83 Plan and Schedule
-- 11月83日のプランとスケジュール
At this point the overall plan for the implementation of domain
style names and name servers, and a schedule of events was
published (RFC-881). Also the design and specification for the
protocol and data base were published (RFC-882, RFC-883).
ここに、ドメインの実装のための全体計画は名前とネームサーバを流行に合わせます、そして、イベントのスケジュールは発表されました(RFC-881)。 また、プロトコルとデータベースのためのデザインと仕様は発表されました(RFC-882、RFC-883)。
<This was done, but the schedule did not work.>
これが行われた<、スケジュールだけが仕事どんな>もしませんでした。
-- Nov 83 Initial Domain Style Host Name Table
-- 11月83日の初期のドメイン様式ホストネームテーブル
At this point a version of the host table which includes the
domain style names is made available (DHOSTS.TXT).
ここに、ドメインスタイル名を含んでいるホストテーブルのバージョンを利用可能に(DHOSTS.TXT)します。
<This was done, on schedule.>
これがスケジュール通りに行われた<、>。
-- Feb 84 Domain Requirements Specification
-- 2月84日のドメイン要件仕様
At this point the requirements for establishing a new domain are
published as an RFC.
ここに、新しいドメインを確立するための要件はRFCとして発表されます。
<This topic was much discussed in the Namedroppers mailing
list, but no RFC was published until Oct84 [5].>
<、Namedroppersメーリングリストでこの話題について非常に議論しましたが、RFCは全くOct84[5]>まで発行されませんでした。
14 Mar 84 Begin using Domain Style Names
1984年3月14日はドメイン様式名を使用し始めます。
At this point all hosts should start using their domain style
names as their official and primary names. The standard table of
host names contains domain style names as the official and primary
name (DHOSTS.TXT becomes HOSTS.TXT).
ここに、すべてのホストが、それらの公式の、そして、プライマリの名前として彼らのドメインスタイル名を使用し始めるべきです。 ホスト名の標準のテーブルは公式の、そして、プライマリの名前としてドメインスタイル名を含んでいます(DHOSTS.TXTはHOSTS.TXTになります)。
<This was done, on schedule.>
これがスケジュール通りに行われた<、>。
04 Apr 84 Server for ARPA Domain
アルパドメインへの1984年4月4日のサーバ
At this point several domain name servers are in operation to
supply host name to internet address translations, one of these
servers is at the NIC.
ここに、いくつかのドメイン名サーバがインターネットアドレス変換にホスト名を供給するために稼働中であり、これらのサーバの1つがNICにあります。
<This was done, not on schedule, but by Sep84.>
これがSep84スケジュール通りではなく、>によって行われた<。
Postel [Page 10]
ポステル[10ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
04 Apr 84 Domain Table
1984年4月4日のドメインテーブル
At this point a master table of top level domain names and their
associated servers is established at the NIC.
ここに、最上位ドメイン名とそれらの関連サーバのマスターテーブルはNICに設立されます。
<Not done yet.>
. 行われなかった<にもかかわらず、>。
02 May 84 Stop using old style Names
古いスタイルNamesを使用する1984年5月2日Stop
At this point the use of old style names must be completely phased
out.
ここに、古いスタイル名の使用を完全に段階的に廃止しなければなりません。
<I think this is done. Except that some hosts still use the
OHOSTS.TXT file.>
私がこれであると考える<は完了しています。 何人かのホストがまだ. OHOSTS.TXTファイル>を使用しているのを除いて
02 May 84 Certain New Domains
1984年5月2日のある一定の新しいドメイン
At this point a few new domains may be established, in particular
the DDN domain.
ここに、いくつかの新しいドメインが確立されるかもしれなくて、特にDDNはドメインです。
<Not done yet. Well, "DDN" won't be a top level domain
according to the new rules (see [5]).>
まだ行われていなかった<。 さて、新しい規則に従って、"DDN"はトップ・レベル・ドメインにならないでしょう。([5])を見てください、>。
06 Jun 84 General & Multilevel Domains
1984年6月6日一般と多レベルドメイン
At this point additional new domains may be established, if they
meet the requirements. Domain style names may have more than two
segments.
ここに、条件を満たすなら、追加新しいドメインは確立されるかもしれません。 ドメインスタイル名には、2つ以上のセグメントがあるかもしれません。
<Not done yet.>
. 行われなかった<にもかかわらず、>。
18 Jul 84 Organizational Domains
1984年7月18日の組織的なドメイン
Domain style names may identify organizations. Finding an address
for a host may involve a level of indirection.
ドメインスタイル名は組織を特定するかもしれません。 ホストのためにアドレスを見つけると、間接指定のレベルはかかわるかもしれません。
<Not done yet.>
. 行われなかった<にもかかわらず、>。
05 Sep 84 Decommission Host Table
1984年9月5日はホストにテーブルの使用を中止します。
At this point the master host table maintained by the NIC need no
longer be complete for the DARPA research community. A full table
of the DDN operational hosts will be maintained by the NIC.
ここに、DARPA研究団体には、NICによって維持されたマスターホストテーブルがもう完全である必要はありません。 DDNの操作上のホストの完全なテーブルはNICによって維持されるでしょう。
<Not done yet.>
. 行われなかった<にもかかわらず、>。
Postel [Page 11]
ポステル[11ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
03 Oct 84 DDN Plan for Domains Name Service
1984年10月3日DDNはドメイン名前サービスの計画を立てます。
At this point the DDN PMO will establish a plan for the future
support of name to address translations in the DDN community.
ここに、DDN PMOは名前の今後のサポートがDDN共同体で翻訳を扱う計画を確立するでしょう。
<Not done yet.>
. 行われなかった<にもかかわらず、>。
Postel [Page 12]
ポステル[12ページ]
RFC 921 October 1984 Domain Implementation Schedule - Revised
RFC921 1984年10月のドメイン遂行スケジュール--復習します。
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] Postel, J., and J. Reynolds, "Domain Requirements", RFC-920, USC
Information Sciences Institute, October 1984.
[5] USC情報科学が1984年10月に設けるポステル、J.とJ.レイノルズ、「ドメイン要求性」、RFC-920。
[6] 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.
[6] Mockapetris、P.、「ドメインネームシステム」(コンピュータメッセージサービス、ノッティンガム、イギリスにおけるIFIP6.5の働くコンファレンスの議事)は1984がそうするかもしれません。 ISI/RS-84-133、1984年6月としても。
[7] Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design
for Distributed Systems", Proceedings of the Seventh
International Conference on Computer Communication, Sidney,
Australia, October 1984. Also as ISI/RS-84-132, June 1984.
コンピュータコミュニケーション、シドニー、オーストラリア(1984年10月)における第7国際会議の[7]MockapetrisとP.、J.ポステルとP.カートン、「分散システムのためのネームサーバデザイン」議事。 ISI/RS-84-132、1984年6月としても。
[8] Feinler, E., K. Harrenstien, Z. Su, and V. White, "DoD Internet
Host Table Specification", RFC-810, Network Information Center,
SRI International, March 1982.
[8] Feinler(E.、K.Harrenstien、Z.Su、および「DoDインターネットホストテーブル仕様」、RFC-810対ホワイト)はインフォメーション・センターをネットワークでつなぎます、SRIインターナショナル、1982年3月。
[9] Harrenstien, K., V. White, and E. Feinler, "Hostnames Server",
RFC-811, Network Information Center, SRI International,
March 1982.
[9] Harrenstien(K.、V.ホワイトとE.Feinler、「ホスト名サーバ」、RFC-811)は1982年3月にインフォメーション・センター、SRIインターナショナルをネットワークでつなぎます。
Postel [Page 13]
ポステル[13ページ]
一覧
スポンサーリンク
