RFC882 日本語訳
0882 Domain names: Concepts and facilities. P.V. Mockapetris. November 1983. (Format: TXT=79776 bytes) (Obsoleted by RFC1034, RFC1035) (Updated by RFC0973) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Mockapetris
Request for Comments: 882 ISI
November 1983
Mockapetrisがコメントのために要求するワーキンググループP.をネットワークでつないでください: 882 ISI1983年11月
DOMAIN NAMES - CONCEPTS and FACILITIES
ドメイン名--概念と施設
+-----------------------------------------------------+
| |
| This RFC introduces domain style names, their use |
| for ARPA Internet mail and host address support, |
| and the protocols and servers used to implement |
| domain name facilities. |
| |
| This memo describes the conceptual framework of the |
| domain system and some uses, but it omits many |
| uses, fields, and implementation details. A |
| complete specification of formats, timeouts, etc. |
| is presented in RFC 883, "Domain Names - |
| Implementation and Specification". That RFC |
| assumes that the reader is familiar with the |
| concepts discussed in this memo. |
| |
+-----------------------------------------------------+
+-----------------------------------------------------+ | | | このRFCはドメインスタイル名、彼らの使用を導入します。| | ARPAに関しては、インターネット・メールとホストはサポートを扱います。| | そして、実装するのにおいて中古のプロトコルとサーバ| | ドメイン名施設。 | | | | このメモは概念の構成について説明します。| | ドメインシステムとしかし、いくつかの用途、それは多くを省略します。| | 用途、分野、および実装の詳細。 A| | 形式、タイムアウトなどの完全な仕様 | | RFC883に提示される、「ドメイン名、-、」| | 「実装と仕様。」 そのRFC| | 仮定、読者は詳しいです。| | このメモで議論した概念。 | | | +-----------------------------------------------------+
INTRODUCTION
序論
The need for domain names
ドメイン名の必要性
As applications grow to span multiple hosts, then networks, and
finally internets, these applications must also span multiple
administrative boundaries and related methods of operation
(protocols, data formats, etc). The number of resources (for
example mailboxes), the number of locations for resources, and the
diversity of such an environment cause formidable problems when we
wish to create consistent methods for referencing particular
resources that are similar but scattered throughout the
environment.
また、アプリケーションが複数のホスト、次に、ネットワーク、および最終的にインターネットにかかるようになるとき、これらのアプリケーションは複数の管理境界と操作の関連手法(プロトコル、データ形式など)にかからなければなりません。 環境中に同様の、しかし、点在している特定のリソースに参照をつけるための一貫したメソッドを作成したいと思うとき、リソース(例えば、メールボックス)の数、リソースのための位置の数、およびそのような環境の多様性は厄介な問題を引き起こします。
The ARPA Internet illustrates the size-related problems; it is a
large system and is likely to grow much larger. The need to have
a mapping between host names (e.g., USC-ISIF) and ARPA Internet
addresses (e.g., 10.2.0.52) is beginning to stress the existing
mechanisms. Currently hosts in the ARPA Internet are registered
with the Network Information Center (NIC) and listed in a global
table (available as the file <NETINFO>HOSTS.TXT on the SRI-NIC
host) [1]. The size of this table, and especially the frequency
of updates to the table are near the limit of manageability. What
is needed is a distributed database that performs the same
function, and hence avoids the problems caused by a centralized
database.
ARPAインターネットはサイズ関連の問題を例証します。 それは、大規模システムであり、はるかに大きくなりそうです。 ホストの間にマッピングを持つ必要性は(例えば、USC-ISIF)とARPAをインターネット・アドレスと命名します。例えば、10.2に、.52が)始まっている.0は既存のメカニズムを強調します。(現在のARPAインターネットのホストは、Networkインフォメーション・センター(NIC)に登録されていて、グローバルなテーブル(SRI-NICホストの上のファイル<NETINFO>HOSTS.TXTとして利用可能な)[1]に記載されています。 このテーブルのサイズ、および特にテーブルへのアップデートの頻度はそうです。ほぼ管理可能性の限界で。 必要であるものは同じ機能を実行して、したがって集中データベースで引き起こされた問題を避ける分散データベースです。
The problem for computer mail is more severe. While mail system
implementers long ago recognized the impossibility of centralizing
コンピュータメールのための問題は、より厳しいです。 メールシステムimplementersは昔に集結の不可能を認識しましたが
Mockapetris [Page 1]
Mockapetris[1ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
mailbox names, they have also created an increasingly large and
irregular set of methods for identifying the location of a
mailbox. Some of these methods involve the use of routes and
forwarding hosts as part of the mail destination address, and
consequently force the mail user to know multiple address formats,
the capabilities of various forwarders, and ad hoc tricks for
passing address specifications through intermediaries.
メールボックス名、また、それらはメールボックスの位置を特定するためのますます大きくて不規則なメソッドを作成しました。 これらのメソッドのいくつかによって、メール送付先アドレスの一部としてルートと推進ホストの使用を伴って、その結果、メールユーザはやむを得ず複数のアドレス形式、様々な混載業者の能力、および仲介者にアドレス指定を通すための臨時のトリックを知ります。
These problems have common characteristics that suggest the nature
of any solution:
これらの問題には、どんなソリューションの本質も示す共通する特徴があります:
The basic need is for a consistent name space which will be
used for referring to resources. In order to avoid the
problems caused by ad hoc encodings, names should not contain
addresses, routes, or similar information as part of the name.
リソースを示すのに使用される一貫した名前スペースには基本的な必要があります。 臨時のencodingsによって引き起こされた問題を避けるために、名前は名前の一部としてアドレス、ルート、または同様の情報を含むべきではありません。
The sheer size of the database and frequency of updates suggest
that it must be maintained in a distributed manner, with local
caching to improve performance. Approaches that attempt to
collect a consistent copy of the entire database will become
more and more expensive and difficult, and hence should be
avoided. The same principle holds for the structure of the
name space, and in particular mechanisms for creating and
deleting names; these should also be distributed.
データベースの全くのサイズとアップデートの頻度は地方のキャッシュで分配された方法でそれを維持して、性能を向上させなければならないのを示します。 全体のデータベースの一貫したコピーを集めるのを試みるアプローチは、ますます高価で難しくなって、したがって、避けられるべきです。 同じ原則はスペースという名前の構造、および名前を作成して、削除するための特定のメカニズムで成立します。 また、これらは分配されるべきです。
The costs of implementing such a facility dictate that it be
generally useful, and not restricted to a single application.
We should be able to use names to retrieve host addresses,
mailbox data, and other as yet undetermined information.
そのような施設を実装するコストは、それが一般に役に立って、ただ一つのアプリケーションに制限されていないと決めます。 私たちは、ホスト・アドレス、メールボックスデータ、および他のまだ非決定した情報を検索するのに名前を使用できるはずです。
Because we want the name space to be useful in dissimilar
networks, it is unlikely that all users of domain names will be
able to agree on the set of resources or resource information
that names will be used to retrieve. Hence names refer to a
set of resources, and queries contain resource identifiers.
The only standard types of information that we expect to see
throughout the name space is structuring information for the
name space itself, and resources that are described using
domain names and no nonstandard data.
私たちが、名前スペースに異なったネットワークで役に立って欲しいと思うので、ドメイン名のすべてのユーザが名前が検索するのにおいて使用するというリソースかリソース情報のセットに同意できるのは、ありそうもないです。 したがって、名前は1セットのリソースを示します、そして、質問はリソース識別子を含んでいます。 私たちが、スペースという名前中で見ると予想するという唯一の標準体型の情報は名前スペース自体にもかかわらず、ドメイン名を使用することで説明されるリソースにもかかわらず、標準的でないデータでない情報を構造化しています。
We also want the name server transactions to be independent of
the communications system that carries them. Some systems may
wish to use datagrams for simple queries and responses, and
only establish virtual circuits for transactions that need the
reliability (e.g. database updates, long transactions); other
systems will use virtual circuits exclusively.
また、私たちは、ネームサーバトランザクションにそれらを運ぶ通信網から独立していて欲しいと思います。 いくつかのシステムが、簡単な質問と応答にデータグラムを使用することを願って、信頼性(例えば、データベース更新、長いトランザクション)を必要とするトランザクションのために仮想の回路を確立するだけであるかもしれません。 他のシステムは排他的に仮想の回路を使用するでしょう。
Mockapetris [Page 2]
Mockapetris[2ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
Elements of the solution
ソリューションのElements
The proposed solution has three major components:
提案されたソリューションには、3個の主要コンポーネントがあります:
The DOMAIN NAME SPACE, which is a specification for a tree
structured name space. Conceptually, each node and leaf of the
domain name space tree names a set of information, and query
operations are attempts to extract specific types of
information from a particular set. A query names the domain
name of interest and describes the type of resource information
that is desired. For example, the ARPA Internet uses some of
its domain names to identify hosts; queries for address
resources return ARPA Internet host addresses. However, to
preserve the generality of the domain mechanism, domain names
are not required to have a one-to-one correspondence with host
names, host addresses, or any other type of information.
DOMAIN NAME SPACEであり、どれが木のための仕様であるかは名前スペースを構造化しました。 概念的に、ドメイン名スペース木の各ノードと葉は1セットの情報を命名します、そして、質問操作は特定のセットから特定のタイプの情報を抜粋する試みです。 質問は、興味があるドメイン名を命名して、望まれているリソース情報のタイプについて説明します。 例えば、ARPAインターネットはホストを特定するのにドメイン名のいくつかを使用します。 アドレスリソースのための質問はARPAインターネット・ホストにアドレスを返します。 しかしながら、ドメインメカニズムの一般性を保存するために、ドメイン名はホスト名、ホスト・アドレス、またはいかなる他の情報の種類との1〜1つの通信も持つのに必要ではありません。
NAME SERVERS are server programs which hold information about
the domain tree's structure and set information. A name server
may cache structure or set information about any part of the
domain tree, but in general a particular name server has
complete information about a subset of the domain space, and
pointers to other name servers that can be used to lead to
information from any part of the domain tree. Name servers
know the parts of the domain tree for which they have complete
information; these parts are called ZONEs; a name server is an
AUTHORITY for these parts of the name space.
NAME SERVERSはドメイン木の構造の情報を保持して、情報を設定するサーバプログラムです。 ネームサーバは、ドメイン木のどんな部分に関しても構造をキャッシュするか、または情報を設定するかもしれませんが、特定のネームサーバには、一般に、ドメイン木のどんな部分からも情報に通じるのに使用できるドメインスペースの部分集合、および他のネームサーバへの指針の完全な情報があります。 ネームサーバはそれらには完全な情報があるドメイン木の部分を知っています。 これらの部品はZONEsと呼ばれます。 ネームサーバはスペースという名前のこれらの部分へのAUTHORITYです。
RESOLVERS are programs that extract information from name
servers in response to user requests. Resolvers must be able
to access at least one name server and use that name server's
information to answer a query directly, or pursue the query
using referrals to other name servers. A resolver will
typically be a system routine that is directly accessible to
user programs; hence no protocol is necessary between the
resolver and the user program.
RESOLVERSはユーザ要求に対応してネームサーバから情報を抜粋するプログラムです。 直接質疑に答えるのに少なくとも1つのネームサーバにアクセスして、そのネームサーバの情報を使用しなければならない、さもなければ、レゾルバは他のネームサーバに紹介を使用するのにおいて質問を追求できなければなりません。 レゾルバは直接ユーザ・プログラムにアクセスしやすい通常システムルーチンになるでしょう。 したがって、どんなプロトコルもレゾルバとユーザ・プログラムの間で必要ではありません。
These three components roughly correspond to the three layers or
views of the domain system:
これらの3つのコンポーネントがおよそドメインシステムの3つの層か視点に対応しています:
From the user's point of view, the domain system is accessed
through simple procedure or OS calls to resolvers. The domain
space consists of a single tree and the user can request
information from any section of the tree.
ユーザの観点から、簡単な手順でドメインシステムはアクセスされるか、またはOSがレゾルバに呼びかけます。 ドメインスペースは単一の木から成ります、そして、ユーザは木のどんなセクションからも情報を要求できます。
From the resolver's point of view, the domain system is
composed of an unknown number of name servers. Each name
server has one or more pieces of the whole domain tree's data,
リゾルバの観点から、ドメインシステムは未知の数のネームサーバで構成されます。 各ネームサーバには、全体のドメイン木の1つ以上のデータがあります。
Mockapetris [Page 3]
Mockapetris[3ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
but the resolver views each of these databases as essentially
static.
しかし、レゾルバは、それぞれのこれらのデータベースが本質的には静的であるとみなします。
From a name server's point of view, the domain system consists
of separate sets of local information called zones. The name
server has local copies of some of the zones. The name server
must periodically refresh its zones from master copies in local
files or foreign name servers. The name server must
concurrently process queries that arrive from resolvers using
the local zones.
ネームサーバの観点から、ドメインシステムはゾーンと呼ばれる別々のローカルの情報から成ります。 ネームサーバには、いくつかのゾーンの地方のコピーがあります。 ネームサーバはマスターコピーからローカルファイルか外国ネームサーバでゾーンを定期的にリフレッシュしなければなりません。 ネームサーバは同時にレゾルバからローカルのゾーンを使用することで到着する質問を処理しなければなりません。
In the interests of performance, these layers blur a bit. For
example, resolvers on the same machine as a name server may share
a database and may also introduce foreign information for use in
later queries. This cached information is treated differently
from the authoritative data in zones.
性能のために、これらの層は少しぼけます。 例えば、ネームサーバと同じマシンの上のレゾルバは、データベースを共有して、また、後の質問における使用のための外国情報を紹介するかもしれません。 このキャッシュされた情報はゾーンで信頼すべきデータと異なって扱われます。
Database model
データベースモデル
The organization of the domain system derives from some
assumptions about the needs and usage patterns of its user
community and is designed to avoid many of the the complicated
problems found in general purpose database systems.
ドメインシステムの組織は、ユーザーコミュニティの必要性と用法パターンに関するいくつかの仮定を得て、設計されていて、一般に、複雑な問題の多くを避けるのが目的データベース・システムを見つけたということです。
The assumptions are:
仮定は以下の通りです。
The size of the total database will initially be proportional
to the number of hosts using the system, but will eventually
grow to be proportional to the number of users on those hosts
as mailboxes and other information are added to the domain
system.
総データベースのサイズは初めはシステムを使用することでホストの数に比例しますが、メールボックスと他の情報がドメインシステムに追加されるとき結局、成長して、それらのホストでユーザの数に比例するでしょう。
Most of the data in the system will change very slowly (e.g.,
mailbox bindings, host addresses), but that the system should
be able to deal with subsets that change more rapidly (on the
order of minutes).
システムが、より急速に変化する部分集合(数分の注文での)に対処できなかったべきであったと、システムのデータの大部分は非常にゆっくり(例えば、メールボックス結合、ホスト・アドレス)を変えるでしょう。
The administrative boundaries used to distribute responsibility
for the database will usually correspond to organizations that
have one or more hosts. Each organization that has
responsibility for a particular set of domains will provide
redundant name servers, either on the organization's own hosts
or other hosts that the organization arranges to use.
通常、データベースへの責任を分配するのに使用される管理境界は1人以上のホストがいる組織に対応するでしょう。 特定のセットのドメインへの責任を持っている各組織が余分なネームサーバを提供するでしょう、組織の自己のホストか組織が使用するように手配する他のホストの上で。
Clients of the domain system should be able to identify trusted
name servers they prefer to use before accepting referrals to
name servers outside of this "trusted" set.
ドメインシステムのクライアントは彼らがこの「信じられた」セットの外で紹介をネームサーバに受け入れる前に使用するのを好む信じられたネームサーバを特定できるべきです。
Access to information is more critical than instantaneous
情報入手は瞬時に起こるより重要です。
Mockapetris [Page 4]
Mockapetris[4ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
updates or guarantees of consistency. Hence the update process
allows updates to percolate out though the users of the domain
system rather than guaranteeing that all copies are
simultaneously updated. When updates are unavailable due to
network or host failure, the usual course is to believe old
information while continuing efforts to update it. The general
model is that copies are distributed with timeouts for
refreshing. The distributor sets the timeout value and the
recipient of the distribution is responsible for performing the
refresh. In special situations, very short intervals can be
specified, or the owner can prohibit copies.
一貫性のアップデートか保証。 したがって、同時に、すべてがコピーされるのを保証するよりむしろドメインシステムのユーザをアップデートしますが、更新処理はこすアップデートの外出することを許します。 アップデートがネットワークかホスト障害で入手できないときに、普通のコースはそれをアップデートするために取り組みを続けている間、旧情報を信じることになっています。 一般的なモデルはコピーがリフレッシュするためにタイムアウトで分配されるということです。 ディストリビュータがタイムアウト値を設定して、分配の受取人は働くのに責任がある、リフレッシュしてください。 特別な状況で、非常に短い間隔を指定できますか、または所有者はコピーを禁止できます。
Some users will wish to access the database via datagrams;
others will prefer virtual circuits. The domain system is
designed so that simple queries and responses can use either
style, although refreshing operations need the reliability of
virtual circuits. The same overall message format is used for
all communication. The domain system does not assume any
special properties of the communications system, and hence
could be used with any datagram or virtual circuit protocol.
何人かのユーザがデータグラムを通してデータベースにアクセスしたくなるでしょう。 他のものは仮想の回路を好むでしょう。 ドメインシステムは簡単な質問と応答がスタイルを使用できるように、設計されています、壮快な操作は仮想の回路の信頼性を必要としますが。 同じ総合的なメッセージ・フォーマットはすべてのコミュニケーションに使用されます。 ドメインシステムは、通信網の少しの特別な性質も仮定しないで、したがって、どんなデータグラムや仮想の回路プロトコルと共にも使用できました。
In any system that has a distributed database, a particular
name server may be presented with a query that can only be
answered by some other server. The two general approaches to
dealing with this problem are "recursive", in which the first
server pursues the query for the client at another server, and
"iterative", in which the server refers the client to another
server and lets the client pursue the query. Both approaches
have advantages and disadvantages, but the iterative approach
is preferred for the datagram style of access. The domain
system requires implementation of the iterative approach, but
allows the recursive approach as an option. The optional
recursive style is discussed in [14], and omitted from further
discussion in this memo.
分散データベースを持っているどんなシステムでも、ある他のサーバで答えることができるだけである質問を特定のネームサーバに与えるかもしれません。(最初のサーバはクライアントのために別のサーバで質問にそれでつきまといます)。この問題に対処することへの2つの一般的方法が、「リカーシブ」と、「繰り返し」です。サーバで、そこでは、クライアントは、別のサーバにクライアントを差し向けて、質問を追求できます。 両方のアプローチには、利点と損失がありますが、繰り返しのアプローチはアクセサリーのデータグラムスタイルのために好まれます。 ドメインシステムは、繰り返しのアプローチの実装を必要としますが、オプションとして再帰的なアプローチを許します。 任意の再帰的なスタイルは、[14]で議論して、このメモでさらなる議論から省略されます。
The domain system assumes that all data originates in master files
scattered through the hosts that use the domain system. These
master files are updated by local system administrators. Master
files are text files that are read by a local name server, and
hence become available to users of the domain system. A standard
format for these files is given in [14].
ドメインシステムは、すべてのデータがドメインシステムを使用するホストを通して点在する基本ファイルで起こると仮定します。 これらの基本ファイルはローカルシステム管理者によってアップデートされます。 基本ファイルは、地方名サーバによって読まれるテキストファイルであり、したがって、ドメインシステムのユーザにとって利用可能になります。 [14]でこれらのファイルのための標準書式を与えます。
The standard format allows these files to be exchanged between
hosts (via FTP, mail, or some other mechanism); this facility is
useful when an organization wants a domain, but doesn't want to
support a name server. The organization can maintain the master
files locally using a text editor, transfer them to a foreign host
which runs a name server, and then arrange with the system
administrator of the name server to get the files loaded.
標準書式は、これらのファイルがホスト(FTP、メール、またはある他のメカニズムを通した)の間で交換されるのを許容します。 この施設は、組織がドメインが欲しいときに、役に立ちますが、ネームサーバをサポートしたがっていません。組織は、局所的にテキストエディタを使用することで基本ファイルを主張して、ネームサーバを実行する異種宿主にそれらを移して、次に、ネームサーバのシステム管理者と共にファイルをロードさせるように手配できます。
Mockapetris [Page 5]
Mockapetris[5ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
Each host's name servers and resolvers are configured by a local
system administrator. For a name server, this configuration data
includes the identity of local master files and instructions on
which non-local master files are to be loaded from foreign
servers. The name server uses the master files or copies to load
its zones. For resolvers, the configuration data identifies the
name servers which should be the primary sources of information.
各ホストのネームサーバとレゾルバはローカルシステム管理者によって構成されます。 ネームサーバのために、このコンフィギュレーション・データは外国サーバからロードされる非ローカルの基本ファイルがことであるローカルの基本ファイルと指示のアイデンティティを含んでいます。 ネームサーバは、ゾーンをロードするのに基本ファイルかコピーを使用します。 レゾルバに関しては、コンフィギュレーション・データはプライマリ情報筋であるべきであるネームサーバを特定します。
The domain system defines procedures for accessing the data and
for referrals to other name servers. The domain system also
defines procedures for caching retrieved data and for periodic
refreshing of data defined by the system administrator.
ドメインシステムはデータにアクセスして、紹介のための手順を他のネームサーバと定義します。 また、ドメインシステムは検索されたデータをキャッシュして、システム管理者によって定義されたデータの周期的なリフレッシュのための手順を定義します。
The system administrators provide:
システム管理者は提供します:
The definition of zone boundaries
ゾーン境界の定義
Master files of data
データに関する基本ファイル
Updates to master files
基本ファイルへのアップデート
Statements of the refresh policies desired
声明、望まれていた方針をリフレッシュしてください。
The domain system provides:
ドメインシステムは提供されます:
Standard formats for resource data
リソースデータのための標準書式
Standard methods for querying the database
データベースについて質問するための標準方法
Standard methods for name servers to refresh local data from
foreign name servers
ネームサーバが外国ネームサーバからのローカルのデータをリフレッシュする標準方法
DOMAIN NAME SPACE
ドメイン名スペース
Name space specifications and terminology
名前スペース仕様と用語
The domain name space is a tree structure. Each node and leaf on
the tree corresponds to a resource set (which may be empty). Each
node and leaf has an associated label. Labels are NOT guaranteed
to be unique, with the exception of the root node, which has a
null label. The domain name of a node or leaf is the path from
the root of the tree to the node or leaf. By convention, the
labels that compose a domain name are read left to right, from the
most specific (lowest) to the least specific (highest).
ドメイン名スペースは木構造です。 木の上の各ノードと葉はリソースセット(空であるかもしれない)に対応します。 各ノードと葉には、関連ラベルがあります。 ラベルは、根のノード以外に、特有になるように保証されません。(ノードには、ヌルラベルがあります)。 ノードか木の根から葉までノードか葉のドメイン名は経路です。 コンベンションによって、ドメイン名を構成するラベルは左で最も特定であるのから最も特有にまさしく読んで聞かせられません(最も低い)(最も高い)。
Internally, programs that manipulate domain names represent them
as sequences of labels, where each label is a length octet
followed by an octet string. Because all domain names end at the
root, which has a null string for a label, these internal
本質的に、ドメイン名を操るプログラムがラベルの系列としてそれらを表します。(八重奏ストリングはそこでの長さの八重奏であると各ラベルをいうことになりました)。 すべてのドメイン名が根で終わるので、どれに、ラベル、これらのインターナルのためのヌルストリングがありますか?
Mockapetris [Page 6]
Mockapetris[6ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
representations can use a length byte of zero to terminate a
domain name. When domain names are printed, labels in a path are
separated by dots ("."). The root label and its associated dot
are omitted from printed domain names, but the root can be named
by a null domain name (" " in this memo).
表現は、ドメイン名を終えるのにゼロの長さのバイトを使用できます。 ドメイン名が印刷されるとき、経路のラベルがドットによって分離される、(「」、)。 中、根のラベルとその関連ドットが印刷されたドメイン名から省略されますが、ヌルドメイン名で根を命名できる、(「「このメモ)、」
To simplify implementations, the total number of octets that
represent label octets and label lengths is limited to 255. Thus
a printed domain name can be up to 254 characters.
実装を簡素化するために、ラベル八重奏とラベルの長さを表す八重奏の総数は255に制限されます。 したがって、印刷されたドメイン名は最大254のキャラクタであるかもしれません。
A special label is defined that matches any other label. This
label is the asterisk or "*". An asterisk matches a single label.
Thus *.ARPA matches FOO.ARPA, but does not match FOO.BAR.ARPA.
The asterisk is mainly used to create default resource records at
the boundary between protocol families, and requires prudence in
its use.
いかなる他のラベルにも合っている特別なラベルは定義されます。 このラベルは、アスタリスクか「*」です。 アスタリスクは単一のラベルに合っています。 *したがって、.ARPAはFOO.ARPAを合わせますが、FOO.BAR.ARPAは合っていません。 アスタリスクは、プロトコルファミリーの間の境界でデフォルトリソース記録を作成するのにおいて主に使用されていて、使用中である思慮を必要とします。
A domain is identified by a domain name, and consists of that part
of the domain name space that is at or below the domain name which
specifies the domain. A domain is a subdomain of another domain
if it is contained within that domain. This relationship can be
tested by seeing if the subdomain's name has the containing
domain's name as the right part of its name. For example, A.B.C.D
is a subdomain of B.C.D, C.D, D, and " ".
ドメインは、ドメイン名によって特定されて、ドメイン名において、または、ドメインを指定するドメイン名の下にあるドメイン名スペースのその地域から成ります。 それがそのドメインの中に保管されているなら、ドメインは別のドメインに関するサブドメインです。 サブドメインの名前で名前の右の部分として含んでいるドメインの名前があるかどうかわかることによって、この関係をテストできます。 そして、D、例えば、A.紀元前Dが紀元前D、C.Dに関するサブドメインである、「「.」
This tree structure is intended to parallel the administrative
organization and delegation of authority. Potentially, each node
or leaf on the tree can create new subdomains ad infinitum. In
practice, this delegation can be limited by the administrator of
the name servers that manage the domain space and resource data.
この木構造が管理編成と権限の委任に沿うことを意図します。 潜在的に、木の上の各ノードか葉が永久に新しいサブドメインを作成できます。 実際には、ドメインスペースとリソースデータを管理するネームサーバの管理者はこの委譲を制限できます。
The following figure shows an example of a domain name space.
以下の図はドメイン名スペースに関する例を示しています。
|
+------------------+------------------+
| | |
COLORS FLAVORS TRUTH
| |
+-----+-----+ |
| | | NATURAL
RED BLUE GREEN |
|
+---------------+---------------+
| | |
CHOCOLATE VANILLA STRAWBERRY
| +------------------+------------------+ | | | 風味を真実に着色します。| | +-----+-----+ | | | | 自然な赤い青いグリーン| | +---------------+---------------+ | | | チョコレートのバニラいちご
In this example, the root domain has three immediate subdomains:
COLORS, FLAVORS, and TRUTH. The FLAVORS domain has one immediate
subdomain named NATURAL.FLAVORS. All of the leaves are also
この例では、根のドメインは3つの即座のサブドメインを持っています: 色、風味、および真実。 FLAVORSドメインには、NATURAL.FLAVORSという1つの即座のサブドメインがあります。 また、葉のすべてがそうです。
Mockapetris [Page 7]
Mockapetris[7ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
domains. This domain tree has the names " "(the root), COLORS,
RED.COLORS, BLUE.COLORS, GREEN.COLORS, FLAVORS, NATURAL.FLAVORS,
CHOCOLATE.NATURAL.FLAVORS, VANILLA.NATURAL.FLAVORS,
STRAWBERRY.NATURAL.FLAVORS, and TRUTH. If we wished to add a new
domain of ARTIFICIAL under FLAVORS, FLAVORS would typically be the
administrative entity that would decide; if we wished to create
CHIP and MOCHA names under CHOCOLATE, CHOCOLATE.NATURAL.FLAVORS
would typically be the appropriate administrative entity.
ドメイン。 このドメイン木には名前がある、「「(根)、COLORS、RED.COLORS、BLUE.COLORS、GREEN.COLORS、FLAVORS、NATURAL.FLAVORS、CHOCOLATE.NATURAL.FLAVORS、VANILLA.NATURAL.FLAVORS、STRAWBERRY.NATURAL.FLAVORS、およびTRUTH。」 FLAVORSの下でARTIFICIALの新しいドメインを加えたいと思うなら、FLAVORSは通常、決める管理実体でしょうに。 CHOCOLATEの下でCHIPとMOCHA名を作成したいと思うなら、CHOCOLATE.NATURAL.FLAVORSは通常、適切な管理実体でしょうに。
Resource set information
リソース情報集合
A domain name identifies a set of resource information. The set
of resource information associated with a particular name is
composed of separate resource records (RRs).
ドメイン名は1セットのリソース情報を特定します。 特定の名前に関連しているリソース情報のセットは別々のリソース記録(RRs)で構成されます。
Each resource record has the following major components:
それぞれのリソース記録には、以下の主要コンポーネントがあります:
The domain name which identifies resource set that holds this
record, and hence the "owner" of the information. For example,
a RR that specifies a host address has a domain name the
specifies the host having that address. Thus F.ISI.ARPA might
be the owner of a RR which specified an address field of
10.2.0.52. Since name servers typically store their resource
information in tree structures paralleling the organization of
the domain space, this information can usually be stored
implicitly in the database; however it is always included in
each resource record carried in a message.
この記録を保持するリソースセットを特定して、したがって情報の「所有者」を特定するドメイン名。 例えば、ホスト・アドレスを指定するRRがドメイン名を持っている、そのアドレスを持っているホストを指定します。 その結果、F. ISI.ARPAは10.2のアドレス・フィールドを指定したRRの所有者であるかもしれません。.0 .52。 ネームサーバがドメインスペースの組織に沿う木構造のそれらのリソース情報を通常保存するので、通常、データベースにそれとなくこの情報を保存できます。 しかしながら、それはメッセージで運ばれたそれぞれのリソース記録にいつも含まれています。
Other information used to manage the RR, such as length fields,
timeouts, etc. This information is omitted in much of this
memo, but is discussed in [14].
他の情報は以前はよく長さの分野、タイムアウトなどのRRを管理していました。 この情報について、このメモの多くで省略されますが、[14]で議論します。
A resource type field that specifies the type of the resource
in this resource record. Types refer to abstract resources
such as host addresses or mail delivery agents. The type field
is two octets long and uses an encoding that is standard
throughout the domain name system.
このリソース記録のリソースのタイプを指定するリソースタイプ分野。 タイプはホスト・アドレスかメール配送エージェントなどの抽象的なリソースを示します。 タイプ分野は、長い間の2つの八重奏であり、ドメイン名システム中で標準であることのコード化を使用します。
A class field identifies the format of the resource data, such
as the ARPA Internet format (IN) or the Computer Science
Network format (CSNET), for certain RR types (such as address
data). Note that while the class may separate different
protocol families, networks, etc. it does not do so in all
cases. For example, the IN class uses 32 bit IP addresses
exclusively, but the CSNET class uses 32 bit IP addresses, X.25
addresses, and phone numbers. Thus the class field should be
used as a guide for interpreting the resource data. The class
field is two octets long and uses an encoding that is standard
throughout the domain name system.
類体はリソースデータの形式を特定します、ARPAインターネット形式(IN)やコンピュータScience Network形式(CSNET)のように、あるRRタイプ(アドレスデータなどの)のために。 クラスが分離しているかもしれない間、異なったプロトコルファミリー、それがするネットワークなどがすべての場合でそうしないことに注意してください。 例えば、INのクラスは排他的に32ビットのIPアドレスを使用しますが、CSNETのクラスは32ビットのIPアドレス、X.25アドレス、および電話番号を使用します。 したがって、類体は、リソースデータを解釈するのにガイドとして使用されるべきです。 類体は、長い間の2つの八重奏であり、ドメイン名システム中で標準であることのコード化を使用します。
Mockapetris [Page 8]
Mockapetris[8ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
Resource data that describes the resource. The format of this
data can be determined given the type and class fields, but
always starts with a two octet length field that allows a name
server or resolver to determine the boundaries of the resource
data in any transaction, even if it cannot "understand" the
resource data itself. Thus name servers and resolvers can hold
and pass on records which they cannot interpret. The format of
the internal data is restricted only by the maximum length of
65535 octets; for example the host address record might specify
a fixed 32 bit number for one class, and a variable length list
of addresses in another class.
リソースについて説明するリソースデータ。 このデータの形式は、タイプと類体を考えて、決定できますが、いつもネームサーバかレゾルバがどんなトランザクションでもリソースデータの限界を決定できる2八重奏長さの野原から始まります、リソースデータ自体を「理解できない」でも。 したがって、ネームサーバとレゾルバは、彼らが解釈できない記録を保持して、伝えることができます。 内部のデータの形式は65535の八重奏の最大の長さだけによって制限されます。 例えば、ホスト・アドレス記録は1つのクラスの32ビットの固定数、およびもう1人のクラスにおける可変長住所録を指定するかもしれません。
While the class field in effect partitions the resource data in
the domain name system into separate parallel sections according
to class, services can span class boundaries if they use
compatible resource data formats. For example, the domain name
system uses compatible formats for structure information, and the
mail data decouples mail agent identification from details of how
to contact the agent (e.g. host addresses).
クラスによると、事実上、類体がドメイン名システムのリソースデータを別々の平行なセクションに仕切っている間、コンパチブルリソースデータ形式を使用するなら、サービスはクラス境界にかかることができます。 例えば、ドメイン名システムは構造情報にコンパチブル形式を使用します、そして、メールデータはどう、エージェント(例えば、ホスト・アドレス)に連絡するかに関する詳細からメールエージェント識別の衝撃を吸収します。
This memo uses the following types in its examples:
このメモは例で以下のタイプを使用します:
A - the host address associated with the domain name
A--ドメイン名に関連しているホスト・アドレス
MF - identifies a mail forwarder for the domain
MF--、メール混載業者はドメインに特定します。
MD - identifies a mail destination for the domain
MD--、メールの目的地をドメインに特定します。
NS - the authoritative name server for the domain
NS--ドメインへの正式のネームサーバ
SOA - identifies the start of a zone of authority
SOA--、権威のゾーンの始まりを特定します。
CNAME - identifies the canonical name of an alias
CNAME--、別名の正準な名前を特定します。
This memo uses the following classes in its examples:
このメモは例で以下のクラスを使用します:
IN - the ARPA Internet system
IN--ARPAインターネット・システム
CS - the CSNET system
CS--CSNETシステム
The first type of resource record holds a host name to host
address binding. Its fields are:
最初のタイプに関するリソース記録はホスト・アドレスへのホスト名を拘束力があるように保持します。 分野は以下の通りです。
+--------+--------+--------+--------------//----------------------+ |<owner> | A | <class>| <class specific address>information | +--------+--------+--------+--------------//----------------------+
+--------+--------+--------+--------------//----------------------+ |<所有者>。| A| <のクラス>| <のクラスの特定のアドレス>情報| +--------+--------+--------+--------------//----------------------+
Mockapetris [Page 9]
Mockapetris[9ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
The content of the class specific information varies according to
the value in the CLASS field; for the ARPA Internet, it is the 32
bit ARPA Internet address of the host, for the CSNET it might be
the phone number of the host. For example, F.ISI.ARPA might have
two A records of the form:
CLASS分野の値に従って、クラス特殊情報の内容は異なります。 ARPAインターネットに、ホストの32ビットのARPAインターネット・アドレスである、CSNETに関して、それはホストの電話番号であるかもしれません。 例えば、F. ISI.ARPAには、フォームに関する2つのA記録があるかもしれません:
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| A | IN | 10.2.0.52 |
+----------+--------+--------+----------------------------+
and
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| A | CS | 213-822-2112 |
+----------+--------+--------+----------------------------+
+----------+--------+--------+----------------------------+ |F.ISI.ARPA| A| IN| 10.2.0.52 | +----------+--------+--------+----------------------------+と+----------+--------+--------+----------------------------+ |F.ISI.ARPA| A| Cs| 213-822-2112 | +----------+--------+--------+----------------------------+
Note that the data formats for the A type are class dependent, and
the Internet address and phone number formats shown above are for
purposes of illustration only. The actual data formats are
specified in [14]. For example, CS class data for type A records
might actually be a list of Internet addresses, phone numbers and
TELENET addresses.
Aタイプのためのデータ形式がクラスに依存していて、上に示されたインターネット・アドレスと電話番号書式がイラストだけの目的のためのものであることに注意してください。 実際のデータ形式は[14]で指定されます。 例えば、タイプA記録のためのCSクラスデータは実際にインターネット・アドレス、電話番号、およびテレネットアドレスのリストであるかもしれません。
The mail forwarder (MF) and mail delivery (MD) records have the
following format:
メール混載業者(MF)と郵便配達(MD)記録には、以下の形式があります:
+--------+--------+--------+----------------------------+
|<owner> | MD/MF | <class>| <domain name> |
+--------+--------+--------+----------------------------+
+--------+--------+--------+----------------------------+ |<所有者>。| MD/mf| <のクラス>| <ドメイン名>。| +--------+--------+--------+----------------------------+
The <domain name> field is a domain name of the host that will
handle mail; note that this domain name may be completely
different from the domain name which names the resource record.
For example, F.ISI.ARPA might have two records of the form:
<ドメイン名>分野はメールを扱うホストのドメイン名です。 このドメイン名がリソース記録を命名するドメイン名と完全に異なるかもしれないことに注意してください。 例えば、F. ISI.ARPAには、フォームに関する2つの記録があるかもしれません:
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| MD | IN | F.ISI.ARPA |
+----------+--------+--------+----------------------------+
and
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| MF | IN | B.ISI.ARPA |
+----------+--------+--------+----------------------------+
+----------+--------+--------+----------------------------+ |F.ISI.ARPA| MD| IN| F.ISI.ARPA| +----------+--------+--------+----------------------------+と+----------+--------+--------+----------------------------+ |F.ISI.ARPA| mf| IN| B.ISI.ARPA| +----------+--------+--------+----------------------------+
These records mean that mail for F.ISI.ARPA can either be
delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA, which
will accept responsibility for its eventual delivery. In
principle, an additional name lookup is required to map the domain
name of the host to the appropriate address, in practice this
information is usually returned in the response to the mail query.
これらの記録は、F. ISI.ARPAのためのメールをホストF. ISI.ARPAに提供するか、またはB. ISI.ARPAに転送できることを意味します。(B. ISI.ARPAは最後の配送への責任を引き受けるでしょう)。 原則として、追加名前ルックアップがホストのドメイン名を適切なアドレスに写像するのに必要です、実際には通常、この情報がメール質問への応答で返される。
The SOA and NS types of resource records are used to define limits
リソース記録のSOAとNSタイプは、限界を定義するのに使用されます。
Mockapetris [Page 10]
Mockapetris[10ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
of authority. The domain name given by the owner field of a SOA
record is the start of a zone; the domain name given by the owner
field of a NS record identifies a point in the name space where
authority has been delegated, and hence marks the zone boundary.
Except in the case where a name server delegates authority to
itself, the SOA identifies the top limit of authority, and NS
records define the first name outside of a zone. These resource
records have a standard format for all of the name space:
権威について。 SOA記録の所有者分野によって与えられたドメイン名はゾーンの始まりです。 NS記録の所有者分野によって与えられたドメイン名は、権威がどこに代表として派遣されて、したがって、ゾーン境界をマークするかをスペースという名前でポイント特定します。 ネームサーバがそれ自体に権限を委ねるケースの中を除いて、SOAは最高権限範囲を特定します、そして、NS記録はゾーンの外で名を定義します。 これらのリソース記録には、スペースという名前のすべてのための標準書式があります:
+----------+--------+--------+-----------------------------+
| <owner> | SOA | <class>| <domain name, etc> |
+----------+--------+--------+-----------------------------+
+----------+--------+--------+-----------------------------+ | <所有者>。| SOA| <のクラス>| <ドメイン名、など>。| +----------+--------+--------+-----------------------------+
+----------+--------+--------+-----------------------------+
| <owner> | NS | <class>| <domain name> |
+----------+--------+--------+-----------------------------+
+----------+--------+--------+-----------------------------+ | <所有者>。| ナノ秒| <のクラス>| <ドメイン名>。| +----------+--------+--------+-----------------------------+
The SOA record marks the start of a zone when it is present in a
database; the NS record both marks the end of a zone started by an
SOA (if a higher SOA is present) and also points to a name server
that has a copy of the zone specified by the <owner. field of the
NS record.
それがデータベースに存在しているとき、SOA記録はゾーンの始まりを示します。 NS記録は、SOA(より高いSOAが存在しているなら)によって始められたゾーンの端を示して、また、<所有者がゾーンのコピーを指定するネームサーバを示します。NSの分野は記録します。
The <domain name, etc> in the SOA record specifies the original
source of the information in the zone and other information used
by name servers to organize their activities. SOA records are
never cached (otherwise they would create false zones); they can
only be created in special name server maintenance operations.
<ドメイン名、SOA記録のなど>はゾーンの情報とネームサーバによって使用される、彼らの活動を組織化する他の情報の一次資料を指定します。 SOA記録は決してキャッシュされません(さもなければ、それらは誤ったゾーンを作成するでしょう)。 特別なネームサーバメインテナンス操作でそれらを作成できるだけです。
The NS record says that a name server which is authoritative for
records of the given CLASS can be found at <domain name>.
NS記録は、<ドメイン名>で与えられたCLASSに関する記録に、正式のネームサーバは見つけることができると言います。
Queries
質問
Queries to a name server must include a domain name which
identifies the target resource set (QNAME), and the type and class
of desired resource records. The type and class fields in a query
can include any of the corresponding type and class fields that
are defined for resource records; in addition, the query type
(QTYPE) and query class (QCLASS) fields may contain special values
that match more than one of the corresponding fields in RRs.
ネームサーバへの質問は必要なリソース記録の目標リソースセット(QNAME)、タイプ、およびクラスを特定するドメイン名を含まなければなりません。 質問におけるタイプと類体はリソース記録のために定義される対応するタイプと類体のどれかを入れることができます。 さらに、質問タイプ(QTYPE)と質問のクラス(QCLASS)分野はRRsに対応する分野の1つ以上に合っている特別な値を含むかもしれません。
For example, the QTYPE field may contain:
例えば、QTYPE分野は以下を含むかもしれません。
MAILA - matches all mail agent RRs (e.g. MD and MF).
MAILA--マッチはすべて、エージェントRRs(例えば、MDとMF)に郵送します。
* - matches any RR type.
* - どんなRRもタイプするマッチ。
Mockapetris [Page 11]
Mockapetris[11ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
The QCLASS field may contain:
QCLASS分野は以下を含むかもしれません。
* - matches any RR class.
* - どんなRRのクラスも合わせます。
Using the query domain name, QTYPE, and QCLASS, the name server
looks for matching RRs. In addition to relevant records, the name
server may return RRs that point toward a name server that has the
desired information or RRs that are expected to be useful in
interpreting the relevant RRs. For example a name server that
doesn't have the requested information may know a name server that
does; a name server that returns a domain name in a relevant RR
may also return the RR that binds that domain name to an address.
質問ドメイン名、QTYPE、およびQCLASSを使用して、ネームサーバは合っているRRsを探します。 関連記録に加えて、ネームサーバは必要な情報を持っているネームサーバか関連RRsを解釈する際に役に立つと予想されるRRsに向かったそのポイントをRRsに返すかもしれません。 例えば、求められた情報を持っていないネームサーバはそれがするネームサーバを知るかもしれません。 また、関連RRのドメイン名を返すネームサーバはそのドメイン名をアドレスに縛るRRを返すかもしれません。
Note that the QCLASS=* construct requires special interpretation
regarding authority. Since a name server may not know all of the
classes available in the domain system, it can never know if it is
authoritative for all classes. Hence responses to QCLASS=*
queries can never be authoritative.
QCLASS=*構造物が権威に関する特別な解釈を必要とすることに注意してください。 ネームサーバがドメインシステムで利用可能なクラスについてすべてを知らないかもしれないので、それは、すべてのクラスに正式であるかどうかを決して知ることができません。 したがって、QCLASS=*質問への応答は正式であるはずがありません。
Example space
例のスペース
For purposes of exposition, the following name space is used for
the remainder of this memo:
博覧会の目的において、以下の名前スペースはこのメモの残りに使用されます:
|
+------------------+------------------+
| | |
DDN ARPA CSNET
| | |
+-----+-----+ | +-----+-----+
| | | | | |
JCS ARMY NAVY | UDEL UCI
|
+--------+---------------+---------------+--------+
| | | | |
DTI MIT ISI UDEL NBS
| |
+---+---+ +---+---+
| | | | |
DMS AI A B F
| +------------------+------------------+ | | | DDNアルパCSNET| | | +-----+-----+ | +-----+-----+ | | | | | | JCS軍隊海軍| UDEL UCI| +--------+---------------+---------------+--------+ | | | | | DTI MIT ISI UDEL NBS| | +---+---+ +---+---+ | | | | | DMS AIはB Fです。
Mockapetris [Page 12]
Mockapetris[12ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
NAME SERVERS
ネームサーバ
Introduction
序論
Name servers store a distributed database consisting of the
structure of the domain name space, the resource sets associated
with domain names, and other information used to coordinate
actions between name servers.
ネームサーバはドメイン名スペースの構造、ドメイン名に関連しているリソースセット、およびネームサーバの間の動作を調整するのに使用される他の情報から成る分散データベースを保存します。
In general, a name server will be an authority for all or part of
a particular domain. The region covered by this authority is
called a zone. Name servers may be responsible for no
authoritative data, and hence have no zones, or may have several
zones. When a name server has multiple zones, the zones may have
no common borders or zones may be contiguous.
一般に、ネームサーバは特定のドメインのすべてか一部への権威になるでしょう。 この権威でカバーされた領域はゾーンと呼ばれます。 ネームサーバには、どんな信頼すべきデータにも責任がなくて、またしたがって、ゾーンを全く持っていないか、またはいくつかのゾーンがあるかもしれません。 ネームサーバに複数のゾーンがあるとき、ゾーンには、どんな一般的な境界もないかもしれませんか、またはゾーンは隣接であるかもしれません。
While administrators should not construct overlapping zones, and
name servers must defend against overlapping zones, overlapping is
regarded as a non-fatal flaw in the database. Hence the measures
taken to protect against it are omitted for the remainder of this
memo. A detailed discussion can be found in [14].
管理者が重なっているゾーンを構成するべきでなくて、ネームサーバがゾーンを重ね合わせないように防御されなければならない間、重なることはデータベースの非重大な欠陥と見なされます。 したがって、それから守るために実施される対策はこのメモの残りのために省略されます。 [14]で詳細な論議を見つけることができます。
When presented with a query for a domain name over which it has
authority, a name server returns the desired resource information
or an indication that the query refers to a domain name or
resource that does not exist. If a name server is presented with
a query for a domain name that is not within its authority, it may
have the desired information, but it will also return a response
that points toward an authoritative name server. If a name server
is not an authority for a query, it can never return a negative
response.
それは権限があるドメイン名のための質問を与えるとき、ネームサーバが質問が存在しないドメイン名かリソースを示すという必要なリソース情報か指示を返します。 権威の中にないドメイン名のための質問をネームサーバに与えるなら、必要な情報があるかもしれませんが、また、それは正式のネームサーバに向かって指す応答を返すでしょう。ネームサーバが質問のための権威でないなら、否定応答を決して返すことができません。
There is no requirement that a name server for a domain reside in
a host which has a name in the same domain, although this will
usually be the case. There is also no restriction on the number
of name servers that can have authority over a particular domain;
most domains will have redundant authoritative name servers. The
assumption is that different authoritative copies are identical,
even though inconsistencies are possible as updates are made.
ドメインへのネームサーバが同じドメインに名前を持っているホストにあるという要件が全くありません、これは通常そうになるでしょうが。 また、制限が全く特定のドメインの上で権限がある場合があるネームサーバの数にありません。 ほとんどのドメインには、余分な正式のネームサーバがあるでしょう。 仮定はアップデートをするとき矛盾が可能ですが、異なった正式のコピーが同じであるということです。
Name server functions are designed to allow for very simple
implementations of name servers. The simplest name server has a
static set of information and uses datagrams to receive queries
and return responses.
ネームサーバ機能は、ネームサーバの非常に簡単な実装を考慮するように設計されています。 最も簡単なネームサーバは、静的な情報を持って、質問を受けて、応答を返すのにデータグラムを使用します。
More sophisticated name server implementations can improve the
performance of their clients by caching information from other
domains. Although this information can be acquired in a number of
ways, the normal method is to store the information acquired by a
より洗練されたネームサーバ実装は、他のドメインからの情報をキャッシュすることによって、彼らのクライアントの性能を向上させることができます。 多くの方法でこの情報を取得できますが、正常なメソッドはaによって取得された情報を保存することです。
Mockapetris [Page 13]
Mockapetris[13ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
resolver when the resolver consults other name servers. In a
sophisticated host, the resolver and name server will coordinate
their actions and use a shared database. This cooperation
requires the incorporation of a time-to-live (TTL) field in all
cached resource records. Caching is discussed in the resolver
section of this memo; this section is devoted to the actions of a
name servers that don't cache.
レゾルバであるときに、レゾルバは他のネームサーバに相談します。 洗練されたホストでは、レゾルバとネームサーバは、彼らの動作を調整して、共有データベースを使用するでしょう。 この協力はすべてのキャッシュされたリソース記録における、生きる時間(TTL)分野の編入を必要とします。 このメモのレゾルバ部でキャッシュについて議論します。 このセクションはそれがキャッシュしないネームサーバの動作にささげられます。
In order to free simple name servers of the requirement of
managing these timeouts, simple name servers should only contain
resource records that are expected to remain constant over very
long periods or resource records for which the name server is an
authority. In the following discussion, the TTL field is assumed
to be stored in the resource record but is omitted in descriptions
of databases and responses in the interest of clarity.
これらのタイムアウトを管理する要件の単純名サーバを解放するために、単純名サーバは非常に長い期間にわたって一定のままで残っていると予想されるリソース記録かネームサーバが権威であるリソース記録を含むだけであるべきです。 以下の議論では、TTL分野は、リソース記録に保存されると思われますが、明快のためにデータベースと応答の記述で省略されます。
Authority and administrative control of domains
ドメインの権威と運営管理コントロール
Although we want to have the potential of delegating the
privileges of name space management at every node, we don't want
such delegation to be required.
あらゆるノードで名前スペース管理の特権を代表として派遣する可能性が欲しいと思いますが、私たちは、そのような委譲を必要として欲しいと思いません。
Hence we introduce the concept of authority. Authority is vested
in name servers. A name server has authority over all of its
domain until it delegates authority for a subdomain to some other
name server.
したがって、私たちは権威の概念を紹介します。 権威はネームサーバに与えられています。 ネームサーバはドメインのすべて上でサブドメインのためにある他のネームサーバに権限を委ねるまで権限があります。
Any administrative entity that wishes to establish its own domain
must provide a name server, and have that server accepted by the
parent name server (i.e. the name server that has authority over
the place in the domain name space that will hold the new domain).
While the principles of authority allow acceptance to be at the
discretion of parent name servers, the following criteria are used
by the root, and are recommended to all name servers because they
are responsible for their children's actions:
それがそれ自身のドメインを確立したがっているどんな管理実体でも、ネームサーバを前提として、親ネームサーバ(すなわち、新しいドメインを保持するドメイン名スペースの場所の上で権限があるネームサーバ)でそのサーバを受け入れなければなりません。 親ネームサーバの裁量には承認が権威の原則である間、以下の評価基準は、根によって使用されて、彼らが彼らの子供の動作に原因となるので、すべてのネームサーバに推薦されます:
1. It must register with the parent administrator of domains.
1. それはドメインの親管理者とともに記名しなければなりません。
2. It must identify a responsible person.
2. それは責任者を特定しなければなりません。
3. In must provide redundant name servers.
3. 中では、余分なネームサーバは提供されなければなりません。
The domain name must be registered with the administrator to avoid
name conflicts and to make the domain related information
available to other domains. The central administrator may have
further requirements, and a domain is not registered until the
central administrator agrees that all requirements are met.
名前闘争を避けて、ドメイン関連情報を他のドメインに利用可能にするように管理者にドメイン名を登録しなければなりません。 主要な管理者には、さらなる要件があるかもしれません、そして、主要な管理者が、すべての必要条件が満たされるのに同意するまで、ドメインは登録されていません。
There must be a responsible person associated with each domain to
各ドメインに関連している責任者がいるに違いありません。
Mockapetris [Page 14]
Mockapetris[14ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
be a contact point for questions about the domain, to verify and
update the domain related information, and to resolve any problems
(e.g., protocol violations) with hosts in the domain.
ドメインに関する質問、ドメイン関連情報を確かめて、アップデートして、そのドメインのホストに関するどんな問題(例えば、プロトコル違反)も解決する接点になってください。
The domain must provide redundant (i.e., two or more) name servers
to provide the name to address resolution service. These name
servers must be accessible from outside the domain (as well as
inside) and must resolve names for at least all the hosts in the
domain.
ドメインは、解決サービスを扱うために名前を提供するために余分な(すなわち、2以上)ネームサーバを提供しなければなりません。 これらのネームサーバは、ドメイン(as well as inside)の外からアクセスしやすくなければならなく、少なくともそのドメインのすべてのホストのために名前を決議しなければなりません。
Once the central administrator is satisfied, he will communicate
the existence to the appropriate administrators of other domains
so that they can incorporate NS records for the new name server
into their databases.
主要な管理者がいったん満たされていると、彼は、新しいネームサーバのためのNS記録を自己のデータベースに組み入れることができるように、他のドメインの適切な管理者に存在を伝えるでしょう。
Name server logic
ネームサーバ論理
The processing steps that a name server performs in responding to
a query are conceptually simple, although implementations may have
internal databases that are quite complex.
ネームサーバが質問に応じる際に実行する処理ステップは概念的に簡単です、実装には、かなり複雑な内部のデータベースがあるかもしれませんが。
For purposes of explanation, we assume that the query consists of
a type QTYPE, a class QCLASS, and a domain name QNAME; we assume
that the name server stores its RRs in sets where each set has all
of the RRs for a particular domain. Note that this database
structure and the following algorithms are meant to illustrate one
possible implementation, rather than a specification of how all
servers must be implemented.
説明の目的のために、私たちが、質問がタイプQTYPEから成ると思って、クラスがQCLASSであり、ドメイン名はQNAMEです。 私たちは、ネームサーバが各セットが特定のドメインへのRRsのすべてを持っているセットでRRsを保存すると思います。 このデータベース構造と以下のアルゴリズムがどうすべてのサーバを実装しなければならないかに関する仕様よりむしろ1つの可能な実装を例証することになっていることに注意してください。
The following notation is used:
以下の記法は使用されています:
ord(DOMAIN-NAME) returns the number of labels in DOMAIN-NAME.
ord(DOMAIN-NAME)はDOMAIN-NAMEのラベルの数を返します。
findset(DOMAIN-NAME) returns a pointer to the set of stored RRs
for DOMAIN-NAME, or NULL if there is no such
information.
findset(DOMAIN-NAME)はDOMAIN-NAMEのために保存されたRRsのセットに指針を返すか、そこであるなら、NULLがそのような情報ではありません。
set(POINTER) refers to a set located previously by
findset, where POINTER is the value returned
by findset.
セット(POINTER)は以前にfindsetによって見つけられたセットについて言及します。そこでは、POINTERがfindsetによって返された値です。
relevant(QTYPE,TYPE) returns true if a RR of the specified TYPE is
relevant to the specified QTYPE. For
example, relevant(MAILA,MF) is true and
relevant(MAILA,NS) is false.
関連、指定されたTYPEのRRが指定されたQTYPEに関連しているなら、(QTYPE、TYPE)は本当に戻ります。 例えば、関連しているのは(MAILA、MF)、本当であって、関連しているのが(MAILA、NS)、偽であるということです。
right(NAME,NUMBER) returns a domain name that is the rightmost
NUMBER labels in the string NAME.
権利(NAME、NUMBER)はストリングNAMEで一番右のNUMBERラベルであるドメイン名を返します。
Mockapetris [Page 15]
Mockapetris[15ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
copy(RR) copies the resource record specified by RR
into the response.
コピー(RR)はRRによって応答に指定されたリソース記録をコピーします。
The name server code could be represented as the following
sequence of steps:
以下のステップの以下の系列としてネームサーバコードを表すことができました:
{ find out whether the database makes this server
authoritative for the domain name specified by QNAME }
データベースでこのサーバがQNAMEによって指定されたドメイン名に正式になるかどうか調べてください。
for i:=0 to ord(QNAME) { sequence through all nodes in QNAME }
do begin
ptr:=findset(right(QNAME,i));
if ptr<>NULL
then { there is domain data for this domain name }
begin
for all RRs in set(ptr)
do if type(RR)=NS and class(RR)=QCLASS
then begin
auth=false;
NSptr:=ptr
end;
for all RRs in set(ptr)
do if type(RR)=SOA and class(RR)=QCLASS
then auth:=true
end
end;
end;
iのために: = QNAMEのすべてのノードを通した系列がそうするord(QNAME)への0はptrを始めます: =findset(正しい(QNAME、i)) このドメイン名のためのドメインデータがptr<>NULLであるならあります。セット(ptr)におけるRRsがするすべてには、(RR)=NSをタイプしてください。そうすれば、次に、クラス(RR)=QCLASSがauthを= 虚偽で始めるなら、始まってください。 NSptr: =ptrエンド。 セット(ptr)におけるすべてのRRsに関しては、QCLASSの当時のタイプ(RR)がSOAと等しいか、そして、クラス(RR)=authをしてください:=本当の終わりエンド 終わってください。
{ copy out authority search results }
権威検索結果を全部写してください。
if auth
then { if authority check for domain found }
if ptr=null
then return(Name error)
else
else { if not authority, copy NS RRs }
for all RRs in set(nsptr)
do if (type(RR)=NS and class(RR)=QCLASS)
or
(QCLASS=*)
then copy(RR);
authであり、見つけられたドメインのための権威チェックであり、ptrがヌルと等しく、権威、コピーNS RRsでないならセット(nsptr)におけるRRsが(タイプ(RR)=NSとクラス(RR)=QCLASS)であるならするすべてか次に、(QCLASSは*と等しいです)コピー(RR)のためにほかにほかに(名前誤り)を返してください。
{ Copy all RRs that answer the question }
質問に答えるすべてのRRsをコピーしてください。
for all RRs in set(ptr)
do if class(RR)=QCLASS and relevant(QTYPE,type(RR))
then copy(RR);
セット(ptr)におけるすべてのRRsに関しては、クラス(RR)がQCLASSと(QTYPE、タイプ(RR))関連当時のコピー(RR)と等しいなら、してください。
The first section of the code (delimited by the for loop over all
コードの最初のセクション、(区切られる、すべて上の輪
Mockapetris [Page 16]
Mockapetris[16ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
of the subnodes of QNAME) discovers whether the name server is
authoritative for the domain specified by QNAME. It sequences
through all containing domains of QNAME, starting at the root. If
it encounters a SOA it knows that the name server is authoritative
unless it finds a lower NS RR which delegates authority. If the
name server is authoritative, it sets auth=true; if the name
server is not authoritative, it sets NSptr to point to the set
which contains the NS RR closest to the domain specified by QNAME.
QNAMEの「副-ノード」) QNAMEによって指定されたドメインに、ネームサーバが正式であるか否かに関係なく、発見します。 QNAMEのドメインを含んでいて、根で始まって、それは通じてすべてを配列します。 SOAに遭遇するなら、それは、下側のNS RRがどの代表権威であるかがわからない場合ネームサーバが正式であることを知っています。 ネームサーバが正式であるなら、= 本当にauthを設定します。 ネームサーバが正式でないなら、それは、NSptrにQNAMEによって指定されたドメインの最も近くにNS RRを含むセットを示すように設定します。
The second section of the code reflects the result of the
authority search into the response. If the name server is
authoritative, the code checks to see that the domain specified by
QNAME exists; if not, a name error is returned. If the name
server is not authoritative, the code copies the RRs for a closer
name server into the response.
コードの第2セクションは権威検索の結果を応答に反映します。 ネームサーバが正式であるなら、コードはQNAMEによって指定されたドメインが存在することを確認するためにチェックします。 そうでなければ、名前誤りは返されます。 ネームサーバが正式でないなら、コードは、より近いネームサーバのために応答にRRsをコピーします。
The last section of the code copies all relevant RRs into the
response.
コードの最後のセクションはすべての関連RRsを応答にコピーします。
Note that this code is not meant as an actual implementation and
is incomplete in several aspects. For example, it doesn't deal
with providing additional information, wildcards, QCLASS=*, or
with overlapping zones. The first two of these issues are dealt
with in the following discussions, the remaining issues are
discussed in [14].
このコードが実際の実装として意味されないで、いくつかの局面で不完全であることに注意してください。 例えば、追加情報を提供するワイルドカードにそれが対処しないで、QCLASSは*と等しい、またはゾーンを重ね合わせるのにそうします。 以下の議論でこれらの2つの最初の問題に対処していて、[14]で残された問題について議論します。
Additional information
追加情報
When a resolver returns information to a user program, the
returned information will often lead to a second query. For
example, if a mailer asks a resolver for the appropriate mail
agent for a particular domain name, the name server queried by the
resolver returns a domain name that identifies the agent. In
general, we would expect that the mailer would then request the
domain name to address binding for the mail agent, and a new name
server query would result.
レゾルバが情報をユーザ・プログラムに返すとき、返された情報はしばしば2番目の質問につながるでしょう。 例えば、郵送者が特定のドメイン名のために適切なメールエージェントをレゾルバに求めるなら、レゾルバによって質問されたネームサーバはエージェントを特定するドメイン名を返します。 一般に、私たちは、次に、郵送者が、メールエージェントのための結合を扱うようドメイン名に要求すると予想するでしょう、そして、新しいネームサーバ質問は結果として生じるでしょう。
To avoid this duplication of effort, name servers return
additional information with a response which satisfies the
anticipated query. This information is kept in a separate section
of the response. Name servers are required to complete the
appropriate additional information if such information is
available, but the requestor should not depend on the presence of
the information since the name server may not have it. If the
resolver caches the additional information, it can respond to the
second query without an additional network transaction.
取り組みのこの重複を避けるために、ネームサーバは予期された質問を満たす応答と共に追加情報を返します。 この情報は応答の別々のセクションに保たれます。 そのような情報が利用可能であるなら、ネームサーバが適切な追加情報を完成するのに必要ですが、ネームサーバにはそれがないかもしれないので、要請者は情報の存在を当てにするべきではありません。 レゾルバが追加情報をキャッシュするなら、それは追加ネットワークトランザクションなしで2番目の質問に応じることができます。
The appropriate information is defined in [14], but generally
[14]にもかかわらず、一般に、適切な情報は定義されます。
Mockapetris [Page 17]
Mockapetris[17ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
consists of host to address bindings for domain names in returned
RRs.
返されたRRsのドメイン名のための結合を扱うためにホストから成ります。
Aliases and canonical names
別名と正準な名前
In existing systems, hosts and other resources often have several
names that identify the same resource. For example, under current
ARPA Internet naming support, USC-ISIF and ISIF both identify the
same host. Similarly, in the case of mailboxes, many
organizations provide many names that actually go to the same
mailbox; for example Mockapetris@ISIF, Mockapetris@ISIB, etc., all
go to the same mailbox (although the mechanism behind this is
somewhat complicated).
既存のシステムでは、ホストと他のリソースはしばしば同じリソースを特定するいくつかの名前を持っています。 例えば、サポートを命名する現在のARPAインターネットの下では、USC-ISIFとISIFはともに同じホストを特定します。 同様に、メールボックスの場合では、多くの組織が実際に同じメールボックスに行く多くの名前を提供します。 例えば、 Mockapetris@ISIF 、Mockapetris@ISIBなどは同じメールボックスにすべて行きます(これの後ろのメカニズムがいくらか複雑ですが)。
Most of these systems have a notion that one of the equivalent set
of names is the canonical name and all others are aliases.
これらのシステムの大部分には、同等なセットの名前の1つが正準な名前であり、すべての他のものが別名であるという考えがあります。
The domain system provides a similar feature using the canonical
name (CNAME) RR. When a name server fails to find a desired RR in
a set associated with some domain name, it checks to see if the
resource set contains a CNAME record with a matching class. If
so, the name server includes the CNAME record in the response, and
continues the query at the domain name specified in the data field
of the CNAME record.
ドメインシステムは、RRという正準な名前(CNAME)を使用することで同様の特徴を提供します。 ネームサーバが何らかのドメイン名に関連しているセットで必要なRRを見つけないと、それは、合っているクラスと共にリソースセットがCNAME記録を含むかどうか確認するためにチェックします。 そうだとすれば、ネームサーバは、応答にCNAME記録を含んでいて、CNAME記録のデータ・フィールドで指定されたドメイン名で質問を続けています。
Suppose a name server was processing a query with QNAME=ISIF.ARPA,
QTYPE=A, and QCLASS=IN, and had the following resource records:
ネームサーバが処理のQNAME=ISIF.ARPAとの質問、QTYPE=A、およびQCLASS=INであり、以下のリソース記録を持っていたと仮定してください:
ISIF.ARPA CNAME IN F.ISI.ARPA
F.ISI.ARPA A IN 10.2.0.52
F.ISI.ARPA F.ISI.ARPA A IN10.2.0におけるISIF.ARPA CNAME、.52
Both of these RRs would be returned in the response.
応答でこれらのRRsの両方を返すでしょう。
In the above example, because ISIF.ARPA has no RRs other than the
CNAME RR, the resources associated with ISIF.ARPA will appear to
be exactly those associated with F.ISI.ARPA for the IN CLASS.
Since the CNAME is effective only when the search fails, a CNAME
can also be used to construct defaults. For example, suppose the
name server had the following set of RRs:
上記の例では、ISIF.ARPAにはCNAME RR以外のRRsが全くないので、ISIF.ARPAに関連しているリソースはちょうどIN CLASSのためにF. ISI.ARPAに関連づけられたものであるように見えるでしょう。 検索が失敗するときだけ、CNAMEが有効であるので、また、デフォルトを構成するのにCNAMEを使用できます。 例えば、ネームサーバにはRRsの以下のセットがあったと仮定してください:
F.ISI.ARPA A IN 10.2.0.52
F.ISI.ARPA MD IN F.ISI.ARPA
XXXX.ARPA CNAME IN F.ISI.ARPA
XXXX.ARPA MF IN A.ISI.ARPA
A.ISI.ARPAのF.ISI.ARPA XXXX.ARPA mfにおけるF.ISI.ARPA A IN10.2.0.52F.ISI.ARPA MD IN F.ISI.ARPA XXXX.ARPA CNAME
Using this database, type A queries for XXXX.ARPA would return the
XXXX.ARPA CNAME RR and the F.ISI.ARPA A RR, but MAILA or MF
queries to XXXX.ARPA would return the XXXX.ARPA MF RR without any
information from F.ISI.ARPA. This structure might be used to send
このデータベースを使用して、XXXX.ARPAのためのタイプA質問はXXXX.ARPA CNAME RRとF. ISI.ARPA A RRを返すでしょうが、XXXX.ARPAへのMAILAかMF質問がF. ISI.ARPAから少しも情報なしでXXXX.ARPA MF RRを返すでしょう。 この構造は、発信するのに使用されるかもしれません。
Mockapetris [Page 18]
Mockapetris[18ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
mail addressed to XXXX.ARPA to A.ISI.ARPA and to direct TELNET for
XXXX.ARPA to F.ISI.ARPA.
A. ISI.ARPAへのXXXX.ARPAと、そして、XXXX.ARPAのためのF. ISI.ARPAへのダイレクトTELNETに扱われたメール。
Wildcards
ワイルドカード
In certain cases, an administrator may wish to associate default
resource information for all or part of a domain. For example,
the CSNET domain administrator may wish to establish IN class mail
forwarding for all hosts in the CSNET domain without IN
capability. In such a case, the domain system provides a special
label "*" that matches any other label. Note that "*" matches
only a single label, and not zero or more than one label. Note
also that the "*" is distinct from the "*" values for QCLASS and
QTYPE.
ある場合には、管理者はドメインのすべてか一部のためのデフォルトリソース情報を関連づけたがっているかもしれません。 例えば、CSNETドメイン管理者はIN能力なしでCSNETドメインのすべてのホストのためのINクラスメール転送を確立したがっているかもしれません。 このような場合には、ドメインシステムはいかなる他のラベルにも合っている特別なラベル「*」を提供します。 「*」がゼロか1個以上のラベルではなく、単一のラベルだけに合っていることに注意してください。 また、QCLASSとQTYPEにおいて、「*」が「*」値と異なっていることに注意してください。
The semantics of "*" depend upon whether it appears in a query
domain name (QNAME) or in a RR in a database.
「*」の意味論は質問ドメイン名(QNAME)かデータベースのRRに現れるかどうかによります。
When an "*" is used in a QNAME, it can only match a "*" in a
resource record.
「*」がQNAMEで使用されるとき、それはリソース記録の「*」に合うことができるだけです。
When "*" appears in a RR in a database, it can never override
an existing exact match. For example, if a name server
received a query for the domain UDEL.CSNET, and had appropriate
RRs for both UDEL.CSNET and *.CSNET, the UDEL.CSNET RRs would
be used and the *.CSNET RRs would be ignored. If a query to
the same database specified FOO.CSNET, the *.CSNET RR would be
used, but the corresponding labels from the QNAME would replace
the "*". Thus the FOO.CSNET query would match the *.CSNET RR
and return a RR for FOO.CSNET rather than *.CSNET.
「*」がデータベースのRRに現れると、それは既存の完全な一致を決してくつがえすことができません。 例えば、ネームサーバがドメインUDEL.CSNETに質問を受けて、UDEL.CSNETと*.CSNETの両方のために適切なRRsを持っているなら、UDEL.CSNET RRsは使用されるでしょうに、そして、*.CSNET RRsは無視されるでしょう。 同じデータベースへの質問がFOO.CSNETを指定するなら、*.CSNET RRは使用されるでしょうにが、QNAMEからの対応するラベルは「*」を取り替えるでしょう。 したがって、FOO.CSNET質問は、*.CSNETよりむしろFOO.CSNETのために*.CSNET RRを合わせて、RRを返すでしょう。
RRs containing "*" labels are copied exactly when zones are
transfered via name server maintenance operations.
ちょうどゾーンがネームサーバメインテナンス操作でtransferedされるとき、「*」ラベルを含むRRsがコピーされます。
These semantics are easily implemented by having the name server
first search for an exact match for a query, and then replacing
the leftmost label with a "*" and trying again, repeating the
process until all labels became "*" or the search succeeded.
質問のための完全な一致のネームサーバ第1検索を持っていることによって容易に実装されて、次に一番左ラベルを「*」に取り替えるこれらの意味論とすべてのラベルが「*」になったか、または検索が成功するまでプロセスを繰り返して、再試行すること。
TYPE=* in RRs is prohibited. If it were to be allowed, the
requestor would have no way of interpreting the data in the RR
because this data is type dependent.
RRsのTYPE=*は禁止されています。 それが許容されることになっているなら、このデータがタイプ扶養家族であるので、要請者はRRにデータを解釈する方法を全く持っていないでしょうに。
CLASS=* is also prohibited. Similar effects can be achieved using
QCLASS=*, and allowing both QCLASS=* and CLASS=* leads to
complexities without apparent benefit.
また、CLASS=*は禁止されています。 QCLASS=*を使用することで同様の効果を達成できます、そして、QCLASS=*とCLASS=*の両方を許容するのは見かけの利益なしで複雑さに通じます。
Mockapetris [Page 19]
Mockapetris[19ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
A scenario
シナリオ
In our sample domain space, suppose we wanted separate
administrative control for the root, DDN, ARPA, CSNET, MIT and ISI
domains. We might allocate name servers as follows:
私たちのサンプルドメインスペースでは、私たちが、根、DDN、ARPA、CSNET、MIT、およびISIドメインのための別々の運営管理コントロールが欲しいと思ったと仮定してください。 私たちは以下のネームサーバを割り当てるかもしれません:
|(B.ISI.ARPA)
|(UDEL.CSNET)
+------------------+------------------+
| | |
DDN ARPA CSNET
|(JCS.DDN) |(F.ISI.ARPA) |(UDEL.ARPA)
+-----+-----+ |(A.ISI.ARPA)+-----+-----+
| | | | | |
JCS ARMY NAVY | UDEL UCI
|
+--------+---------------+---------------+--------+
| | | | |
DTI MIT ISI UDEL NBS
|(AI.MIT.ARPA) |(F.ISI.ARPA)
+---+---+ +---+---+
| | | | |
DMS AI A B F
| (B.ISI.ARPA)|(UDEL.CSNET) +------------------+------------------+ | | | DDNアルパCSNET|(JCS.DDN) |(F.ISI.ARPA) |(UDEL.ARPA) +-----+-----+ |(A.ISI.ARPA)+-----+-----+ | | | | | | JCS軍隊海軍| UDEL UCI| +--------+---------------+---------------+--------+ | | | | | DTI MIT ISI UDEL NBS|(AI.MIT.ARPA) |(F.ISI.ARPA) +---+---+ +---+---+ | | | | | DMS AIはB Fです。
In this example the authoritative name server is shown in
parentheses at the point in the domain tree at which is assumes
control.
この例では、どれがあるかでドメイン木のポイントの括弧でコントロールを仮定します正式のネームサーバが示される。
Thus the root name servers are on B.ISI.ARPA and UDEL.CSNET, the
DDN name server is on JCS.DDN, the CSNET domain server is on
UDEL.ARPA, etc.
したがって、根のネームサーバがB. ISI.ARPAとUDEL.CSNETにあって、DDNネームサーバがJCS.DDNにあって、CSNETドメインサーバがUDEL.ARPAなどにあります。
In an actual system, all domains should have redundant name
servers, but in this example only the ARPA domain has redundant
servers A.ISI.ARPA and F.ISI.ARPA. (The B.ISI.ARPA and UDEL.CSNET
name servers happen to be not redundant because they handle
different classes.) The F.ISI.ARPA name server has authority over
the ARPA domain, but delegates authority over the MIT.ARPA domain
to the name server on AI.MIT.ARPA. The A.ISI.ARPA name server
also has authority over the ARPA domain, but delegates both the
ISI.ARPA and MIT.ARPA domains to other name servers.
実際のシステムでは、すべてのドメインが余分なネームサーバを持つべきですが、この例だけでは、ARPAドメインは余分なサーバのA. ISI.ARPAとF. ISI.ARPAを持っています。 (異なったクラスを扱うので、B. ISI.ARPAとUDEL.CSNETネームサーバはたまたま余分ではありません。) ARPAドメインの上に権威を持っていますが、F. ISI.ARPAネームサーバはAI.MIT.ARPAの上のネームサーバへのMIT.ARPAドメインの上に代表権威を持っています。 また、A. ISI.ARPAネームサーバはARPAドメインの上で権限があって、唯一の代表は、他のネームサーバへのISI.ARPAとMIT.ARPAドメインの両方です。
Mockapetris [Page 20]
Mockapetris[20ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
B.ISI.ARPA Name server for " "
B.ISI.ARPA Nameサーバ、「」
B.ISI.ARPA has the root name server for the IN class. Its
database might contain:
B. ISI.ARPAには、INのクラスのための根のネームサーバがあります。 データベースは以下を含むかもしれません。
Domain Resource Record
ドメインリソース記録
" " SOA IN A.ISI.ARPA
DDN NS IN JCS.DDN
ARPA NS IN F.ISI.ARPA
CSNET NS IN UDEL.ARPA
" " NS IN B.ISI.ARPA
" " NS CS UDEL.CSNET
「「UDEL.ARPAのF.ISI.ARPA CSNETナノ秒のJCS.DDNアルパナノ秒のA.ISI.ARPA DDNナノ秒のSOA」、「B.ISI.ARPAのナノ秒、」 「ナノ秒Cs UDEL.CSNET」
JCS.DDN A IN 9.0.0.1
F.ISI.ARPA A IN 10.2.0.52
UDEL.CSNET A CS 302-555-0000
UDEL.ARPA A IN 10.0.0.96
10.2.0.52UDEL.CSNET A Cs302-555-0000UDEL.ARPA A IN10.0.0.96の9.0.0.1F.ISI.ARPA AのJCS.DDN A
The SOA record for the root is necessary so that the name server
knows that it is authoritative for the root domain for class IN.
The contents of the SOA resource record point back to A.ISI.ARPA
and denote that the master data for the zone of authority is
originally from this host. The first three NS records denote
delegation of authority. The NS root entry for the B.ISI.ARPA
name server is necessary so that this name server knows about
itself, and can respond correctly to a query for NS information
about the root (for which it is an authority). The root entry for
class CS denotes that UDEL.CSNET is the authoritative name server
for the CS class root. UDEL.CSNET and UDEL.ARPA may or may not
refer to the same name server; from this information it is
impossible to tell.
根のためのSOA記録が必要であるので、ネームサーバは、根のドメインに、それがクラスINに正式であることを知っています。 SOAリソース記録の内容は、A. ISI.ARPAを示して、権威のゾーンのためのマスタデータが元々このホストからあるのを指示します。 最初の3つのNS記録が権限の委任を指示します。 B. ISI.ARPAネームサーバのためのNS根のエントリーが、このネームサーバが周囲で己を知って、正しく根(それが権威である)のNS情報のための質問に応じることができるくらい必要です。 クラスCSのための根のエントリーは、UDEL.CSNETがCSクラス根のための正式のネームサーバであることを指示します。 UDEL.CSNETとUDEL.ARPAは同じネームサーバについて言及するかもしれません。 この情報から、言うのは不可能です。
If this name server was sent a query specifying QTYPE=MAILA,
QCLASS=IN, QNAME=F.ISI.ARPA, it would begin processing (using the
previous algorithm) by determining that it was not an authority
for F.ISI.ARPA. The test would note that it had authority at " ",
but would also note that the authority was delegated at ARPA and
never reestablished via another SOA. Thus the response would
return the NS record for the domain ARPA.
QTYPE=MAILA、QCLASS=INを指定する質問をこのネームサーバに送ったなら、QNAMEはF. ISI.ARPAと等しく、それは、それが権威でなかったことを決定することによってF. ISI.ARPAのために処理し(前のアルゴリズムを使用します)始めるでしょう。 それは権限があったテストに注意されるだろう、「「また、権威がARPAで代表として派遣されたことに注意して、別のSOAを通って決して復職していない、」 したがって、応答はドメインARPAのためのNS記録を返すでしょう。
Any queries presented to this server with QCLASS=CS would result
in the UDEL.CSNET NS record being returned in the response.
QCLASS=CSと共にこのサーバに提示されたどんな質問も応答で返されるUDEL.CSNET NS記録をもたらすでしょう。
Mockapetris [Page 21]
Mockapetris[21ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
F.ISI.ARPA Name server for ARPA and ISI.ARPA
ARPAとISI.ARPAのためのF.ISI.ARPA Nameサーバ
In the same domain space, the F.ISI.ARPA database for the domains
ARPA and ISI.ARPA might be:
同じドメインスペースでは、ドメインのARPAとISI.ARPAのためのF. ISI.ARPAデータベースは以下の通りです。
Domain Resource Record
ドメインリソース記録
" " NS IN B.ISI.ARPA
" " NS CS CSNET.UDEL
ARPA SOA IN B.ISI.ARPA
ARPA NS IN A.ISI.ARPA
ARPA NS IN F.ISI.ARPA
MIT.ARPA NS IN AI.MIT.ARPA
ISI.ARPA SOA IN F.ISI.ARPA
ISI.ARPA NS IN F.ISI.ARPA
「「B.ISI.ARPAのナノ秒、」 「F.ISI.ARPAのF.ISI.ARPA ISI.ARPAナノ秒のAI.MIT.ARPA ISI.ARPA SOAのF.ISI.ARPA MIT.ARPAナノ秒のA.ISI.ARPAアルパナノ秒のB.ISI.ARPAアルパナノ秒のナノ秒Cs CSNET.UDELアルパSOA」
A.ISI.ARPA MD IN A.ISI.ARPA
ISI.ARPA MD IN F.ISI.ARPA
A.ISI.ARPA MF IN F.ISI.ARPA
B.ISI.ARPA MD IN B.ISI.ARPA
B.ISI.ARPA MF IN F.ISI.ARPA
F.ISI.ARPA MD IN F.ISI.ARPA
F.ISI.ARPA MF IN A.ISI.ARPA
DTI.ARPA MD IN DTI.ARPA
NBS.ARPA MD IN NBS.ARPA
UDEL.ARPA MD IN UDEL.ARPA
UDEL.ARPAのNBS.ARPA UDEL.ARPA MDのDTI.ARPA NBS.ARPA MDのA.ISI.ARPA DTI.ARPA MDのF.ISI.ARPA F.ISI.ARPA mfにおけるF.ISI.ARPA F.ISI.ARPA MDのB.ISI.ARPA B.ISI.ARPA mfにおけるF.ISI.ARPA B.ISI.ARPA MDのF.ISI.ARPA A.ISI.ARPA mfにおけるA.ISI.ARPA ISI.ARPA MDのA.ISI.ARPA MD
A.ISI.ARPA A IN 10.1.0.32
F.ISI.ARPA A IN 10.2.0.52
B.ISI.ARPA A IN 10.3.0.52
DTI.ARPA A IN 10.0.0.12
AI.MIT.ARPA A IN 10.2.0.6
DMS.MIT.ARPA A IN 10.1.0.6
NBS.ARPA A IN 10.0.0.19
UDEL.ARPA A IN 10.0.0.96
10.0.0.19UDEL.ARPA A IN10.0.0における10.1.0.6NBS.ARPA Aの10.2.0.6DMS.MIT.ARPA Aの10.0.0.12AI.MIT.ARPA Aの10.3.0.52DTI.ARPA Aの10.2.0.52B.ISI.ARPA Aの10.1.0.32F.ISI.ARPA AのA.ISI.ARPA A、.96
For the IN class, the SOA RR for ARPA denotes that this name
server is authoritative for the domain ARPA, and that the master
file for this authority is stored on B.ISI.ARPA. This zone
extends to ISI.ARPA, where the database delegates authority back
to this name server in another zone, and doesn't include the
domain MIT.ARPA, which is served by a name server on AI.MIT.ARPA.
INのクラスのために、ARPAのためのSOA RRは、ドメインARPAに、このネームサーバが正式であり、この権威のための基本ファイルがB. ISI.ARPAに保存されるのを指示します。 このゾーンは、別のゾーンのこのネームサーバへのデータベース代表権威をISI.ARPA、どこに広げているか、そして、ドメインMIT.ARPAを含んでいません。(MIT.ARPAはAI.MIT.ARPAの上のネームサーバによって役立たれています)。
This name server is not authoritative for any data in the CS
class. It has a pointer to the root server for CS data which
could be use to resolve CS class queries.
CSのクラスにおけるどんなデータにも、このネームサーバは正式ではありません。 それはCSクラス質問を決議するためには使用であるかもしれないCSデータのためのルートサーバーに指針を持っています。
Suppose this name server received a query of the form
QNAME=A.ISI.ARPA, QTYPE=A, and QCLASS=IN. The authority search
このネームサーバがフォームQNAME=A. ISI.ARPA、QTYPE=A、およびQCLASS=INの質問を受けたと仮定してください。 権威検索
Mockapetris [Page 22]
Mockapetris[22ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
would notice the NS record for " ", its SOA at ARPA, a delegation
at ISI.ARPA, and the reassumption of authority at ISI.ARPA. Hence
it would know that it was an authority for this query. It would
then find the A record for A.ISI.ARPA, and return a datagram
containing this record.
NSが記録するのに気付くだろう、「「ARPAのSOA、ISI.ARPAの委譲、およびISI.ARPAの権威の「再-仮定」、」 したがって、それは、この質問のための権威であったのを知っているでしょう。 そして、それは、A. ISI.ARPAのためのAレコード、およびリターンがこの記録を含むデータグラムであることが、わかるでしょう。
Another query might be QNAME=B.ISI.ARPA, QTYPE=MAILA, QCLASS=*.
In this case the name server would know that it cannot be
authoritative because of the "*" value of QCLASS, and would look
for records for domain B.ISI.ARPA that match. Assuming that the
name server performs the additional record inclusion mentioned in
the name server algorithm, the returned datagram would include:
別の質問はB.QNAME=ISI.ARPAであるかもしれません、QTYPE=MAILA、QCLASS=*。この場合、ネームサーバは、それがQCLASSの「*」値のために正式であるはずがないことを知って、合っているドメインB.ISI.ARPAとして記録を探すでしょう。 ネームサーバがネームサーバアルゴリズムで言及された追加記録的な包含を実行すると仮定する場合、返されたデータグラムは以下を含んでいるでしょう。
ISI.ARPA NS IN F.ISI.ARPA
" " NS CS UDEL.CSNET
B.ISI.ARPA MD IN B.ISI.ARPA
B.ISI.ARPA MF IN F.ISI.ARPA
B.ISI.ARPA A IN 10.3.0.52
F.ISI.ARPA A IN 10.2.0.52
F.ISI.ARPAのISI.ARPAナノ秒、「「ナノ秒Cs UDEL.CSNET B.ISI.ARPA MD IN B.ISI.ARPA B.ISI.ARPA mf IN F.ISI.ARPA B.ISI.ARPA A IN10.3.0.52F.ISI.ARPA A IN10.2.0.52」
If the query were QNAME=DMS.MIT.ARPA, QTYPE=MAILA, QCLASS=IN, the
name server would discover that AI.MIT.ARPA was the authoritative
name server and return the following:
質問がQNAME=DMS.MIT.ARPA、QTYPE=MAILA、QCLASS=INであるなら、ネームサーバは、AI.MIT.ARPAが正式のネームサーバであったと発見して、以下を返すでしょうに:
MIT.ARPA NS IN AI.MIT.ARPA
AI.MIT.ARPA A IN 10.2.0.6
MIT.ARPAナノ秒IN AI.MIT.ARPA AI.MIT.ARPA A IN10.2.0.6
In this case, the requestor is directed to seek information from
the MIT.ARPA domain name server residing on AI.MIT.ARPA.
この場合、要請者がAI.MIT.ARPAにあるMIT.ARPAドメイン名サーバからの情報を求めるよう指示されます。
Mockapetris [Page 23]
Mockapetris[23ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
UDEL.ARPA and UDEL.CSNET name server
UDEL.ARPAとUDEL.CSNETネームサーバ
In the previous discussion of the sample domain, we stated that
UDEL.CSNET and UDEL.ARPA might be the same name server. In this
example, we assume that this is the case. As such, the name
server is an authority for the root for class CS, and an authority
for the CSNET domain for class IN.
サンプルドメインの前の議論では、私たちは、UDEL.CSNETとUDEL.ARPAが同じネームサーバであるかもしれないと述べました。この例では、これがそうであると思います。 そういうものとして、ネームサーバは、クラスCSのための根のための権威と、CSNETドメインへのクラスINのための権威です。
This name server deals with mail forwarding between the ARPA
Internet and CSNET systems. Its RRs illustrate one approach to
solving this problem. The name server has the following resource
records:
このネームサーバはARPAインターネットとCSNETシステムの間のメール転送に対処します。RRsはこの問題を解決することへの1つのアプローチを例証します。 ネームサーバには、以下のリソース記録があります:
" " SOA CS UDEL.CSNET
" " NS CS UDEL.CSNET
" " NS IN B.ISI.ARPA
CSNET SOA IN UDEL.ARPA
CSNET NS IN UDEL.ARPA
ARPA NS IN A.ISI.ARPA
「「SOA Cs UDEL.CSNET」、「ナノ秒Cs UDEL.CSNET、」 「A.ISI.ARPAのUDEL.ARPAアルパナノ秒のUDEL.ARPA CSNETナノ秒のB.ISI.ARPA CSNET SOAのナノ秒」
*.CSNET MF IN UDEL.ARPA
UDEL.CSNET MD CS UDEL.CSNET
UCI.CSNET MD CS UCI.CSNET
UDEL.ARPA MD IN UDEL.ARPA
*UDEL.ARPAのUDEL.ARPA UDEL.CSNET MD CS UDEL.CSNET UCI.CSNET MD Cs UCI.CSNET UDEL.ARPA MDの.CSNET mf
B.ISI.ARPA A IN 10.3.0.52
UDEL.ARPA A IN 10.0.0.96
UDEL.CSNET A CS 302-555-0000
UCI.CSNET A CS 714-555-0000
10.0.0.96UDEL.CSNET A Cs302-555-0000UCI.CSNET A Cs714-555-0000の10.3.0.52UDEL.ARPA AのB.ISI.ARPA A
Suppose this name server received a query of the form
QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=IN. The name server
would discover it was authoritative for the CSNET domain under
class IN, but would find no explicit mail data for UCI.CSNET.
However, using the *.CSNET record, it would construct a reply:
このネームサーバがフォームQNAME=UCI.CSNET、QTYPE=MAILA、およびQCLASS=INの質問を受けたと仮定してください。 ネームサーバは、クラスINの下のCSNETドメインに、それが正式であったと発見するでしょうが、UCI.CSNETのためのどんな明白なメールデータも見つけないでしょう。 しかしながら、*.CSNET記録を使用して、回答を構成するでしょう:
UCI.CSNET MF IN UDEL.ARPA
UDEL.ARPA A IN 10.0.0.96
UCI.CSNET mf IN UDEL.ARPA UDEL.ARPA A IN10.0.0.96
If this name server received a query of the form QNAME=UCI.CSNET,
QTYPE=MAILA, and QCLASS=CS, the name server would return:
このネームサーバがフォームのQNAME=UCI.CSNET、QTYPE=MAILA、およびQCLASS=CSの質問を受けるなら、ネームサーバは戻るでしょうに:
UCI.CSNET MD CS UCI.CSNET
UCI.CSNET A CS 714-555-0000
UCI.CSNET MD Cs UCI.CSNET UCI.CSNETはCs714-555-0000です。
Note that although this scheme allows for forwarding of all mail
addressed as <anything>.CSNET, it doesn't help with names that
have more than two components, e.g. A.B.CSNET. Although this
problem could be "fixed" by a series of MF entries for *.*.CSNET,
この体系が、進めると考慮しますが、すべてでは、メールが、<として何がも>.CSNETであるとも扱ったというメモ、それは2つ以上のコンポーネント(例えば、A. B. CSNET)を持っている名前で助かりません。 **.CSNETのための一連のMFエントリーでこの問題を「修理できるでしょう」が
Mockapetris [Page 24]
Mockapetris[24ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
*.*.*.CSNET, etc, a more tasteful solution would be to introduce a
cleverer pattern matching algorithm in the CSNET name server.
*. **.CSNET、など、より趣味のよいソリューションはCSNETネームサーバにおける、より賢明なパターン・マッチングアルゴリズムを導入するだろうことです。
Summary of requirements for name servers
ネームサーバのための要件の概要
The requirements for a name server are as follows:
ネームサーバのための要件は以下の通りです:
1. It must be recognized by its parent.
1. 親はそれを認識しなければなりません。
2. It must have complete resource information for all domain
names for which it is the authority.
2. それには、それが権威であるすべてのドメイン名のための完全なリソース情報がなければなりません。
3. It must periodically refresh authoritative information from
a master file or name server which holds the master.
3. それは定期的にマスターを保持する基本ファイルかネームサーバからの信頼できる情報をリフレッシュしなければなりません。
4. If it caches information it must also handle TTL management
for that information.
4. また、情報をキャッシュするなら、それはその情報のためのTTL管理を扱わなければなりません。
5. It must answer simple queries.
5. それは簡単な質問に答えなければなりません。
Inverse queries
逆さの質問
Name servers may also support inverse queries that map a
particular resource to a domain name or domain names that have
that resource. For example, while a query might map a domain name
to a host address, the corresponding inverse query might map the
address back to the domain name.
また、ネームサーバは特定のリソースをドメイン名に写像する逆さの質問かそのリソースを持っているドメイン名をサポートするかもしれません。 例えば、質問はドメイン名をホスト・アドレスに写像するかもしれませんが、対応する逆さの質問はアドレスをドメイン名に写像して戻すかもしれません。
Implementation of this service is optional in a name server, but
all name servers must at least be able to understand an inverse
query message and return an error response.
このサービスの実装がネームサーバで任意ですが、すべてのネームサーバが、逆さの質問メッセージを理解して、誤り応答を少なくとも返すことができなければなりません。
The domain system cannot guarantee the completeness or uniqueness
of inverse queries because the domain system is organized by
domain name rather than by host address or any other resource
type. In general, a resolver or other program that wishes to
guarantee that an inverse query will work must use a name server
that is known to have the appropriate data, or ask all name
servers in a domain of interest.
ドメインシステムがホスト・アドレスかいかなる他のリソースタイプでもというよりむしろドメイン名によって組織化されるので、ドメインシステムは逆さの質問の完全性かユニークさを保証できません。 一般に、レゾルバか逆さの質問が働くのを保証したがっている他のプログラムが、適切なデータを持っているのが知られているネームサーバを使用しなければならないか、または興味があるドメインのすべてのネームサーバを尋ねなければなりません。
For example, if a resolver wishes to perform an inverse query for
an arbitrary host on the ARPA Internet, it must consult a set of
name servers sufficient to know that all IN data was considered.
In practice, a single inverse query to a name server that has a
fairly comprehensive database should satisfy the vast majority of
inverse queries.
例えば、レゾルバが任意のホストのための逆さの質問をARPAインターネットに実行したいなら、すべてのINデータが考えられたのを知ることができるくらいそれは1セットのネームサーバに相談しなければなりません。 実際には、かなり包括的なデータベースを持っているネームサーバへのただ一つの逆さの質問は逆さの質問のかなりの大部分を満たすべきです。
A detailed discussion of inverse queries is contained in [14].
逆さの質問の詳細な論議は[14]に含まれています。
Mockapetris [Page 25]
Mockapetris[25ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
Completion services
完成サービス
Some existing systems provide the ability to complete partial
specifications of arguments. The general principle is that the
user types the first few characters of the argument and then hits
an escape character to prompt the system to complete the rest.
Some completion systems require that the user type enough of the
argument to be unique; others do not.
いくつかの既存のシステムが議論の部分的な仕様を完成する能力を提供します。 一般的な原則はユーザが議論の最初の数文字をタイプして、次に、システムが残りを完成するようにうながすために拡張文字を打つということです。 いくつかの完成システムが、ユーザが議論を特有であることができるくらいタイプするのを必要とします。 他のものはそうしません。
Other systems allow the user to specify one argument and ask the
system to fill in other arguments. For example, many mail systems
allow the user to specify a username without a host for local mail
delivery.
他のシステムで、ユーザを1つの議論を指定して、他の議論に記入するようにシステムに頼みます。 例えば、多くのメールシステムで、ユーザはホストなしで地方の郵便配達にユーザ名を指定できます。
The domain system defines name server completion transactions that
perform the analogous service for the domain system.
Implementation of this service is optional in a name server, but
all name servers must at least be able to understand a completion
request and return an error response.
ドメインシステムはドメインシステムのための類似のサービスを実行するネームサーバ完成トランザクションを定義します。 このサービスの実装がネームサーバで任意ですが、すべてのネームサーバが、完成要求を理解して、誤り応答を少なくとも返すことができなければなりません。
When a resolver wishes to request a completion, it sends a name
server a message that sets QNAME to the partial string, QTYPE to
the type of resource desired, and QCLASS to the desired class.
The completion request also includes a RR for the target domain.
The target domain RR identifies the preferred location of the
resource. In completion requests, QNAME must still have a null
label to terminate the name, but its presence is ignored. Note
that a completion request is not a query, but shares some of the
same field formats.
レゾルバが完成を要求したがっているとき、それは部分的なストリング、望まれていたリソースのタイプへのQTYPE、および必要なクラスへのQCLASSにQNAMEを設定するメッセージをネームサーバに送ります。 また、完成要求はターゲット・ドメインへのRRを含んでいます。 ターゲット・ドメインRRはリソースの都合のよい位置を特定します。 完成要求では、QNAMEはまだ名前を終えるヌルラベルを持たなければなりませんが、存在は無視されます。 完成要求が質問ではありませんが、同じフィールド形式のいくつかを共有することに注意してください。
For example, a completion request might contain QTYPE=A, QNAME=B,
QCLASS=IN and a RR for ISI.ARPA. This request asks for completion
for a resource whose name begins with "B" and is "close" to
ISI.ARPA. This might be a typical shorthand used in the ISI
community which uses "B" as a way of referring to B.ISI.ARPA.
例えば、完成要求はQTYPE=A、QNAME=B、QCLASS=IN、およびISI.ARPAのためのRRを含むかもしれません。 この要求は名前が「B」と共に始まって、「近いところにISI.ARPAの」あるリソースのための完成を求めます。 これはB.ISI.ARPAについて言及する方法として「B」を使用するISI共同体で使用される典型的な速記であるかもしれません。
The first step in processing a completion request is to look for a
"whole label" match. When the name server receives the request
mentioned above, it looks at all records that are of type A, class
IN, and whose domain name starts (on the left) with the labels of
QNAME, in this case, "B". If multiple records match, the name
server selects those whose domain names match (from the right) the
most labels of the preferred domain name. If there are still
multiple candidates, the name server selects the records that have
the shortest (in terms of octets in the name) domain name. If
several records remain, then the name server returns them all.
完成要求を処理することにおける第一歩は「全体のラベル」マッチを探すことです。 ネームサーバが前記のように要求を受け取るとき、それはタイプAにはあるすべての記録、クラスIN、およびこの場合、QNAMEのラベルによるドメイン名始め(左の)「B」を見ます。 複数の記録が合っているなら、ネームサーバはドメイン名が都合のよいドメイン名の最も多くのラベルに合っている(右から)それらを選択します。 複数の候補がまだいれば、ネームサーバは最も短い(名前における八重奏による)ドメイン名を持っている記録を選択します。 いくつかの記録が残っているなら、ネームサーバはそれらを皆、返します。
If no records are found in the previous algorithm, the name server
assumes that the rightmost label in QNAME is not complete, and
そして記録が全く前のアルゴリズムで見つけられないなら、ネームサーバが、QNAMEの一番右のラベルが完全でないと仮定する。
Mockapetris [Page 26]
Mockapetris[26ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
looks for records that match but require addition of characters to
the rightmost label of QNAME. For example, the previous search
would not match BB.ARPA to B, but this search would. If multiple
hits are found, the same discarding strategy is followed.
QNAMEの一番右のラベルへのキャラクタの追加を合わせますが、必要とする記録のための面相。 例えば、前の検索はBB.ARPAをBに合わせないでしょうが、この検索は合わせるでしょう。 複数のヒットが見つけられるなら、同じ捨てる戦略は従われています。
A detailed discussion of completion can be found in [14].
[14]で完成の詳細な論議を見つけることができます。
RESOLVERS
レゾルバ
Introduction
序論
Resolvers are programs that interface user programs to domain name
servers. In the simplest case, a resolver receives a request from
a user program (e.g. mail programs, TELNET, FTP) in the form of a
subroutine call, system call etc., and returns the desired
information in a form compatible with the local host's data
formats.
レゾルバはドメイン名サーバにユーザ・プログラムを接続するプログラムです。 最も簡単な場合では、レゾルバは、システムコールサブルーチン呼出しなどの形にユーザ・プログラム(例えば、プログラムを郵送してください、TELNET、FTP)から要求を受け取って、ローカル・ホストのデータ形式とのコンパチブルフォームで必要な情報を返します。
Because a resolver may need to consult several name servers, the
amount of time that a resolver will take to complete can vary.
This variance is part of the justification for the split between
name servers and resolvers; name servers may use datagrams and
have a response time that is essentially equal to network delay
plus a short service time, while resolvers may take an essentially
indeterminate amount of time.
レゾルバが、いくつかのネームサーバに相談する必要があるかもしれないので、レゾルバがそうする時間に、終了する撮影は異なることができます。 この変化はネームサーバとレゾルバの間の分裂のための正当化の一部です。 ネームサーバは、データグラムを使用して、本質的にはネットワーク遅延とショートサービス時間と等しい応答時間を過すかもしれません、レゾルバは本質的には不確定の時かかるかもしれませんが。
We expect to see two types of resolvers: simple resolvers that can
chain through multiple name servers when required, and more
complicated resolvers that cache resource records for use in
future queries.
私たちは、2つのタイプのレゾルバに会うと予想します: 必要であると複数のネームサーバを通して鎖を作ることができる純真なレゾルバ、および今後の質問における使用のためのリソース記録をキャッシュするより複雑なレゾルバ。
Simple resolvers
純真なレゾルバ
A simple resolver needs the following capabilities:
純真なレゾルバは以下の能力を必要とします:
1. It must know how to access a name server, and should know the
authoritative name server for the host that it services.
1. それは、ネームサーバにアクセスする方法を知らなければならなくて、サービスを提供するホストで正式のネームサーバを知るべきです。
2. It must know the protocol capabilities for its clients so that
it can set the class fields of the queries it sends to return
information that is useful to its clients. If the resolver
serves a client that has multiple protocol capabilities, it
should be able to support the preferences of the client.
2. それは、クライアントでそれが送る質問の類体にクライアントの役に立つ情報を返すように設定できるようにプロトコル能力を知らなければなりません。 レゾルバが複数のプロトコル能力を持っているクライアントに勤めるなら、クライアントの好みをサポートすることができるべきです。
The resolver for a multiple protocol client can either collect
information for all classes using the * class value, or iterate
on the classes supported by the client. Note that in either
case, the resolver must understand the preferences of the host.
For example, the host that supports both CSNET and ARPA
複数のプロトコルクライアントがすべてのための情報を集めることができるので、レゾルバは*クラスがクライアントによってサポートされたクラスで評価するか、または繰り返す使用を分類します。 どちらの場合ではも、レゾルバがホストの好みを理解しなければならないことに注意してください。 例えば、CSNETとARPAの両方をサポートするホスト
Mockapetris [Page 27]
Mockapetris[27ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
Internet protocols might prefer mail delivery (MD) to mail
forwarding (MF), regardless of protocol, or might prefer one
protocol regardless of whether MD or MF is required. Care is
required to prevent loops.
インターネットプロトコルは、プロトコルにかかわらず郵便配達(MD)が推進(MF)を郵送するのを好むか、またはMDかMFが必要であるかどうかにかかわらず1つのプロトコルを好むかもしれません。 注意が、輪を防ぐのに必要です。
3. The resolver must be capable of chaining through multiple name
servers to get to an authoritative name server for any query.
The resolver should guard against loops in referrals; a simple
policy is to discard referrals that don't match more of the
query name than the referring name server, and also to avoid
querying the same name server twice (This test should be done
using addresses of name servers instead of domain names to
avoid problems when a name server has multiple domain names or
errors are present in aliases).
3. レゾルバは、正式のネームサーバを始めるために複数のネームサーバを通してどんな質問においても鎖を作ることができなければなりません。 レゾルバは紹介で輪に用心するはずです。 簡単な方針は、質問名に参照ネームサーバよりもう合っていない紹介を捨てて、また、二度同じネームサーバについて質問するのを避ける(このテストはネームサーバには複数のドメイン名があるか、または誤りが別名で存在しているとき、問題を避けるのにドメイン名の代わりにネームサーバのアドレスを使用し終わるべきです)ことです。
4. The resolver must be able to try alternate name servers when a
name server doesn't respond.
4. ネームサーバが応じないとき、レゾルバは別名称サーバを試みることができなければなりません。
5. The resolver must be able to communicate different failure
conditions to its client. These failure conditions include
unknown domain name, unknown resource for a know domain name,
and inability to access any of the authoritative name servers
for a domain.
5. レゾルバは異なった失敗状態をクライアントに伝えることができなければなりません。 これらの失敗状態は未知のドメイン名を含んでいて、aのための未知のリソースはドメイン名、および正式のネームサーバのどれかにドメインにアクセスできないことを知っています。
6. If the resolver uses datagrams for queries, it must recover
from lost and duplicate datagrams.
6. レゾルバが質問にデータグラムを使用するなら、それは無くなるのと写しデータグラムから回復しなければなりません。
Resolvers with cache management
キャッシュ管理のレゾルバ
Caching provides a tool for improving the performance of name
service, but also is a potential source of incorrect results. For
example, a database might cache information that is later changed
in the authoritative name servers. While this problem can't be
eliminated without eliminating caching, it can be reduced to an
infrequent problem through the use of timeouts.
キャッシュは、名前サービスの性能を向上させるのにツールを提供しますが、不正確な結果の可能なまた源でもあります。 例えば、データベースは後で正式のネームサーバで変えられる情報をキャッシュするかもしれません。 キャッシュを排除しないでこの問題を解決できない間、それはタイムアウトの使用による珍しい問題に減少できます。
When name servers return resource records, each record has an
associated time-to-live (TTL) field. This field is expressed in
seconds, and has 16 bits of significance.
ネームサーバがリソース記録を返すとき、各記録には、生きる関連時間(TTL)分野があります。 この分野は、秒に表されて、意味の16ビットを持っています。
When a resolver caches a returned resource record it must also
remember the TTL field. The resolver must discard the record when
the equivalent amount of time has passed. If the resolver shares
a database with a name server, it must decrement the TTL field of
imported records periodically rather than simply deleting the
record. This strategy is necessary to avoid exporting a resource
record whose TTL field doesn't reflect the amount of time that the
resource record has been cached. Of course, the resolver should
また、レゾルバが返されたリソース記録をキャッシュするとき、それはTTL分野を覚えていなければなりません。 同等な時間が経過したとき、レゾルバは記録を捨てなければなりません。 レゾルバがネームサーバとデータベースを共有するなら、それは単に記録を削除するよりインポートしている記録のTTL分野を定期的にむしろ減少させなければなりません。 この戦略が、TTL分野がリソース記録がキャッシュされた時間に反射しないリソース記録をエクスポートするのを避けるのに必要です。 もちろん、レゾルバはそうするべきです。
Mockapetris [Page 28]
Mockapetris[28ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
not decrement the TTL fields of records for which the associated
name server is an authority.
TTLがさばく関連ネームサーバが権威である記録の減少でない。
Mockapetris [Page 29]
Mockapetris[29ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
Appendix 1 - Domain Name Syntax Specification
付録1--ドメイン名構文仕様
The preferred syntax of domain names is given by the following BNF rules. Adherence to this syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET). Note that some applications described in [14] use domain names containing binary information and hence do not follow this syntax.
以下のBNF規則でドメイン名の都合のよい構文を与えます。 この構文への固守はドメイン名(例えば、メール、TELNET)を使用する多くのアプリケーションに関する、より少ない問題をもたらすでしょう。 [14]で説明されたいくつかのアプリケーションが2進情報を含むドメイン名を使用して、したがって、この構文に従わないことに注意してください。
<domain> ::= <subdomain> | " "
<ドメイン>:、:= <サブドメイン>。| " "
<subdomain> ::= <label> | <subdomain> "." <label>
<サブドメイン>:、:= <ラベル>。| 「<サブドメイン>」、」 <ラベル>。
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ラベル>:、:= <手紙>。[皮肉をさせている[<ldh-str>]<>]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<ldh-str>:、:= <の皮肉をさせているhypの>。| <の皮肉をさせているhypの><ldh-str>。
<let-dig-hyp> ::= <let-dig> | "-"
<の皮肉をさせているhypの>:、:= 皮肉をさせている<>。| "-"
<let-dig> ::= <letter> | <digit>
皮肉をさせている<>:、:= <手紙>。| <ケタ>。
<letter> ::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
<手紙>:、:= 小文字のzを通した大文字とaのZを通した52の英字Aのいずれも
<digit> ::= any one of the ten digits 0 through 9
<ケタ>:、:= 10ケタ0〜9のいずれも
Note that while upper and lower case letters are allowed in domain names no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical.
大文字と小文字手紙がドメイン名で許容されていますが、意味が全くケースに付けられていないことに注意してください。 すなわち、同じスペルにもかかわらず、異なったケースの2つの名前はまるで同じであるかのように扱われることです。
The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.
ラベルはアルパネットホスト名のために約束を守らなければなりません。 彼らは、文字から始まって、手紙かケタで終わって、内部のキャラクタだけとして文字、ケタ、およびハイフンを持たなければなりません。 また、いくつかの制限が長さにあります。 ラベルは63以下のキャラクタであるに違いありません。
For example, the following strings identify hosts in the ARPA Internet:
例えば、以下のストリングはARPAインターネットでホストを特定します:
F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
Mockapetris [Page 30]
Mockapetris[30ページ]
RFC 882 November 1983
Domain Names - Concepts and Facilities
RFC882 1983年11月ドメイン名--概念と施設
REFERENCES and BIBLIOGRAPHY
参照と図書目録
[1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet
Host Table Specification", RFC 810, Network Information Center,
SRI International, March 1982.
[1] E.Feinler(K.Harrenstien、Z.Su、および「DODインターネットホストテーブル仕様」、RFC810対ホワイト)はインフォメーション・センターをネットワークでつなぎます、SRIインターナショナル、1982年3月。
[2] J. Postel, "Computer Mail Meeting Notes", RFC 805,
USC/Information Sciences Institute, February 1982.
[2] J.ポステル、「コンピュータメールミーティング注意」、USC/情報科学が1982年2月に設けるRFC805。
[3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet
User Applications", RFC 819, Network Information Center, SRI
International, August 1982.
[3] Z.Su、およびJ.ポステル、「インターネットユーザアプリケーションのためのドメイン命名規則」、RFC819はインフォメーション・センターをネットワークでつなぎます、SRIインターナショナル、1982年8月。
[4] Z. Su, "A Distributed System for Internet Name Service",
RFC 830, Network Information Center, SRI International,
October 1982.
[4] Z.Su(「インターネット名前サービスのための分散システム」、RFC830)は1982年10月にインフォメーション・センター、SRIインターナショナルをネットワークでつなぎます。
[5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network
Information Center, SRI International, March 1982.
[5] K.Harrenstien、およびV.ホワイト、「NICNAME/WHOIS」RFC812は1982年3月にインフォメーション・センター、SRIインターナショナルをネットワークでつなぎます。
[6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name
Server", Computer Networks, vol 6, nr 3, July 1982.
1982年のnr vol6、7月3日の[6] M.ソロモン、L.LandweberとD.Neuhengen、「CSNETネームサーバ」コンピュータNetworks。
[7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information
Center, SRI International, December 1977.
[7] K.Harrenstien(「名前/指」、RFC742)は1977年12月にインフォメーション・センター、SRIインターナショナルをネットワークでつなぎます。
[8] J. Postel, "Internet Name Server", IEN 116, USC/Information
Sciences Institute, August 1979.
[8] J.ポステル、「インターネットネームサーバ」、IEN116、科学が1979年8月に設けるUSC/情報。
[9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server",
RFC 811, Network Information Center, SRI International,
March 1982.
[9] K.Harrenstien、V.ホワイトとE.Feinler、「ホスト名サーバ」、RFC811、ネットワーク情報センター、SRIインターナショナル、1982年3月。
[10] J. Postel, "Transmission Control Protocol", RFC 793,
USC/Information Sciences Institute, September 1981.
[10] J.ポステル、「通信制御プロトコル」、RFC793、科学が1981年9月に設けるUSC/情報。
[11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, August 1980.
[11] J.ポステル、「ユーザー・データグラム・プロトコル」、RFC768、科学が1980年8月に設けるUSC/情報。
[12] J. Postel, "Simple Mail Transfer Protocol", RFC 821,
USC/Information Sciences Institute, August 1980.
[12] J.ポステル、「簡単なメール転送プロトコル」、RFC821、科学が1980年8月に設けるUSC/情報。
[13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870,
USC/Information Sciences Institute, October 1983.
J.レイノルズ、およびJ.ポステル、「規定番号」、RFC870、USC/情報科学が1983年10月に設ける[13]。
[14] P. Mockapetris, "Domain Names - Implementation and
Specification", RFC 883, USC/Information Sciences Institute,
November 1983.
[14] P.Mockapetris、「ドメイン名--、実装と仕様、」、RFC883、科学が設けるUSC/情報、11月1983日
Mockapetris [Page 31]
Mockapetris[31ページ]
一覧
スポンサーリンク
