RFC756 日本語訳

RFC: 756                                                July 1979

RFC: 756 1979年7月

    The NIC Name Server--A Datagram Based Information Utility

NICネームサーバ--データグラムは情報ユーティリティを基礎づけました。

                         by

by

   John R. Pickens, Elizabeth J. Feinler, and James E. Mathis

ジョン・R.ピケンズ、エリザベスJ.Feinler、およびジェームス・E.マシス

                            July 1979

1979年7月

                        SRI International
               Telecommunications Sciences Center
                         333 Ravenswood
                  Menlo Park, California 94025

SRIインターナショナルテレコミュニケーション科学はカリフォルニア 333レーヴンズウッドMenlo Park、94025を中心に置きます。

(Also published in Proceedings of the Fourth Berkeley Conference
on Distributed Data Management and Computer Networks)           
NIC Name Server                                         July 1979

(また、Distributed Data ManagementとコンピュータNetworksの上のFourthバークレーコンファレンスのProceedingsでは、発行されます) NICネームサーバ1979年7月

                            Abstract

要約

  In this paper a new method for distributing and updating host
name/address information in large computer networks is described.
The technique uses datagrams to provide a simple
transaction-based query/response service.  A provisional service
is being provided by the Arpanet Network Information Center (NIC)
and is used by mobile packet radio terminals, as well as by
several Arpanet DEC-10 hosts.  Extensions to the service are
suggested that would expand the query functionality to allow more
flexible query formats as well as queries for service addresses.
Several architectural approaches with potential for expansion
into a distributed internet environment are proposed.  This
technique may be utilized in support of other distributed
applications such as user identification and group distribution
for computer based mail.

この紙では、大きいコンピュータネットワークのホスト名/アドレス情報を分配して、アップデートするための新しいメソッドは説明されます。 テクニックは、簡単なトランザクションベースの質問/応答サービスを提供するのにデータグラムを使用します。 暫定的なサービスは、Arpanet Networkインフォメーション・センター(NIC)によって提供されていて、モバイルパケットラジオ端末、およびArpanet数12月-10人のホストによって利用されます。 サービスへのサービスアドレスのための質問と同様によりフレキシブルな質問形式を許容するために質問の機能性を広くする拡大が示されます。 分散インターネット環境への拡張の可能性に関するいくつかの建築アプローチが提案されます。 このテクニックはユーザ登録名などの他の分配された応用を支持して利用されたかもしれません、そして、コンピュータのためのグループ分配はメールを基礎づけました。

1. INTRODUCTION

1. 序論

  In large computer networks, such as the Arpanet [1],
network-wide standard host-addressing information must be
maintained and distributed.  To fulfill that need, the Arpanet
Network Information Center (NIC) at SRI International has
maintained, administered, and distributed the host addressing
data base to Arpanet hosts since 1972 [2].

Arpanet[1]などの大きいコンピュータネットワークでは、ネットワーク全体の標準のホストアドレス指定情報を維持されて、分配しなければなりません。 1972[2]以来、必要性(SRIインターナショナルのインフォメーション・センター(NIC)が維持したArpanet Network)は、それを実現させるために、Arpanetホストにデータベースを扱うホストを、管理して、分配しました。

  The most common method for maintaining an up-to-date copy on
each host is to bulk-transfer the entire data base to each host
individually.  This technique satisfies most host addressing
needs on the Arpanet today.  However, some hosts maintain neither
a complete nor a current copy of the data base because of limited
memory capacity and infrequent processing of updates.  In
addition, with the expansion of the Arpanet into the internet
environment [3, 4], a strong need has arisen for new techniques
to augment the distribution of name/address information.

全体のデータが個別に各ホストに基礎づけるバルク転送には各ホストの上で最新のコピーを維持するための最も多くの共通方法があります。 このテクニックは今日、Arpanetのほとんどのホストアドレシング需要を満たします。 しかしながら、アップデートの限られた記憶容量と珍しい処理のためにa完全であるのも、データベースの現在のコピーも維持しないホストもいます。 さらに、インターネット環境[3、4]へのArpanetの拡張で、新しいやり方が名前/アドレス情報の分配を増大させるように、強い必要性は起こりました。

  One method currently being investigated is the dynamic
distribution of host-address information via a transaction-based,
inquiry-response process called the Name Server [5, 6].  To
support this investigation, the NIC has developed a provisional
Name Server that is compatible with a level of service specified
in the Defense Advanced Research Projects Agency (DARPA) Internet
experiment [5].  The basic Name Server is described in this paper
and a set of additional functions that such a service might be
expected to support is proposed.

現在調査される1つのメソッドはName Server[5、6]と呼ばれるトランザクションベースの問い合せ応答プロセスを通したホスト・アドレス情報のダイナミックな分配です。 この調査をサポートするために、NICは国防高等研究計画庁(DARPA)のインターネット実験[5]で指定されるサービスのレベルと互換性がある暫定的なName Serverを開発しました。 基本的なName Serverはこの紙で説明されます、そして、そのようなサービスがサポートすると予想されるかもしれない1セットの追加機能は提案されます。

  The discussion is structured as follows:  Section 1 describes
