RFC883 日本語訳
0883 Domain names: Implementation specification. P.V. Mockapetris. November 1983. (Format: TXT=175067 bytes) (Obsoleted by RFC1034, RFC1035) (Updated by RFC0973) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Mockapetris
Request for Comments: 883 ISI
November 1983
Mockapetrisがコメントのために要求するワーキンググループP.をネットワークでつないでください: 883 ISI1983年11月
DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION
ドメイン名--実装と仕様
+-----------------------------------------------------+
| |
| This memo discusses the implementation of domain |
| name servers and resolvers, specifies the format of |
| transactions, and discusses the use of domain names |
| in the context of existing mail systems and other |
| network software. |
| |
| This memo assumes that the reader is familiar with |
| RFC 882, "Domain Names - Concepts and Facilities" |
| which discusses the basic principles of domain |
| names and their use. |
| |
| The algorithms and internal data structures used in |
| this memo are offered as suggestions rather than |
| requirements; implementers are free to design their |
| own structures so long as the same external |
| behavior is achieved. |
| |
+-----------------------------------------------------+
+-----------------------------------------------------+ | | | このメモはドメインの実装について議論します。| | ネームサーバとレゾルバ、形式を指定します。| | トランザクション、ドメイン名の使用について議論します。| | メールシステムで他で存在することの文脈で| | ソフトウェアをネットワークでつないでください。 | | | | このメモは、読者が詳しいと仮定します。| | RFC882、「ドメイン名--、概念と施設、」| | どれがドメインの基本原理について議論しますか。| | 名前と彼らの使用。 | | | | アルゴリズムと中で使用された内部のデータ構造| | 提案としてむしろこのメモを提供します。| | 要件。 implementersが自由に設計できる、彼ら| | 同じくらい同じように外部であることの形でとても長い構造を所有してください。| | 振舞いは達成されます。 | | | +-----------------------------------------------------+
+-----------------------------------------------+
| |
| ***** WARNING ***** |
| |
| This RFC contains format specifications which |
| are preliminary and are included for purposes |
| of explanation only. Do not attempt to use |
| this information for actual implementations. |
| |
+-----------------------------------------------+
+-----------------------------------------------+ | | | ***** 警告*****| | | | このRFCが書式仕様を含んでいる、どれ| | 予備であり、目的のために含まれています。| | 説明だけについて。 使用するどんな試みもしないでください。| | 実際の実装のためのこの情報。 | | | +-----------------------------------------------+
Mockapetris [Page i]
Mockapetris[ページi]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
TABLE OF CONTENTS
INTRODUCTION........................................................3
Overview.........................................................3
Implementation components........................................2
Conventions......................................................6
Design philosophy................................................8
NAME SERVER TRANSACTIONS...........................................11
Introduction....................................................11
Query and response transport....................................11
Overall message format..........................................13
The contents of standard queries and responses..................15
Standard query and response example.............................15
The contents of inverse queries and responses...................17
Inverse query and response example..............................18
Completion queries and responses................................19
Completion query and response example...........................22
Recursive Name Service..........................................24
Header section format...........................................26
Question section format.........................................29
Resource record format..........................................30
Domain name representation and compression......................31
Organization of the Shared database.............................33
Query processing................................................36
Inverse query processing........................................37
Completion query processing.....................................38
NAME SERVER MAINTENANCE............................................39
Introduction....................................................39
Conceptual model of maintenance operations......................39
Name server data structures and top level logic.................41
Name server file loading........................................43
Name server file loading example................................45
Name server remote zone transfer................................47
RESOLVER ALGORITHMS................................................50
Operations......................................................50
DOMAIN SUPPORT FOR MAIL............................................52
Introduction....................................................52
Agent binding...................................................53
Mailbox binding.................................................54
Appendix 1 - Domain Name Syntax Specification......................56
Appendix 2 - Field formats and encodings...........................57
TYPE values.....................................................57
QTYPE values....................................................57
CLASS values....................................................58
QCLASS values...................................................58
Standard resource record formats................................59
Appendix 3 - Internet specific field formats and operations........67
REFERENCES and BIBLIOGRAPHY........................................72
INDEX..............................................................73
目次序論…3概要…3 実装コンポーネント…2つのコンベンション…6 哲学を設計してください…8 ネームサーバトランザクション…11序論…11質問と応答輸送…11 総合的なメッセージ・フォーマット…13 標準の質問と応答のコンテンツ…15の標準の質問と応答の例…15 逆さの質問と応答のコンテンツ…17の逆さの質問と応答の例…18の完成質問と応答…19の完成質問と応答の例…22 再帰的な名前サービス…24 ヘッダーセクション形式…26 セクション形式に質問してください…29リソースレコード形式…30ドメイン名表現と圧縮…31 Sharedデータベースの組織…33 処理について質問してください…36 逆さの問い合わせ処理…37 完成問い合わせ処理…38 ネームサーバメインテナンス…39序論…39 メインテナンス操作の概念モデル…39 ネームサーバデータ構造と先端は論理を平らにします…41ネームサーバファイルローディング…43ネームサーバファイルローディングの例…45 ネームサーバのリモートゾーン転送…47 レゾルバアルゴリズム…50の操作…50 メールのドメインサポート…52序論…52 エージェント結合…53 メールボックス結合…54 付録1--ドメイン名構文仕様…56 付録2--Fieldは…をフォーマットして、encodingsします…57 TYPE値…57 QTYPE値…57のCLASS値…58のQCLASS値…58 標準のリソースレコード形式…59 付録3--インターネットの特定のフィールド形式と操作…67の参照箇所と図書目録…72 索引をつけてください…73
Mockapetris [Page ii]
Mockapetris[ページii]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
INTRODUCTION
序論
Overview
概要
The goal of domain names is to provide a mechanism for naming
resources in such a way that the names are usable in different
hosts, networks, protocol families, internets, and administrative
organizations.
ドメイン名の目標は名前が異なったホスト、ネットワーク、プロトコルファミリー、インターネット、および管理編成で使用可能であるような方法でリソースを命名するのにメカニズムを提供することです。
From the user's point of view, domain names are useful as
arguments to a local agent, called a resolver, which retrieves
information associated with the domain name. Thus a user might
ask for the host address or mail information associated with a
particular domain name. To enable the user to request a
particular type of information, an appropriate query type is
passed to the resolver with the domain name. To the user, the
domain tree is a single information space.
レゾルバ(ドメイン名に関連している情報を検索する)は、ユーザの観点から、ドメイン名が議論として地元のエージェントの役に立つと言いました。 したがって、ユーザは特定のドメイン名に関連しているホスト・アドレスかメール情報を求めるかもしれません。 ユーザが特定の情報の種類を要求するのを可能にするために、適切な質問タイプはドメイン名でレゾルバに渡されます。 ユーザにとって、ドメイン木はただ一つの情報スペースです。
From the resolver's point of view, the database that makes up the
domain space is distributed among various name servers. Different
parts of the domain space are stored in different name servers,
although a particular data item will usually be stored redundantly
in two or more name servers. The resolver starts with knowledge
of at least one name server. When the resolver processes a user
query it asks a known name server for the information; in return,
the resolver either receives the desired information or a referral
to another name server. Using these referrals, resolvers learn
the identities and contents of other name servers. Resolvers are
responsible for dealing with the distribution of the domain space
and dealing with the effects of name server failure by consulting
redundant databases in other servers.
リゾルバの観点から、ドメインスペースを作るデータベースは様々なネームサーバの中で分配されます。 ドメインスペースの異なった地域は異なったネームサーバで保存されます、特定のデータ項目が2つ以上のネームサーバで通常冗長に保存されるでしょうが。 レゾルバは少なくとも1つのネームサーバに関する知識から始まります。レゾルバがユーザー・クエリーを処理するとき、情報のために知られているネームサーバを尋ねます。 代わりに、レゾルバは必要な情報か紹介を別のネームサーバに受け取ります。これらの紹介を使用して、レゾルバは他のネームサーバのアイデンティティとコンテンツを学びます。 レゾルバはドメインスペースの分配に対処して、他のサーバの余分なデータベースに相談することによってネームサーバ失敗の影響に対処するのに責任があります。
Name servers manage two kinds of data. The first kind of data
held in sets called zones; each zone is the complete database for
a particular subtree of the domain space. This data is called
authoritative. A name server periodically checks to make sure
that its zones are up to date, and if not obtains a new copy of
updated zones from master files stored locally or in another name
server. The second kind of data is cached data which was acquired
by a local resolver. This data may be incomplete but improves the
performance of the retrieval process when non-local data is
repeatedly accessed. Cached data is eventually discarded by a
timeout mechanism.
ネームサーバは2種類のデータを管理します。 最初の種類に関するデータはゾーンと呼ばれるセットで成立しました。 各ゾーンはドメインスペースの特定の下位木のための完全なデータベースです。 このデータは正式であると呼ばれます。 データの種類は地元のレゾルバによって取得されたキャッシュされたデータです。定期的にゾーンが上がっているのを念のため日付までチェックして、そうでなければ、局所的に保存された基本ファイルから新しいコピーのアップデートされたゾーンを得るか、または別名サーバ非ローカルのデータが繰り返して向上するこのデータが不完全であるかもしれませんが、検索過程の性能を向上させる秒にアクセスされて、ネームサーバはチェックします。 キャッシュされたデータは結局、タイムアウトメカニズムによって捨てられます。
This functional structure isolates the problems of user interface,
failure recovery, and distribution in the resolvers and isolates
the database update and refresh problems in the name servers.
この機能別組織構造は、レゾルバでユーザーインタフェースの問題、失敗回復、および分配を隔離して、データベース更新を隔離します、そして、ネームサーバにおける問題をリフレッシュしてください。
Mockapetris [Page 1]
Mockapetris[1ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Implementation components
実装コンポーネント
A host can participate in the domain name system in a number of
ways, depending on whether the host runs programs that retrieve
information from the domain system, name servers that answer
queries from other hosts, or various combinations of both
functions. The simplest, and perhaps most typical, configuration
is shown below:
ホストは多くの方法でドメイン名システムに参加できます、ホストがドメインシステム、他のホストから質問に答えるネームサーバ、または両方の機能の様々な組み合わせから情報を検索するプログラムを動かすかどうかによって。 最も簡単で、恐らく最も典型的な構成は以下に示されます:
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| database | |
+----------+ |
ローカル・ホスト| 外国| +---------+ +----------+ | +--------+ | | ユーザー・クエリー| |質問| | | | ユーザ|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、-、--、|、-、>|外国| | プログラム| | レゾルバ| | | 名前| | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、--、|、--、| サーバ| | | ユーザ応答| |応答| | | +---------+ +----------+ | +--------+ | A| キャッシュ追加| | 参照| V| | +----------+ | | データベース| | +----------+ |
User programs interact with the domain name space through
resolvers; the format of user queries and user responses is
specific to the host and its operating system. User queries will
typically be operating system calls, and the resolver and its
database will be part of the host operating system. Less capable
hosts may choose to implement the resolver as a subroutine to be
linked in with every program that needs its services.
ユーザ・プログラムはレゾルバを通してドメイン名スペースと対話します。 ユーザー・クエリーとユーザ応答の形式はホストとそのオペレーティングシステムに特定です。 ユーザー・クエリーは通常オペレーティングシステム呼び出しになるでしょう、そして、レゾルバとそのデータベースはホスト・オペレーティング・システムの一部になるでしょう。 それほどできないホストは、サービスを必要とするあらゆるプログラムにリンクされるサブルーチンとしてレゾルバを実装するのを選ぶかもしれません。
Resolvers answer user queries with information they acquire via
queries to foreign name servers, and may also cache or reference
domain information in the local database.
それらが外国ネームサーバへの質問で取得して、またキャッシュするかもしれない情報か参照ドメイン情報がローカルのデータベースにある状態で、レゾルバはユーザー・クエリーに答えます。
Note that the resolver may have to make several queries to several
different foreign name servers to answer a particular user query,
and hence the resolution of a user query may involve several
network accesses and an arbitrary amount of time. The queries to
foreign name servers and the corresponding responses have a
standard format described in this memo, and may be datagrams.
レゾルバが特定のユーザー・クエリーに答えるためにいくつかの質問をいくつかの異なった外国ネームサーバにしなければならないかもしれないことに注意してください。そうすれば、したがって、ユーザー・クエリーの決議はいくつかのネットワークアクセスと任意の時間を伴ってもよいです。 外国ネームサーバと対応する応答への質問は、このメモで説明された標準書式を持って、データグラムであるかもしれません。
Mockapetris [Page 2]
Mockapetris[2ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Depending on its capabilities, a name server could be a stand
alone program on a dedicated machine or a process or processes on
a large timeshared host. A simple configuration might be:
能力によって、ネームサーバは大きいtimesharedホストの上の専用マシン、プロセスまたはプロセスに関するスタンドアロンプログラムであるかもしれません。 簡単な構成は以下の通りです。
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
ローカル・ホスト| 外国| +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | |応答| | | | | | | 名前|、-、-、-、-、-、-、-、--、|、-、>|外国| | マスター|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| サーバ| | |レゾルバ| | ファイル| | | | <、-、-、-、-、-、-、--、|、--、|、|、| |/ | | 質問| +--------+ +---------+ +----------+ |
Here the name server acquires information about one or more zones
by reading master files from its local file system, and answers
queries about those zones that arrive from foreign resolvers.
ここで、ネームサーバは、ローカルファイルシステムから基本ファイルを読むことによってより多くの情報およそ1ゾーンを取得して、外国人のレゾルバから到着するそれらのゾーンに関して質問に答えます。
A more sophisticated name server might acquire zones from foreign
name servers as well as local master files. This configuration is
shown below:
より洗練されたネームサーバはローカルの基本ファイルと同様に外国ネームサーバからゾーンを取得するかもしれません。 この構成は以下に示されます:
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| \------------|->| |
| queries | |Foreign |
| | | Name |
\------------------|--| Server |
maintenance responses | +--------+
ローカル・ホスト| 外国| +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | |応答| | | | | | | 名前|、-、-、-、-、-、-、-、--、|、-、>|外国| | マスター|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| サーバ| | |レゾルバ| | ファイル| | | | <、-、-、-、-、-、-、--、|、--、|、|、| |/ | | 質問| +--------+ +---------+ +----------+ | A|メインテナンス| +--------+ | \------------|、-、>|、|、| 質問| |外国| | | | 名前| \------------------|--| サーバ| メインテナンス応答| +--------+
In this configuration, the name server periodically establishes a
virtual circuit to a foreign name server to acquire a copy of a
zone or to check that an existing copy has not changed. The
messages sent for these maintenance activities follow the same
form as queries and responses, but the message sequences are
somewhat different.
この構成では、ネームサーバは、ゾーンのコピーを入手するか、または既存のコピーが変化していないのをチェックするために仮想の回路を外国ネームサーバに定期的に確立します。 これらのメインテナンス活動のために送られたメッセージは質問と応答と同じフォームに続きますが、メッセージ系列はいくらか異なっています。
Mockapetris [Page 3]
Mockapetris[3ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
The information flow in a host that supports all aspects of the
domain name system is shown below:
ドメイン名システムの全面をサポートするホストでの情報流動は以下に示されます:
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| Shared | |
| database | |
+----------+ |
A | |
+---------+ refreshes | | references |
/ /| | V |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| \------------|->| |
| queries | |Foreign |
| | | Name |
\------------------|--| Server |
maintenance responses | +--------+
ローカル・ホスト| 外国| +---------+ +----------+ | +--------+ | | ユーザー・クエリー| |質問| | | | ユーザ|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、-、--、|、-、>|外国| | プログラム| | レゾルバ| | | 名前| | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、--、|、--、| サーバ| | | ユーザ応答| |応答| | | +---------+ +----------+ | +--------+ | A| キャッシュ追加| | 参照| V| | +----------+ | | 共有されます。| | | データベース| | +----------+ | A| | +---------+はリフレッシュします。| | 参照| / /| | V| +---------+ | +----------+ | +--------+ | | | | |応答| | | | | | | 名前|、-、-、-、-、-、-、-、--、|、-、>|外国| | マスター|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| サーバ| | |レゾルバ| | ファイル| | | | <、-、-、-、-、-、-、--、|、--、|、|、| |/ | | 質問| +--------+ +---------+ +----------+ | A|メインテナンス| +--------+ | \------------|、-、>|、|、| 質問| |外国| | | | 名前| \------------------|--| サーバ| メインテナンス応答| +--------+
The shared database holds domain space data for the local name
server and resolver. The contents of the shared database will
typically be a mixture of authoritative data maintained by the
periodic refresh operations of the name server and cached data
from previous resolver requests. The structure of the domain data
and the necessity for synchronization between name servers and
resolvers imply the general characteristics of this database, but
the actual format is up to the local implementer. This memo
suggests a multiple tree format.
共有データベースは地方名サーバとレゾルバへのドメインスペースデータを保持します。共有データベースのコンテンツは前のレゾルバ要求からネームサーバとキャッシュされたデータの周期的なリフレッシュ操作で維持された信頼すべきデータの通常混合物になるでしょう。 ドメインデータの構造とネームサーバとレゾルバの間の同期の必要性はこのデータベースの一般的特色を含意しますが、実際の形式は地方のimplementer次第です。 このメモは複数の木の書式を示します。
Mockapetris [Page 4]
Mockapetris[4ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
This memo divides the implementation discussion into sections:
このメモは実装議論をセクションに分割します:
NAME SERVER TRANSACTIONS, which discusses the formats for name
servers queries and the corresponding responses.
NAME SERVER TRANSACTIONS。(そのNAME SERVER TRANSACTIONSはネームサーバ質問と対応する応答のために形式について議論します)。
NAME SERVER MAINTENANCE, which discusses strategies,
algorithms, and formats for maintaining the data residing in
name servers. These services periodically refresh the local
copies of zones that originate in other hosts.
NAME SERVER MAINTENANCE。(そのNAME SERVER MAINTENANCEは、ネームサーバであるデータを保守するために戦略、アルゴリズム、および形式について議論します)。 これらのサービスは定期的に他のホストで起こる地方のコピーのゾーンをリフレッシュします。
RESOLVER ALGORITHMS, which discusses the internal structure of
resolvers. This section also discusses data base sharing
between a name server and a resolver on the same host.
RESOLVER ALGORITHMS。(そのRESOLVER ALGORITHMSはレゾルバの内部の構造について議論します)。 また、このセクションは同じホストの上にネームサーバとレゾルバを平等に割り当てるデータベースについて論じます。
DOMAIN SUPPORT FOR MAIL, which discusses the use of the domain
system to support mail transfer.
DOMAIN SUPPORT FOR MAIL。(そのDOMAIN SUPPORT FOR MAILは、メールが転送であるとサポートするためにドメインシステムの使用について議論します)。
Mockapetris [Page 5]
Mockapetris[5ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Conventions
コンベンション
The domain system has several conventions dealing with low-level,
but fundamental, issues. While the implementer is free to violate
these conventions WITHIN HIS OWN SYSTEM, he must observe these
conventions in ALL behavior observed from other hosts.
ドメインシステムで、数人のコンベンションが低レベルですが、基本的な問題に対処します。 implementerが自由にこれらのコンベンションWITHIN HIS OWN SYSTEMに違反できる間、彼は他のホストから観測されたすべての振舞いにおけるこれらのコンベンションを観測しなければなりません。
********** Data Transmission Order **********
********** データ伝送オーダー**********
The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows
a group of octets, the order of transmission of those octets is
the normal order in which they are read in English. For example,
in the following diagram the octets are transmitted in the order
they are numbered.
本書では説明されたヘッダーとデータの伝達の注文を八重奏レベルに決議します。 ダイヤグラムが八重奏のグループを示しているときはいつも、それらの八重奏の送信の注文はそれらが英語で読まれる通常のオーダーです。 例えば、以下のダイヤグラムで、八重奏はオーダーで伝えられて、それらが番号付であるということです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transmission Order of Bytes
バイトのトランスミッション命令
Whenever an octet represents a numeric quantity the left most bit
in the diagram is the high order or most significant bit. That
is, the bit labeled 0 is the most significant bit. For example,
the following diagram represents the value 170 (decimal).
八重奏が数値量を表すときはいつも、ダイヤグラムで最も噛み付かれた左は、高位か最上位ビットです。 すなわち、0とラベルされたビットは最も重要なビットです。 例えば、以下のダイヤグラムは値170の(小数)を表します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1 0 1 0 1 0 1 0| +-+-+-+-+-+-+-+-+
Significance of Bits
ビットの意味
Similarly, whenever a multi-octet field represents a numeric
quantity the left most bit of the whole field is the most
significant bit. When a multi-octet quantity is transmitted the
most significant octet is transmitted first.
同様に、マルチ八重奏分野が数値量を表すときはいつも、大部分が噛み付いた全体の分野の左は最も重要なビットです。 マルチ八重奏量が伝えられるとき、最も重要な八重奏は最初に、伝えられます。
Mockapetris [Page 6]
Mockapetris[6ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
********** Character Case **********
********** キャラクターケース**********
All comparisons between character strings (e.g. labels, domain
names, etc.) are done in a case-insensitive manner.
大文字と小文字を区別しない方法で文字列(例えば、ラベル、ドメイン名など)でのすべての比較をします。
When data enters the domain system, its original case should be
preserved whenever possible. In certain circumstances this cannot
be done. For example, if two domain names x.y and X.Y are entered
into the domain database, they are interpreted as the same name,
and hence may have a single representation. The basic rule is
that case can be discarded only when data is used to define
structure in a database, and two names are identical when compared
in a case insensitive manner.
データがドメインシステムを入れるとき、可能であるときはいつも、オリジナルのケースは保存されるべきです。 ある特定の状況ではこれができません。 例えば、2つのドメイン名x.yとX.Yがドメインデータベースに入れられるなら、それらは、同じ名前として解釈されて、したがって、ただ一つの表現を持っているかもしれません。 基本的な規則はデータがデータベースで構造を定義するのに使用されるときだけ、ケースを捨てることができて、大文字と小文字を区別しない方法で比べると2つの名前が同じであるということです。
Loss of case sensitive data must be minimized. Thus while data
for x.y and X.Y may both be stored under x.y, data for a.x and B.X
can be stored as a.x and B.x, but not A.x, A.X, b.x, or b.X. In
general, this prevents the first component of a domain name from
loss of case information.
大文字と小文字を区別するデータの損失を最小にしなければなりません。 したがって、x.yとX.Yのためのデータがx.yの下にともに保存されているかもしれない間、A.x、A.X、b.x、またはb.X.In一般ではなく、a.xとB.xとしてa.xとB.Xのためのデータを保存できて、これはケース情報の損失からドメイン名の最初の成分を防ぎます。
Systems administrators who enter data into the domain database
should take care to represent the data they supply to the domain
system in a case-consistent manner if their system is
case-sensitive. The data distribution system in the domain system
will ensure that consistent representations are preserved.
それらのシステムが大文字と小文字を区別しているなら、ドメインデータベースにデータを入力する上級システムアドミニストレータは、それらがケース一貫した方法でドメインシステムに提供するデータを表すために注意するべきです。 ドメインシステムのデータ流通制度は、一貫した表現が保存されるのを確実にするでしょう。
Mockapetris [Page 7]
Mockapetris[7ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Design philosophy
設計理念
The design presented in this memo attempts to provide a base which
will be suitable for several existing networks. An equally
important goal is to provide these services within a framework
that is capable of adjustment to fit the evolution of services in
early clients as well as to accommodate new networks.
このメモに提示されたデザインは、いくつかの既存のネットワークに適したベースを供給するのを試みます。 等しく重要な目標は初期のクライアントでのサービスの発展に合って、新しいネットワークに対応するために調整ができるフレームワークの中のこれらのサービスを提供することです。
Since it is impossible to predict the course of these
developments, the domain system attempts to provide for evolution
in the form of an extensible framework. This section describes
the areas in which we expect to see immediate evolution.
これらの開発のコースを予測するのが不可能であるので、ドメインシステムは、広げることができるフレームワークの形に発展に備えるのを試みます。 このセクションは私たちが即座の発展を見ると予想する領域について説明します。
DEFINING THE DATABASE
データベースを定義します。
This memo defines methods for partitioning the database and data
for host names, host addresses, gateway information, and mail
support. Experience with this system will provide guidance for
future additions.
このメモはデータベースを仕切るためのメソッドとホスト名、ホスト・アドレス、ゲートウェイ情報、およびメールサポートのためのデータを定義します。 このシステムの経験は将来の追加のための指導を提供するでしょう。
While the present system allows for many new RR types, classes,
etc., we feel that it is more important to get the basic services
in operation than to cover an exhaustive set of information.
Hence we have limited the data types to those we felt were
essential, and would caution designers to avoid implementations
which are based on the number of existing types and classes.
Extensibility in this area is very important.
現行制度が多くの新しいRRタイプ、クラスなどを考慮している間、私たちは、稼働中である基本サービスを得るのが徹底的な情報をカバーするより重要であると感じます。 したがって、私たちは、それらへの私たちが不可欠であると感じたデータ型を制限して、デザイナーが既存のタイプとクラスの数に基づいている実装を避けると警告するでしょう。 この領域の伸展性は非常に重要です。
While the domain system provides techniques for partitioning the
database, policies for administrating the orderly connection of
separate domains and guidelines for constructing the data that
makes up a particular domain will be equally important to the
success of the system. Unfortunately, we feel that experience
with prototype systems will be necessary before this question can
be properly addressed. Thus while this memo has minimal
discussion of these issues, it is a critical area for development.
ドメインシステムがデータベースを仕切るためのテクニックを提供する間、別々のドメインの規則的な接続を管理するための方針と特定のドメインを作るデータを構成するためのガイドラインは等しくシステムの成功に重要になるでしょう。 残念ながら、私たちは、適切にこの質問を扱うことができる前にプロトタイプ装置の経験が必要になるのを感じます。 したがって、このメモはこれらの問題の最小量の議論をしますが、それは開発のための重大な領域です。
TYING TOGETHER INTERNETS
インターネットを結びつけます。
Although it is very difficult to characterize the types of
networks, protocols, and applications that will be clients of the
domain system, it is very obvious that some of these applications
will cross the boundaries of network and protocol. At the very
least, mail is such a service.
ドメインシステムのクライアントになるネットワーク、プロトコル、およびアプリケーションのタイプについて描写するのが非常に難しいのですが、これらのアプリケーションのいくつかがネットワークの限界に交差していて、議定書を作るのは、非常に明白です。 メールは少なくとも、サービスです。
Attempts to unify two such systems must deal with two major
problems:
そのような2台のシステムを統一する試みは2つの大した問題に対処しなければなりません:
1. Differing formats for environment sensitive data. For example,
1. 相違は環境のために極秘データをフォーマットします。 例えば
Mockapetris [Page 8]
Mockapetris[8ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
network addresses vary in format, and it is unreasonable to
expect to enforce consistent conventions.
ネットワーク・アドレスは形式において異なります、そして、一貫したコンベンションを実施すると予想するのは無理です。
2. Connectivity may require intermediaries. For example, it is a
frequent occurence that mail is sent between hosts that share
no common protocol.
2. 接続性は仲介者を必要とするかもしれません。 例えば、どんな一般的なプロトコルも共有しないホストの間にメールを送るのは、頻繁なoccurenceです。
The domain system acknowledges that these are very difficult
problems, and attempts to deal with both problems through its
CLASS mechanism:
ドメインシステムは、これらが非常に難しい問題であると認めて、CLASSメカニズムを通して両方の問題に対処するのを試みます:
1. The CLASS field in RRs allows data to be tagged so that all
programs in the domain system can identify the format in use.
1. RRsのCLASS分野は、ドメインシステムにおけるすべてのプログラムが使用中の形式を特定できるように、データがタグ付けをされるのを許容します。
2. The CLASS field allows the requestor to identify the format of
data which can be understood by the requestor.
2. CLASS分野で、要請者は要請者に解釈できるデータの形式を特定できます。
3. The CLASS field guides the search for the requested data.
3. CLASS分野は要求されたデータの検索を誘導します。
The last point is central to our approach. When a query crosses
protocol boundaries, it must be guided though agents capable of
performing whatever translation is required. For example, when a
mailer wants to identify the location of a mailbox in a portion of
the domain system that doesn't have a compatible protocol, the
query must be guided to a name server that can cross the boundary
itself or form one link in a chain that can span the differences.
最後のポイントは私たちのアプローチに主要です。 質問がプロトコル限界に交差するとき、翻訳がことなら何でもであるか実行できるエージェントが必要ですが、それを誘導しなければなりません。 例えば、郵送者がコンパチブルプロトコルを持っていないドメインシステムの部分でメールボックスの位置を特定したいと、境界自体に交差しているか、または違いにかかることができる1個の鎖の輪を形成できるネームサーバに質問を誘導しなければなりません。
If query and response transport were the only problem, then this
sort of problem could be dealt with in the name servers
themselves. However, the applications that will use domain
service have similar problems. For example, mail may need to be
directed through mail gateways, and the characteristics of one of
the environments may not permit frequent connectivity between name
servers in all environments.
質問と応答輸送が唯一の問題であるなら、ネームサーバ自体でこの種類の問題に対処できるでしょうに。 しかしながら、ドメインサービスを利用するアプリケーションは同様の問題を持っています。例えば、メールは、メール・ゲートウェイを通して指示される必要があるかもしれません、そして、環境の1つの特性はすべての環境におけるネームサーバの間の頻繁な接続性を許可しないかもしれません。
These problems suggest that connectivity will be achieved through
a variety of measures:
これらの問題は、接続性がさまざまな測定を通して達成されるのを示します:
Translation name servers that act as relays between different
protocols.
異なったプロトコルの間のリレーとして機能する翻訳ネームサーバ。
Translation application servers that translate application
level transactions.
アプリケーションを翻訳する翻訳アプリケーション・サーバーがトランザクションを平らにします。
Default database entries that route traffic through application
level forwarders in ways that depend on the class of the
requestor.
アプリケーションでトラフィックを発送するデフォルトデータベースエントリーが要請者のクラスに依存する方法で混載業者を平らにします。
While this approach seems best given our current understanding of
私たちの現在の理解を考えて、アプローチが最もよく思えるこれをゆったり過ごします。
Mockapetris [Page 9]
Mockapetris[9ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
the problem, we realize that the approach of using resource data
that transcends class may be appropriate in future designs or
applications. By not defining class to be directly related to
protocol, network, etc., we feel that such services could be added
by defining a new "universal" class, while the present use of
class will provide immediate service.
問題、私たちはクラスを超えているデータがそうする使用リソースのアプローチが将来のデザインかアプリケーションで適切であるとわかります。 直接プロトコル、ネットワークなどに関連されるようにクラスを定義しないことによって、私たちは、新しい「普遍的な」クラスを定義することによってそのようなサービスを加えることができるだろうと感じます、クラスの現在の使用は即座のサービスを提供するでしょうが。
This problem requires more thought and experience before solutions
can be discovered. The concepts of CLASS, recursive servers and
other mechanisms are intended as tools for acquiring experience
and not as final solutions.
ソリューションを発見できる前にこの問題は、より多くの考えと経験を必要とします。 CLASSの概念、再帰的なサーバ、および他のメカニズムは最終的な解決として意図するのではなく、経験を積むためのツールとして意図します。
Mockapetris [Page 10]
Mockapetris[10ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
NAME SERVER TRANSACTIONS
ネームサーバトランザクション
Introduction
序論
The primary purpose of name servers is to receive queries from
resolvers and return responses. The overall model of this service
is that a program (typically a resolver) asks the name server
questions (queries) and gets responses that either answer the
question or refer the questioner to another name server. Other
functions related to name server database maintenance use similar
procedures and formats and are discussed in a section later in
this memo.
ネームサーバのプライマリ目的は、レゾルバから質問を受けて、応答を返すことです。 このサービスの総合的なモデルはプログラム(通常レゾルバ)が別のネームサーバにネームサーバ質問(質問)をして、質問に答えるか、または質問者を参照する応答を得るということです。ネームサーバデータベースメインテナンスに関連する他の機能について、同様の手順と形式を用いて、後でこのメモでセクションで議論します。
There are three kinds of queries presently defined:
現在定義されている3種類の質問があります:
1. Standard queries that ask for a specified resource attached
to a given domain name.
1. 指定されたリソースを求める標準の質問が与えられたドメイン名に付きました。
2. Inverse queries that specify a resource and ask for a domain
name that possesses that resource.
2. リソースを指定して、そのリソースを持っているドメイン名を求める逆さの質問。
3. Completion queries that specify a partial domain name and a
target domain and ask that the partial domain name be
completed with a domain name close to the target domain.
3. 部分的なドメイン名とターゲット・ドメインを指定して、部分的なドメイン名がドメイン名で完成するように頼む完成質問がターゲット・ドメインに終えられます。
This memo uses an unqualified reference to queries to refer to
either all queries or standard queries when the context is clear.
このメモは、関係が明確であるときに、すべての質問か標準の質問のどちらかに言及するのに質問の資格のない参照を使用します。
Query and response transport
質問と応答輸送
Name servers and resolvers use a single message format for all
communications. The message format consists of a variable-length
octet string which includes binary values.
ネームサーバとレゾルバはすべてのコミュニケーションにただ一つのメッセージ・フォーマットを使用します。 メッセージ・フォーマットは2進の値を含んでいる可変長の八重奏ストリングから成ります。
The messages used in the domain system are designed so that they
can be carried using either datagrams or virtual circuits. To
accommodate the datagram style, all responses carry the query as
part of the response.
ドメインシステムに使用されるメッセージは、データグラムか仮想の回路のどちらかを使用することでそれらを運ぶことができるように設計されています。 データグラムスタイルを収容するために、すべての応答が応答の一部として質問を運びます。
While the specification allows datagrams to be used in any
context, some activities are ill suited to datagram use. For
example, maintenance transactions and recursive queries typically
require the error control of virtual circuits. Thus datagram use
should be restricted to simple queries.
仕様が、データグラムがどんな文脈でも使用されるのを許容している間、いくつかの活動はデータグラム使用にほとんど合っていません。 例えば、メインテナンストランザクションと反復クエリーは仮想の回路の誤り制御を通常必要とします。 したがって、データグラム使用は簡単な質問に制限されるべきです。
The domain system assumes that a datagram service provides:
ドメインシステムは、データグラムサービスが提供されると仮定します:
1. A non-reliable (i.e. best effort) method of transporting a
message of up to 512 octets.
1. 最大512の八重奏に関するメッセージを輸送する非信頼できる(すなわち、ベストエフォート型の)メソッド。
Mockapetris [Page 11]
Mockapetris[11ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Hence datagram messages are limited to 512 octets. If a
datagram message would exceed 512 octets, it is truncated
and a truncation flag is set in its header.
したがって、データグラムメッセージは512の八重奏に制限されます。 データグラムメッセージが512の八重奏を超えているなら、端が欠けています、そして、トランケーション旗はヘッダーに設定されます。
2. A message size that gives the number of octets in the
datagram.
2. データグラムの八重奏の数を与えるメッセージサイズ。
The main implications for programs accessing name servers via
datagrams are:
データグラムを通してネームサーバにアクセスするプログラムのための主な含意は以下の通りです。
1. Datagrams should not be used for maintenance transactions
and recursive queries.
1. メインテナンストランザクションと反復クエリーにデータグラムを使用するべきではありません。
2. Since datagrams may be lost, the originator of a query must
perform error recovery (such as retransmissions) as
appropriate.
2. データグラムがなくされるかもしれないので、質問の創始者は適宜、エラー回復(「再-トランスミッション」などの)を実行しなければなりません。
3. Since network or host delay may cause retransmission when a
datagram has not been lost, the originator of a query must
be ready to deal with duplicate responses.
3. データグラムがなくされていないとき、ネットワークかホスト遅れが「再-トランスミッション」を引き起こすかもしれないので、質問の創始者は写し応答に対処する準備ができているに違いありません。
The domain system assumes that a virtual circuit service provides:
ドメインシステムは、仮想の回路サービスが提供されると仮定します:
1. A reliable method of transmitting a message of up to 65535
octets.
1. 最大65535の八重奏に関するメッセージを送る確かな方法。
2. A message size that gives the number of octets in the
message.
2. メッセージの八重奏の数を与えるメッセージサイズ。
If the virtual circuit service does not provide for message
boundary detection or limits transmission size to less than
65535 octets, then messages are prefaced with an unsigned 16
bit length field and broken up into separate transmissions
as required. The length field is only prefaced on the first
message. This technique is used for TCP virtual circuits.
仮想の回路サービスがメッセージ境界検出に備えないか、またはトランスミッションサイズを65535未満の八重奏に制限するなら、メッセージは、16ビットの未署名の長さの分野で前書きされて、必要に応じて別々のトランスミッションに終えられます。 長さの分野は最初のメッセージに前書きされるだけです。 このテクニックはTCPの仮想の回路に使用されます。
3. Multiple messages may be sent over a virtual circuit.
3. 仮想の回路の上に複数のメッセージを送るかもしれません。
4. A method for closing a virtual circuit.
4. 仮想の回路を閉じるためのメソッド。
5. A method for detecting that the other party has requested
that the virtual circuit be closed.
5. それを検出して、他がパーティーへ行くので、メソッドは、仮想の回路が閉じられるよう要求しました。
The main implications for programs accessing name servers via
virtual circuits are:
仮想の回路を通してネームサーバにアクセスするプログラムのための主な含意は以下の通りです。
1. Either end of a virtual circuit may initiate a close when
there is no activity in progress. The other end should
comply.
1. 進行中のどんな活動もないとき、仮想の回路のどちらの端も閉鎖を開始するかもしれません。 もう一方の端は応じるべきです。
Mockapetris [Page 12]
Mockapetris[12ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
The decision to initiate a close is a matter of individual
site policy; some name servers may leave a virtual circuit
open for an indeterminate period following a query to allow
for subsequent queries; other name servers may choose to
initiate a close following the completion of the first query
on a virtual circuit. Of course, name servers should not
close the virtual circuit in the midst of a multiple message
stream used for zone transfer.
閉鎖を開始するという決定は独特のサイト方針の問題です。 いくつかのネームサーバが、不確定の期間、開いている仮想の回路がその後の質問を考慮するために質問に続いているままにするかもしれません。 他のネームサーバは、仮想の回路における最初の質問の完成に続いて、閉鎖を開始するのを選ぶかもしれません。 もちろん、ネームサーバはゾーン転送に使用される複数のメッセージストリームの中で仮想の回路を閉じるべきではありません。
2. Since network delay may cause one end to erroneously believe
that no activity is in progress, a program which receives a
virtual circuit close while a query is in progress should
close the virtual circuit and resubmit the query on a new
virtual circuit.
2. 片端が、ネットワーク遅延で活動が全く進行していないと誤って信じるかもしれないので、質問が進行していますが、近くで仮想の回路を受けるプログラムは、仮想の回路を閉じて、新しい仮想の回路の上に質問を再提出するはずです。
All messages may use a compression scheme to reduce the space
consumed by repetitive domain names. The use of the compression
scheme is optional for the sender of a message, but all receivers
must be capable of decoding compressed domain names.
すべてのメッセージが、反復性のドメイン名によって消費されたスペースを減少させるのに圧縮技術を使用するかもしれません。 メッセージの送付者にとって、圧縮技術の使用は任意ですが、すべての受信機が圧縮されたドメイン名を解読できなければなりません。
Overall message format
総合的なメッセージ・フォーマット
All messages sent by the domain system are divided into 5 sections
(some of which are empty in certain cases) shown below:
ドメインシステムによって送られたすべてのメッセージが以下で見せられた5つのセクション(ある場合には、それの或るものは空である)に分割されます:
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | answering resource records (RRs)
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding pertinent information
+---------------------+
+---------------------+ | ヘッダー| +---------------------+ | 問題| ネームサーバ+のための問題---------------------+ | 答え| (RRs)+にリソース記録に答えます。---------------------+ | 権威| 権威+に向かって指すRRs---------------------+ | 追加| 適切な情報+を保持するRRs---------------------+
The header section is always present. The header includes fields
that specify which of the remaining sections are present, and also
specify whether the message is a query, inverse query, completion
query, or response.
ヘッダー部分はいつも存在しています。 ヘッダーは残っているセクションのどれが存在しているかを指定して、またメッセージが質問、逆さの質問、完成質問、または応答であるかを指定する分野を入れます。
The question section contains fields that describe a question to a
name server. These fields are a query type (QTYPE), a query class
(QCLASS), and a query domain name (QNAME).
質問部は質問をネームサーバに説明する分野を含みます。これらの分野は、質問タイプ(QTYPE)と、質問のクラス(QCLASS)と、質問ドメイン名(QNAME)です。
The last three sections have the same format: a possibly empty
list of concatenated resource records (RRs). The answer section
contains RRs that answer the question; the authority section
最後の3つのセクションには、同じ形式があります: 連結されたリソースのことによると空のリストは(RRs)を記録します。 答え部は質問に答えるRRsを含みます。 権威部
Mockapetris [Page 13]
Mockapetris[13ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
contains RRs that point toward an authoritative name server; the
additional records section contains RRs which relate to the query,
but are not strictly answers for the question.
正式のネームサーバに向かって指すRRsを含んでいます。 追加記録部は質問に関連しますが、厳密に関連するというわけではないRRsを含みます。質問のための答え。
The next two sections of this memo illustrate the use of these
message sections through examples; a detailed discussion of data
formats follows the examples.
このメモの次の2つのセクションが例を通したこれらのメッセージ部の使用を例証します。 データ形式の詳細な論議は例に倣っています。
Mockapetris [Page 14]
Mockapetris[14ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
The contents of standard queries and responses
標準の質問と応答のコンテンツ
When a name server processes a standard query, it first determines
whether it is an authority for the domain name specified in the
query.
ネームサーバが標準の質問を処理するとき、それは、最初に、質問で指定されたドメイン名のために権威であるかどうか決定します。
If the name server is an authority, it returns either:
ネームサーバが権威であるなら、戻ります:
1. the specified resource information
1. 指定されたリソース情報
2. an indication that the specified name does not exist
2. 指定された名前が存在していないという指示
3. an indication that the requested resource information does
not exist
3. 要求されたリソース情報が存在していないという指示
If the name server is not an authority for the specified name, it
returns whatever relevant resource information it has along with
resource records that the requesting resolver can use to locate an
authoritative name server.
ネームサーバが指定された名前のための権威でないなら、どんな関連リソース情報も要求しているレゾルバが正式のネームサーバの場所を見つけるのに使用できるリソース記録と共にあっても、それは戻ります。
Standard query and response example
標準の質問と応答の例
The overall structure of a query for retrieving information for
Internet mail for domain F.ISI.ARPA is shown below:
ドメインF. ISI.ARPAのためのインターネット・メールのための情報を検索するための質問の全体的な構造は以下に示されます:
+-----------------------------------------+
Header | OPCODE=QUERY, ID=2304 |
+-----------------------------------------+
Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
+-----------------------------------------+ ヘッダー| OPCODE=質問、ID=2304| +-----------------------------------------+ 問題|QTYPE=MAILA、QCLASS=IN QNAMEはF.ISI.ARPAと等しいです。| +-----------------------------------------+ 答え| <の空の>。| +-----------------------------------------+ 権威| <の空の>。| +-----------------------------------------+追加しています。| <の空の>。| +-----------------------------------------+
The header includes an opcode field that specifies that this
datagram is a query, and an ID field that will be used to
associate replies with the original query. (Some additional
header fields have been omitted for clarity.) The question
section specifies that the type of the query is for mail agent
information, that only ARPA Internet information is to be
considered, and that the domain name of interest is F.ISI.ARPA.
The remaining sections are empty, and would not use any octets in
a real query.
ヘッダーはこのデータグラムが質問であると指定するopcode分野、およびオリジナルの質問に回答を関連づけるのに使用されるID分野を入れます。 (いくつかの追加ヘッダーフィールドが明快ために省略されました。) 質問部は質問のタイプがメールエージェント情報に賛成して、ARPAインターネット情報だけが考えられることになっていて、興味があるドメイン名がF. ISI.ARPAであると指定します。 残っているセクションは、空であり、本当の質問におけるどんな八重奏も使用しないでしょう。
Mockapetris [Page 15]
Mockapetris[15ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
One possible response to this query might be:
この質問への1つの可能な応答は以下の通りです。
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=2304 |
+-----------------------------------------+
Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | ARPA NS IN A.ISI.ARPA |
| ------- |
| ARPA NS IN F.ISI.ARPA |
+-----------------------------------------+
Additional | F.ISI.ARPA A IN 10.2.0.52 |
| ------- |
| A.ISI.ARPA A IN 10.1.0.22 |
+-----------------------------------------+
+-----------------------------------------+ ヘッダー| OPCODE=応答、ID=2304| +-----------------------------------------+ 問題|QTYPE=MAILA、QCLASS=IN QNAMEはF.ISI.ARPAと等しいです。| +-----------------------------------------+ 答え| <の空の>。| +-----------------------------------------+ 権威| A.ISI.ARPAのアルパナノ秒| | ------- | | F.ISI.ARPAのアルパナノ秒| +-----------------------------------------+追加しています。| F.ISI.ARPA A IN10.2.0、.52| | ------- | | A.ISI.ARPA A IN10.1.0、.22| +-----------------------------------------+
This type of response would be returned by a name server that was
not an authority for the domain name F.ISI.ARPA. The header field
specifies that the datagram is a response to a query with an ID of
2304. The question section is copied from the question section in
the query datagram.
ドメイン名F. ISI.ARPAのための権威でなかったネームサーバはこのタイプの応答を返すでしょう。 ヘッダーフィールドは、データグラムが2304年のIDとの質問への応答であると指定します。 質問部は質問データグラムの質問部からコピーされます。
The answer section is empty because the name server did not have
any information that would answer the query. (Name servers may
happen to have cached information even if they are not
authoritative for the query.)
ネームサーバには質問に答える少しの情報もなかったので、答え部は人影がありません。 (質問には、それらが正式でなくても、ネームサーバはたまたま情報をキャッシュしたかもしれません。)
The best that this name server could do was to pass back
information for the domain ARPA. The authority section specifies
two name servers for the domain ARPA using the Internet family:
A.ISI.ARPA and F.ISI.ARPA. Note that it is merely a coincidence
that F.ISI.ARPA is a name server for ARPA as well as the subject
of the query.
このネームサーバが尽くすことができたベストはドメインARPAのための情報を戻すことでした。 権威部はインターネットファミリーを使用することでドメインARPAに2つのネームサーバを指定します: A.ISI.ARPAとF.ISI.ARPA。 F. ISI.ARPAが質問の対象と同様にARPAのためのネームサーバであることが単に偶然の一致であることに注意してください。
In this case, the name server included in the additional records
section the Internet addresses for the two hosts specified in the
authority section. Such additional data is almost always
available.
この場合、ネームサーバは追加記録部に権威部で指定された2人のホストのためのインターネット・アドレスを含んでいました。 そのような追加データはほとんどいつも利用可能です。
Given this response, the process that originally sent the query
might resend the query to the name server on A.ISI.ARPA, with a
new ID of 2305.
この応答を考えて、元々質問を送ったプロセスはA. ISI.ARPAの上のネームサーバに質問を再送するかもしれません、2305年の新しいIDと共に。
Mockapetris [Page 16]
Mockapetris[16ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
The name server on A.ISI.ARPA might return a response:
A. ISI.ARPAの上のネームサーバは応答を返すかもしれません:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=2305 |
+-----------------------------------------+
Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | F.ISI.ARPA MD IN F.ISI.ARPA |
| ------- |
| F.ISI.ARPA MF IN A.ISI.ARPA |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | F.ISI.ARPA A IN 10.2.0.52 |
| ------- |
| A.ISI.ARPA A IN 10.1.0.22 |
+-----------------------------------------+
+-----------------------------------------+ ヘッダー| OPCODE=応答、ID=2305| +-----------------------------------------+ 問題|QTYPE=MAILA、QCLASS=IN QNAMEはF.ISI.ARPAと等しいです。| +-----------------------------------------+ 答え| F.ISI.ARPAのF.ISI.ARPA MD| | ------- | | A.ISI.ARPAのF.ISI.ARPA mf| +-----------------------------------------+ 権威| <の空の>。| +-----------------------------------------+追加しています。| F.ISI.ARPA A IN10.2.0、.52| | ------- | | A.ISI.ARPA A IN10.1.0、.22| +-----------------------------------------+
This query was directed to an authoritative name server, and hence
the response includes an answer but no authority records. In this
case, the answer section specifies that mail for F.ISI.ARPA can
either be delivered to F.ISI.ARPA or forwarded to A.ISI.ARPA. The
additional records section specifies the Internet addresses of
these hosts.
この質問は正式のネームサーバに向けられました、そして、したがって、答えを含んでいますが、応答はどんな権威記録も含んでいません。 この場合、答え部は、F. ISI.ARPAのためのメールをF. ISI.ARPAに提供するか、またはA. ISI.ARPAに転送できると指定します。 追加記録部はこれらのホストのインターネット・アドレスを指定します。
The contents of inverse queries and responses
逆さの質問と応答のコンテンツ
Inverse queries reverse the mappings performed by standard query
operations; while a standard query maps a domain name to a
resource, an inverse query maps a resource to a domain name. For
example, a standard query might bind a domain name to a host
address; the corresponding inverse query binds the host address to
a domain name.
逆さの質問は標準の質問操作で実行されたマッピングを逆にします。 標準の質問はドメイン名をリソースに写像しますが、逆さの質問はリソースをドメイン名に写像します。 例えば、標準の質問はホスト・アドレスにドメイン名を縛るかもしれません。 対応する逆さの質問はドメイン名にホスト・アドレスを縛ります。
Inverse query mappings are not guaranteed to be unique or complete
because the domain system does not have any internal mechanism for
determining authority from resource records that parallels the
capability for determining authority as a function of domain name.
In general, resolvers will be configured to direct inverse queries
to a name server which is known to have the desired information.
ドメインシステムにはリソース記録から権威を決定するためのドメイン名の機能として権威を決定するために能力に沿うどんな内部のメカニズムもないので、逆さの質問マッピングはユニークであるか、または完全になるように保証されません。 一般に、レゾルバは、必要な情報を持っているのが知られているネームサーバに逆さの質問を向けるために構成されるでしょう。
Name servers are not required to support any form of inverse
queries; it is anticipated that most name servers will support
address to domain name conversions, but no other inverse mappings.
If a name server receives an inverse query that it does not
support, it returns an error response with the "Not Implemented"
error set in the header. While inverse query support is optional,
all name servers must be at least able to return the error
response.
ネームサーバはどんな形式の逆さの質問もサポートするのに必要ではありません。 ほとんどのネームサーバがドメイン名変換にもかかわらず、他のどんな逆マッピング変換にもアドレスをサポートしないと予期されます。 ネームサーバがそれがサポートしない逆さの質問を受けるなら、それはヘッダーに設定された「実装していない」誤りと共に誤り応答を返します。 逆さの質問サポートが任意である間、すべてのネームサーバが誤り応答を少なくとも返すことができなければなりません。
Mockapetris [Page 17]
Mockapetris[17ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
When a name server processes an inverse query, it either returns:
ネームサーバが逆さの質問を処理するとき、戻ります:
1. zero, one, or multiple domain names for the specified
resource
1. 指定されたリソースのためのゼロ、もの、または複数のドメイン名
2. an error code indicating that the name server doesn't
support inverse mapping of the specified resource type.
2. ネームサーバが指定されたリソースタイプの逆マッピング変換をサポートしないのを示すエラーコード。
Inverse query and response example
逆さの質問と応答の例
The overall structure of an inverse query for retrieving the
domain name that corresponds to Internet address 10.2.0.52 is
shown below:
インターネット・アドレスに対応するドメイン名を検索するための逆さの質問の全体的な構造、10.2、.0、.52、以下では、示されます:
+-----------------------------------------+
Header | OPCODE=IQUERY, ID=997 |
+-----------------------------------------+
Question | <empty> |
+-----------------------------------------+
Answer | <anyname> A IN 10.2.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
+-----------------------------------------+ ヘッダー| OPCODE=IQUERY、ID=997| +-----------------------------------------+ 問題| <の空の>。| +-----------------------------------------+ 答え| <anyname>A IN10.2.0、.52| +-----------------------------------------+ 権威| <の空の>。| +-----------------------------------------+追加しています。| <の空の>。| +-----------------------------------------+
This query asks for a question whose answer is the Internet style
address 10.2.0.52. Since the owner name is not known, any domain
name can be used as a placeholder (and is ignored). The response
to this query might be:
この質問はだれの解答がインターネットスタイルアドレス10.2.0.52であるかという質問を求めます。 所有者名が知られていないので、プレースホルダ(そして、無視される)としてどんなドメイン名も使用できます。 この質問への応答は以下の通りです。
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=997 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | F.ISI.ARPA A IN 10.2.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
+-----------------------------------------+ ヘッダー| OPCODEは応答、ID=997と等しいです。| +-----------------------------------------+ 問題| QTYPE=A、QCLASS=IN QNAMEはF.ISI.ARPAと等しいです。| +-----------------------------------------+ 答え| F.ISI.ARPA A IN10.2.0、.52| +-----------------------------------------+ 権威| <の空の>。| +-----------------------------------------+追加しています。| <の空の>。| +-----------------------------------------+
Note that the QTYPE in a response to an inverse query is the same
as the TYPE field in the answer section of the inverse query.
Responses to inverse queries may contain multiple questions when
the inverse is not unique.
逆さの質問への応答におけるQTYPEが逆さの質問の答え部でTYPE分野と同じであることに注意してください。 逆さの質問への応答は逆がいつユニークでないかという複数の質問を含むかもしれません。
Mockapetris [Page 18]
Mockapetris[18ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Completion queries and responses
完成質問と応答
Completion queries ask a name server to complete a partial domain
name and return a set of RRs whose domain names meet a specified
set of criteria for "closeness" to the partial input. This type
of query can provide a local shorthand for domain names or command
completion similar to that in TOPS-20.
完成質問は、部分的なドメイン名を完成して、ドメイン名が「密接」のための指定されたセットの評価基準を部分的な入力を満たすRRsの1セットを返すようにネームサーバに頼みます。 このタイプの質問はTOPS-20でそれと同様のドメイン名かコマンド完成のためのローカルの速記を提供できます。
Implementation of completion query processing is optional in a
name server. However, a name server must return a "Not
Implemented" (NI) error response if it does not support
completion.
完成問い合わせ処理の実装はネームサーバで任意です。しかしながら、完成をサポートしないなら、ネームサーバは「実装していない」(NI)誤り応答を返さなければなりません。
The arguments in a completion query specify:
完成質問における議論は指定します:
1. A type in QTYPE that specifies the type of the desired name.
The type is used to restrict the type of RRs which will match
the partial input so that completion queries can be used for
mailbox names, host names, or any other type of RR in the
domain system without concern for matches to the wrong type of
resource.
1. 必要な名前のタイプを指定するQTYPEのタイプ。 タイプは、マッチに関する心配なしでドメインシステムのメールボックス名に完成質問を使用できるように部分的な入力に合っているRRsのタイプ、ホスト名、またはRRのいかなる他のタイプも間違ったタイプに関するリソースに制限するのに使用されます。
2. A class in QCLASS which specifies the desired class of the RR.
2. RRの必要なクラスを指定するQCLASSのクラス。
3. A partial domain name that gives the input to be completed.
All returned RRs will begin with the partial string. The
search process first looks for names which qualify under the
assumption that the partial string ends with a full label
("whole label match"); if this search fails, the search
continues under the assumption that the last label in the
partial sting may be an incomplete label ("partial label
match"). For example, if the partial string "Smith" was used
in a mailbox completion, it would match Smith@ISI.ARPA in
preference to Smithsonian@ISI.ARPA.
3. 完成されるために入力を与える部分的なドメイン名。 すべての返されたRRsが部分的なひもで始まるでしょう。 検索プロセスは最初に、部分的なストリングが完全なラベル(「全体のラベルマッチ」)で終わるという仮定で資格を得る名前を探します。 この検索が失敗するなら、検索は部分的な刺し傷における最後のラベルが不完全なラベルであるかもしれない(「部分的なラベルマッチ」)という仮定で続きます。 例えば、部分的なストリング「スミス」がメールボックス完成に使用されるなら、それは Smithsonian@ISI.ARPA に優先して Smith@ISI.ARPA に合っているでしょうに。
The partial name is supplied by the user through the user
program that is using domain services. For example, if the
user program is a mail handler, the string might be "Mockap"
which the user intends as a shorthand for the mailbox
Mockapetris@ISI.ARPA; if the user program is TELNET, the user
might specify "F" for F.ISI.ARPA.
部分的な名前はドメインサービスを利用しているユーザ・プログラムでユーザによって提供されます。 例えば、ユーザ・プログラムがメール操作者であるなら、ストリングはユーザがメールボックス Mockapetris@ISI.ARPA; のための速記として意図する"Mockap"であるかもしれません。 ユーザ・プログラムがTELNETであるなら、ユーザはF.ISI.ARPAのための「F」を指定するかもしれません。
In order to make parsing of messages consistent, the partial
name is supplied in domain name format (i.e. a sequence of
labels terminated with a zero length octet). However, the
trailing root label is ignored during matching.
メッセージの構文解析を一貫するようにするように、ドメイン名形式で部分的な名前を提供します(すなわち、ラベルの系列はゼロ・レングス八重奏で終わりました)。 しかしながら、引きずっている根のラベルはマッチングの間、無視されます。
4. A target domain name which specifies the domain which is to be
examined for matches. This name is specified in the additional
4. マッチがないかどうか調べられることであるドメインを指定する目標ドメイン名。 この名前は追加で指定されます。
Mockapetris [Page 19]
Mockapetris[19ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
section using a NULL RR. All returned names will end with the
target name.
NULL RRを使用するセクション。 すべての返された名前が目標名で終わるでしょう。
The user program which constructs the query uses the target
name to restrict the search. For example, user programs
running at ISI might restrict completion to names that end in
ISI.ARPA; user programs running at MIT might restrict
completion to the domain MIT.ARPA.
質問を構成するユーザ・プログラムは、検索を制限するのに目標名を使用します。 例えば、ISIを動くユーザ・プログラムはその終わりにISI.ARPAで完成を名前に制限するかもしれません。 MITを動くユーザ・プログラムは完成をドメインMIT.ARPAに制限するかもしれません。
The target domain name is also used by the resolver to
determine the name server which should be used to process the
query. In general, queries should be directed to a name server
that is authoritative for the target domain name. User
programs which wish to provide completion for a more than one
target can issue multiple completion queries, each directed at
a different target. Selection of the target name and the
number of searches will depend on the goals of the user
program.
また、目標ドメイン名は、使用されるべきであるネームサーバが質問を処理することを決定するのにレゾルバによって使用されます。 一般に、質問は目標ドメイン名に、正式のネームサーバに向けられるべきです。 1個以上の目標のための完成を提供したがっているユーザ・プログラムは複数の完成質問(異なった目標が向けられたそれぞれ)を発行できます。 目標名の選択と検索の数はユーザ・プログラムの目標に依存するでしょう。
5. An opcode for the query. The two types of completion queries
are "Completion Query - Multiple", or CQUERYM, which asks for
all RRs which could complete the specified input, and
"Completion Query - Unique", or CQUERYU, which asks for the
"best" completion.
5. 質問のためのopcode。 そして、2つのタイプの完成質問がそうである、「完成質問--」 倍数CQUERYM、どれが指定された入力を終了できたすべてのRRsを求めるか、「完成質問--、ユニークである、」 CQUERYU。(そのCQUERYUは「最も良い」完成を求めます)。
CQUERYM is used by user programs which want to know if
ambiguities exist or wants to do its own determinations as to
the best choice of the available candidates.
CQUERYMはあいまいさが存在するかどうかを知りたがっているユーザ・プログラムで使用されたいか、または手があいている候補の最も良い選択に関してそれ自身の決断をしたがっています。
CQUERYU is used by user programs which either do not wish to
deal with multiple choices or are willing to use the closeness
criteria used by CQUERYU to select the best match.
CQUERYUは選択式に対処することを願っていないか、または最も良いマッチを選択するのにCQUERYUによって使用された密接評価基準を使用しても構わないと思っているユーザ・プログラムで使用されます。
When a name server receives either completion query, it first
looks for RRs that begin (on the left) with the same labels as are
found in QNAME (with the root deleted), and which match the QTYPE
and QCLASS. This search is called "whole label" matching. If one
or more hits are found the name server either returns all of the
hits (CQUERYM) or uses the closeness criteria described below to
eliminate all but one of the matches (CQUERYU).
ネームサーバがどちらの完成質問も受けるとき、それは最初に、QNAME(根が削除されている)で見つけられるのと同じラベルで始まって(左で)、QTYPEとQCLASSに合っているRRsを探します。 この検索は「全体のラベル」マッチングと呼ばれます。 1つ以上のヒットが見つけられるなら、ネームサーバは、マッチ(CQUERYU)の1つ以外のすべてを排除するのにヒット(CQUERYM)のすべてを返すか、または以下で説明された密接評価基準を使用します。
If the whole label match fails to find any candidates, then the
name server assumes that the rightmost label of QNAME (after root
deletion) is not a complete label, and looks for candidates that
would match if characters were added (on the right) to the
rightmost label of QNAME. If one or more hits are found the name
server either returns all of the hits (CQUERYM) or uses the
closeness criteria described below to eliminate all but one of the
matches (CQUERYU).
キャラクタがQNAMEの一番右のラベルに加えられて(右で)、全体のラベルマッチがどんな候補も見つけないなら、ネームサーバは、QNAME(根の削除の後の)の一番右のラベルが完全なラベルでないと思って、合っている候補を探します。 1つ以上のヒットが見つけられるなら、ネームサーバは、マッチ(CQUERYU)の1つ以外のすべてを排除するのにヒット(CQUERYM)のすべてを返すか、または以下で説明された密接評価基準を使用します。
Mockapetris [Page 20]
Mockapetris[20ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
If a CQUERYU query encounters multiple hits, it uses the following
sequence of rules to discard multiple hits:
CQUERYU質問が複数のヒットに遭遇するなら、複数のヒットを捨てるのに規則の以下の系列を使用します:
1. Discard candidates that have more labels than others. Since
all candidates start with the partial name and end with the
target name, this means that we select those entries that
require the fewest number of added labels. For example, a host
search with a target of "ISI.ARPA" and a partial name of "A"
will select A.ISI.ARPA in preference to A.IBM-PCS.ISI.ARPA.
1. 他のものより多くのラベルを持っている候補を捨ててください。 すべての候補が目標名で部分的な名前と終わりから始まるので、これは、私たちが最も数数の加えられたラベルを必要とするそれらのエントリーを選択することを意味します。 例えば、"ISI.ARPA"の目標によるホスト検索とウィルという部分的な名前はA.IBM-PCS.ISI.ARPAに優先してA.ISI.ARPAを選択します。
2. If partial label matching was used, discard those labels which
required more characters to be added. For example, a mailbox
search for partial "X" and target "ISI.ARPA" would prefer
XX@ISI.ARPA to XYZZY@ISI.ARPA.
2. 部分的なラベルマッチングが使用されたなら、より多くのキャラクタが加えられるのを必要としたそれらのラベルを捨ててください。 例えば、部分的な「X」と目標"ISI.ARPA"のメールボックス検索は XYZZY@ISI.ARPA より XX@ISI.ARPA を好むでしょう。
If multiple hits are still present, return all hits.
複数のヒットがまだ存在しているなら、すべてのヒットを返してください。
Completion query mappings are not guaranteed to be unique or
complete because the domain system does not have any internal
mechanism for determining authority from a partial domain name
that parallels the capability for determining authority as a
function of a complete domain name. In general, resolvers will be
configured to direct completion queries to a name server which is
known to have the desired information.
ドメインシステムには完全なドメイン名の機能として権威を決定するために能力に沿う部分的なドメイン名から権威を決定するためのどんな内部のメカニズムもないので、完成質問マッピングはユニークであるか、または完全になるように保証されません。 一般に、レゾルバは、必要な情報を持っているのが知られているネームサーバに完成質問を向けるために構成されるでしょう。
When a name server processes a completion query, it either
returns:
ネームサーバが完成質問を処理するとき、戻ります:
1. An answer giving zero, one, or more possible completions.
1. ゼロ、1つ以上の可能な落成を与える答え。
2. an error response with Not Implemented (NI) set.
2. Not Implemented(NI)との誤り応答はセットしました。
Mockapetris [Page 21]
Mockapetris[21ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Completion query and response example
完成質問と応答の例
Suppose that the completion service was used by a TELNET program
to allow a user to specify a partial domain name for the desired
host. Thus a user might ask to be connected to "B". Assuming
that the query originated from an ISI machine, the query might
look like:
完成サービスがユーザが必要なホストに部分的なドメイン名を指定するのを許容するのにTELNETプログラムで利用されたと仮定してください。 したがって、ユーザは、「B」に接続されるように頼むかもしれません。 質問がISIマシンから発したと仮定する場合、質問に似るかもしれません:
+-----------------------------------------+
Header | OPCODE=CQUERYU, ID=409 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=B |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | ISI.ARPA NULL IN |
+-----------------------------------------+
+-----------------------------------------+ ヘッダー| OPCODE=CQUERYU、ID=409| +-----------------------------------------+ 問題| QTYPE=A、QCLASS=IN QNAME=B| +-----------------------------------------+ 答え| <の空の>。| +-----------------------------------------+ 権威| <の空の>。| +-----------------------------------------+追加しています。| ISI.ARPAのヌルIN| +-----------------------------------------+
The partial name in the query is "B", the mappings of interest are
ARPA Internet address records, and the target domain is ISI.ARPA.
Note that NULL is a special type of NULL resource record that is
used as a placeholder and has no significance; NULL RRs obey the
standard format but have no other function.
質問における部分的な名前は「B」です、そして、興味があるマッピングはアルパインターネット・アドレス記録です、そして、ターゲット・ドメインはISI.ARPAです。 NULLがプレースホルダとして使用されて、意味を全く持っていない特別なタイプに関するNULLリソース記録であることに注意してください。 NULL RRsには、標準書式に従いますが、他の機能が全くありません。
The response to this completion query might be:
この完成質問への応答は以下の通りです。
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=409 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=B |
+-----------------------------------------+
Answer | B.ISI.ARPA A IN 10.3.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | ISI.ARPA NULL IN |
+-----------------------------------------+
+-----------------------------------------+ ヘッダー| OPCODEは応答、ID=409と等しいです。| +-----------------------------------------+ 問題| QTYPE=A、QCLASS=IN QNAME=B| +-----------------------------------------+ 答え| B.ISI.ARPA A IN10.3.0、.52| +-----------------------------------------+ 権威| <の空の>。| +-----------------------------------------+追加しています。| ISI.ARPAのヌルIN| +-----------------------------------------+
This response has completed B to mean B.ISI.ARPA.
この応答は、B. ISI.ARPAを意味するためにBを完成しました。
Mockapetris [Page 22]
Mockapetris[22ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Another query might be:
別の質問は以下の通りです。
+-----------------------------------------+
Header | OPCODE=CQUERYM, ID=410 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=B |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | ARPA NULL IN |
+-----------------------------------------+
+-----------------------------------------+ ヘッダー| OPCODE=CQUERYM、ID=410| +-----------------------------------------+ 問題| QTYPE=A、QCLASS=IN QNAME=B| +-----------------------------------------+ 答え| <の空の>。| +-----------------------------------------+ 権威| <の空の>。| +-----------------------------------------+追加しています。| 中のアルパヌル| +-----------------------------------------+
This query is similar to the previous one, but specifies a target
of ARPA rather than ISI.ARPA. It also allows multiple matches.
In this case the same name server might return:
この質問は、前のものと同様ですが、ISI.ARPAよりむしろARPAの目標を指定します。 また、それは複数のマッチを許容します。 この場合、同じネームサーバは戻るかもしれません:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=410 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=B |
+-----------------------------------------+
Answer | B.ISI.ARPA A IN 10.3.0.52 |
| - |
| B.BBN.ARPA A IN 10.0.0.49 |
| - |
| B.BBNCC.ARPA A IN 8.1.0.2 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | ARPA NULL IN |
+-----------------------------------------+
+-----------------------------------------+ ヘッダー| OPCODEは応答、ID=410と等しいです。| +-----------------------------------------+ 問題| QTYPE=A、QCLASS=IN QNAME=B| +-----------------------------------------+ 答え| B.ISI.ARPA A IN10.3.0、.52| | - | | B.BBN.ARPA A IN10.0.0、.49| | - | | B.BBNCC.ARPA A IN8.1.0、.2| +-----------------------------------------+ 権威| <の空の>。| +-----------------------------------------+追加しています。| 中のアルパヌル| +-----------------------------------------+
This response contains three answers, B.ISI.ARPA, B.BBN.ARPA, and
B.BBNCC.ARPA.
この応答は3つの答え、B. ISI.ARPA、B. BBN.ARPA、およびB. BBNCC.ARPAを含んでいます。
Mockapetris [Page 23]
Mockapetris[23ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Recursive Name Service
再帰的な名前サービス
Recursive service is an optional feature of name servers.
再帰的なサービスはネームサーバに関するオプション機能です。
When a name server receives a query regarding a part of the name
space which is not in one of the name server's zones, the standard
response is a message that refers the requestor to another name
server. By iterating on these referrals, the requestor eventually
is directed to a name server that has the required information.
ネームサーバがネームサーバのゾーンの1つにない名前スペースの一部に関して質問を受けるとき、標準の応答は別のネームサーバに要請者を差し向けるメッセージです。これらの紹介のときに繰り返すことによって、要請者は結局、必須情報を持っているネームサーバに向けられます。
Name servers may also implement recursive service. In this type
of service, a name server either answers immediately based on
local zone information, or pursues the query for the requestor and
returns the eventual result back to the original requestor.
また、ネームサーバは再帰的なサービスを実装するかもしれません。 このタイプのサービスでは、ネームサーバは、すぐローカルのゾーン情報に基づいて答えるか、要請者のために質問を追求して、または最後の結果をオリジナルの要請者に返して戻します。
A name server that supports recursive service sets the Recursion
Available (RA) bit in all responses it generates. A requestor
asks for recursive service by setting the Recursion Desired (RD)
bit in queries. In some situations where recursive service is the
only path to the desired information (see below), the name server
may go recursive even if RD is zero.
再帰的なサービスをサポートするネームサーバはRecursion Available(RA)ビットをそれが生成するすべての応答にはめ込みます。 要請者は、Recursion Desired(RD)ビットを質問にはめ込むことによって、再帰的なサービスを求めます。 再帰的なサービスが必要な情報への唯一の経路(以下を見る)であるいくつかの状況で、ネームサーバはRDがゼロであっても再帰的になるかもしれません。
If a query requests recursion (RD set), but the name server does
not support recursion, and the query needs recursive service for
an answer, the name server returns a "Not Implemented" (NI) error
code. If the query can be answered without recursion since the
name server is authoritative for the query, it ignores the RD bit.
質問が再帰を要求しますが(RDはセットしました)、ネームサーバが再帰をサポートしないで、質問が答えのための再帰的なサービスを必要とするなら、ネームサーバは「実装していない」(NI)エラーコードを返します。 質問に、ネームサーバが正式であるので再帰なしで質問に答えることができるなら、それはRDビットを無視します。
Because of the difficulty in selecting appropriate timeouts and
error handling, recursive service is best suited to virtual
circuits, although it is allowed for datagrams.
適切なタイムアウトとエラー処理を選択することにおける苦労のために、仮想の回路に再帰的なサービスを合わせるのが最も良い、それはデータグラムのために許容されていますが。
Recursive service is valuable in several special situations:
再帰的なサービスはいくつかの特別な状況で貴重です:
In a system of small personal computers clustered around one or
more large hosts supporting name servers, the recursive
approach minimizes the amount of code in the resolvers in the
personal computers. Such a design moves complexity out of the
resolver into the name server, and may be appropriate for such
systems.
1時頃にクラスタリングした小さいパーソナルコンピュータか、より大きいホストがネームサーバをサポートするシステムでは、再帰的なアプローチはパーソナルコンピュータのレゾルバのコードの量を最小にします。 そのようなデザインは、複雑さをレゾルバからネームサーバに動かして、そのようなシステムに、適切であるかもしれません。
Name servers on the boundaries of different networks may wish
to offer recursive service to create connectivity between
different networks. Such name servers may wish to provide
recursive service regardless of the setting of RD.
異なったネットワークの限界のネームサーバは、異なったネットワークの間で接続性を作成するために再帰的なサービスを提供したがっているかもしれません。 そのようなネームサーバはRDの設定にかかわらず再帰的なサービスを提供したがっているかもしれません。
Name servers that translate between domain name service and
some other name service may wish to adopt the recursive style.
Implicit recursion may be valuable here as well.
ドメイン名サービスとある他の名前サービスの間で翻訳されるネームサーバは再帰的なスタイルを採用したがっているかもしれません。 また、暗黙の再帰はここで貴重であるかもしれません。
Mockapetris [Page 24]
Mockapetris[24ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
These concepts are still under development.
これらの概念はまだ開発中です。
Mockapetris [Page 25]
Mockapetris[25ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Header section format
ヘッダーセクション形式
+-----------------------------------------------+
| |
| ***** WARNING ***** |
| |
| The following format is preliminary and is |
| included for purposes of explanation only. In |
| particular, the size and position of the |
| OPCODE, RCODE fields and the number and |
| meaning of the single bit fields are subject |
| to change. |
| |
+-----------------------------------------------+
+-----------------------------------------------+ | | | ***** 警告*****| | | | 以下の形式は、予備であり、あります。| | 説明だけの目的のために、含まれています。 コネ| | 事項、サイズ、および位置| | そしてOPCODE、RCODE分野、および数。| | 意味して、単一のビットにおいて、分野は受けることがあります。| | 変化するように。 | | | +-----------------------------------------------+
The header contains the following fields:
ヘッダーは以下の分野を含んでいます:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode|AA|Tc|rd|RA| | RCODE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
どこ:
ID - A 16 bit identifier assigned by the program that
generates any kind of query. This identifier is copied
into all replies and can be used by the requestor to
relate replies to outstanding questions.
ID--どんな種類の質問も生成するプログラムで割り当てられた16ビットの識別子。 この識別子をすべての回答にコピーして、要請者は、傑出している質問に回答に関連するのに使用できます。
QR - A one bit field that specifies whether this message is a
query (0), or a response (1).
QR--ものはこのメッセージが質問(0)、または応答(1)であるかを指定する分野に噛み付きました。
OPCODE - A four bit field that specifies kind of query in this
message. This value is set by the originator of a query
and copied into the response. The values are:
OPCODE--このメッセージの質問の種類を指定する4ビットの分野。 この値は、質問の創始者によって設定されて、応答にコピーされます。 値は以下の通りです。
0 a standard query (QUERY)
0 標準の質問(質問)
Mockapetris [Page 26]
Mockapetris[26ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
1 an inverse query (IQUERY)
1 逆さの質問(IQUERY)
2 an completion query allowing multiple
answers (CQUERYM)
2 複数の答えを許容する完成質問(CQUERYM)
2 an completion query requesting a single
answer (CQUERYU)
2 ただ一つの答えを要求する完成質問(CQUERYU)
4-15 reserved for future use
今後の使用のために予約された4-15
AA - Authoritative Answer - this bit is valid in responses,
and specifies that the responding name server
is an authority for the domain name in the
corresponding query.
AA--正式のAnswer--このビットは、応答で有効であり、応じるネームサーバが対応する質問におけるドメイン名のための権威であると指定します。
TC - TrunCation - specifies that this message was truncated
due to length greater than 512 characters.
This bit is valid in datagram messages but not
in messages sent over virtual circuits.
TC(TrunCation)は、このメッセージが長さより多くの512のキャラクタのため先端を切られたと指定します。 このビットは、データグラムメッセージで有効ですが、仮想の回路の上に送られたメッセージで有効であるというわけではありません。
RD - Recursion Desired - this bit may be set in a query and
is copied into the response. If RD is set, it
directs the name server to pursue the query
recursively. Recursive query support is
optional.
RD--再帰Desired--このビットは質問で設定されるかもしれなくて、応答にコピーされます。 RDが用意ができているなら、それは、質問を再帰的に追求するようネームサーバに指示します。 反復クエリーサポートは任意です。
RA - Recursion Available - this be is set or cleared in a
response, and denotes whether recursive query
support is available in the name server.
RA--再帰Available--これ、反復クエリーサポートがネームサーバで利用可能であるか否かに関係なく、設定するか、a応答でクリアして、または指示します。
RCODE - Response code - this 4 bit field is set as part of
responses. The values have the following
interpretation:
RCODE--応答コード--この4ビットの分野は応答の一部として設定されます。 値には、以下の解釈があります:
0 No error condition
0 エラー条件がありません。
1 Format error - The name server was unable
to interpret the query.
1 形式誤り--ネームサーバは質問を解釈できませんでした。
2 Server failure - The name server was unable
to process this query due to a problem with
the name server.
2 サーバ失敗--ネームサーバはネームサーバに関する問題のためこの質問を処理できませんでした。
3 Name Error - Meaningful only for responses
from an authoritative name server, this
code signifies that the domain name
referenced in the query does not exist.
3 名前Error--正式のネームサーバからの応答だけに重要です、このコードは質問で参照をつけられるドメイン名が存在しないのを意味します。
Mockapetris [Page 27]
Mockapetris[27ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
4 Not Implemented - The name server does not
support the requested kind of query.
4 Implementedでない--ネームサーバは要求された種類の質問をサポートしません。
5 Refused - The name server refuses to
perform the specified operation for policy
reasons. For example, a name server may
not wish to provide the information to the
particular requestor, or a name server may
not wish to perform a particular operation
(e.g. zone transfer) for particular data.
5は拒否しました--ネームサーバは、方針理由で指定された操作を実行するのを拒否します。 例えば、ネームサーバが特定の要請者に情報を提供したがっていないかもしれませんか、またはネームサーバは特定のデータのための特定の操作(例えば、ゾーン転送)を実行したがっていないかもしれません。
6-15 Reserved for future use.
今後の使用のために予約された6-15。
QDCOUNT - an unsigned 16 bit integer specifying the number of
entries in the question section.
QDCOUNT--未署名の16は質問部のエントリーの数を指定する整数に噛み付きました。
ANCOUNT - an unsigned 16 bit integer specifying the number of
resource records in the answer section.
ANCOUNT--未署名の16は答え部のリソース記録の数を指定する整数に噛み付きました。
NSCOUNT - an unsigned 16 bit integer specifying the number of name
server resource records in the authority records
section.
NSCOUNT--未署名の16は権威記録部のネームサーバリソース記録の数を指定する整数に噛み付きました。
ARCOUNT - an unsigned 16 bit integer specifying the number of
resource records in the additional records section.
ARCOUNT--未署名の16は追加記録部のリソース記録の数を指定する整数に噛み付きました。
Mockapetris [Page 28]
Mockapetris[28ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Question section format
質問セクション形式
The question section is used in all kinds of queries other than
inverse queries. In responses to inverse queries, this section
may contain multiple entries; for all other responses it contains
a single entry. Each entry has the following format:
質問部は逆さの質問以外のすべての種類の質問に使用されます。 逆さの質問への応答では、このセクションは多回入国を含むかもしれません。 他のすべての応答のために、それは単一のエントリーを含んでいます。 各エントリーには、以下の形式があります:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / /+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| QTYPE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
どこ:
QNAME - a variable number of octets that specify a domain name.
This field uses the compressed domain name format
described in the next section of this memo. This field
can be used to derive a text string for the domain name.
Note that this field may be an odd number of octets; no
padding is used.
QNAME--ドメイン名を指定する可変数の八重奏。 この分野はこのメモの次のセクションで説明された圧縮されたドメイン名形式を使用します。 ドメイン名のためにテキスト文字列を引き出すのにこの分野を使用できます。 この分野が八重奏の奇数であるかもしれないことに注意してください。 水増しは使用されていません。
QTYPE - a two octet code which specifies the type of the query.
The values for this field include all codes valid for a
TYPE field, together with some more general codes which
can match more than one type of RR. For example, QTYPE
might be A and only match type A RRs, or might be MAILA,
which matches MF and MD type RRs. The values for this
field are listed in Appendix 2.
QTYPE--質問のタイプを指定する2八重奏コード。 この分野への値はTYPE分野に、有効なすべてのコードを含んでいます、RRの1つ以上のタイプに合うことができるそれ以上の一般的なコードと共に。 例えば、QTYPEはAであり、タイプA RRsを合わせるだけであるかもしれないか、またはMAILAであるかもしれません。(そのMAILAはMFとMDタイプRRsに合っています)。 この分野への値はAppendix2に記載されています。
QCLASS - a two octet code that specifies the class of the query.
For example, the QCLASS field is IN for the ARPA
Internet, CS for the CSNET, etc. The numerical values
are defined in Appendix 2.
QCLASS--質問のクラスを指定する2八重奏コード。 例えば、QCLASS分野はARPAインターネットへのIN、CSNETのためのCSですなど。 数値はAppendix2で定義されます。
Mockapetris [Page 29]
Mockapetris[29ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Resource record format
リソースレコード形式
The answer, authority, and additional sections all share the same
format: a variable number of resource records, where the number of
records is specified in the corresponding count field in the
header. Each resource record has the following format:
答え、権威、および追加セクションはすべて、同じ形式を共有します: 可変数のリソース記録。(そこでは、記録の数がヘッダーの対応するカウント分野で指定されます)。 それぞれのリソース記録には、以下の形式があります:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | ///名/| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | タイプ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | クラス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / /+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
どこ:
NAME - a compressed domain name to which this resource record
pertains.
NAME--このリソース記録が関係する圧縮されたドメイン名。
TYPE - two octets containing one of the RR type codes defined
in Appendix 2. This field specifies the meaning of the
data in the RDATA field.
TYPE--RRの1つを含む2つの八重奏がAppendix2で定義されたコードをタイプします。 この分野はRDATA分野でデータの意味を指定します。
CLASS - two octets which specify the class of the data in the
RDATA field.
CLASS--RDATA分野のデータのクラスを指定する2つの八重奏。
TTL - a 16 bit unsigned integer that specifies the time
interval (in seconds) that the resource record may be
cached before it should be discarded. Zero values are
interpreted to mean that the RR can only be used for the
transaction in progress, and should not be cached. For
example, SOA records are always distributed with a zero
TTL to prohibit caching. Zero values can also be used
for extremely volatile data.
TTL--時間間隔(秒の)を指定する16の噛み付いている符号のない整数に、リソース記録がそれの前にキャッシュされるかもしれないのは捨てられるべきです。 値は、全くRRが進行中のトランザクションに使用できるだけであって、キャッシュされるべきでないことを意味するために解釈されません。 例えば、SOA記録は、キャッシュするのを禁止するためにどんなTTLと共にもいつも分配されるというわけではありません。 また、非常に揮発性のデータに値を全く使用できません。
Mockapetris [Page 30]
Mockapetris[30ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
RDLENGTH- an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDLENGTH16ビットの未署名の整数に、それはRDATA分野の八重奏における長さを指定します。
RDATA - a variable length string of octets that describes the
resource. The format of this information varies
according to the TYPE and CLASS of the resource record.
For example, the if the TYPE is A and the CLASS is IN,
the RDATA field is a 4 octet ARPA Internet address.
RDATA--リソースについて説明する八重奏の可変長ストリング。 リソース記録のTYPEとCLASSによると、この情報の形式は異なります。 例えば、TYPEがAであり、CLASSがINであるなら、RDATA分野は4八重奏ARPAインターネットアドレスです。
Formats for particular resource records are shown in Appendicies 2
and 3.
特定のリソース記録のための書式はAppendicies2と3に示されます。
Domain name representation and compression
ドメイン名表現と圧縮
Domain names messages are expressed in terms of a sequence of
labels. Each label is represented as a one octet length field
followed by that number of octets. Since every domain name ends
with the null label of the root, a compressed domain name is
terminated by a length byte of zero. The high order two bits of
the length field must be zero, and the remaining six bits of the
length field limit the label to 63 octets or less.
ドメイン名メッセージはラベルの系列で言い表されます。 その数の八重奏で1つの八重奏長さの野原が続いたので、各ラベルは表されます。 あらゆるドメイン名が根のヌルラベルで終わるので、圧縮されたドメイン名はゼロの長さのバイト終えられます。 長さの分野の高位2ビットはゼロであるに違いありません、そして、長さの分野の残っている6ビットはラベルを63以下の八重奏に制限します。
To simplify implementations, the total length of label octets and
label length octets that make up a domain name is restricted to
255 octets or less. Since the trailing root label and its dot are
not printed, printed domain names are 254 octets or less.
実装を簡素化するために、ドメイン名を作るラベル八重奏とラベル長さの八重奏の全長は255以下の八重奏に制限されます。 引きずっている根のラベルとそのドットが印刷されないので、印刷されたドメイン名は254以下の八重奏です。
Although labels can contain any 8 bit values in octets that make
up a label, it is strongly recommended that labels follow the
syntax described in Appendix 1 of this memo, which is compatible
with existing host naming conventions. Name servers and resolvers
must compare labels in a case-insensitive manner, i.e. A=a, and
hence all character strings must be ASCII with zero parity.
Non-alphabetic codes must match exactly.
ラベルはラベルを作る八重奏におけるどんな8ビットの値も含むことができますが、ラベルがこの既存のホスト命名規則と互換性があるメモのAppendix1で説明された構文に従うことが強く勧められます。 ネームサーバとレゾルバは、ゼロがあるASCIIが同等であったに違いないなら大文字と小文字を区別しない方法によるラベル、すなわち、A=aを比較して、したがって、すべての文字列を比較しなければなりません。 非英字コードはまさに合わなければなりません。
Whenever possible, name servers and resolvers must preserve all 8
bits of domain names they process. When a name server is given
data for the same name under two different case usages, this
preservation is not always possible. For example, if a name
server is given data for ISI.ARPA and isi.arpa, it should create a
single node, not two, and hence will preserve a single casing of
the label. Systems with case sensitivity should take special
precautions to insure that the domain data for the system is
created with consistent case.
可能であるときはいつも、ネームサーバとレゾルバはそれらが処理するドメイン名のすべての8ビットを保存しなければなりません。 この保存はネームサーバを与えるとき、同じくらいのためのデータが2未満の異なったケースを用法と命名するのがいつも可能であるというわけではありません。 例えば、ISI.ARPAとisi.arpaのためのデータをネームサーバに与えると、それは、2ではなくただ一つのノードを作成するべきであり、したがって、ラベルの単一のケーシングを保存するでしょう。 ケース感度があるシステムは、システムのためのドメインデータが一貫したケースで作成されるのを保障するために特別な注意を払うはずです。
In order to reduce the amount of space used by repetitive domain
names, the sequence of octets that defines a domain name may be
terminated by a pointer to the length octet of a previously
specified label string. The label string that the pointer
反復性のドメイン名によって使用されるスペースの合計を減少させるために、ドメイン名を定義する八重奏の系列は以前に指定されたラベルストリングの長さの八重奏への指針によって終えられるかもしれません。 ラベルがそれを結ぶ、指針
Mockapetris [Page 31]
Mockapetris[31ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
specifies is appended to the already specified label string.
Exact duplication of a previous label string can be done with a
single pointer. Multiple levels are allowed.
指定、既に指定されたラベルストリングに追加します。 ただ一つの指針で前のラベルストリングの正確な複製ができます。 複数のレベルが許容されています。
Pointers can only be used in positions in the message where the
format is not class specific. If this were not the case, a name
server that was handling a RR for another class could make
erroneous copies of RRs. As yet, there are no such cases, but
they may occur in future RDATA formats.
形式がクラス特有でないメッセージの見解で指針を使用できるだけです。 これがそうでないなら、もう1人のクラスのためにRRを扱っていたネームサーバはRRsの誤ったコピーを作るかもしれないでしょうに。 まだ、少しのそのような場合もありませんが、それらは将来のRDATA形式で起こるかもしれません。
If a domain name is contained in a part of the message subject to
a length field (such as the RDATA section of an RR), and
compression is used, the length of the compressed name is used in
the length calculation, rather than the length of the expanded
name.
ドメイン名がメッセージの一部に長さの分野(RRのRDATA部などの)を条件として含まれていて、圧縮が使用されているなら、圧縮された名前の長さは拡張名前の長さよりむしろ長さの計算に使用されます。
Pointers are represented as a two octet field in which the high
order 2 bits are ones, and the low order 14 bits specify an offset
from the start of the message. The 01 and 10 values of the high
order bits are reserved for future use and should not be used.
指針は高位2ビットがものである2八重奏分野として表されます、そして、下位14ビットはメッセージの始まりからオフセットを指定します。 高位のビットの01と10の値を今後の使用のために予約して、使用するべきではありません。
Programs are free to avoid using pointers in datagrams they
generate, although this will reduce datagram capacity. However
all programs are required to understand arriving messages that
contain pointers.
プログラムは、これがデータグラム容量を減少させますが、それらが生成するデータグラムで指針を使用するのを無料で避けることができます。 しかしながら、すべてのプログラムが、指針を含む到着メッセージを理解するのに必要です。
For example, a datagram might need to use the domain names
F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the
other fields of the message, these domain names might be
represented as:
例えば、データグラムは、ドメイン名F. ISI.ARPA、FOO.F. ISI.ARPA、ARPA、および根を使用する必要があるかもしれません。 メッセージの他の分野を無視して、これらのドメイン名は以下として表されるかもしれません。
Mockapetris [Page 32]
Mockapetris[32ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 1 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 3 | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | S | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 4 | A |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | R | P |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30 | A | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 20 | 1 | F| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 22 | 3 | I| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 24 | S| I| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 26 | 4 | A| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 28 | R| P| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 30 | A| 0 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | 3 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | O | O |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1| 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 40 | 3 | F| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 42 | O| O| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 44 | 1 1| 20 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 1| 26 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 64 | 1 1| 26 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
92 | 0 | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 92 | 0 | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The domain name for F.ISI.ARPA is shown at offset 20. The domain
name FOO.F.ISI.ARPA is shown at offset 40; this definition uses a
pointer to concatenate a label for FOO to the previously defined
F.ISI.ARPA. The domain name ARPA is defined at offset 64 using a
pointer to the ARPA component of the name F.ISI.ARPA at 20; note
that this reference relies on ARPA being the last label in the
string at 20. The root domain name is defined by a single octet
of zeros at 92; the root domain name has no labels.
F. ISI.ARPAのためのドメイン名はオフセット20時に示されます。 ドメイン名FOO.F. ISI.ARPAは40オフセット歳のときに見せられます。 この定義は、以前に定義されたF. ISI.ARPAにFOOのためのラベルを連結するのに指針を使用します。 ドメイン名ARPAは64オフセット歳のときに20時にF. ISI.ARPAという名前のARPAの部品に指針を使用することで定義されます。 この参照が20時にストリングで最後のラベルであるARPAを当てにすることに注意してください。 根のドメイン名は92歳のときにゼロのただ一つの八重奏で定義されます。 根のドメイン名には、ラベルなしがあります。
Organization of the Shared database
Sharedデータベースの組織
While name server implementations are free to use any internal
data structures they choose, the suggested structure consists of
several separate trees. Each tree has structure corresponding to
the domain name space, with RRs attached to nodes and leaves.
Each zone of authoritative data has a separate tree, and one tree
holds all non-authoritative data. All of the trees corresponding
to zones are managed identically, but the non-authoritative or
cache tree has different management procedures.
ネームサーバ実装は自由に、彼らが選ぶどんな内部のデータ構造も使用できますが、提案された構造はいくつかの別々の木から成ります。 各木は、構造をRRsがノードに取り付けられている状態でドメイン名スペースに対応するようにして、いなくなります。 信頼すべきデータの各ゾーンには別々の木があります、そして、1本の木がすべての非信頼すべきデータを保持します。 ゾーンに対応する木のすべてが同様に管理されますが、非正式であるかキャッシュ木には、異なった管理手順があります。
Mockapetris [Page 33]
Mockapetris[33ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Data stored in the database can be kept in whatever form is
convenient for the name server, so long as it can be transformed
back into the format needed for messages. In particular, the
database will probably use structure in place of expanded domain
names, and will also convert many of the time intervals used in
the domain systems to absolute local times.
ネームサーバが都合がよいいかなるフォームにもデータベースに保存されたデータは保つことができます、それをメッセージに必要である形式に変えて戻すことができる限り。 データベースは、特に、たぶん広がった領域名に代わって構造を使用して、また、ドメインシステムで費やされた時間間隔の多くを絶対現地時間まで変換するでしょう。
Each tree corresponding to a zone has complete information for a
"pruned" subtree of the domain space. The top node of a zone has
a SOA record that marks the start of the zone. The bottom edge of
the zone is delimited by nodes containing NS records signifying
delegation of authority to other zones, or by leaves of the domain
tree. When a name server contains abutting zones, one tree will
have a bottom node containing a NS record, and the other tree will
begin with a tree location containing a SOA record.
ゾーンに対応するそれぞれの木には、ドメインスペースの「剪定された」下位木のための完全な情報があります。 ゾーンのトップノードには、ゾーンの始まりを示すSOA記録があります。 ゾーンのボトムエッジは他のゾーンに権限の委任を意味するNS記録を含むノード、またはドメイン木の葉によって区切られます。 ネームサーバが隣接しているゾーンを含んでいると、1本の木には、NS記録を含む下部ノードがあるでしょう、そして、木の位置がSOA記録を含んでいて、もう片方の木は始まるでしょう。
Note that there is one special case that requires consideration
when a name server is implemented. A node that contains a SOA RR
denoting a start of zone will also have NS records that identify
the name servers that are expected to have a copy of the zone.
Thus a name server will usually find itself (and possibly other
redundant name servers) referred to in NS records occupying the
same position in the tree as SOA records. The solution to this
problem is to never interpret a NS record as delimiting a zone
started by a SOA at the same point in the tree. (The sample
programs in this memo deal with this problem by processing SOA
records only after NS records have been processed.)
ネームサーバが実装されるとき考慮を必要とする1つの特別なケースがあることに注意してください。 また、ゾーンの始まりを指示するSOA RRを含むノードはゾーンのコピーを持っていると予想されるネームサーバを特定するNS記録を持つでしょう。 したがって、ネームサーバによって、通常、それ自体(そして、ことによると他の余分なネームサーバ)がSOAが記録するように木で同じ位置を占めながらNS記録で言及されるのを見つけるでしょう。 この問題への解決は木で同じポイントでSOAによって始められたゾーンを区切るとNS記録を決して解釈しないことです。 (NS記録を処理してある後にだけこのメモによるサンプルプログラムは処理SOA記録でこの問題に対処します。)
Zones may also overlap a particular part of the name space when
they are of different classes.
また、それらが異なったクラスのものであるときに、ゾーンはスペースという名前の特定の部分を重ね合わせるかもしれません。
Other than the abutting and separate class cases, trees are always
expected to be disjoint. Overlapping zones are regarded as a
non-fatal error. The scheme described in this memo avoids the
overlap issue by maintaining separate trees; other designs must
take the appropriate measures to defend against possible overlap.
隣接と別々のクラスケースを除いて、木はばらばらになることであるといつも予想されます。 重なっているゾーンは非致命的な誤りと見なされます。 このメモで説明された体系は別々の木を維持することによって、オーバラップ問題を避けます。 他のデザインは可能なオーバラップに対して防御する穏当な処置を取らなければなりません。
Non-authoritative data is maintained in a separate tree. This
tree is unlike the zone trees in that it may have "holes". Each
RR in the cache tree has its own TTL that is separately managed.
The data in this tree is never used if authoritative data is
available from a zone tree; this avoids potential problems due to
cached data that conflicts with authoritative data.
非信頼すべきデータは別々の木で維持されます。 それには「穴」があるかもしれないので、この木はゾーン木と異なっています。 キャッシュ木の各RRは別々に管理されるそれ自身のTTLを持っています。 信頼すべきデータがゾーン木から利用可能であるなら、この木のデータは決して使用されません。 これは信頼すべきデータと衝突するキャッシュされたデータのため潜在的な問題を避けます。
The shared database will also contain data structures to support
the processing of inverse queries and completion queries if the
local system supports these optional features. Although many
schemes are possible, this memo describes a scheme that is based
on tables of pointers that invert the database according to key.
また、ローカルシステムが、これらが任意の特徴であるとサポートすると、共有データベースは逆さの質問と完成質問の処理をサポートするデータ構造を含むでしょう。 多くの体系が可能ですが、このメモはキーに従ってデータベースを逆にする指針のテーブルに基づいている体系について説明します。
Mockapetris [Page 34]
Mockapetris[34ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
Each kind of retrieval has a separate set of tables, with one
table per zone. When a zone is updated, these tables must also be
updated. The contents of these tables are discussed in the
"Inverse query processing" and "Completion query processing"
sections of this memo.
各種類の検索には、1ゾーンあたり1個のテーブルがある別々のセットのテーブルがあります。 また、ゾーンをアップデートするとき、これらのテーブルをアップデートしなければなりません。 このメモの「逆さの問い合わせ処理」と「完成問い合わせ処理」セクションでこれらのテーブルの内容について議論します。
The database implementation described here includes two locks that
are used to control concurrent access and modification of the
database by name server query processing, name server maintenance
operations, and resolver access:
ここで説明されたデータベース実装はネームサーバ問い合わせ処理、ネームサーバメインテナンス操作、およびレゾルバアクセスによるデータベースの同時発生のアクセスと変更を制御するのに使用される2個の錠を含んでいます:
The first lock ("main lock") controls access to all of the
trees. Multiple concurrent reads are allowed, but write access
can only be acquired by a single process. Read and write
access are mutually exclusive. Resolvers and name server
processes that answer queries acquire this lock in read mode,
and unlock upon completion of the current message. This lock
is acquired in write mode by a name server maintenance process
when it is about to change data in the shared database. The
actual update procedures are described under "NAME SERVER
MAINTENANCE" but are designed to be brief.
最初の錠(「メイン錠」)は木のすべてへのアクセスを制御します。 単一のプロセスは倍数を取得できるだけです許容されていますが、同時発生の読書が、アクセスを書く。 読んでください、そして、書いてください。アクセスは互いに排他的です。 答え質問がこの錠を入手するレゾルバとネームサーバプロセスは、現在のメッセージの完成のときにモードを読んで、アンロックされます。 この錠による取得して、それが共有データベースのデータを変えようとしているネームサーバメインテナンスプロセスによるモードが中に書くということです。 実際のアップデート手順は、「ネームサーバメインテナンス」で説明されますが、手短かに言えば設計されています。
The second lock ("cache queue lock") controls access to the
cache queue. This queue is used by a resolver that wishes to
add information to the cache tree. The resolver acquires this
lock, then places the RRs to be cached into the queue. The
name server maintenance procedure periodically acquires this
lock and adds the queue information to the cache. The
rationale for this procedure is that it allows the resolver to
operate with read-only access to the shared database, and
allows the update process to batch cache additions and the
associated costs for inversion calculations. The name server
maintenance procedure must take appropriate precautions to
avoid problems with data already in the cache, inversions, etc.
キャッシュへの2番目のロック(「キャッシュ待ち行列錠」)コントロールアクセスは列を作ります。 この待ち行列はキャッシュ木に情報を加えたがっているレゾルバによって使用されます。 レゾルバは、この錠を入手して、次に、待ち行列にキャッシュされるためにRRsを置きます。 ネームサーバ保守手順は、定期的にこの錠を入手して、待ち行列情報をキャッシュに加えます。 この手順のための原理はレゾルバが共有データベースへのリード・オンリー・アクセスで働いているのを許容して、バッチキャッシュ追加と逆計算のための関連コストに更新処理を許容するということです。 ネームサーバ保守手順は、キャッシュ、既に逆などにおけるデータに関する問題を避けるために適切な注意を払わなければなりません。
This organization solves several difficulties:
この組織はいくつかの困難を解決します:
When searching the domain space for the answer to a query, a
name server can restrict its search for authoritative data to
that tree that matches the most labels on the right side of the
domain name of interest.
質問の答えのためにドメインスペースを捜すとき、ネームサーバは信頼すべきデータの検索をドメイン名の興味がある右側の最も多くのラベルに合っているその木に制限する場合があります。
Since updates to a zone must be atomic with respect to
searches, maintenance operations can simply acquire the main
lock, insert a new copy of a particular zone without disturbing
other zones, and then release the storage used by the old copy.
Assuming a central table pointing to valid zone trees, this
operation can be a simple pointer swap.
ゾーンへのアップデートが検索に関して原子であるに違いないので、メインテナンス操作は、単にメイン錠を入手して、他の不穏なゾーンのない特定のゾーンの新しいコピーを挿入して、次に、ストレージが古いコピーで使用したリリースを挿入できます。 有効なゾーン木を示す中央のテーブルを仮定する場合、この操作は簡単な指針スワッピングであるかもしれません。
Mockapetris [Page 35]
Mockapetris[35ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
TTL management of zones can be performed using the SOA record
for the zone. This avoids potential difficulties if individual
RRs in a zone could be timed out separately. This issue is
discussed further in the maintenance section.
ゾーンにSOA記録を使用することでゾーンのTTL管理を実行できます。 別々に外でゾーンの個々のRRsを調節できるなら、これは潜在的困難を避けます。 保全部門で、より詳しくこの問題について議論します。
Query processing
問い合わせ処理
The following algorithm outlines processing that takes place at a
name server when a query arrives:
以下のアルゴリズムは質問が到着するとネームサーバで行われる処理について概説します:
1. Search the list of zones to find zones which have the same
class as the QCLASS field in the query and have a top domain
name that matches the right end of the QNAME field. If there
are none, go to step 2. If there are more than one, pick the
zone that has the longest match and go to step 3.
1. ゾーンのリストを捜して、質問におけるQCLASS分野と同じクラスを持っているゾーンを見つけて、QNAME分野の正しい端に合っている最高ドメイン名を持ってください。 なにもなければ、ステップ2に行ってください。 1以上があれば、最も長いマッチを持っているゾーンを選んでください、そして、ステップ3に行ってください。
2. Since the zone search failed, the only possible RRs are
contained in the non-authoritative tree. Search the cache tree
for the NS record that has the same class as the QCLASS field
and the largest right end match for domain name. Add the NS
record or records to the authority section of the response. If
the cache tree has RRs that are pertinent to the question
(domain names match, classes agree, not timed-out, and the type
field is relevant to the QTYPE), copy these RRs into the answer
section of the response. The name server may also search the
cache queue. Go to step 4.
2. ゾーン検索が失敗したので、唯一の可能なRRsが非正式の木に含まれています。 QCLASS分野と正しい最も大きい終わりと同じクラスがドメイン名のために合っているNS記録のためにキャッシュ木を捜してください。 NS記録か記録を応答の権威部に追加してください。 キャッシュ木に質問に適切なRRsがあるなら(ドメイン名は合っています、とクラスは-外での調節にされるのではなく、同意します、そして、タイプ分野はQTYPEに関連しています)、応答の答え部にこれらのRRsをコピーしてください。 また、ネームサーバはキャッシュ待ち行列を捜すかもしれません。 ステップ4に行ってください。
3. Since this zone is the best match, the zone in which QNAME
resides is either this zone or a zone to which this zone will
directly or indirectly delegate authority. Search down the
tree looking for a NS RR or the node specified by QNAME.
3. このゾーンが最も良いマッチであるので、QNAMEが住んでいるゾーンは、このゾーンが直接か間接的に権限を委ねるこのゾーンかゾーンのどちらかです。 NS RRかノードを探す木の下側への検索はQNAMEで指定しました。
If the node exists and has no NS record, copy the relevant
RRs to the answer section of the response and go to step 4.
ノードで存在していて、どんなNSも記録しないなら、応答の答え部に関連RRsをコピーしてください、そして、ステップ4に行ってください。
If a NS RR is found, either matching a part or all of QNAME,
then QNAME is in a delegated zone outside of this zone. If
so, copy the NS record or records into the authority section
of the response, and search the remainder of the zone for an
A type record corresponding to the NS reference. If the A
record is found, add it to the additional section. Go to
step 2.
QNAMEの部分かすべてを合わせて、NS RRが見つけられるなら、QNAMEが代表として派遣されたゾーンにいるこのゾーンのその時です。 そうだとすれば、応答の権威部にNS記録か記録をコピーしてください、そして、NS参照に対応するAタイプ記録のためにゾーンの残りを捜してください。 A記録が見つけられるなら、追加セクションにそれを追加してください。 ステップ2に行ってください。
If the node is not found and a NS is not found, there is no
such name; set the Name error bit in the response and exit.
ノードが見つけられないで、またNSが見つけられないなら、どんなそのような名前もありません。 Name誤りビットを応答と出口にはめ込んでください。
4. When this step is reached, the answer and authority sections
are complete. What remains is to complete the additional
section. This procedure is only possible if the name server
4. このステップに達しているとき、答えと権威部は完全です。 何が残っているかが追加セクションを完成することになっています。 この手順はネームサーバである場合にだけ可能です。
Mockapetris [Page 36]
Mockapetris[36ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
knows the data formats implied by the class of records in the
answer and authority sections. Hence this procedure is class
dependent. Appendix 3 discusses this procedure for Internet
class data.
答えと権威部の記録のクラスによって含意されたデータ書式を知っています。 したがって、この手順はクラスに依存しています。 付録3はインターネットクラスデータのためにこの手順について議論します。
While this algorithm deals with typical queries and databases,
several additions are required that will depend on the database
supported by the name server:
このアルゴリズムが典型的な質問とデータベースに対処している間、ネームサーバでサポートされたデータベースによるいくつかの追加が必要です:
QCLASS=*
QCLASSは*と等しいです。
Special procedures are required when the QCLASS of the query is
"*". If the database contains several classes of data, the
query processing steps above are performed separately for each
CLASS, and the results are merged into a single response. The
name error condition is not meaningful for a QCLASS=* query.
If the requestor wants this information, it must test each
class independently.
質問のQCLASSが「*」であるときに、特別な手順が必要です。 データベースが数人のクラスに関するデータを含んでいるなら、上の問い合わせ処理ステップは各CLASSのために別々に実行されます、そして、結果はただ一つの応答に合併されています。 QCLASS=*質問には、名前エラー条件は重要ではありません。 要請者がこの情報が欲しいなら、それは独自に各クラスをテストしなければなりません。
If the database is limited to data of a particular class, this
operation can be performed by simply reseting the authoritative
bit in the response, and performing the query as if QCLASS was
the class used in the database.
データベースが特定のクラスに関するデータに制限されるなら、応答で単に正式のビットをresetingして、まるでQCLASSがデータベースで使用されるクラスであるかのように質問を実行することによって、この操作を実行できます。
* labels in database RRs
* データベースRRsのラベル
Some zones will contain default RRs that use * to match in
cases where the search fails for a particular domain name. If
the database contains these records then a failure must be
retried using * in place of one or more labels of the search
key. The procedure is to replace labels from the left with
"*"s looking for a match until either all labels have been
replaced, or a match is found. Note that these records can
never be the result of caching, so a name server can omit this
processing for zones that don't contain RRs with * in labels,
or can omit this processing entirely if * never appears in
local authoritative data.
いくつかのゾーンが検索が特定のドメイン名のために失敗する場合で合わせる*を使用するデフォルトRRsを含むでしょう。 データベースがこれらの記録を含んでいるなら、検索キーの1個以上のラベルに代わって*を使用することで失敗を再試行しなければなりません。 手順は結婚相手を探しながらすべてのラベルを取り替えたか、またはマッチを見つけるまで左からのラベルを「*」sに取り替えることです。 ネームサーバがラベルで*でRRsを含まないゾーンのためのこの処理を省略できるか、または完全に*がローカルの信頼すべきデータに決して現れないならこの処理を省略できるように、これらの記録がキャッシュの結果であるはずがないことに注意してください。
Inverse query processing
逆さの問い合わせ処理
Name servers that support inverse queries can support these
operations through exhaustive searches of their databases, but
this becomes impractical as the size of the database increases.
An alternative approach is to invert the database according to the
search key.
逆さの質問をサポートするネームサーバはそれらのデータベースの徹底的な検索でこれらの操作をサポートすることができますが、データベースのサイズが増加するのに応じて、これは非実用的になります。 代替的アプローチは検索キーに従ってデータベースを逆にすることです。
For name servers that support multiple zones and a large amount of
data, the recommended approach is separate inversions for each
複数のゾーンをサポートするネームサーバと多量のデータに関しては、お勧めのアプローチはそれぞれのための別々の逆です。
Mockapetris [Page 37]
Mockapetris[37ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
zone. When a particular zone is changed during a refresh, only
its inversions need to be redone.
ゾーン。 aの間、特定のゾーンを変えるときにはリフレッシュしてください、そして、逆だけが、やり直される必要があります。
Support for transfer of this type of inversion may be included in
future versions of the domain system, but is not supported in this
version.
このタイプの逆の転送のサポートは、ドメインシステムの将来のバージョンに含まれるかもしれませんが、このバージョンでサポートされません。
Completion query processing
完成問い合わせ処理
Completion query processing shares many of the same problems in
data structure design as are found in inverse queries, but is
different due to the expected high rate of use of top level labels
(ie., ARPA, CSNET). A name server that wishes to be efficient in
its use of memory may well choose to invert only occurrences of
ARPA, etc. that are below the top level, and use a search for the
rare case that top level labels are used to constrain a
completion.
完成問い合わせ処理は、逆さの質問で見つけられるデータ構造デザインで同じ問題の多くを共有しますが、トップレベルラベルで役に立つ予想(最高)レートで異なっています。(ie、ARPA、CSNET) メモリを使用で効率的であるという願望がトップ平らなラベルがトップレベルの下にあって、まれなケースに検索を使用するARPAなどの唯一の発生ですが、完成を抑制するのに使用されて、逆にするのをたぶん選ぶだろうネームサーバ。
Mockapetris [Page 38]
Mockapetris[38ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
NAME SERVER MAINTENANCE
ネームサーバメインテナンス
Introduction
序論
Name servers perform maintenance operations on their databases to
insure that the data they distribute is accurate and timely. The
amount and complexity of the maintenance operations that a name
server must perform are related to the size, change rate, and
complexity of the database that the name server manages.
ネームサーバは、それらが分配するデータが正確であって、タイムリーであることを保障するためにそれらのデータベースにメインテナンス操作を実行します。 ネームサーバが実行しなければならないメインテナンス操作の量と複雑さはネームサーバが管理するデータベースのサイズ、変化率、および複雑さに関連します。
Maintenance operations are fundamentally different for
authoritative and non-authoritative data. A name server actively
attempts to insure the accuracy and timeliness of authoritative
data by refreshing the data from master copies. Non-authoritative
data is merely purged when its time-to-live expires; the name
server does not attempt to refresh it.
正式、そして、非信頼すべきデータにおいて、メインテナンス操作は基本的に異なっています。 ネームサーバは、マスターコピーからのデータをリフレッシュすることによって信頼すべきデータの精度とタイムリーさであるのを保障するのを活発に試みます。 生きる時間が期限が切れるとき、非信頼すべきデータは単に掃除されます。 ネームサーバは、それをリフレッシュするのを試みません。
Although the refreshing scheme is fairly simple to implement, it
is somewhat less powerful than schemes used in other distributed
database systems. In particular, an update to the master does not
immediately update copies, and should be viewed as gradually
percolating though the distributed database. This is adequate for
the vast majority of applications. In situations where timliness
is critical, the master name server can prohibit caching of copies
or assign short timeouts to copies.
壮快な体系は実装するのがかなり簡単ですが、それは体系が他の分散データベースにシステムを使用したよりいくらか強力ではありません。マスターへのアップデートは、特に、すぐにコピーをアップデートしないで、もっとも、同じくらい徐々に分散データベースをこしながら、見られるべきです。 アプリケーションのかなりの大部分に、これは適切です。 timlinessが重要である状況で、マスターネームサーバは、コピーがキャッシュされるのを禁止するか、または短いタイムアウトをコピーに割り当てることができます。
Conceptual model of maintenance operations
メインテナンス操作の概念モデル
The vast majority of information in the domain system is derived
from master files scattered among hosts that implement name
servers; some name servers will have no master files, other name
servers will have one or more master files. Each master file
contains the master data for a single zone of authority rather
than data for the whole domain name space. The administrator of a
particular zone controls that zone by updating its master file.
ネームサーバを実装するホストの中に点在する基本ファイルからドメインシステムのかなりの大多数の情報を得ます。 いくつかのネームサーバには、基本ファイルが全くなくて、他のネームサーバに1つ以上の基本ファイルがあるでしょう。 各基本ファイルは全体のドメイン名スペースのためのデータよりむしろ権威のただ一つのゾーンのためのマスタデータを含んでいます。 特定のゾーンの管理者は、基本ファイルをアップデートすることによって、そのゾーンを制御します。
Master files and zone copies from remote servers may include RRs
that are outside of the zone of authority when a NS record
delegates authority to a domain name that is a descendant of the
domain name at which authority is delegated. These forward
references are a problem because there is no reasonable method to
guarantee that the A type records for the delegatee are available
unless they can somehow be attached to the NS records.
リモートサーバからの基本ファイルとゾーンコピーはNSが権威が代表として派遣されるドメイン名の子孫であるドメイン名への代表権威を記録するとき権威のゾーンの外にあるRRsを含むかもしれません。 どうにかNS記録にそれらを付けることができないなら「反-遺産受取人」のためのAタイプ記録が利用可能であることを保証するどんな合理的なメソッドもないので、これらの前進の参照は問題です。
For example, suppose the ARPA zone delegates authority at
MIT.ARPA, and states that the name server is on AI.MIT.ARPA. If a
resolver gets the NS record but not the A type record for
AI.MIT.ARPA, it might try to ask the MIT name server for the
address of AI.MIT.ARPA.
例えば、ネームサーバがAI.MIT.ARPAにあるMIT.ARPA、および州でARPAゾーンが代表権威であると仮定してください。 レゾルバがAI.MIT.ARPAのためのAタイプ記録ではなく、NS記録を得るなら、それはアドレスのためにMITネームサーバをAI.MIT.ARPAに尋ねようとするかもしれません。
Mockapetris [Page 39]
Mockapetris[39ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
The solution is to allow type A records that are outside of the
zone of authority to be copied with the zone. While these records
won't be found in a search for the A type record itself, they can
be protected by the zone refreshing system, and will be passed
back whenever the name server passes back a referral to the
corresponding NS record. If a query is received for the A record,
the name server will pass back a referral to the name server with
the A record in the additional section, rather than answer
section.
ソリューションはゾーンでコピーされるべき権威のゾーンの外にある記録をタイプAに許すことです。 これらの記録がAタイプ記録自体の検索で見つけられていない間、それらは、ゾーンの壮快なシステムで保護できて、ネームサーバが対応するNS記録に紹介を戻すときはいつも、戻されるでしょう。 A記録のために質問を受けると、A記録が追加セクションにある状態で、ネームサーバはセクションに答えるよりむしろ紹介をネームサーバに戻すでしょう。
The only exception to the use of master files is a small amount of
data stored in boot files. Boot file data is used by name servers
to provide enough resource records to allow zones to be imported
from foreign servers (e.g. the address of the server), and to
establish the name and address of root servers. Boot file records
establish the initial contents of the cache tree, and hence can be
overridden by later loads of authoritative data.
基本ファイルの使用への唯一の例外がブート・ファイルに保存された少量のデータです。 ブート・ファイルデータはネームサーバによって使用されて、ゾーンがルートサーバーの名前とアドレスを外国サーバ(例えば、サーバのアドレス)から意味されて、確立するのを許容できるくらいのリソース記録を提供します。 ブート・ファイル記録を、キャッシュ木の初期のコンテンツを確立して、したがって、信頼すべきデータの後の負荷で優越できます。
The data in a master file first becomes available to users of the
domain name system when it is loaded by the corresponding name
server. By definition, data from a master file is authoritative.
それが対応するネームサーバによってロードされるとき、基本ファイルのデータは最初に、ドメイン名システムのユーザにとって利用可能になります。定義上、基本ファイルからのデータは正式です。
Other name servers which wish to be authoritative for a particular
zone do so by transferring a copy of the zone from the name server
which holds the master copy using a virtual circuit. These copies
include parameters which specify the conditions under which the
data in the copy is authoritative. In the most common case, the
conditions specify a refresh interval and policies to be followed
when the refresh operation cannot be performed.
特定のゾーンに正式であるというそれの願望がマスターを保持するネームサーバからゾーンのコピーを移すことによってそうする他のネームサーバは、仮想の回路を使用することでコピーされます。 これらのコピーはコピーのデータが正式である状態を指定するパラメタを含んでいます。 最も一般的な場合では、状態はaを指定します。リフレッシュ操作を実行できない続くべき間隔と方針をリフレッシュしてください。
A name server may acquire multiple zones from different name
servers and master files, but the name server must maintain each
zone separately from others and from non-authoritative data.
ネームサーバは異なったネームサーバと基本ファイルから複数のゾーンを取得するかもしれませんが、ネームサーバは別々に他のものと非信頼すべきデータから各ゾーンを維持しなければなりません。
When the refresh interval for a particular zone copy expires, the
name server holding the copy must consult the name server that
holds the master copy. If the data in the zone has not changed,
the master name server instructs the copy name server to reset the
refresh interval. If the data has changed, the master passes a
new copy of the zone and its associated conditions to the copy
name server. Following either of these transactions, the copy
name server begins a new refresh interval.
いつ、コピーが吐き出す特定のゾーンに間隔をリフレッシュしてください、そして、コピーを持っているネームサーバはマスターコピーを持っているネームサーバに相談しなければならないか。 ゾーンが変えていないコネ、マスターネームサーバがリセットするようコピーネームサーバに命令するデータ、間隔をリフレッシュしてください。 データが変化したなら、マスターは新しいコピーを渡します。ゾーンとどちらかこれらのトランザクションの次のコピーネームサーバに、コピーネームサーバがaを新しい状態で始めるというその関連症状では、間隔をリフレッシュしてください。
Copy name servers must also deal with error conditions under which
they are unable to communicate with the name server that holds the
master copy of a particular zone. The policies that a copy name
server uses are determined by other parameters in the conditions
distributed with every copy. The conditions include a retry
interval and a maximum holding time. When a copy name server is
また、コピーネームサーバはそれらが特定のゾーンのマスターコピーを持っているネームサーバで交信できないエラー条件に対処しなければなりません。 コピーネームサーバが使用する方針はあらゆるコピーで分配された状態の他のパラメタで決定します。 状態は再試行間隔と最大の把持時間を含んでいます。 コピーネームサーバはいつですか。
Mockapetris [Page 40]
Mockapetris[40ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
unable to establish communications with a master or is unable to
complete the refresh transaction, it must retry the refresh
operation at the rate specified by the retry interval. This retry
interval will usually be substantially shorter than the refresh
interval. Retries continue until the maximum holding time is
reached. At that time the copy name server must assume that its
copy of the data for the zone in question is no longer
authoritative.
設立できない、aとのコミュニケーションがマスタリングするか、または完成できない、トランザクションをリフレッシュしてください、そして、それは再試行間隔で指定されたレートでのリフレッシュ操作を再試行しなければなりません。 通常、この再試行間隔が実質的により短くなる、間隔をリフレッシュしてください。 最大の把持時間に達するまで、再試行は続きます。 その時、コピーネームサーバは、問題のゾーンのためのデータのコピーがもう正式でないと仮定しなければなりません。
Queries must be processed while maintenance operations are in
progress because a zone transfer can take a long time. However,
to avoid problems caused by access to partial databases, the
maintenance operations create new copies of data rather than
directly modifying the old copies. When the new copy is complete,
the maintenance process locks out queries for a short time using
the main lock, and switches pointers to replace the old data with
the new. After the pointers are swapped, the maintenance process
unlocks the main lock and reclaims the storage used by the old
copy.
ゾーン転送が長くかかることができるのでメインテナンス操作が進行している間、質問を処理しなければなりません。 しかしながら、部分的なデータベースへのアクセスで引き起こされた問題を避けるために、メインテナンス操作は直接古いコピーを変更するよりむしろ新しいコピーに関するデータを作成します。 新しいコピーが完全であるときに、メインテナンスプロセスは、短い間メイン錠を使用することで質問を締め出して、古いデータを新しさに取り替えるために指針を切り換えます。 指針が交換された後に、メインテナンスプロセスは、メイン錠をアンロックして、古いコピーによって使用されるストレージを取り戻します。
Name server data structures and top level logic
ネームサーバデータ構造と最高平らな論理
The name server must multiplex its attention between multiple
activities. For example, a name server should be able to answer
queries while it is also performing refresh activities for a
particular zone. While it is possible to design a name server
that devotes a separate process to each query and refresh activity
in progress, the model described in this memo is based on the
assumption that there is a single process performing all
maintenance operations, and one or more processes devoted to
handling queries. The model also assumes the existence of shared
memory for several control structures, the domain database, locks,
etc.
ネームサーバは複数の活動の間に注意を多重送信しなければなりません。 例えば、また、実行が特定のゾーンのための活動をリフレッシュするということですが、ネームサーバは質問に答えることができるべきです。 各質問に別々のプロセスをささげるネームサーバを設計して、進行中の活動をリフレッシュするのが可能である間、このメモで説明されたモデルはすべてのメインテナンス操作を実行する単一のプロセス、および取り扱い質問にささげられた1つ以上のプロセスがあるという仮定に基づいています。 また、モデルはいくつかの制御構造、ドメインデータベース、錠などのために共有メモリの存在を仮定します。
The model name server uses the following files and shared data
structures:
モデルネームサーバは以下のファイルと共有データ構造を使用します:
1. A configuration file that describes the master and boot
files which the name server should load and the zones that
the name server should attempt to load from foreign name
servers. This file establishes the initial contents of the
status table.
1. マスターについて説明する構成ファイル、ネームサーバがロードするべきであるブート・ファイル、およびネームサーバが外国ネームサーバからロードするのを試みるべきであるゾーン。 このファイルは状態テーブルの初期のコンテンツを確立します。
2. Domain data files that contain master and boot data to be
loaded.
2. マスターを含んでいて、ロードされるためにデータをブートするドメインデータファイル。
3. A status table that is derived from the configuration file.
Each entry in this table describes a source of data. Each
entry has a zone number. The zone number is zero for
3. 構成ファイルから得られる状態テーブル。 このテーブルの各エントリーはデータの源について説明します。 各エントリーには、ゾーン番号があります。 ゾーン番号はゼロです。
Mockapetris [Page 41]
Mockapetris[41ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
non-authoritative sources; authoritative sources are
assigned separate non-zero numbers.
非権威筋。 別々の非ゼロ番号は権威筋に割り当てられます。
4. The shared database that holds the domain data. This
database is assumed to be organized in some sort of tree
structure paralleling the domain name space, with a list of
resource records attached to each node and leaf in the tree.
The elements of the resource record list need not contain
the exact data present in the corresponding output format,
but must contain data sufficient to create the output
format; for example, these records need not contain the
domain name that is associated with the resource because
that name can be derived from the tree structure. Each
resource record also internal data that the name server uses
to organize its data.
4. ドメインデータを保持する共有データベース。 ドメイン名スペースに沿うある種の木構造でこのデータベースが組織化されると思われます、リソース記録のリストが各ノードに添付されて、葉が木にある状態で。 リソース記録リストの要素は、対応する出力形式における現在の正確なデータを含む必要はありませんが、出力形式を作成できるくらいのデータを含まなければなりません。 例えば、これらの記録は木構造からその名前を得ることができるのでリソースに関連しているドメイン名を含む必要はありません。 また、各リソースはネームサーバがデータを組織化するのに使用する内部のデータを記録します。
5. Inversion data structures that allow the name server to
process inverse queries and completion queries. Although
many structures could be used, the implementation described
in this memo supposes that there is one array for every
inversion that the name server can handle. Each array
contains a list of pointers to resource records such that
the order of the inverted quantities is sorted.
5. ネームサーバが逆さの質問と完成質問を処理できる逆データ構造。 多くの構造を使用できましたが、このメモで説明された実装は、ネームサーバが扱うことができる各逆あたり1つの配列があると思います。 各配列がリソース記録に指針のリストを含んでいるので、逆さの量の注文を分類します。
6. The main and cache queue locks
6. メインとキャッシュ待ち行列錠
7. The cache queue
7. キャッシュ待ち行列
The maintenance process begins by loading the status table from
the configuration file. It then periodically checks each entry,
to see if its refresh interval has elapsed. If not, it goes on to
the next entry. If so, it performs different operations depending
on the entry:
メインテナンスプロセスは、構成ファイルから状態テーブルを積み込むことによって、始まります。 間隔をリフレッシュしてください。次に、見るために定期的に各エントリーをチェックする、それ、経過しました。 そうでなければ、それは次のエントリーに進んでいます。 そうだとすれば、エントリーによる異なった操作を実行します:
If the entry is for zone 0, or the cache tree, the maintenance
process checks to see if additions or deletions are required.
Additions are acquired from the cache queue using the cache
queue lock. Deletions are detected using TTL checks. If any
changes are required, the maintenance process recalculates
inversion data structures and then alters the cache tree under
the protection of the main lock. Whenever the maintenance
process modifies the cache tree, it resets the refresh interval
to the minimum of the contained TTLs and the desired time
interval for cache additions.
エントリーがゾーン0、またはキャッシュ木のためのものであるなら、メインテナンスプロセスは、追加か削除が必要であるかどうか確認するためにチェックします。 キャッシュ待ち行列からキャッシュ待ち行列錠を使用することで追加を取得します。 削除はTTLチェックを使用するのが検出されます。 変化が必要です、メインテナンスプロセスrecalculates逆データ構造、メインの保護でのキャッシュ木がその時変わるなら、ロックしてください。 メインテナンスプロセスがキャッシュ木を変更して、それがリセットであることのときはいつも、キャッシュ追加のために含まれたTTLsと必要な時間間隔の最小限に間隔をリフレッシュしてください。
If the entry is not zone 0, and the entry refers to a local
file, the maintenance process checks to see if the file has
been modified since its last load. If so the file is reloaded
using the procedures specified under "Name server file
エントリーがゾーン0でなく、エントリーがローカルファイルを示すなら、メインテナンスプロセスは、最後の負荷以来ファイルが変更されているかどうか確認するためにチェックします。 そうだとすれば、ファイルは、「ネームサーバファイル」の下で指定された手順を用いることで再ロードされます。
Mockapetris [Page 42]
Mockapetris[42ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
loading". The refresh interval is reset to that specified in
the SOA record if the file is a master file.
「ローディング。」 間隔をリフレッシュしてください。ファイルが基本ファイルであるならSOA記録で指定されたそれにリセットされます。
If the entry is for a remote master file, the maintenance
process checks for a new version using the procedure described
in "Names server remote zone transfer".
エントリーがリモート基本ファイルのためのものであるなら、メインテナンスプロセスは、新しいバージョンがないかどうか「サーバの遠く離れたゾーンが移す名前」で説明された手順を用いることでチェックします。
Name server file loading
ネームサーバファイルローディング
Master files are kept in text form for ease of editing by system
maintainers. These files are not exchanged by name servers; name
servers use the standard message format when transferring zones.
基本ファイルはシステムで維持装置を編集する容易さのためにテキストフォームで保たれます。 これらのファイルはネームサーバによって交換されません。 ゾーンを移すとき、ネームサーバは標準のメッセージ・フォーマットを使用します。
Organizations that want to have a domain, but do not want to run a
name server, can use these files to supply a domain definition to
another organization that will run a name server for them. For
example, if organization X wants a domain but not a name server,
it can find another organization, Y, that has a name server and is
willing to provide service for X. Organization X defines domain X
via the master file format and ships a copy of the master file to
organization Y via mail, FTP, or some other method. A system
administrator at Y configures Y's name server to read in X's file
and hence support the X domain. X can maintain the master file
using a text editor and send new versions to Y for installation.
ドメインが欲しいのですが、ネームサーバを実行したがっていない組織は、それらのためにネームサーバを実行する別の組織にドメイン定義を供給するのにこれらのファイルを使用できます。 例えば、組織Xがネームサーバではなく、ドメインが欲しいなら、それは、別の組織、ネームサーバを持って、X.Organization Xにサービスを供給しても構わないと思っているYがメール、FTP、またはある他のメソッドで基本ファイル形式でドメインXを定義して、基本ファイルのコピーを組織Yに出荷するのを見つけることができます。 Yのシステム管理者は、Xのファイルで読んで、したがって、XドメインをサポートするためにYのネームサーバを構成します。 Xは、テキストエディタを使用することで基本ファイルを維持して、新しいバージョンをインストールのためのYに送ることができます。
These files have a simple line-oriented format, with one RR per
line. Fields are separated by any combination of blanks and tab
characters. Tabs are treated the same as spaces; in the following
discussion the term "blank" means either a tab or a blank. A line
can be either blank (and ignored), a RR, or a $INCLUDE line.
これらのファイルには、1系列あたり1RRがある簡単な系列指向の形式があります。 野原は空白とタブキャラクタのどんな組み合わせでも分離されます。 タブは同じように空間として扱われます。 以下の議論では、「空白である」という用語はタブか空白のどちらかを意味します。 系列は、どちらかの空白(そして、無視される)、RR、または$INCLUDE系列であるかもしれません。
If a RR line starts with a domain name, that domain name is used
to specify the location in the domain space for the record, i.e.
the owner. If a RR line starts with a blank, it is loaded into
the location specified by the most recent location specifier.
RR系列がドメイン名から始まるなら、そのドメイン名は、ドメインスペースで記録(すなわち、所有者)に位置を指定するのに使用されます。 RR系列が空白から始まるなら、それは最新の位置の特許説明書の作成書によって指定された位置にロードされます。
The location specifiers are assumed to be relative to some origin
that is provided by the user of a file unless the location
specifier contains the root label. This provides a convenient
shorthand notation, and can also be used to prevent errors in
master files from propagating into other zones. This feature is
particularly useful for master files imported from other sites.
位置の特許説明書の作成書が位置の特許説明書の作成書が根のラベルを含まない場合ファイルのユーザによって提供される何らかの発生源に比例していると思われます。 これは、便利な簡単な表記法を提供して、また、基本ファイルにおける誤りが他のゾーンに伝播されるのを防ぐのに使用できます。 この特徴は特に他のサイトからインポートされた基本ファイルの役に立ちます。
An include line begins with $INCLUDE, starting at the first line
position, and is followed by a local file name and an optional
offset modifier. The filename follows the appropriate local
conventions. The offset is one or more labels that are added to
the offset in use for the file that contained the $INCLUDE. If
the offset is omitted, the included file is loaded using the
インクルード系列の第1代系列位置で始まって、$INCLUDEと共に始まって、ローカルファイル名と任意のオフセット修飾語はあとに続いています。 ファイル名は適切な地方のコンベンションに続きます。 オフセットは$INCLUDEを入れてあたファイルに、使用中のオフセットに加えられる1個以上のラベルです。 オフセットが省略されるなら、含まれているファイルはロードされた使用です。
Mockapetris [Page 43]
Mockapetris[43ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
offset of the file that contained the $INCLUDE command. For
example, a file being loaded at offset ARPA might contain the
following lines:
INCLUDEが命令する$を含んだファイルのオフセット。 例えば、オフセットARPAでロードされるファイルは以下の系列を含むかもしれません:
$INCLUDE <subsys>isi.data ISI
$INCLUDE <subsys>addresses.data
$インクルード<subsys>isi.data ISI$インクルード<subsys>addresses.data
The first line would be interpreted to direct loading of the file
<subsys>isi.data at offset ISI.ARPA. The second line would be
interpreted as a request to load data at offset ARPA.
最初の系列は、オフセットISI.ARPAでファイル<subsys>isi.dataの荷重を指示するために解釈されるでしょう。 系列がデータをロードする要求として解釈されるだろう秒に、ARPAを相殺してください。
Note that $INCLUDE commands do not cause data to be loaded into a
different zone or tree; they are simply ways to allow data for a
given zone to be organized in separate files. For example,
mailbox data might be kept separately from host data using this
mechanism.
$INCLUDEコマンドで異なったゾーンか木にデータをロードしないことに注意してください。 それらは単に与えられたゾーンが別々のファイルで組織化されるためにデータを許容する方法です。 例えば、メールボックスデータは、別々にホストデータからこのメカニズムを使用することで妨げられるかもしれません。
Resource records are entered as a sequence of fields corresponding
to the owner name, TTL, CLASS, TYPE and RDATA components. (Note
that this order is different from the order used in examples and
the order used in the actual RRs; the given order allows easier
parsing and defaulting.)
リソース記録は所有者名、TTL、CLASS、TYPE、およびRDATAの部品に対応する分野の系列として入力されます。 (このオーダーが例で使用される注文と実際のRRsで使用される注文と異なっていることに注意してください; 与えられたオーダーは、より簡単な構文解析とデフォルトを許容します。)
The owner name is derived from the location specifier.
位置の特許説明書の作成書から所有者名を得ます。
The TTL field is optional, and is expressed as a decimal
number. If omitted TTL defaults to zero.
TTL分野は、任意であり、10進数として言い表されます。 省略されるなら、TTLはゼロをデフォルトとします。
The CLASS field is also optional; if omitted the CLASS defaults
to the most recent value of the CLASS field in a previous RR.
また、CLASS分野も任意です。 省略されるなら、CLASSは前のRRのCLASS分野の最新の値をデフォルトとします。
The RDATA fields depend on the CLASS and TYPE of the RR. In
general, the fields that make up RDATA are expressed as decimal
numbers or as domain names. Some exceptions exist, and are
documented in the RDATA definitions in Appendicies 2 and 3 of
this memo.
RDATA分野はRRのCLASSとTYPEに依存します。 一般に、RDATAを作る分野は10進数として、または、ドメイン名として言い表されます。 いくつかの例外が、存在していて、このメモのAppendicies2と3とのRDATA定義に記録されます。
Because CLASS and TYPE fields don't contain any common
identifiers, and because CLASS and TYPE fields are never decimal
numbers, the parse is always unique.
CLASSとTYPE分野がどんな一般的な識別子も含んでいなくて、またCLASSとTYPE分野が決して10進数でないので分析、いつもユニークです。
Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded. In particular:
これらのファイルがテキストファイルであるので、数個の特別なencodingsが任意のデータがロードされるのを許容するのに必要です。 特に:
. A free standing dot is used to refer to the current domain
name.
. 無料の地位のドットは、現在のドメイン名を示すのに使用されます。
@ A free standing @ is used to denote the current origin.
@自由な地位の@は、現在の発生源を指示するのに使用されます。
Mockapetris [Page 44]
Mockapetris[44ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
.. Two free standing dots represent the null domain name of
the root.
.. 2つの無料の地位のドットが根のヌルドメイン名を表します。
\X where X is any character other than a digit (0-9), is used
to quote that character so that its special meaning does
not apply. For example, "\." can be used to place a dot
character in a label.
Xがケタ(0-9)以外のあらゆるキャラクタである\Xがそのキャラクタを引用するのにおいて使用されているので、特別な意味は適用されません。 「例えば」、\」 ドットキャラクタをラベルに置くのに使用できます。
\DDD where each D is a digit is the octet corresponding to the
decimal number described by DDD. The resulting octet is
assumed to be text and is not checked for special meaning.
各Dがケタである\DDDはDDDによって説明された10進数に対応する八重奏です。 結果として起こる八重奏は、テキストであると思われて、特別な意味がないかどうかチェックされません。
( ) Parentheses are used to group data that crosses a line
boundary. In effect, line terminations are not recognized
within parentheses.
( ) 括弧は、系列境界に交差するデータを分類するのに使用されます。 事実上、ライン・ターミネーションは括弧の中で認識されません。
; Semicolon is used to start a comment; the remainder of the
line is ignored.
; セミコロンはコメントを始めるのに使用されます。 系列の残りは無視されます。
Name server file loading example
ネームサーバファイルローディングの例
A name server for F.ISI.ARPA , serving as an authority for the
ARPA and ISI.ARPA domains, might use a boot file and two master
files. The boot file initializes some non-authoritative data, and
would be loaded without an origin:
ARPAとISI.ARPAドメインへの権威として機能して、F. ISI.ARPAのためのネームサーバはブート・ファイルと2つの基本ファイルを使用するかもしれません。 ブート・ファイルは、いくつかの非信頼すべきデータを初期化して、発生源なしでロードされるでしょう:
.. 9999999 IN NS B.ISI.ARPA
9999999 CS NS UDEL.CSNET
B.ISI.ARPA 9999999 IN A 10.3.0.52
UDEL.CSNET 9999999 CS A 302-555-0000
.. 10.3.0.52UDEL.CSNET9999999Csのナノ秒B.ISI.ARPA9999999Csナノ秒UDEL.CSNET B.ISI.ARPA9999999の9999999 302-555-0000
This file loads non-authoritative data which provides the
identities and addresses of root name servers. The first line
contains a NS RR which is loaded at the root; the second line
starts with a blank, and is loaded at the most recent location
specifier, in this case the root; the third and fourth lines load
RRs at B.ISI.ARPA and UDEL.CSNET, respectively. The timeouts are
set to high values (9999999) to prevent this data from being
discarded due to timeout.
このファイルは根のネームサーバのアイデンティティとアドレスを提供する非信頼すべきデータをロードします。 最初の系列は根で積み込まれるNS RRを含んでいます。 セカンドラインは、空白から始めて、最新の位置の特許説明書の作成書、この場合根でロードされます。 3番目と4番目の系列はB. ISI.ARPAとUDEL.CSNETでそれぞれRRsを積み込みます。 高い値(9999999)にタイムアウトが、このデータがタイムアウトのため捨てられるのを防ぐように設定されます。
The first master file loads authoritative data for the ARPA
domain. This file is designed to be loaded with an origin of
ARPA, which allows the location specifiers to omit the trailing
.ARPA labels.
最初の基本ファイルはARPAドメインのための信頼すべきデータをロードします。 このファイルは、位置の特許説明書の作成書に引きずっている.ARPAラベルを省略させるARPAの発生源に積むように設計されています。
Mockapetris [Page 45]
Mockapetris[45ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
@ IN SOA F.ISI.ARPA Action.E.ISI.ARPA (
20 ; SERIAL
3600 ; REFRESH
600 ; RETRY
3600000; EXPIRE
60) ; MINIMUM
NS F.ISI.ARPA ; F.ISI.ARPA is a name server for ARPA
NS A.ISI.ARPA ; A.ISI.ARPA is a name server for ARPA
MIT NS AI.MIT.ARPA; delegation to MIT name server
ISI NS F.ISI.ARPA ; delegation to ISI name server
@SOA F.ISI.ARPA Action.E. ISI.ARPA(20; シリーズ3600;は600をリフレッシュします; 再試行3600000; 60を吐き出す)で。 最小のナノ秒F.ISI.ARPA。 F. ISI.ARPAはARPA NS A. ISI.ARPAのためのネームサーバです。 A. ISI.ARPAはARPA MIT NS AI.MIT.ARPAのためのネームサーバです。 MITネームサーバISI NS F. ISI.ARPAへの委譲。 ISIネームサーバへの委譲
UDEL MD UDEL.ARPA
A 10.0.0.96
NBS MD NBS.ARPA
A 10.0.0.19
DTI MD DTI.ARPA
A 10.0.0.12
UDEL MD UDEL.ARPA A10.0.0.96NBS MD NBS.ARPA A10.0.0.19DTI MD DTI.ARPA A10.0.0、.12
AI.MIT A 10.2.0.6
F.ISI A 10.2.0.52
AI.MIT A10.2.0.6F.ISI A10.2.0、.52
The first group of lines contains the SOA record and its
parameters, and identifies name servers for this zone and for
delegated zones. The Action.E.ISI.ARPA field is a mailbox
specification for the responsible person for the zone, and is the
domain name encoding of the mail destination Action@E.ISI.ARPA.
The second group specifies data for domain names within this zone.
The last group has forward references for name server address
resolution for AI.MIT.ARPA and F.ISI.ARPA. This data is not
technically within the zone, and will only be used for additional
record resolution for NS records used in referrals. However, this
data is protected by the zone timeouts in the SOA, so it will
persist as long as the NS references persist.
系列の最初のグループは、SOA記録とそのパラメタを含んでいて、このゾーンと代表として派遣されたゾーンにネームサーバを特定します。 Action.E. ISI.ARPA分野は、ゾーンへの責任者へのメールボックス仕様であり、メールの目的地 Action@E.ISI.ARPA のドメイン名コード化です。 2番目のグループはこのゾーンの中のドメイン名のためのデータを指定します。 最後のグループには、AI.MIT.ARPAとF. ISI.ARPAのためのネームサーバアドレス解決の前進の参照があります。 このデータは、技術的にゾーンの中になくて、紹介に使用されるNS記録のための追加記録的な解決に使用されるだけでしょう。 しかしながら、このデータがSOAのゾーンタイムアウトによって保護されるので、NS参照が持続している限り、それは固執するでしょう。
The second master file defines the ISI.ARPA environment, and is
loaded with an origin of ISI.ARPA:
2番目の基本ファイルは、ISI.ARPA環境を定義して、ISI.ARPAの発生源に積みます:
@ IN SOA F.ISI.ARPA Action\.ISI.E.ISI.ARPA (
20 ; SERIAL
7200 ; REFRESH
600 ; RETRY
3600000; EXPIRE
60) ; MINIMUM
NS F.ISI.ARPA ; F.ISI.ARPA is a name server
A A 10.1.0.32
MD A.ISI.ARPA
MF F.ISI.ARPA
B A 10.3.0.52
MD B.ISI.ARPA
@SOA F.ISI.ARPA動作\.ISI.E. ISI.ARPA(20; シリーズ7200;は600をリフレッシュします; 再試行3600000; 60を吐き出す)で。 最小のナノ秒F.ISI.ARPA。 F. ISI.ARPAはネームサーバA A10.1.0.32MD A. ISI.ARPA MF F. ISI.ARPA B A10.3.0.52MD B. ISI.ARPAです。
Mockapetris [Page 46]
Mockapetris[46ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
MF F.ISI.ARPA
F A 10.2.0.52
MD F.ISI.ARPA
MF A.ISI.ARPA
$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
mf F.ISI.ARPA F A10.2.0.52MD F.ISI.ARPA mf A.ISI.ARPA$インクルード<SUBSYS>ISI-MAILBOXES.TXT
Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
ファイル<SUBSYS>ISI-MAILBOXES.TXTがあるところ:
MOE MB F.ISI.ARPA
LARRY MB A.ISI.ARPA
CURLEY MB B.ISI.ARPA
STOOGES MB B.ISI.ARPA
MG MOE.ISI.ARPA
MG LARRY.ISI.ARPA
MG CURLEY.ISI.ARPA
ムーMB F.ISI.ARPAラリーMB A.ISI.ARPAカーリーMB B.ISI.ARPA引立て役MB B.ISI.ARPA mg MOE.ISI.ARPA mg LARRY.ISI.ARPA mg CURLEY.ISI.ARPA
Note the use of the \ character in the SOA RR to specify the
responsible person mailbox "Action.ISI@E.ISI.ARPA".
SOA RRにおける\キャラクタの使用に注意して、責任者メールボックス" Action.ISI@E.ISI.ARPA "を指定してください。
Name server remote zone transfer
ネームサーバのリモートゾーン転送
When a name server needs to make an initial copy of a zone or test
to see if a existing zone copy should be refreshed, it begins by
attempting to open a virtual circuit to the foreign name server.
ネームサーバが、既存のゾーンコピーがリフレッシュされるべきであるかどうか確認するためにゾーンかテストの初期のコピーを作る必要があると、外国ネームサーバに仮想の回路を開けるのを試みることによって、それは始まります。
If this open attempt fails, and this was an initial load attempt,
it schedules a retry and exits. If this was a refresh operation,
the name server tests the status table to see if the maximum
holding time derived from the SOA EXPIRE field has elapsed. If
not, the name server schedules a retry. If the maximum holding
time has expired, the name server invalidates the zone in the
status table, and scans all resource records tagged with this zone
number. For each record it decrements TTL fields by the length of
time since the data was last refreshed. If the new TTL value is
negative, the record is deleted. If the TTL value is still
positive, it moves the RR to the cache tree and schedules a retry.
この開いている試みが失敗して、これがイニシャルロード試みであり、再試行の計画をするということであり、出るなら。 これがリフレッシュ操作であったなら、ネームサーバは、SOA EXPIRE分野から時間を得るように主張する最大が経過したかどうか確認するために状態テーブルを検査します。 そうでなければ、ネームサーバは再試行の計画をします。 最大の把持時間が期限が切れたなら、ネームサーバは、状態テーブルのゾーンを無効にして、このゾーン番号でタグ付けをされたすべてのリソース記録をスキャンします。 各記録に関しては、データが最後にリフレッシュされたので、時間の長さに従って、それはTTL分野を減少させます。 新しいTTL値が否定的であるなら、記録は削除されます。 TTL値がまだ上向きであるなら、それは、RRをキャッシュ木に動かして、再試行の計画をします。
If the open attempt succeeds, the name server sends a query to the
foreign name server in which QTYPE=SOA, QCLASS is set according to
the status table information from the configuration file, and
QNAME is set to the domain name of the zone of interest.
開いている試みが成功するなら、ネームサーバはどのQTYPE=SOAで外国ネームサーバに質問を送るか、そして、構成ファイルからの状態テーブル情報によると、QCLASSは用意ができています、そして、QNAMEはゾーンの興味があるドメイン名に用意ができています。
The foreign name server will return either a SOA record indicating
that it has the zone or an error. If an error is detected, the
virtual circuit is closed, and the failure is treated in the same
way as if the open attempt failed.
外国ネームサーバはそれにはゾーンがあるのを示すSOA記録か誤りのどちらかを返すでしょう。 誤りが検出されるなら、仮想の回路は閉じられます、そして、同様に、まるで開いている試みが失敗するかのように失敗は扱われます。
If the SOA record is returned and this was a refresh, rather than
an initial load of the zone, the name server compares the SERIAL
SOA記録を返して、これがaであったなら、リフレッシュしてください、そして、ゾーンのイニシャルロードよりむしろ、ネームサーバはSERIALを比較します。
Mockapetris [Page 47]
Mockapetris[47ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
field in the new SOA record with the SERIAL field in the SOA
record of the existing zone copy. If these values match, the zone
has not been updated since the last copy and hence there is no
reason to recopy the zone. In this case the name server resets
the times in the existing SOA record and closes the virtual
circuit to complete the operation.
新しいSOA記録では、SERIAL分野が既存のゾーンコピーに関するSOA記録にある状態で、さばきます。 これらの値が合っているなら、最後のコピー以来ゾーンをアップデートしていません、そして、したがって、ゾーンを再コピーする理由が全くありません。 この場合、ネームサーバは、既存のSOA記録の回をリセットして、操作を完了するために仮想の回路を閉じます。
If this is initial load, or the SERIAL fields were different, the
name server requests a copy of the zone by sending the foreign
name server an AXFR query which specifies the zone by its QCLASS
and QNAME fields.
これがイニシャルロードであるかSERIAL分野が異なったなら、ネームサーバは、QCLASSとQNAME分野でゾーンを指定するAXFR質問を外国ネームサーバに送ることによって、ゾーンのコピーを要求します。
When the foreign name server receives the AXFR request, it sends
each node from the zone to the requestor in a separate message.
It begins with the node that contains the SOA record, walks the
tree in breadth-first order, and completes the transfer by
resending the node containing the SOA record.
外国ネームサーバがAXFR要求を受け取るとき、それは別々のメッセージで各ノードをゾーンから要請者に送ります。 それは、SOA記録を含むノードで始まって、最初に幅のオーダーに木を押して行って、SOA記録を含むノードを再送することによって、転送を終了します。
Several error conditions are possible:
いくつかのエラー条件が可能です:
If the AXFR request cannot be matched to a SOA, the foreign
name server will return a single message in response that does
not contain the AXFR request. (The normal SOA query preceding
the AXFR is designed to avoid this condition, but it is still
possible.)
AXFR要求にSOAに合うことができないと、外国ネームサーバはAXFR要求を含まない応答におけるただ一つのメッセージを返すでしょう。 (AXFRに先行する通常のSOA質問はこの状態を避けるように設計されていますが、それはまだ可能です。)
The foreign name server can detect an internal error or detect
some other condition (e.g. system going down, out of resources,
etc.) that forces the transfer to be aborted. If so, it sends
a message with the "Server failure" condition set. If the AXFR
can be immediately retried with some chance of success, it
leaves the virtual open; otherwise it initiates a close.
外国ネームサーバは、内部エラーを検出するか、または転送がやむを得ず中止されるある他の条件(例えば、リソースからなどを下るシステム)を検出できます。 そうだとすれば、それは「サーバ失敗」状態セットがあるメッセージを送ります。 すぐに何らかの勝算でAXFRを再試行できるなら、仮想の戸外を出ます。 さもなければ、それは閉鎖を開始します。
If the foreign name server doesn't wish to perform the
operation for policy reasons (i.e. the system administrator
wishes to forbid zone copies), the foreign server returns a
"Refused" condition.
外国ネームサーバが方針理由で操作を実行したくないなら(すなわち、システム管理者はゾーンコピーを禁じたがっています)、外国サーバは「拒否された」状態を返します。
The requestor receives these records and builds a new tree. This
tree is not yet in the status table, so its data are not used to
process queries. The old copy of the zone, if any, may be used to
satisfy request while the transfer is in progress.
要請者は、これらの記録を受け取って、新しい木を建てます。 この木がまだ状態テーブルにないので、データは質問を処理するのに使用されません。 もしあればゾーンの古いコピーは、転送が進行している間、要望に応じるのに使用されるかもしれません。
When the requestor receives the second copy of the SOA node, it
compares the SERIAL field in the first copy of the SOA against the
SERIAL field in the last copy of the SOA record. If these don't
match, the foreign server updated its zone while the transfer was
in progress. In this case the requestor repeats the AXFR request
to acquire the newer version.
要請者がSOAノードの2番目のコピーを受け取るとき、それはSOA記録の最後のコピーのSERIAL分野に対してSOAの第一刷におけるSERIAL分野をたとえます。 これらが合っていないなら、転送は進行していましたが、外国サーバはゾーンをアップデートしました。 この場合、要請者は、より新しいバージョンを取得するというAXFR要求を繰り返します。
Mockapetris [Page 48]
Mockapetris[48ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
If the AXFR transfer eventually succeeds, the name server closes
the virtual circuit and and creates new versions of inversion data
structures for this zone. When this operation is complete, the
name server acquires the main lock in write mode and then replaces
any old copy of the zone and inversion data structures with new
ones. The name server then releases the main lock, and can
reclaim the storage used by the old copy.
そして、そして、AXFR転送が結局成功するなら、ネームサーバが仮想の回路を閉じる、逆データ構造の新しいバージョンをこのゾーンに作成します。 この操作が完全であるときに、ネームサーバはコネがゾーンと逆データ構造のどんな古いコピーも新しいものに取り替えるとモードとその時に書くメイン錠を入手します。 ネームサーバは、次に、メイン錠をリリースして、古いコピーによって使用されるストレージを取り戻すことができます。
If an error occurs during the AXFR transfer, the name server can
copy any partial information into its cache tree if it wishes,
although it will not normally do so if the zone transfer was a
refresh rather than an initial load.
誤りがAXFR転送の間、発生するなら、ゾーン転送がaであったなら通常そうしませんが、イニシャルロードよりむしろリフレッシュするように願うなら、ネームサーバはどんな部分的な情報もキャッシュ木にコピーできます。
Mockapetris [Page 49]
Mockapetris[49ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
RESOLVER ALGORITHMS
レゾルバアルゴリズム
Operations
操作
Resolvers have a great deal of latitude in the semantics they
allow in user calls. For example, a resolver might support
different user calls that specify whether the returned information
must be from and authoritative name server or not. Resolvers are
also responsible for enforcement of any local restrictions on
access, etc.
レゾルバには、彼らがユーザ呼び出しで許す意味論における多くの緯度があります。 例えば、レゾルバは情報が来ているに違いない返上と正式のネームサーバであるか否かに関係なく、指定する異なったユーザ呼び出しをサポートするかもしれません。 また、レゾルバもアクセスなどにおけるどんなローカルの制限の実施にも責任があります。
In any case, the resolver will transform the user query into a
number of shared database accesses and queries to remote name
servers. When a user requests a resource associated with a
particular domain name, the resolver will execute the following
steps:
どのような場合でも、レゾルバはユーザー・クエリーをリモートネームサーバへの多くの共有データベースアクセスと質問に変えるでしょう。 ユーザが特定のドメイン名に関連しているリソースを要求するとき、レゾルバは以下のステップを実行するでしょう:
1. The resolver first checks the local shared database, if any,
for the desired information. If found, it checks the
applicable timeout. If the timeout check succeeds, the
information is used to satisfy the user request. If not, the
resolver goes to step 2.
1. レゾルバは最初に、必要な情報がないかどうかもしあればローカルの共有データベースをチェックします。 見つけられるなら、それは適切なタイムアウトをチェックします。 タイムアウトチェックが成功するなら、情報は、ユーザ要求を満たすのに使用されます。 そうでなければ、レゾルバはステップ2に行きます。
2. In this step, the resolver consults the shared database for the
name server that most closely matches the domain name in the
user query. Multiple redundant name servers may be found. The
resolver goes to step 3.
2. このステップでは、レゾルバは最も密接にユーザー・クエリーにおけるドメイン名に合っているネームサーバのための共有データベースに相談します。 複数の余分なネームサーバが見つけられるかもしれません。 レゾルバはステップ3に行きます。
3. In this step the resolver chooses one of the available name
servers and sends off a query. If the query fails, it tries
another name server. If all fail, an error indication is
returned to the user. If a reply is received the resolver adds
the returned RRs to its database and goes to step 4.
3. このステップでは、レゾルバは、利用可能なネームサーバの1つを選んで、質問を送ります。 質問が失敗するなら、それは別のネームサーバを試みます。すべてが失敗するなら、誤り表示をユーザに返します。 回答が受け取られているなら、レゾルバは、返されたRRsをデータベースに追加して、ステップ4に行きます。
4. In this step, the resolver interprets the reply. If the reply
contains the desired information, the resolver returns the
information to the user. The the reply indicates that the
domain name in the user query doesn't exist, then the resolver
returns an error to the user. If the reply contains a
transient name server failure, the resolver can either wait and
retry the query or go back to step 3 and try a different name
server. If the reply doesn't contain the desired information,
but does contain a pointer to a closer name server, the
resolver returns to step 2, where the closer name servers will
be queried.
4. このステップでは、レゾルバは回答を解釈します。 回答が必要な情報を含んでいるなら、レゾルバは情報をユーザに返します。 回答は、ユーザー・クエリーにおけるドメイン名が存在していなくて、次に、レゾルバが誤りをユーザに返すのを示します。 回答が一時的なネームサーバ失敗を含んでいるなら、レゾルバは、待っていて、質問を再試行するか、ステップ3に戻って、または異なったネームサーバを試みることができます。回答が必要な情報を含んでいませんが、より近いネームサーバに指針を含んでいるなら、レゾルバはステップ2に戻ります。そこでは、より近いネームサーバが質問されるでしょう。
Several modifications to this algorithm are possible. A resolver
may not support a local cache and instead only cache information
during the course of a single user request, discarding it upon
このアルゴリズムへのいくつかの変更が可能です。 レゾルバはシングルユーザー要求のコースの間、ローカルなキャッシュと代わりにキャッシュ情報だけをサポートしないかもしれません、それを捨てて
Mockapetris [Page 50]
Mockapetris[50ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
completion. The resolver may also find that a datagram reply was
truncated, and open a virtual circuit so that the complete reply
can be recovered.
完成。 また、レゾルバは、完全な回答を回復できるようにデータグラム回答が先端を切られて、仮想の回路を開けるのがわかるかもしれません。
Inverse and completion queries must be treated in an
environment-sensitive manner, because the domain system doesn't
provide a method for guaranteeing that it can locate the correct
information. The typical choice will be to configure a resolver
to use a particular set of known name servers for inverse queries.
環境敏感な方法で逆と完成質問を扱わなければなりません、ドメインシステムが正確な情報の場所を見つけることができるのを保証するためのメソッドを提供しないので。 典型的な選択は逆さの質問に特定のセットの知られているネームサーバを使用するためにレゾルバを構成することでしょう。
Mockapetris [Page 51]
Mockapetris[51ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
DOMAIN SUPPORT FOR MAIL
メールのドメインサポート
Introduction
序論
Mail service is a particularly sensitive issue for users of the
domain system because of the lack of a consistent system for
naming mailboxes and even hosts, and the need to support continued
operation of existing services. This section discusses an
evolutionary approach for adding consistent domain name support
for mail.
メールサービスはメールボックスとホストさえ任命する整合的体系の不足、および既存にサービスの継続運転をサポートする必要性によるドメインシステムのユーザには、特に敏感な問題です。 このセクションはメールの一貫したドメイン名サポートを加えるための進化論のアプローチについて論じます。
The crucial issue is deciding on the types of binding to be
supported. Most mail systems specify a mail destination with a
two part construct such as X@Y. The left hand side, X, is an
string, often a user or account, and Y is a string, often a host.
This section refers to the part on the left, i.e. X, as the local
part, and refers to the part on the right, i.e. Y, as the global
part.
極めて重要な課題はサポートされるために付くタイプを決めています。 ほとんどのメールシステムが X@Y などの2部分構造物でメールの目的地を指定します。 しばしば、左側(X)は、ストリング、ユーザまたはアカウントです、そして、しばしばYはストリング、ホストです。 このセクションは、すなわち、左の部分、地方の部分としてのXについて言及して、右の部分について言及します、すなわち、Y、グローバルな部分として。
Most existing mail systems route mail based on the global part; a
mailer with mail to deliver to X@Y will decide on the host to be
contacted using only Y. We refer to this type of binding as
"agent binding".
ほとんどの既存のメールシステムがグローバルな部分に基づくメールを発送します。 X@Y に提供するメールをもっている郵送者は、Y.だけを使用することで連絡されるべきホストの上でWeが「エージェント結合」として付くこのタイプについて言及すると決めるでしょう。
For example, mail addressed to Mockapetris@ISIF is delivered to
host USC-ISIF (USC-ISIF is the official name for the host
specified by nickname ISIF).
例えば、 Mockapetris@ISIF に扱われたメールはホストUSC-ISIFに提供されます(USC-ISIFはあだ名ISIFによって指定されたホストのための正式名称です)。
More sophisticated mail systems use both the local and global
parts, i.e. both X and Y to determine which host should receive
the mail. These more sophisticated systems usually separate the
binding of the destination to the host from the actual delivery.
This allows the global part to be a generic name rather than
constraining it to a single host. We refer to this type of
binding as "mailbox binding".
より精巧なメールシステムは、どのホストがメールを受け取るべきであるかを決定するのに両方の地方の、そして、グローバルな部分、すなわち、両方XとYを使用します。 通常、これらのより精巧なシステムは実際の配送とホストに目的地の結合を切り離します。 これは、グローバルな部分が独身のホストにそれを抑制するよりむしろ総称であることを許容します。 私たちは「メールボックス結合」として付くこのタイプについて言及します。
For example, mail addressed to Mockapetris@ISI might be bound
to host F.ISI.ARPA, and subsequently delivered to that host,
while mail for Cohen@ISI might be bound to host B.ISI.ARPA.
例えば、 Mockapetris@ISI に扱われたメールは、ホストF. ISI.ARPAに縛られて、次にそのホストに提供されるかもしれません、 Cohen@ISI のためのメールは必ずB. ISI.ARPAを接待するかもしれないでしょうが。
The domain support for mail consists of two levels of support,
corresponding to these two binding models.
これらの拘束力がある2つのモデルに文通していて、メールのドメインサポートは2つのレベルのサポートから成ります。
The first level, agent binding, is compatible with existing
ARPA Internet mail procedures and uses maps a global part onto
one or more hosts that will accept the mail. This type of
binding uses the MAILA QTYPE.
最初のレベル(エージェント結合)は、既存のARPAインターネット・メール手順と互換性があって、メールを受け入れる1つ以上へのグローバルな部分がホスティングする地図を使用します。 このタイプの結合はMAILA QTYPEを使用します。
The second level, mailbox binding, offers extended services
第2レベル(メールボックス結合)は拡張サービスを提供します。
Mockapetris [Page 52]
Mockapetris[52ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
that map a local part and a global part onto one or more sets
of data via the MAILB QTYPE. The sets of data include hosts
that will accept the mail, mailing list members (mail groups),
and mailboxes for reporting errors or requests to change a mail
group.
1つ以上への地方の部分とグローバルな部分が設定するMAILB QTYPEを通したデータのその地図。 データのセットは誤りかメールグループを変えるという要求を報告するためにメール、メーリングリストメンバー(メールグループ)、およびメールボックスを受け入れるホストを含んでいます。
The domain system encodes the global part of a mail destination as
a domain name and uses dots in the global part to separate labels
in the encoded domain name. The domain system encodes the local
part of a mail destination as a single label, and any dots in this
part are simply copied into the label. The domain system forms a
complete mail destination as the local label concatenated to the
domain string for the global part. We call this a mailbox.
ドメインシステムは、ドメイン名としてメールの目的地のグローバルな部分をコード化して、コード化されたドメイン名でラベルを分離するのにグローバルな部分でドットを使用します。 ドメインシステムは単一のラベルとしてメールの目的地の地方の部分をコード化します、そして、この部分のどんなドットも単にラベルにコピーされます。 ドメインシステムはドメインストリングに連結された地方のラベルとして完全なメールの目的地をグローバルな部分に形成します。 私たちは、これをメールボックスと呼びます。
For example, the mailbox Mockapetris@F.ISI.ARPA has a global
domain name of three labels, F.ISI.ARPA. The domain name
encoding for the whole mailbox is Mockapetris.F.ISI.ARPA. The
mailbox Mockapetris.cad@F.ISI.ARPA has the same domain name for
the global part and a 4 label domain name for the mailbox of
Mockapetris\.cad.F.ISI.ARPA (the \ is not stored in the label,
its merely used to denote the "quoted" dot).
例えば、メールボックス Mockapetris@F.ISI.ARPA には、3個のラベル、F. ISI.ARPAのグローバルなドメイン名があります。 全体のメールボックスのためのドメイン名コード化はMockapetris.F. ISI.ARPAです。 メールボックス Mockapetris.cad@F.ISI.ARPA には、同じドメイン名がMockapetris\.cad.F. ISI.ARPAのメールボックスのためのグローバルな部分と4ラベルドメイン名のためにあります(\はラベルに保存されないで、それは単に以前はよく「引用された」ドットを指示し続けていました)。
It is anticipated that the Internet system will adopt agent
binding as part of the initial implementation of the domain
system, and that mailbox binding will eventually become the
preferred style as organizations convert their mail systems to the
new style. To facilitate this approach, the domain information
for these two binding styles is organized to allow a requestor to
determine which types of support are available, and the
information is kept in two disjoint classes.
組織がそれらのメールシステムを新式に変換するとき、インターネット・システムがドメインシステムの初期の実装の一部としてエージェント結合を採用して、メールボックス結合が結局都合のよいスタイルになると予期されます。 どのタイプのサポートが利用可能であるかを決定するためにスタイルを縛ると要請者が許容されるのが組織化されて、情報が保たれるこれらの2のためにこのアプローチ、ドメイン情報を容易にするために、2はクラスをばらばらにならせます。
Agent binding
エージェント結合
In agent binding, a mail system uses the global part of the mail
destination as a domain name, with dots denoting structure. The
domain name is resolved using a MAILA query which return MF and MD
RRs to specify the domain name of the appropriate host to receive
the mail. MD (Mail delivery) RRs specify hosts that are expected
to have the mailbox in question; MF (Mail forwarding) RRs specify
hosts that are expected to be intermediaries willing to accept the
mail for eventual forwarding. The hosts are hints, rather than
definite answers, since the query is made without the full mail
destination specification.
In agent binding, a mail system uses the global part of the mail destination as a domain name, with dots denoting structure. The domain name is resolved using a MAILA query which return MF and MD RRs to specify the domain name of the appropriate host to receive the mail. MD (Mail delivery) RRs specify hosts that are expected to have the mailbox in question; MF (Mail forwarding) RRs specify hosts that are expected to be intermediaries willing to accept the mail for eventual forwarding. The hosts are hints, rather than definite answers, since the query is made without the full mail destination specification.
For example, mail for MOCKAPETRIS@F.ISI.ARPA would result in a
query with QTYPE=MAILA and QNAME=F.ISI.ARPA, which might return
two RRs:
For example, mail for MOCKAPETRIS@F.ISI.ARPA would result in a query with QTYPE=MAILA and QNAME=F.ISI.ARPA, which might return two RRs:
Mockapetris [Page 53]
Mockapetris [Page 53]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
F.ISI.ARPA MD IN F.ISI.ARPA
F.ISI.ARPA MF IN A.ISI.ARPA
F.ISI.ARPA MD IN F.ISI.ARPA F.ISI.ARPA MF IN A.ISI.ARPA
The mailer would interpret these to mean that the mail agent on
F.ISI.ARPA should be able to deliver the mail directly, but that
A.ISI.ARPA is willing to accept the mail for probable forwarding.
The mailer would interpret these to mean that the mail agent on F.ISI.ARPA should be able to deliver the mail directly, but that A.ISI.ARPA is willing to accept the mail for probable forwarding.
Using this system, an organization could implement a system that
uses organization names for global parts, rather than the usual
host names, but all mail for the organization would be routed the
same, regardless of its local part. Hence and organization with
many hosts would expect to see many forwarding operations.
Using this system, an organization could implement a system that uses organization names for global parts, rather than the usual host names, but all mail for the organization would be routed the same, regardless of its local part. Hence and organization with many hosts would expect to see many forwarding operations.
Mailbox binding
Mailbox binding
In mailbox binding, the mailer uses the entire mail destination
specification to construct a domain name. The encoded domain name
for the mailbox is used as the QNAME field in a QTYPE=MAILB query.
In mailbox binding, the mailer uses the entire mail destination specification to construct a domain name. The encoded domain name for the mailbox is used as the QNAME field in a QTYPE=MAILB query.
Several outcomes are possible for this query:
Several outcomes are possible for this query:
1. The query can return a name error indicating that the mailbox
does not exist as a domain name.
1. The query can return a name error indicating that the mailbox does not exist as a domain name.
In the long term this would indicate that the specified mailbox
doesn't exist. However, until the use of mailbox binding is
universal, this error condition should be interpreted to mean
that the organization identified by the global part does not
support mailbox binding. The appropriate procedure is to
revert to agent binding at this point.
In the long term this would indicate that the specified mailbox doesn't exist. However, until the use of mailbox binding is universal, this error condition should be interpreted to mean that the organization identified by the global part does not support mailbox binding. The appropriate procedure is to revert to agent binding at this point.
2. The query can return a Mail Rename (MR) RR.
2. The query can return a Mail Rename (MR) RR.
The MR RR carries new mailbox specification in its RDATA field.
The mailer should replace the old mailbox with the new one and
retry the operation.
The MR RR carries new mailbox specification in its RDATA field. The mailer should replace the old mailbox with the new one and retry the operation.
3. The query can return a MB RR.
3. The query can return a MB RR.
The MB RR carries a domain name for a host in its RDATA field.
The mailer should deliver the message to that host via whatever
protocol is applicable, e.g. SMTP.
The MB RR carries a domain name for a host in its RDATA field. The mailer should deliver the message to that host via whatever protocol is applicable, e.g. SMTP.
4. The query can return one or more Mail Group (MG) RRs.
4. The query can return one or more Mail Group (MG) RRs.
This condition means that the mailbox was actually a mailing
list or mail group, rather than a single mailbox. Each MG RR
has a RDATA field that identifies a mailbox that is a member of
This condition means that the mailbox was actually a mailing list or mail group, rather than a single mailbox. Each MG RR has a RDATA field that identifies a mailbox that is a member of
Mockapetris [Page 54]
Mockapetris [Page 54]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
the group. The mailer should deliver a copy of the message to
each member.
the group. The mailer should deliver a copy of the message to each member.
5. The query can return a MB RR as well as one or more MG RRs.
5. The query can return a MB RR as well as one or more MG RRs.
This condition means the the mailbox was actually a mailing
list. The mailer can either deliver the message to the host
specified by the MB RR, which will in turn do the delivery to
all members, or the mailer can use the MG RRs to do the
expansion itself.
This condition means the the mailbox was actually a mailing list. The mailer can either deliver the message to the host specified by the MB RR, which will in turn do the delivery to all members, or the mailer can use the MG RRs to do the expansion itself.
In any of these cases, the response may include a Mail Information
(MINFO) RR. This RR is usually associated with a mail group, but
is legal with a MB. The MINFO RR identifies two mailboxes. One
of these identifies a responsible person for the original mailbox
name. This mailbox should be used for requests to be added to a
mail group, etc. The second mailbox name in the MINFO RR
identifies a mailbox that should receive error messages for mail
failures. This is particularly appropriate for mailing lists when
errors in member names should be reported to a person other than
the one who sends a message to the list. New fields may be added
to this RR in the future.
In any of these cases, the response may include a Mail Information (MINFO) RR. This RR is usually associated with a mail group, but is legal with a MB. The MINFO RR identifies two mailboxes. One of these identifies a responsible person for the original mailbox name. This mailbox should be used for requests to be added to a mail group, etc. The second mailbox name in the MINFO RR identifies a mailbox that should receive error messages for mail failures. This is particularly appropriate for mailing lists when errors in member names should be reported to a person other than the one who sends a message to the list. New fields may be added to this RR in the future.
Mockapetris [Page 55]
Mockapetris [Page 55]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
Appendix 1 - Domain Name Syntax Specification
Appendix 1 - Domain Name Syntax Specification
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 use domain names containing binary information and hence do not follow this syntax.
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 use domain names containing binary information and hence do not follow this syntax.
<domain> ::= <subdomain> | " "
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<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
<letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
<digit> ::= any one of the ten digits 0 through 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.
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.
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.
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.
For example, the following strings identify hosts in the ARPA Internet:
For example, the following strings identify hosts in the ARPA Internet:
F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
Mockapetris [Page 56]
Mockapetris [Page 56]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
Appendix 2 - Field formats and encodings
Appendix 2 - Field formats and encodings
+-----------------------------------------------+
| |
| ***** WARNING ***** |
| |
| The following formats are preliminary and |
| are included for purposes of explanation only.|
| In particular, new RR types will be added, |
| and the size, position, and encoding of |
| fields are subject to change. |
| |
+-----------------------------------------------+
+-----------------------------------------------+ | | | ***** WARNING ***** | | | | The following formats are preliminary and | | are included for purposes of explanation only.| | In particular, new RR types will be added, | | and the size, position, and encoding of | | fields are subject to change. | | | +-----------------------------------------------+
TYPE values
TYPE values
TYPE fields are used in resource records. Note that these types
are not the same as the QTYPE fields used in queries, although the
functions are often similar.
TYPE fields are used in resource records. Note that these types are not the same as the QTYPE fields used in queries, although the functions are often similar.
TYPE value meaning
TYPE value meaning
A 1 a host address
A 1 a host address
NS 2 an authoritative name server
NS 2 an authoritative name server
MD 3 a mail destination
MD 3 a mail destination
MF 4 a mail forwarder
MF 4 a mail forwarder
CNAME 5 the canonical name for an alias
CNAME 5 the canonical name for an alias
SOA 6 marks the start of a zone of authority
SOA 6 marks the start of a zone of authority
MB 7 a mailbox domain name
MB 7 a mailbox domain name
MG 8 a mail group member
MG 8 a mail group member
MR 9 a mail rename domain name
MR 9 a mail rename domain name
NULL 10 a null RR
NULL 10 a null RR
WKS 11 a well known service description
WKS 11 a well known service description
PTR 12 a domain name pointer
PTR 12 a domain name pointer
HINFO 13 host information
HINFO 13 host information
MINFO 14 mailbox or mail list information
MINFO 14 mailbox or mail list information
Mockapetris [Page 57]
Mockapetris [Page 57]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
QTYPE values
QTYPE values
QTYPE fields appear in the question part of a query. They include
the values of TYPE with the following additions:
QTYPE fields appear in the question part of a query. They include the values of TYPE with the following additions:
AXFR 252 A request for a transfer of an entire zone of authority
AXFR 252 A request for a transfer of an entire zone of authority
MAILB 253 A request for mailbox-related records (MB, MG or MR)
MAILB 253 A request for mailbox-related records (MB, MG or MR)
MAILA 254 A request for mail agent RRs (MD and MF)
MAILA 254 A request for mail agent RRs (MD and MF)
* 255 A request for all records
* 255 A request for all records
CLASS values
CLASS values
CLASS fields appear in resource records
CLASS fields appear in resource records
CLASS value meaning
CLASS value meaning
IN 1 the ARPA Internet
IN 1 the ARPA Internet
CS 2 the computer science network (CSNET)
CS 2 the computer science network (CSNET)
QCLASS values
QCLASS values
QCLASS fields appear in the question section of a query. They
include the values of CLASS with the following additions:
QCLASS fields appear in the question section of a query. They include the values of CLASS with the following additions:
* 255 any class
* 255 any class
Mockapetris [Page 58]
Mockapetris [Page 58]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
Standard resource record formats
Standard resource record formats
All RRs have the same top level format shown below:
All RRs have the same top level format shown below:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
NAME - a compressed domain name to which this resource
record pertains.
NAME - a compressed domain name to which this resource record pertains.
TYPE - two octets containing one of the RR type codes
defined in Appendix 2. This field specifies the
meaning of the data in the RDATA field.
TYPE - two octets containing one of the RR type codes defined in Appendix 2. This field specifies the meaning of the data in the RDATA field.
CLASS - two octets which specifies the class of the data in
the RDATA field.
CLASS - two octets which specifies the class of the data in the RDATA field.
TTL - a 16 bit signed integer that specifies the time
interval that the resource record may be cached
before the source of the information should again be
consulted. Zero values are interpreted to mean that
the RR can only be used for the transaction in
progress, and should not be cached. For example, SOA
records are always distributed with a zero TTL to
prohibit caching. Zero values can also be used for
extremely volatile data.
TTL - a 16 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. For example, SOA records are always distributed with a zero TTL to prohibit caching. Zero values can also be used for extremely volatile data.
RDLENGTH- an unsigned 16 bit integer that specifies the length
in octets of the RDATA field.
RDLENGTH- an unsigned 16 bit integer that specifies the length in octets of the RDATA field.
Mockapetris [Page 59]
Mockapetris [Page 59]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
RDATA - a variable length string of octets that describes the
resource. The format of this information varies
according to the TYPE and CLASS of the resource
record.
RDATA - a variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record.
The format of the RDATA field is standard for all classes for the
RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO and
NULL. These formats are shown below together with the appropriate
additional section RR processing.
The format of the RDATA field is standard for all classes for the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO and NULL. These formats are shown below together with the appropriate additional section RR processing.
CNAME RDATA format
CNAME RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
CNAME - A compressed domain name which specifies that the
domain name of the RR is an alias for a canonical
name specified by CNAME.
CNAME - A compressed domain name which specifies that the domain name of the RR is an alias for a canonical name specified by CNAME.
CNAME records cause no additional section processing. The
RDATA section of a CNAME line in a master file is a standard
printed domain name.
CNAME records cause no additional section processing. The RDATA section of a CNAME line in a master file is a standard printed domain name.
HINFO RDATA format
HINFO RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CPU /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ OS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CPU / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / OS / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
CPU - A character string which specifies the CPU type. The
character string is represented as a single octet
length followed by that number of characters. The
following standard strings are defined:.
CPU - A character string which specifies the CPU type. The character string is represented as a single octet length followed by that number of characters. The following standard strings are defined:.
PDP-11/70 C/30 C/70 VAX-11/780
H-316 H-516 DEC-2060 DEC-1090T
ALTO IBM-PC IBM-PC/XT PERQ
IBM-360/67 IBM-370/145
PDP-11/70 C/30 C/70 VAX-11/780 H-316 H-516 DEC-2060 DEC-1090T ALTO IBM-PC IBM-PC/XT PERQ IBM-360/67 IBM-370/145
OS - A character string which specifies the operating system
type. The character string is represented as a single octet
OS - A character string which specifies the operating system type. The character string is represented as a single octet
Mockapetris [Page 60]
Mockapetris [Page 60]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
length followed by that number of characters. The following
standard types are defined:.
length followed by that number of characters. The following standard types are defined:.
ASP AUGUST BKY CCP
DOS/360 ELF EPOS EXEC-8
GCOS GPOS ITS INTERCOM
KRONOS MCP MOS MPX-RT
MULTICS MVT NOS NOS/BE
OS/MVS OS/MVT RIG RSX11
RSX11M RT11 SCOPE SIGNAL
SINTRAN TENEX TOPS10 TOPS20
TSS UNIX VM/370 VM/CMS
VMS WAITS
ASP AUGUST BKY CCP DOS/360 ELF EPOS EXEC-8 GCOS GPOS ITS INTERCOM KRONOS MCP MOS MPX-RT MULTICS MVT NOS NOS/BE OS/MVS OS/MVT RIG RSX11 RSX11M RT11 SCOPE SIGNAL SINTRAN TENEX TOPS10 TOPS20 TSS UNIX VM/370 VM/CMS VMS WAITS
HINFO records cause no additional section processing.
HINFO records cause no additional section processing.
HINFO records are used to acquire general information about a
host. The main use is for protocols such as FTP that can use
special procedures when talking between machines or operating
systems of the same type.
HINFO records are used to acquire general information about a host. The main use is for protocols such as FTP that can use special procedures when talking between machines or operating systems of the same type.
MB RDATA format
MB RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MADNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
MADNAME - A compressed domain name which specifies a host which
has the specified mailbox.
MADNAME - A compressed domain name which specifies a host which has the specified mailbox.
MB records cause additional section processing which looks up
an A type record corresponding to MADNAME. The RDATA section
of a MB line in a master file is a standard printed domain
name.
MB records cause additional section processing which looks up an A type record corresponding to MADNAME. The RDATA section of a MB line in a master file is a standard printed domain name.
MD RDATA format
MD RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MADNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
MADNAME - A compressed domain name which specifies a host which
MADNAME - A compressed domain name which specifies a host which
Mockapetris [Page 61]
Mockapetris [Page 61]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
has a mail agent for the domain which should be able
to deliver mail for the domain.
has a mail agent for the domain which should be able to deliver mail for the domain.
MD records cause additional section processing which looks up
an A type record corresponding to MADNAME. The RDATA section
of a MD line in a master file is a standard printed domain
name.
MD records cause additional section processing which looks up an A type record corresponding to MADNAME. The RDATA section of a MD line in a master file is a standard printed domain name.
MF RDATA format
MF RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MADNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
MADNAME - A compressed domain name which specifies a host which
has a mail agent for the domain which will accept
mail for forwarding to the domain.
MADNAME - A compressed domain name which specifies a host which has a mail agent for the domain which will accept mail for forwarding to the domain.
MF records cause additional section processing which looks up
an A type record corresponding to MADNAME. The RDATA section
of a MF line in a master file is a standard printed domain
name.
MF records cause additional section processing which looks up an A type record corresponding to MADNAME. The RDATA section of a MF line in a master file is a standard printed domain name.
MG RDATA format
MG RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MGMNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MGMNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
MGMNAME - A compressed domain name which specifies a mailbox
which is a member of the mail group specified by the
domain name.
MGMNAME - A compressed domain name which specifies a mailbox which is a member of the mail group specified by the domain name.
MF records cause no additional section processing. The RDATA
section of a MF line in a master file is a standard printed
domain name.
MF records cause no additional section processing. The RDATA section of a MF line in a master file is a standard printed domain name.
Mockapetris [Page 62]
Mockapetris [Page 62]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
MINFO RDATA format
MINFO RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RMAILBX /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EMAILBX /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RMAILBX / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / EMAILBX / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
RMAILBX - A compressed domain name which specifies a mailbox
which is responsible for the mailing list or mailbox.
If this domain name names the root, the owner of the
MINFO RR is responsible for itself. Note that many
existing mailing lists use a mailbox X-request for
the RMAILBX field of mailing list X, e.g.
Msgroup-request for Msgroup. This field provides a
more general mechanism.
RMAILBX - A compressed domain name which specifies a mailbox which is responsible for the mailing list or mailbox. If this domain name names the root, the owner of the MINFO RR is responsible for itself. Note that many existing mailing lists use a mailbox X-request for the RMAILBX field of mailing list X, e.g. Msgroup-request for Msgroup. This field provides a more general mechanism.
EMAILBX - A compressed domain name which specifies a mailbox
which is to receive error messages related to the
mailing list or mailbox specified by the owner of the
MINFO RR (similar to the ERRORS-TO: field which has
been proposed). If this domain name names the root,
errors should be returned to the sender of the
message.
EMAILBX - A compressed domain name which specifies a mailbox which is to receive error messages related to the mailing list or mailbox specified by the owner of the MINFO RR (similar to the ERRORS-TO: field which has been proposed). If this domain name names the root, errors should be returned to the sender of the message.
MINFO records cause no additional section processing. Although
these records can be associated with a simple mailbox, they are
usually used with a mailing list. The MINFO section of a MF
line in a master file is a standard printed domain name.
MINFO records cause no additional section processing. Although these records can be associated with a simple mailbox, they are usually used with a mailing list. The MINFO section of a MF line in a master file is a standard printed domain name.
MR RDATA format
MR RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NEWNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / NEWNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
NEWNAME - A compressed domain name which specifies a mailbox
which is the proper rename of the specified mailbox.
NEWNAME - A compressed domain name which specifies a mailbox which is the proper rename of the specified mailbox.
MR records cause no additional section processing. The RDATA
section of a MR line in a master file is a standard printed
domain name.
MR records cause no additional section processing. The RDATA section of a MR line in a master file is a standard printed domain name.
Mockapetris [Page 63]
Mockapetris [Page 63]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
NULL RDATA format
NULL RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ <anything> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / <anything> / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Anything at all may be in the RDATA field so long as it is
65535 octets or less.
Anything at all may be in the RDATA field so long as it is 65535 octets or less.
NULL records cause no additional section processing. NULL RRs
are not allowed in master files.
NULL records cause no additional section processing. NULL RRs are not allowed in master files.
NS RDATA format
NS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / NSDNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
NSDNAME - A compressed domain name which specifies a host which
has a name server for the domain.
NSDNAME - A compressed domain name which specifies a host which has a name server for the domain.
NS records cause both the usual additional section processing
to locate a type A record, and a special search of the zone in
which they reside. The RDATA section of a NS line in a master
file is a standard printed domain name.
NS records cause both the usual additional section processing to locate a type A record, and a special search of the zone in which they reside. The RDATA section of a NS line in a master file is a standard printed domain name.
PTR RDATA format
PTR RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ PTRDNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / PTRDNAME / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
PTRDNAME - A compressed domain name which points to some
location in the domain name space.
PTRDNAME - A compressed domain name which points to some location in the domain name space.
PTR records cause no additional section processing. These RRs
are used in special domains to point to some other location in
the domain space. These records are simple data, and don't
imply any special processing similar to that performed by
CNAME, which identifies aliases. Appendix 3 discusses the use
of these records in the ARPA Internet address domain.
PTR records cause no additional section processing. These RRs are used in special domains to point to some other location in the domain space. These records are simple data, and don't imply any special processing similar to that performed by CNAME, which identifies aliases. Appendix 3 discusses the use of these records in the ARPA Internet address domain.
Mockapetris [Page 64]
Mockapetris [Page 64]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
SOA RDATA format
SOA RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SERIAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| REFRESH |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RETRY |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EXPIRE |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MINIMUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RNAME / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | SERIAL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | REFRESH | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RETRY | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | EXPIRE | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | MINIMUM | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
MNAME - The domain name of the name server that was the
original source of data for this zone.
MNAME - The domain name of the name server that was the original source of data for this zone.
RNAME - A domain name which specifies the mailbox of the
person responsible for this zone.
RNAME - A domain name which specifies the mailbox of the person responsible for this zone.
SERIAL - The unsigned 16 bit version number of the of the
original copy of the zone. This value wraps and
should be compared using sequence space arithmetic.
SERIAL - The unsigned 16 bit version number of the of the original copy of the zone. This value wraps and should be compared using sequence space arithmetic.
REFRESH - The unsigned 32 bit time interval before the zone
should be refreshed.
REFRESH - The unsigned 32 bit time interval before the zone should be refreshed.
RETRY - The unsigned 32 bit time interval that should elapse
before a failed refresh should be retried.
RETRY - The unsigned 32 bit time interval that should elapse before a failed refresh should be retried.
EXPIRE - A 32 bit time value that specifies the upper limit on
the time interval that can elapse before the zone is
no longer authoritative.
EXPIRE - A 32 bit time value that specifies the upper limit on the time interval that can elapse before the zone is no longer authoritative.
MINIMUM - The unsigned 16 bit minimum TTL field that should be
exported with any RR from this zone (other than the
SOA itself).
MINIMUM - The unsigned 16 bit minimum TTL field that should be exported with any RR from this zone (other than the SOA itself).
SOA records cause no additional section processing. The RDATA
SOA records cause no additional section processing. The RDATA
Mockapetris [Page 65]
Mockapetris [Page 65]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
section of a SOA line in a master file is a standard printed
domain name for MNAME, a standard X@Y mailbox specification for
RNAME, and decimal numbers for the remaining parameters.
section of a SOA line in a master file is a standard printed domain name for MNAME, a standard X@Y mailbox specification for RNAME, and decimal numbers for the remaining parameters.
All times are in units of seconds.
All times are in units of seconds.
Most of these fields are pertinent only for name server
maintenance operations. However, MINIMUM is used in all query
operations that retrieve RRs from a zone. Whenever a RR is
sent in a response to a query, the TTL field is set to the
maximum of the TTL field from the RR and the MINIMUM field in
the appropriate SOA. Thus MINIMUM is a lower bound on the TTL
field for all RRs in a zone. RRs in a zone are never discarded
due to timeout unless the whole zone is deleted. This prevents
partial copies of zones.
Most of these fields are pertinent only for name server maintenance operations. However, MINIMUM is used in all query operations that retrieve RRs from a zone. Whenever a RR is sent in a response to a query, the TTL field is set to the maximum of the TTL field from the RR and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower bound on the TTL field for all RRs in a zone. RRs in a zone are never discarded due to timeout unless the whole zone is deleted. This prevents partial copies of zones.
Mockapetris [Page 66]
Mockapetris [Page 66]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
Appendix 3 - Internet specific field formats and operations
Appendix 3 - Internet specific field formats and operations
Message transport
Message transport
The Internet supports name server access using TCP [10] on server
port 53 (decimal) as well as datagram access using UDP [11] on UDP
port 53 (decimal). Messages sent over TCP virtual circuits are
preceded by an unsigned 16 bit length field which describes the
length of the message, excluding the length field itself.
The Internet supports name server access using TCP [10] on server port 53 (decimal) as well as datagram access using UDP [11] on UDP port 53 (decimal). Messages sent over TCP virtual circuits are preceded by an unsigned 16 bit length field which describes the length of the message, excluding the length field itself.
+-----------------------------------------------+
| |
| ***** WARNING ***** |
| |
| The following formats are preliminary and |
| are included for purposes of explanation only.|
| In particular, new RR types will be added, |
| and the size, position, and encoding of |
| fields are subject to change. |
| |
+-----------------------------------------------+
+-----------------------------------------------+ | | | ***** WARNING ***** | | | | The following formats are preliminary and | | are included for purposes of explanation only.| | In particular, new RR types will be added, | | and the size, position, and encoding of | | fields are subject to change. | | | +-----------------------------------------------+
A RDATA format
A RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ADDRESS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
ADDRESS - A 32 bit ARPA internet address
ADDRESS - A 32 bit ARPA internet address
Hosts that have multiple ARPA Internet addresses will have
multiple A records.
Hosts that have multiple ARPA Internet addresses will have multiple A records.
A records cause no additional section processing. The RDATA
section of an A line in a master file is an Internet address
expressed as four decimal numbers separated by dots without any
imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6").
A records cause no additional section processing. The RDATA section of an A line in a master file is an Internet address expressed as four decimal numbers separated by dots without any imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6").
Mockapetris [Page 67]
Mockapetris [Page 67]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC 883 November 1983 Domain Names - Implementation and Specification
WKS RDATA format
WKS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ADDRESS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PROTOCOL | | +--+--+--+--+--+--+--+--+ | | | / <BIT MAP> / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
where:
ADDRESS - An 32 bit ARPA Internet address
ADDRESS - An 32 bit ARPA Internet address
PROTOCOL - An 8 bit IP protocol number
プロトコル--8ビットのIPプロトコル番号
<BIT MAP> - A variable length bit map. The bit map must be a
multiple of 8 bits long.
<BIT MAP>--可変長ビットマップ。 長い間、ビットマップは8ビットの倍数であるに違いありません。
The WKS record is used to describe the well known services
supported by a particular protocol on a particular internet
address. The PROTOCOL field specifies an IP protocol number, and
the bit map has one bit per port of the specified protocol. The
first bit corresponds to port 0, the second to port 1, etc. If
less than 256 bits are present, the remainder are assumed to be
zero. The appropriate values for ports and protocols are
specified in [13].
WKS記録は、特定のインターネットアドレスで特定のプロトコルで後押しされているよく知られているサービスについて説明するのに使用されます。 プロトコル分野はIPプロトコル番号を指定します、そして、ビットマップで、指定されたプロトコルのポート単位で1つに噛み付きます。 最初のビットは、0、1などを移植する2番目を移植するために対応しています。 256ビット未満が存在しているなら、残りはゼロであると思われます。 ポートとプロトコルのための適切な値は[13]で指定されます。
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP
port 25 (SMTP). If this bit is set, a SMTP server should be
listening on TCP port 25; if zero, SMTP service is not supported
on the specified address.
例えば、プロトコルがTCP(6)と等しいなら、26番目のビットはTCPポート25(SMTP)に対応しています。 このビットが設定されるなら、SMTPサーバーはTCPポート25の上で聴かれるべきです。 ゼロであるなら、SMTPサービスは指定されたアドレスでサポートされません。
The anticipated use of WKS RRs is to provide availability
information for servers for TCP and UDP. If a server supports
both TCP and UDP, or has multiple Internet addresses, then
multiple WKS RRs are used.
WKS RRsの予期された使用はサーバのための有用性情報をTCPとUDPに供給することです。 サーバに、TCPとUDPの両方をサポートするか、または複数のインターネット・アドレスがあるなら、複数のWKS RRsが使用されています。
WKS RRs cause no additional section processing. The RDATA section
of a WKS record consists of a decimal protocol number followed by
mnemonic identifiers which specify bits to be set to 1.
WKS RRsはどんな追加セクション処理も引き起こしません。 WKS記録のRDATA部は1に設定されるためにビットを指定する簡略記憶識別子があとに続いた10進プロトコル番号から成ります。
IN-ADDR special domain
IN-ADDRの特別なドメイン
The ARPA internet uses a special domain to support gateway
location and ARPA Internet address to host mapping. The intent of
this domain is to allow queries to locate all gateways on a
ARPAインターネットは、ゲートウェイ位置とARPAがインターネット・アドレスであるとホストマッピングにサポートするのに特別なドメインを使用します。 このドメインの意図は質問がすべてのゲートウェイのaに場所を見つけるのを許容することです。
Mockapetris [Page 68]
Mockapetris[68ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
particular network in the ARPA Internet, and also to provide a
guaranteed method to perform host address to host name mapping.
事項は中でARPAインターネットをネットワークでつなぎます、そして、また、ホスティングするホスト・アドレスを実行する保証されたメソッドを提供するのはマッピングを命名します。
Note that both of these services are similar to functions that
could be performed by inverse queries; the difference is that this
part of the domain name space is structured according to address,
and hence can guarantee that the appropriate data can be located
without an exhaustive search of the domain space. It is
anticipated that the special tree will be used by ARPA Internet
resolvers for all gateway location services, but that address to
name resolution will be performed by first trying the inverse
query on the local name server database followed by a query in the
special space if the inverse query fails.
これらのサービスの両方が逆さの質問で実行されるかもしれない機能と同様であることに注意してください。 違いはドメイン名スペースのこの部分が、アドレスによって構造化されて、したがって、ドメインスペースの徹底的な検索なしで適切なデータの見つけることができるのを保証できるということです。 逆さの質問が失敗するなら特別なスペースでの質問があとに続いた地方名サーバデータベースで逆さの質問を試みながら、特別な木がすべてのゲートウェイ位置のサービスにARPAインターネットレゾルバによって使用されますが、名前解決へのアドレスが最初にによって実行されると予期されます。
The domain is a top level domain called IN-ADDR whose substructure
follows the ARPA Internet addressing structure.
ドメインは基礎が構造を扱うARPAインターネットに続くIN-ADDRと呼ばれるトップ・レベル・ドメインです。
Domain names in the IN-ADDR domain are defined to have up to four
labels in addition to the IN-ADDR label. Each label is a
character string which expresses a decimal value in the range
0-255 (with leading zeros omitted except in the case of a zero
octet which is represented by a single zero). These labels
correspond to the 4 octets of an ARPA Internet address.
IN-ADDRドメインのドメイン名は、IN-ADDRラベルに加えて最大4個のラベルを持つために定義されます。 各ラベルは範囲0-255(先行ゼロで、ゼロに関するケースを除いて、ただ一つのゼロで表される八重奏を省略します)でデシマル値を言い表す文字列です。 これらのラベルはARPAインターネット・アドレスの4つの八重奏に対応しています。
Host addresses are represented by domain names that have all four
labels specified. Thus data for ARPA Internet address 10.2.0.52
is located at domain name 52.0.2.10.IN-ADDR. The reversal, though
awkward to read, allows zones to follow the natural grouping of
hosts within networks. For example, 10.IN-ADDR can be a zone
containing data for the ARPANET, while 26.IN-ADDR can be a
separate zone for MILNET. Address nodes are used to hold pointers
to primary host names in the normal domain space.
ホスト・アドレスはすべての4個のラベルを指定するドメイン名によって表されます。 その結果、ARPAインターネット・アドレスのためのデータ、10.2、.0、.52、読むために反転の、そして、もっとも、扱いにくいドメイン名52.0.2.10.IN-ADDRに位置していて、ネットワークの中でホストの自然な組分けに続くのをゾーンを許容します。 例えば、10.IN-ADDRはアルパネットのためのデータを含むゾーンであるかもしれません、26.IN-ADDRがMILNETのための別々のゾーンであるかもしれませんが。 アドレスノードは、正常なドメインスペースで一次ホスト名に指針を保つのに使用されます。
Network addresses correspond to some of the non-terminal nodes in
the IN-ADDR tree, since ARPA Internet network numbers are either
1, 2, or 3 octets. Network nodes are used to hold pointers to
primary host names (which happen to be gateways) in the normal
domain space. Since a gateway is, by definition, on more than one
network, it will typically have two or more network nodes that
point at the gateway. Gateways will also have host level pointers
at their fully qualified addresses.
ネットワーク・アドレスはIN-ADDR木でいくつかの非端末ノードに一致しています、ARPAインターネットネットワーク・ナンバーが1、2、または3つの八重奏であるので。 ネットワーク・ノードは、正常なドメインスペースで一次ホスト名(たまたまゲートウェイである)に指針を保つのに使用されます。 ゲートウェイが定義上1つ以上のネットワークにあるので、それには、ゲートウェイを指し示す2つ以上のネットワーク・ノードが通常あるでしょう。 また、ゲートウェイで、ホストはそれらの完全に適切なアドレスで指針を平らにするでしょう。
Both the gateway pointers at network nodes and the normal host
pointers at full address nodes use the PTR RR to point back to the
primary domain names of the corresponding hosts.
ネットワーク・ノードの両方のゲートウェイ指針といっぱいのアドレスノードの正常なホスト指針は、対応するホストの一次的領域名を示すのにPTR RRを使用します。
For example, part of the IN-ADDR domain will contain information
about the ISI to MILNET and MIT gateways, and hosts F.ISI.ARPA and
MULTICS.MIT.ARPA. Assuming that ISI gateway has addresses
例えば、IN-ADDRドメインの一部がホストのMILNET、MITゲートウェイ、F. ISI.ARPA、およびMULTICS.MIT.ARPAにISIの情報を含むでしょう。 ISIゲートウェイにはアドレスがあると仮定します。
Mockapetris [Page 69]
Mockapetris[69ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
10.2.0.22 and 26.0.0.103, and a name MILNET-GW.ISI.ARPA, and the
MIT gateway has addresses 10.0.0.77 and 18.10.0.4 and a name
GW.MIT.ARPA, the domain database would contain:
10.2.0.22、26.0に、.103、およびaがMILNET-GW.ISI.ARPAと命名して、MITゲートウェイが持っている.0が10.0に.0を扱う、GW.MIT.ARPA、ドメインデータベースがそうする18.10の.0の.77、.4、およびa名は以下を含んでいます。
10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
10.IN-ADDR PTR IN GW.MIT.ARPA
18.IN-ADDR PTR IN GW.MIT.ARPA
26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
22.0.2.10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
103.0.0.26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
77.0.0.10.IN-ADDR PTR IN GW.MIT.ARPA
4.0.10.18.IN-ADDR PTR IN GW.MIT.ARPA
52.0.2.10.IN-ADDR PTR IN F.ISI.ARPA
6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA
ADDR PTRの10. MULTICS.MIT.ARPAのF.ISI.ARPA 6.0.0.10.IN-ADDR PTRのGW.MIT.ARPA 52.0.2.10.IN-ADDR PTRのGW.MIT.ARPA 4.0.10.18.IN-ADDR PTRのMILNET-GW.ISI.ARPA 77.0.0.10.IN-ADDR PTRのMILNET-GW.ISI.ARPA 103.0.0.26.IN-ADDR PTRのMILNET-GW.ISI.ARPA 22.0.2.10.IN-ADDR PTRのGW.MIT.ARPA 26.IN-ADDR PTRのGW.MIT.ARPA 18.IN-ADDR PTRのMILNET-GW.ISI.ARPA 10.IN-ADDR PTRで
Thus a program which wanted to locate gateways on net 10 would
originate a query of the form QTYPE=PTR, QCLASS=IN,
QNAME=10.IN-ADDR. It would receive two RRs in response:
したがって、ネットの10にゲートウェイの場所を見つけたがっていたプログラムはフォームQTYPE=PTR、QCLASS=INの質問を溯源するでしょう、QNAME=10.IN-ADDR。応答で2RRsを受けるでしょう:
10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
10.IN-ADDR PTR IN GW.MIT.ARPA
ADDR PTRの10. GW.MIT.ARPAのMILNET-GW.ISI.ARPA 10.IN-ADDR PTRで
The program could then originate QTYPE=A, QCLASS=IN queries for
MILNET-GW.ISI.ARPA and GW.MIT.ARPA to discover the ARPA Internet
addresses of these gateways.
そして、MILNET-GW.ISI.ARPAとGW.MIT.ARPAがこれらのゲートウェイのARPAインターネット・アドレスを発見するように、プログラムはQTYPE=A、QCLASS=IN質問を溯源するかもしれません。
A resolver which wanted to find the host name corresponding to
ARPA Internet host address 10.0.0.6 might first try an inverse
query on the local name server, but find that this information
wasn't available. It could then try a query of the form
QTYPE=PTR, QCLASS=IN, QNAME=6.0.0.10.IN-ADDR, and would receive:
ARPAインターネットホスト・アドレスに対応しながらホストが名義であることがわかりたがっていたレゾルバ、10.0、.0、.6、最初に地方名サーバで逆さの質問を試みますが、この情報が利用可能でなかったのがわかるかもしれません。 それは、次に、フォームQTYPE=PTR、QCLASS=IN QNAME=6.0.0.10.IN-ADDRの質問を試みることができて、受信されるでしょう:
6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA
ADDR PTRの6.0.0.10. MULTICS.MIT.ARPAで
Several cautions apply to the use of these services:
いくつかの警告がこれらのサービスの使用に適用されます:
Since the IN-ADDR special domain and the normal domain for a
particular host or gateway will be in different zones, the
possibility exists that that the data may be inconsistent.
以来、IN-ADDRの特別なドメインと特定のホストかゲートウェイへの正常なドメインはデータがそれであるかもしれないのにもかかわらずの、異なったゾーンでは、可能性が存在しているということであるために矛盾していた状態で望んでいます。
Gateways will often have two names in separate domains, only
one of which can be primary.
ゲートウェイは別々のドメインにしばしば2つの名前を持つでしょう。その1つだけがプライマリである場合があります。
Systems that use the domain database to initialize their
routing tables must start with enough gateway information to
guarantee that they can access the appropriate name server.
それらの経路指定テーブルを初期化するのにドメインデータベースを使用するシステムは適切なネームサーバにアクセスできるのを保証できるくらいのゲートウェイ情報から始まらなければなりません。
The gateway data only reflects the existence of a gateway in a
ゲートウェイデータはaのゲートウェイの存在を反映するだけです。
Mockapetris [Page 70]
Mockapetris[70ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
manner equivalent to the current HOSTS.TXT file. It doesn't
replace the dynamic availability information from GGP or EGP.
現在のHOSTS.TXTファイルに同等な方法。 それはGGPかEGPからダイナミックな有用性情報を置き換えません。
Mockapetris [Page 71]
Mockapetris[71ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 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 - Concepts and Facilities,"
RFC 882, USC/Information Sciences Institute, November 1983.
[14] P.Mockapetris、「ドメイン名--、概念とFacilities、」、RFC882、USC/情報Sciences Institute、11月1983日
Mockapetris [Page 72]
Mockapetris[72ページ]
RFC 883 November 1983
Domain Names - Implementation and Specification
RFC883 1983年11月ドメイン名--実装と仕様
INDEX
インデックス
* usage........................................................37, 57
* 用法…37, 57
A RDATA format.....................................................67
RDATA形式…67
byte order..........................................................6
バイトオーダー…6
cache queue....................................................35, 42 character case..................................................7, 31 CLASS...........................................................9, 58 completion.........................................................19 compression........................................................31 CNAME RR...........................................................60
待ち行列をキャッシュしてください…35、42キャラクタ事件…7、31のクラス…9、58完成…19圧縮…31CNAME RR…60
header format......................................................26 HINFO RR...........................................................60
ヘッダー形式…26HINFO RR…60
include files......................................................43 inverse queries....................................................17
ファイルを含めてください…43 逆さの質問…17
mailbox names......................................................53 master files.......................................................43 MB RR..............................................................61 MD RR..............................................................61 message format.....................................................13 MF RR..............................................................62 MG RR..............................................................62 MINFO RR...........................................................63 MR RR..............................................................63
メールボックス名…53の基本ファイル…43MBのRR…61 MD RR…61 メッセージ形式…13 mf RR…62mgのRR…62MINFO RR…63 RRさん…63
NULL RR............................................................64 NS RR..............................................................64
ヌルRR…64ナノ秒のRR…64
PTR RR.........................................................64, 69
PTR RR…64, 69
QCLASS.............................................................58 QTYPE..............................................................57 queries (standard).................................................15
QCLASS…58QTYPE…57 質問します(標準の)。15
recursive service..................................................24 RR format..........................................................59
再帰的なサービス…24 RR形式…59
SOA RR.............................................................65 Special domains....................................................68
SOA RR…65の特別なドメイン…68
TYPE...............................................................57
タイプしてください…57
WKS type RR........................................................68
WKSはRRをタイプします…68
Mockapetris [Page 73]
Mockapetris[73ページ]
一覧
スポンサーリンク