the NIC Name Server and how it is derived from the NIC data base
service.  Section 2 describes extensions of the name server which
allow a richer syntax and queries for service addresses.  Section

議論は以下の通り構造化されます: セクション1はNIC Name ServerとNICデータベースサービスからそれをどう得るかを説明します。 セクション2はサービスアドレスのための、より豊かな構文と質問を許すネームサーバの拡大について説明します。 セクション

SRI International                                        [Page 1]

SRIインターナショナル[1ページ]1979年7月のNICネームサーバ

3 discusses architectural issues, and presents some preliminary
thoughts on how to evolve from the current centralized,
hierarchic service to a distributed Name Server service.

3 構造的な問題について議論して、分配されたName Serverサービスに対する現在の集結されて、階層的なサービスからどう発展するかに関するいくつかの予備の考えを提示します。

2. THE NIC NAME SERVER

2. NICネームサーバ

  A Name Server service has been installed on SRI-KA, an Arpanet
DEC-10.  Inquiry-response access is via the Internet Name Server
protocol [5], which in turn employs the DARPA Internet Protocol,
IP4 [7].

Name ServerサービスはSRI-kA、Arpanet12月-10にインストールされました。 IP4[7]、問い合せ応答アクセスがインターネットName Serverプロトコル[5]であります。(順番に、それは、DARPAインターネットプロトコルを使います)。

  To demonstrate the service a simple interactive facility is
provided to format user input into name server requests--e.g. a
query of the form !ARPANET!FOO-TENEX returns an address such as
"10 2 0 9" (NET=10, HOST=2, LOGICALHOST=0, IMP=9; for details of
host address formats see [8]).

サービスを示すために、ネームサーバ要求への形式ユーザ入力に簡単な対話的な施設を提供します--例えば、形式の質問。FOO-TENEXがアドレスを返すアルパネット!、「10、2 0、9インチ、(ネット=10、ホスト=2、LOGICALHOST=0、ホストアドレス形式の詳細のための悪童=9が[8])を見る、」

  User access to the name server has been implemented on several
Arpanet DEC-10 TENEX and Packet Radio Network LSI-11 Terminal
Interface Unit (TIU) hosts [9, 10].  While the TENEX program
serves primarily as a demonstration vehicle, the LSI-11 program
provides a valuable augmentation of the TIU's host table.  A
typical scenario is that when the packet radio TIU is initiated
or initialized, it contains only a minimal host table, with the
addresses of a few candidate name servers.  The user queries the
name server with a simple manual query process, and then uses the
address obtained to open a TELNET connection to the desired host.

ネームサーバへのユーザアクセスは数個Arpanet12月-10TENEXとLSI-11人のPacket Radio Network Terminal Interface Unit(TIU)ホスト[9、10]の上で実装されました。 TENEXプログラムは主としてデモンストレーション乗り物として機能しますが、LSI-11プログラムはTIUのホストテーブルの貴重な増大を提供します。 典型的なシナリオはパケットラジオTIUが開始されるか、または初期化されるとき、最小量のホストテーブルだけを含んでいるということです、いくつかの候補ネームサーバのアドレスで。 ユーザは、簡単な手動の質問プロセスでネームサーバについて質問して、次に、TELNET接続を開くために得られたアドレスを必要なホストに使用します。

  The information to support the name server originates from the
NIC's Arpanet host address data base.  An optimized version of
this data base is presented to the name server upon program
initiation as an input file.

ネームサーバをサポートする情報はNICのArpanetホスト・アドレスデータベースから発します。 このデータベースの最適化されたバージョンはプログラム起動のときに入力ファイルとしてネームサーバに提示されます。

3. NAME SERVER ISSUES

3. ネームサーバ問題

  The basic name server provides a simple address-binding service
[5].  In response to a datagram query [7, 11], the name server
returns either an address, a list of similar names if a unique
match is not found, or an error indication.  Several useful
additional functions can be envisioned for the name server such
as service queries and broader access to host-related
information.

基本的なネームサーバは簡単なアドレス結合サービス[5]を提供します。 データグラム質問[7、11]に対応して、ネームサーバはユニークなマッチが見つけられないか、そして、誤り表示をアドレス、同様の名前のリストに返します。 ホスト関連の情報へのサービス質問であって、より広いアクセスなどのネームサーバのためにいくつかの役に立つ追加機能を思い描くことができます。

3.1. Similar Names

3.1. 同様の名前

  An important issue to be resolved is that of the interpretation
given to the "similar names" response.  A standard definition
should be given and not be left to implementors' whims.

応答という「同様の名前」に考えて、決議されるべき切迫した課題は解釈のものです。 標準定義を与えて、作成者の気まぐれに残すべきではありません。

[Page 2]                                        SRI International

[2ページ] SRIインターナショナルNICネームサーバ1979年7月

  If the "similar names" response is used primarily to provide
helpful information to a human-interface process, then it may be
useful to model the behavior of the name server on the behavior
of other known processes that present host name information on
demand.  An example of this is a common implementation of virtual
terminal access on the Arpanet, User TELNET [12], in which three
different functions occur:

応答という「同様の名前」が主としてヒューマンインターフェースプロセスに役立つ情報を提供するのに使用されるなら、オンデマンドのホスト名情報を提示する他の知られているプロセスの振舞いにネームサーバの振舞いを似せるのは役に立つかもしれません。 この例はArpanet、3つの異なった機能が起こるUser TELNET[12]における仮想端末アクセスの一般的な実装です:

  1. Upon termination of host name input (e.g. <CR>), the
     user is warned only with an audible alarm if the name
     used is not unique.  If the name is unique, the name is
     completed, and the requested operation is initiated.

1. ホスト名入力(例えば、<CR>)の終了のときに、ユーザは単に聞きとれるアラームで使用という名前がユニークでないかどうか注意されます。 名前がユニークであるなら、名前は完成します、そして、要求された操作は開始されます。

  2. In response to <ESC>, either the name will be completed
     if unique or the user will be warned with an audible
     alarm if the name is not unique.

2. <ESC>に対応して、完成していますが、名前がユニークになるだろうか、またはユーザは聞きとれるアラームで名前がユニークでないかどうか注意されるでしょう。

  3. Only in response to "?" will a list of similar names be
     printed.  "Similar names", in this case, means all
     names that begin with the same character string.  The
     list is alphabetized.

3. 単に“?"に対応して、同様の名前のリストは印刷されるでしょう。 「同様の名前」はこの場合同じ文字列で始まるすべての名前を意味します。 リストはアルファベット順にされます。

  In support of this style of user interface, it may be
appropriate to return the "similar names" response only when
requested.  Two ways to achieve this might be either to set an
option bit or to use "?" to force the similar names response.

このスタイルのユーザーインタフェースを支持して、要求される場合にだけ、応答という「同様の名前」を返すのは適切であるかもしれません。 これを達成する2つの方法が、オプションビットを設定するか、または応答という同様の名前を強制するのに“?"を使用するためにはどちらかであるかもしれません。

3.2. Query Syntax

3.2. 質問構文

  A second issue in the provision of name server service is that
of query syntax.  The basic level of service previously described
allows only a few query functions.  With more intelligent name
servers, complex queries can be supported.

ネームサーバサービスの支給における第2刷は質問構文のものです。 以前に説明されたサービスの基礎水準はほんのいくつかの質問機能を許容します。 より知的なネームサーバで、複雑な質問をサポートすることができます。

  The current Internet name server requires two fields in the
query string--a network name field and a host name field.  If the
network field is non-existent, a local network query is assumed.

現在のインターネットネームサーバは質問ストリングの2つの分野を必要とします--ネットワーク名分野とホスト名分野。 ネットワーク分野が実在しないなら、企業内情報通信網質問は想定されます。

  Since network independent queries are desirable, an expanded
query functionality must be specified.  One way this might be
done is to add to the notion of "missing field", which means
"local", the notion of a special character like "*", which means
"all".

ネットワーク以来、独立している質問が望ましい、拡張質問の機能性を指定しなければなりません。 これが完了しているかもしれない1つの方法は「地方であること」を意味する「なくなった分野」の概念に加えることです、「*」のような特殊文字の概念、「すべて」を意味するどれ。

  The semantic range of queries afforded by adopting this
convention is listed below (Note: ~ is used to mean "null".  If
both network and host fields are null the representation is "~
~".  "N" means "network" and "H" means "host"):

: ~、は、「ヌルであること」を意味するのに使用されます。「このコンベンションを採用しながら提供された意味範囲の質問は(両方が分野をネットワークでつないで、接待するならヌル」 . 」 ~~、が「N」であるという手段が「ネットワークでつなぐ」表現と「H」手段が「ホスト」であるという注意)の下に記載されています:

SRI International                                        [Page 3]

SRIインターナショナル[3ページ]1979年7月のNICネームサーバ

~  ~    local net, local host (validity check?)

~~地元のネットの、そして、地元のホスト(バリディティチェック)?

~  *    local net, all hosts

~ * ローカルのネット、すべてのホスト

~  H    local net, named host

~ H地元のネットの、そして、命名されたホスト

*  ~    all nets, local host (inverse search)

* ~ すべてのネット、ローカル・ホスト(逆さの検索)

*  *    all nets, all hosts (probably prohibited)

* * すべてのネット、すべてのホスト(たぶん禁止されています)

*  H    all nets, named host

* ホストは、Hがすべて網状になると命名しました。

N  ~    named net, local host (inverse search)

ネットの、そして、地元のホストというN~(逆さの検索)

N  *    named net, all hosts

ネット、すべてのホストというN*

N  H    named net, named host

ホストは、N Hがネットを命名したと命名しました。

  By combining the on-demand similar-names function, "all" and
"local", and by allowing "*" to be prefixed or appended to the
query string as a wild card character, one can query as follows:

「すべて」の、そして、「地方」の要求次第の同様の名前機能を結合して、「*」がワイルドカードキャラクタとして質問ストリングに前に置かれているか、または追加されるのを許容することによって、1つは以下の通り以下について質問できます。

~  SRI*?        All hosts named SRI* on local net

~SRI*?ローカルのネットのSRI*というAllホスト

*  SRI*?        All hosts named SRI* on all nets

* SRI*?すべてのネットのSRI*というAllホスト

*  *UNIX*?      All hosts named *UNIX* on all nets

* *UNIX*?すべてのネットの*UNIX*というAllホスト

3.3. Service Queries

3.3. サービス質問

  It has been suggested that the name server be generalized into
a binding function [13, 14].  In this context, allowing service
queries is a very useful extension.  One application of this
service, that exists within the Packet Radio Project at SRI, is
the need to find the addresses of Hosts that support the
LoaderServer service--a service that allows packet radio TIUs to
receive executable programs via downline loading.

ネームサーバが拘束力がある機能[13、14]に一般化されることが提案されました。 このような関係においては、サービス質問を許すのは、非常に役に立つ拡大です。 Hostsのアドレスがそのサポートであることがわかる必要性はLoaderServerサービスです--このサービスのある応用であり、それはSRIのPacket Radio Projectの中に存在していて、パケットラジオTIUsがダウンラインローディングで実行可能プログラムを受け取ることができるサービス?

  Service querying, unlike host names querying, requires a
multiple response capability.  The querying process would, upon
receiving multiple service descriptors, attempt to establish
access to each service, one at a time, until successful.

ホスト名と異なって質問しているサービス質問は複数の応答能力を必要とします。 複数のサービス記述子を受け取るとき、質問プロセスは、各サービスへのアクセスを確立するのを試みるでしょう、一度に一つ、うまくいくまで。

  Service descriptors consist of an official name, a list of
alias names, and a network-dependent address.  In the case of
Arpanet Internet services, this address field would consist of
the host address(32 bits), port(32 bits), and protocol number(8
bits).  For Arpanet NCP services, the address would consist of a
host address(24 bits) and a socket(32 bits).

サービス記述子は正式名称、別名のリスト、およびネットワーク依存するアドレスから成ります。 Arpanetインターネットのサービスの場合では、このアドレス・フィールドはホスト・アドレス(32ビット)、ポート(32ビット)、およびプロトコル番号(8ビット)から成るでしょう。 Arpanet NCPサービスのために、アドレスはホスト・アドレス(24ビット)とソケット(32ビット)から成るでしょう。

[Page 4]                                        SRI International

[4ページ] SRIインターナショナルNICネームサーバ1979年7月

  Syntactically, service queries can be derived from host queries
by the addition of a service name field, as below:

シンタクス上、サービス名前欄の追加でホスト質問から派生できて、以下の質問を修理してください:

                        NET HOST SERVICE

正味のホストサービス

  A network-independent service query, for example, can be
represented as:

以下として例えばネットワークから独立しているサービス質問を表すことができます。

                           * * SERVICE

* * サービス

3.4. Name Server Options

3.4. ネームサーバオプション

  The concept of options has been introduced in the discussion of
the "similar names" function.  Another group of options may be
used to specify the format of the reply.  At one extreme is the
compact, binary, style such as exists in the basic level of
service.  At the other extreme is an expanded, textual, style
such as is represented by a NIC host table record with official
and alias names included.  Options can be envisioned that
specify:

オプションの概念は機能という「同様の名前」の議論で紹介されました。 オプションの別のグループは、回答の形式を指定するのに使用されるかもしれません。 極端は1時にサービスの基礎水準に存在するようにコンパクトで、2進のスタイルです。 それとは正反対に、職員と別名があるNICホストテーブル記録によって表されるような広げられて、原文のスタイルは含まれていますか? 指定するオプションは思い描くことができます:

   - Binary versus text format

- テキスト形式に対して2進です。

   - Inclusion of each field in the reply

- 回答でのそれぞれの分野の包含

   - Inclusion of official name, per field, in the reply

- 回答における分野あたりの正式名称の包含

   - Inclusion of alias names, per field, in the reply

- 回答における分野あたりの別名の包含

   - Inclusion of other miscellaneous information, such as
     operating system, machine type, access restrictions,
     and so on.

- オペレーティングシステムなどの他の種々雑多な情報の包含、マシンタイプは制限などにアクセスします。

Other options can be envisioned that specify the scope of the
search, such as "find SERVER hosts only".  An alternate form for
specifying formats might be to settle on several standard ones,
and allow an option to select among them.

検索の範囲を指定して、「SERVERホストだけを見つける」別の選択肢は、思い描くことができます。 形式を指定するための代替のフォームは、いくつかの標準のものについて決めて、それらの中で選択するオプションを許容することであるかもしれません。

  Certainly, not all name servers can support all such options,
and not all options are equally useful.  Thus, the proposed list
will be expanded or contracted to fit the actual needs of
processes using the name server service.

確かに、すべてではなく、ネームサーバがすべてではなく、そのようなすべてのオプションをサポートできるので、オプションは等しく役に立ちます。 したがって、提案されたリストは、ネームサーバサービスを利用することでプロセスの実際の必要性に合うように膨張するか、または収縮するでしょう。

3.5. MORE DATA Protocol

3.5. より多くのデータプロトコル

  It should be noted that some of the proposed name server
extensions have the potential for generating more than a single
datagram's worth of reply, since the current DARPA Internet
Protocol limits the size which all networks must support to 576
octets [15].  In spite of this, the size of such replies need not
require a full-blown stream protocol.  Several alternatives

提案されたネームサーバ拡大のいくつかが生成することの可能性を単一のデータグラムの回答の価値より多くにすることに注意されるべきであり、現在のDARPAインターネットプロトコル限界以来、すべてがネットワークでつなぐサイズは、八重奏が[15]であると576にサポートしなければなりません。 これにもかかわらず、そのような回答のサイズは完全なストリームプロトコルを必要とする必要はありません。 いくつかの選択肢

SRI International                                        [Page 5]

SRIインターナショナル[5ページ]1979年7月のNICネームサーバ

exist:

存在しています:

  1. Disallow options that imply large replies.

1. 大きい回答を含意するオプションを禁じてください。

  2. Truncate the packet for large replies.

2. 大きい回答のためにパケットに先端を切らせてください。

  3. Ignore the recommended maximum datagram size.

3. お勧めの最大のデータグラムサイズを無視してください。

  4. Utilize an alternate base protocol for such requests.

4. 代替のベースプロトコルをそのような要求に利用してください。

  5. Develop a MORE DATA protocol.

5. MORE DATAプロトコルを開発してください。

If alternative 1 is chosen, the potential for overflow exists,
even with the basic level of service.  Alternative 2 implies
unpredictable behavior to the user of the name server service.
Alternative 3 reduces the availability of the service.
Alternative 4 is certainly possible, but may be overkill.

代替の1が選ばれているなら、オーバーフローの可能性はサービスの基礎水準があっても存在しています。 代替手段2はネームサーバサービスのユーザへの予測できない振舞いを含意します。 代替手段3はサービスの有用性を減らします。 代替手段4は、確かに可能ですが、過剰殺傷であるかもしれません。

  Alternative 5 appears to be a reasonable solution and could be
implemented very simply.  The name server could return, as part
of the reply, a code of the following form:

代替手段5は、妥当なソリューションであるように見えて、非常に単に実装することができました。 ネームサーバは回答の一部として以下のフォームのコードを返すかもしれません:

                       +------+---------+
                       | MORE | ID_NEXT |
                       +------+---------+

+------+---------+ | more| 次のID_| +------+---------+

where ID_NEXT is a name-server-chosen quantity that allows the
name server to find the next block of reply, the next time it is
queried.  This quantity may be an internal pointer, a block
number, or whatever the name server chooses.  Follow-on queries
may be implemented by recomputing the entire original query and
discarding output until the ID_NEXT block is reached, or by
efficiently storing the entire reply in a cache, fragmented into
blocks (with appropriate decay algorithms).

ID_ネクストがネームサーバが回答の次のブロックを見つけることができる選ばれた名前サーバ量であるところでは、次の時に、それは質問されます。 この量は、内部の指針、街区番号、またはネームサーバが選ぶことなら何でもであるかもしれません。 全体のオリジナルの質問を再計算して、ID_ネクストブロックに達するまで出力を捨てるか、またはブロックに断片化されたキャッシュで効率的に全体の回答を保存することによって(適切な腐敗アルゴリズムがある)、フォローオン質問は実装されるかもしれません。

3.6. Dynamic Updates

3.6. ダイナミックなアップデート

  In the previous discussion, the host name data base was assumed
to have been a static or slowly changing entity with an
administrative and manual update authority.  This model reflects
most of the network needs in the Arpanet and Internet
communities.  However, dynamic automated updating of the host
table may be needed in the future, especially in mobile
environments such as the Packet Radio Network.

前の議論では、ホスト名データベースは管理の、そして、手動の更新権限がある静的であるかゆっくり変化している実体であると思われました。 このモデルはネットワークの必要性の大部分をArpanetとインターネットコミュニティに反映します。 しかしながら、ホストテーブルのダイナミックな自動化されたアップデートが将来必要であるかもしれません、特にPacket Radio Networkなどのモバイル環境で。

  In a closed user group community (such as a local network of
mutually trusting hosts), dynamic updating becomes simply a
technical question concerning packet formats.  In wider
communities, a mechanism to authenticate the change request must
be developed; however, the authentication issue is outside the
scope of this paper.

クローズド・ユーザ・グループ共同体(互いにホストを信じる企業内情報通信網などの)では、ダイナミックなアップデートはパケット・フォーマットに関して単に技術的な質問になります。 より広い共同体では、変更要求を認証するメカニズムを開発しなければなりません。 しかしながら、この紙の範囲の外に認証問題があります。

[Page 6]                                        SRI International

[6ページ] SRIインターナショナルNICネームサーバ1979年7月

4. ARCHITECTURE

4. アーキテクチャ

  The Name Server concept is invaluable for allowing hosts with
incomplete knowledge of the network address space to obtain full
access to network services.  Whether for reasons of insufficient
kernel space or of dynamically changing environments, the need
for the service is little questioned.  However, significant
design issues revolve around the methods for providing the
service and for administering and updating the data base.

ネットワークアドレス空間に関する不完全な知識をもっているホストがネットワーク・サービスへの完全なアクセスを得るのを許容するのに、Name Server概念は非常に貴重です。 不十分なカーネルスペースかダイナミックに変化している環境の理由で、サービスの必要性は少ししか質問されるのでないかどうか しかしながら、重要なデザイン問題はデータベースをサービスを提供して、管理して、アップデートするためのメソッドを中心題目とします。

  In the current NIC Name Server, the service is centralized, and
is supported by a data base administered by a single authority.
In the long range, other architectures are possible that present
more flexible ways to distribute host information within and
between networks and administrative entities.  These present
opportunities for dynamic, automated, approaches to the
maintenance and sharing of data--particularly host name data.

現在のNIC Name Serverでは、サービスは、集結されて、ただ一つの権威によって管理されたデータベースで後押しされています。 長い範囲では、他のアーキテクチャが実体以内とネットワークと管理実体の間にホスト情報を分配する可能なそんなに現在の以上フレキシブルな方法です。 これらはデータのメインテナンスと共有へのダイナミックで、自動化されたアプローチの機会を提示します--特にホスト名データ。

  From an evolutionary point of view, initial Name Server
services will likely exist as a centralized service, possibly
with one large Name Server that has knowledge of multiple
networks.  From this beginning, an expansion in two orthogonal
directions can be envisioned.

進化論の観点から、初期のName Serverサービスは集結されたサービスとしておそらく存在するでしょう、ことによると複数のネットワークに関する知識を持っている1大きいName Serverと共に。 この始めから、2つの直交した方向での拡張を思い描くことができます。

   - In the direction of internal distribution, the name
     server can be partitioned into multiple, cooperating
     processes on separate hosts.  The data base can be
     replicated exactly or managed as a distributed data
     base.

- 内部の分配の向きに、別々のホストで複数の、そして、協力関係を持っているプロセスにネームサーバを仕切ることができます。 データベースにまさに模写するか、または分散形データベースとして対処できます。

   - In the direction of administrative distribution,
     multiple autonomous name servers may exist that
     exchange data in an appropriate fashion, on a per
     network or other administrative basis.

- 管理分配の向きに、適切なファッションによるデータを交換する複数の自治のネームサーバが存在するかもしれません、1ネットワークあたりのaか他の管理ベースで。

  For hosts with small host tables, caching might be used,
whereby local, temporary copies would be maintained of subsets of
the addressing data base.  Such copies may be obtained either by
remembering previous queries made of name servers, or by
receiving automatic distributions of data from name servers.  For
mobile hosts, in which even the home network is unknown, it would
be possible to maintain a very sparse table with the addresses of
only a few name servers.

小さいホストテーブルをもっているホストのために、キャッシュ(地方的、そして、一時的なコピーはアドレシングデータベースの部分集合について維持される)は使用されるかもしれません。 ネームサーバでされた前の質問を覚えているか、またはネームサーバからデータの自動配を受けることによって、そのようなコピーを入手するかもしれません。 モバイルホストにとって、ほんのいくつかのネームサーバのアドレスがある非常にまばらなテーブルを維持するのは可能でしょう。そこでは、ホームネットワークさえ未知です。

  For hosts lacking even the knowledge of name server addresses,
a very primitive name server function can be provided by all
network hosts that would allow real name servers to be located;
e.g., a query of the form "*  *  RealNameServer" addressed to an
arbitrarily selected host could elicit the address of a real Name
Server.

ネームサーバアドレスに関する知識さえ欠いているホストにとって、本名サーバが見つけられるのを許すすべてのネットワークホストが非常に原始のネームサーバ機能を提供できます。 」 **RealNameServerを形成してください。「例えば、質問、」 任意に選択されたホストに扱われて、本当のName Serverのアドレスを引き出すことができました。

  Finally, the possibility exists for multiple name servers to
communicate dynamically in attempting to resolve queries.  If,

最終的に、可能性は、質問を決議するのを試みる際に複数のネームサーバがダイナミックに交信するために存在しています。 ,

SRI International                                        [Page 7]

SRIインターナショナル[7ページ]1979年7月のNICネームサーバ

for example, a name server on the Arpanet receives a query for a
host on the Packet Radio Network, then the Arpanet name server
can conceivably query the Packet Radio Network Name Server to
resolve the reply.

例えば、Arpanetの上のネームサーバはPacket Radio Networkでホストのための質問を受けて、次に、Arpanetネームサーバは、回答を決議するために多分Packet Radio Network Name Serverについて質問できます。

5. FUTURE WORK

5. 今後の活動

  The techniques discussed in this paper for providing dynamic
access to and maintenance of host address information are
generally applicable to other information-providing services.
Two possibilities currently under investigation at SRI include
user identification servers [16] and time servers, which offer
people/address and time-stamp information, respectively, as
datagram driven information utilities.

一般に、ホストアドレス情報の動的呼出しとメインテナンスを提供するためのこの紙で議論したテクニックは他の情報を提供するサービスに適切です。 現在SRIの調査中の2つの可能性がユーザ登録名サーバ[16]と時間サーバを含んでいます。(サーバはデータグラム駆動の情報ユーティリティとしてそれぞれ人々/アドレスとタイムスタンプに情報を提供します)。

  Further work is needed to refine the implementation of the name
server and its using query processes.  Two items in particular
are direct system calls into the NIC data base management system
for general access to host information and process-level query
interfaces for using processes.  The design issues for efficient
implementation are complex and involve some trade-offs.  The most
obvious trade-off is volume of network traffic versus "freshness"
of information. The local host table handler can either send a
message to the name server for every address request, or it can
use some type of local cache to remember frequently requested
names.  SRI is exploring both the process-level interface for the
LSI-11 TIU and the problems of local host table management in
small machines operating in a dynamic environment.

さらなる仕事は、ネームサーバの実装を洗練するのが必要であり、それは質問プロセスを使用することです。 特に2つの項目がホスト情報への一般的なアクセスのNICデータベースの管理システムとプロセスを使用するためのプロセスレベル質問インタフェースへのダイレクトシステムコールです。 効率的な実装のためのデザイン問題は、複雑であり、いくつかのトレードオフにかかわります。 最も明白なトレードオフはネットワークトラフィック対情報の「新しさ」のボリュームです。 ローカル・ホストのテーブル操作者があらゆるアドレス要求のためにメッセージをネームサーバに送ることができますか、またはそれは、頻繁に要求された名前を覚えているのにタイプのローカルなキャッシュを使用できます。 SRIは、動的環境で作動しながら、小さいマシンでLSI-11TIUのためのプロセスレベルインタフェースとローカル・ホストテーブル管理の問題の両方を探っています。

  Information services such as the Name Server are integral
components of distributed systems and applications.  However, the
effective utilization of such services is a relatively unstudied
and unexplored area.  One area in which SRI plans to study their
impact on distributed architectures is in computer based mail
applications.  Information utilities in this environment can
range from the support of simple mailbox address queries to
complex address list management needed for inter-organizational
and group resolution.

Name Serverなどの情報サービスは分散システムとアプリケーションの不可欠の成分です。 しかしながら、そのようなサービスの有効な利用は比較的自然に会得していて非探検された領域です。 1つの領域が分配されたアーキテクチャでそれらの影響を研究するSRI計画がコンピュータのどれであるかでメールアプリケーションを基礎づけました。 この環境における情報ユーティリティは簡単なメールボックスアドレス質問のサポートから複雑な相互組織的、そして、グループ解決に必要である住所録管理まで及ぶことができます。

6. CONCLUSION

6. 結論

  A provisional Name Server service, based on the NIC host
address data base was described in this paper.  In addition, a
collection of design ideas for an internet Name Server service
has been presented.

暫定的なName Serverサービスであり、NICに基づいてホスト・アドレスデータベースはこの紙で説明されました。 さらに、インターネットName Serverサービスのためのデザイン考えの収集は提示されました。

  Work is continuing on the refinement of the NIC name server
service.  New requirements and opportunities for functional
distribution are being investigated.  Many questions have been

仕事はNICネームサーバサービスの気品のときに続きます。 機能的分配の新しい要件と機会は調査されています。 多くの質問がありました。

[Page 8]                                        SRI International

[8ページ] SRIインターナショナルNICネームサーバ1979年7月

raised in exploring an expansion of the existing service. Such an
expansion is expected to result in more useful support of
internet (and intranet) capability.

既存にサービスの拡張を探検する際に、高くします。 そのような拡張がインターネット(そして、イントラネット)能力の、より役に立つサポートをもたらすと予想されます。

REFERENCES

参照

1.    L. G. Roberts and B. D. Wessler, "Computer Network
      Development to Achieve Resource Sharing," in Proceedings of
      SJCC, pp. 543-549 (AFIP, 1970).

1. L。 G。 ロバーツとB.D.Wessler、SJCC、ページのProceedingsの「リソース・シェアリングを達成するコンピュータネットワーク開発」 543-549 (AFIP、1970。)

2.    M. D. Kudlick and E. J. Feinler, Host Names On-line, RFC
      608, Stanford Research Institute, Menlo Park, California
      (January 1974).

2. M。 D。 KudlickとE.J.Feinler、ホストはメンローパーク(カリフォルニア)(1974年1月)とオンラインRFC608、スタンフォード研究所を命名します。

3.    V. G. Cerf and R. E. Kahn, "A Protocol for Packet Network
      Interconnection," IEEE Transactions on Communication
      Technology, Vol. COM-22, pp. 637-641 (1974)._

3. V。 G。 サーフとR.E.カーン、「パケット網インタコネクトのためのプロトコル」、Communication Technology、Vol.COM-22、ページのIEEE Transactions 637-641 (1974)._

4.    V. G. Cerf and P. T. Kirstein, "Issues in Packet-Network
      Interconnection," Proc. IEEE, Vol. 66, No. 11, pp.
      1386-1408 (November 1978).

4. V。 G。 サーフとP.T.カースタイン、「パケット網インタコネクトにおける問題」、Proc。 IEEE、Vol.66、No.11、ページ 1386-1408 (1978年11月。)

5.    J. Postel, Internet Name Server, IEN 89, Information
      Sciences Institute, Univ. of Southern Calif., Marina Del
      Rey, California, May 1979.

5. J。 ポステル(インターネットネームサーバ、IEN89、科学が設ける情報、南部のカリフォルニア、マリーナデル・レイ(カリフォルニア)の大学)は1979がそうするかもしれません。

6.    J. R. Pickens, E. J. Feinler and J. E. Mathis, An
      Experimental Network Information Center Name Server
      (NICNAME), IEN 103, SRI International, Menlo Park,
      California (May 1979).

6. J。 R。 ピケンズとE.J.FeinlerとJ.E.マシス、実験的なネットワークインフォメーション・センターネームサーバ(NICNAME)、IEN103、SRIインターナショナル、Menloは駐車して、カリフォルニアは(1979年5月)です。

7.    J. Postel, Internet Protocol, IEN 81, Information Sciences
      Institute, Univ. of Southern Calif., Marina Del Rey,
      California (February 1979).

7. J。 ポステル、インターネットプロトコル、IEN81、科学が設ける情報、南部のカリフォルニア、マリーナデル・レイ(カリフォルニア)(1979年2月)の大学。

8.    J. Postel, Address Mappings, IEN 91, Information Sciences
      Institute, Univ. of Southern Calif., Marina Del Rey,
      California (May 1979).

8. J。 ポステル、科学が設ける情報、南部のカリフォルニア、マリーナデル・レイ(カリフォルニア)(1979年5月)の大学にマッピング、IEN91に演説してください。

9.    R. E. Kahn, "The Organization of Computer Resources into a
      Packet Radio Network," IEEE Transactions on Communications,
      Vol. COM-25, No. 1, pp. 169-178 (January 1977).

9. R。 E。 カーン、「パケット無線ネットワークへのコンピュータリソースの組織」、Communications、Vol.COM-25、No.1、ページのIEEE Transactions 169-178 (1977年1月。)

10.   R. E. Kahn, S. A. Gronemeyer, J. Burchfiel, and R. C.
      Kunzelman, "Advances in Packet Radio Technology," Proc.
      IEEE, Vol. 66, No. 11, pp. 1468-1496 (November 1978).

10. R。 E。 カーンとS.A.グレーネマイヤー、J.BurchfielとR.C.Kunzelman、「パケットラジオ技術における進歩」Proc。 IEEE、Vol.66、No.11、ページ 1468-1496 (1978年11月。)

11.   J. Postel, User Datagram Protocol, IEN 88, Information
      Sciences Institute, Univ. of Southern Calif., Marina Del
      Rey, California (May 1979).

11. J。 ポステル、ユーザー・データグラム・プロトコル、IEN88、科学が設ける情報、南部のカリフォルニア、マリーナデル・レイ(カリフォルニア)(1979年5月)の大学。

SRI International                                        [Page 9]

SRIインターナショナル[9ページ]1979年7月のNICネームサーバ

12.   E. Leavitt, TENEX USER'S GUIDE, Bolt Beranek and Newman,
      Inc., Cambridge, Massachusetts.

12. E。 レービット、TENEX使用手引書はBeranekとニューマンInc.、ケンブリッジ、マサチューセッツをボルトで締めます。

13.   R. Bressler, A Proposed Experiment With a Message Switching
      Protocol (section on Information Operator), pp. 26-31, RFC
      333, Bolt Beranek and Newman Inc, Cambridge, Mass. (May 15,
      1972).

13. R。 Bressler、A Proposed Experiment WithはMessage Switchingプロトコル(情報Operatorの上のセクション)、ページです。 26-31 RFC333とボルトBeranekとニューマンInc、ケンブリッジ、マサチューセッツ州 (1972年5月15日。)

14.   Y. Dalal, Internet Meeting, January 24,25 1979, (Group
      Discussion).

14. Y。 Dalal、1月24日に25 1979に会うインターネット(集団討議)。

15.   J. Postel, Internet Meeting Notes - 25,26 January 1979, pp.
      12, IEN 76, Information Sciences Institute, Univ. of
      Southern Calif., Marina Del Rey, California (February
      1979).

15. J。 ポステル、インターネットMeeting Notes--25、1979年1月26日、ページ 12 IEN76、科学が設ける情報、南部のカリフォルニア、マリーナデル・レイ(カリフォルニア)(1979年2月)の大学。

16.   E. J. Feinler, "The Identification Data Base in a
      Networking Environment," in NTC '77 Conference Record, pp.
      21:3 (IEEE, 1977).

16. E。 J。 Feinler、NTC77年コンファレンスRecord、ページの「ネットワーク環境における識別情報基地」 21:3 (IEEE、1977。)

[Page 10]                                       SRI International

[10ページ] SRIインターナショナルNICネームサーバ1979年7月

                        Table of Contents

目次

1. INTRODUCTION                                                 1
2. THE NIC NAME SERVER                                          2
3. NAME SERVER ISSUES                                           2
     3.1. Similar Names                                         2
     3.2. Query Syntax                                          3
     3.3. Service Queries                                       4
     3.4. Name Server Options                                   5
     3.5. MORE DATA Protocol                                    5
     3.6. Dynamic Updates                                       6
4. ARCHITECTURE                                                 7
5. FUTURE WORK                                                  8
6. CONCLUSION                                                   8
REFERENCES                                                      9

1. 序論1 2。 NICネームサーバ2 3。 ネームサーバは3.1に2を発行します。 同様の名前2 3.2。 構文3 3.3について質問してください。 3.4に質問4を修理してください。 ネームサーバオプション5 3.5。 より多くのデータが3.6に5について議定書の中で述べます。 ダイナミックなアップデート6 4。 アーキテクチャ7 5。 今後の活動8 6。 結論8参照9

SRI International                                        [Page i]


SRIインターナショナル[ページi]