この文書はRFC1035の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group P. Mockapetris
Request for Comments: 1035 ISI
November 1987
Obsoletes: RFCs 882, 883, 973
DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
ドメイン名 − 実装と仕様書
1. STATUS OF THIS MEMO
1. このメモの状態
This RFC describes the details of the domain system and protocol, and
assumes that the reader is familiar with the concepts discussed in a
companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
このRFCはドメインシステムとプロトコルの細部を記述し、読者が関連するRFC
「ドメイン名 − コンセプトと機能」[RFC-1034]で論じたコンセプトに精通して
いると想定します。
The domain system is a mixture of functions and data types which are an
official protocol and functions and data types which are still
experimental. Since the domain system is intentionally extensible, new
data types and experimental behavior should always be expected in parts
of the system beyond the official protocol. The official protocol parts
include standard queries, responses and the Internet class RR data
formats (e.g., host addresses). Since the previous RFC set, several
definitions have changed, so some previous definitions are obsolete.
ドメインシステムは公式のプロトコルと機能とまだ実験的なデータタイプの混合
です。ドメインシステムが意図的に拡大可能であるので、新しいデータタイプと
実験的な行動が常に公式のプロトコルの範囲外で行わてると予想されるべきです。
公式のプロトコルの部分は標準的な問合せ、回答とインターネットクラス資源レ
コードデータフォーマット（例えば、ホストアドレス）を含みます。前のRFC群
から、いくつかの定義が変化したので、いくつかの前の定義が時代遅れです。
Experimental or obsolete features are clearly marked in these RFCs, and
such information should be used with caution.
これらのRFCの実験的か時代遅れの機能は明確にマークを付けたので、このよう
な情報に注意すべきです。
The reader is especially cautioned not to depend on the values which
appear in examples to be current or complete, since their purpose is
primarily pedagogical. Distribution of this memo is unlimited.
例で示している値が教育的な目的の値なので、読者はこの値が現在の値もしくは
正しい値と思わないように注意してください。このメモの配布は無制限です。
Table of Contents
目次
1. STATUS OF THIS MEMO
このメモの状態
2. INTRODUCTION
はじめに
2.1. Overview
概要
2.2. Common configurations
普通の設定
2.3. Conventions
取り決め
2.3.1. Preferred name syntax
望ましい名前文法
2.3.2. Data Transmission Order
データ転送順序
2.3.3. Character Case
文字
2.3.4. Size limits
サイズの上限
3. DOMAIN NAME SPACE AND RR DEFINITIONS
ドメイン名空間とＲＲ定義
3.1. Name space definitions
名前空間定義
3.2. RR definitions
資源レコード定義
3.2.1. Format
フォーマット
3.2.2. TYPE values
種別値
3.2.3. QTYPE values
問合せ種別
3.2.4. CLASS values
クラス値
3.2.5. QCLASS values
問合せクラス値
3.3. Standard RRs
標準資源レコード
3.3.1. CNAME RDATA format
標準名資源データフォーマット
3.3.2. HINFO RDATA format
ホスト情報資源レコードフォーマット
3.3.3. MB RDATA format (EXPERIMENTAL)
メールボックス資源データフォーマット（実験的）
3.3.4. MD RDATA format (Obsolete)
MD資源データフォーマット（時代遅れ）
3.3.5. MF RDATA format (Obsolete)
MF資源データフォーマット（時代遅れ）
3.3.6. MG RDATA format (EXPERIMENTAL)
メールグループ資源データフォーマット（実験的）
3.3.7. MINFO RDATA format (EXPERIMENTAL)
メール情報資源レコードフォーマット（実験的）
3.3.8. MR RDATA format (EXPERIMENTAL)
メール改名資源データフォーマット（実験的）
3.3.9. MX RDATA format
メール交換資源データフォーマット
3.3.10. NULL RDATA format (EXPERIMENTAL)
ヌル資源データフォーマット（実験的）
3.3.11. NS RDATA format
ネームサーバ資源データフォーマット
3.3.12. PTR RDATA format
ポインタ資源データフォーマット
3.3.13. SOA RDATA format
SOA資源データ
3.3.14. TXT RDATA format
テキスト資源データフォーマット
3.4. ARPA Internet specific RRs
インターネット特有資源レコード
3.4.1. A RDATA format
アドレス資源データフォーマット
3.4.2. WKS RDATA format
仕事資源データフォーマット
3.5. IN-ADDR.ARPA domain
IN-ADDR.ARPAドメイン
3.6. Defining new types, classes, and special namespaces
新しいタイプ、クラスと特別な名前空間の定義
4. MESSAGES
メッセージ
4.1. Format
フォーマット
4.1.1. Header section format
ヘッダ部フォーマット
4.1.2. Question section format
質問部フォーマット
4.1.3. Resource record format
資源レコードフォーマット
4.1.4. Message compression
メッセージ圧縮
4.2. Transport
転送
4.2.1. UDP usage
ＵＤＰ使用法
4.2.2. TCP usage
ＴＣＰ使用法
5. MASTER FILES
マスターファイル
5.1. Format
フォーマット
5.2. Use of master files to define zones
ゾーンを定義するためのマスターファイルの使用
5.3. Master file example
マスターファイルの例
6. NAME SERVER IMPLEMENTATION
ネームサーバー情報
6.1. Architecture
構造
6.1.1. Control
制御
6.1.2. Database
データベース
6.1.3. Time
時間
6.2. Standard query processing
標準問合せ処理
6.3. Zone refresh and reload processing
ゾーン更新と読み直し処理
6.4. Inverse queries (Optional)
逆問合せ（任意)
6.4.1. The contents of inverse queries and responses
逆の質問と回答の中身
6.4.2. Inverse query and response example
逆問合せと回答例
6.4.3. Inverse query processing
逆問合せ処理
6.5. Completion queries and responses
完成問合せと回答
7. RESOLVER IMPLEMENTATION
リゾルバの実装
7.1. Transforming a user request into a query
ユーザ要求の質問への変換
7.2. Sending the queries
問合せの送信
7.3. Processing responses
処理回答
7.4. Using the cache
キャッシュの使用
8. MAIL SUPPORT
メールサポート
8.1. Mail exchange binding
メール交換割付
8.2. Mailbox binding (Experimental)
メールボックス割付(実験的）
9. REFERENCES and BIBLIOGRAPHY
参考文献と文献目録
Index
索引
2. INTRODUCTION
2. はじめに
2.1. Overview
2.1. 概要
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; the resolver is
responsible for hiding the distribution of data among name servers from
the user.
ユーザーの見地から、ドメイン名はリゾルバと呼ばれるローカルなエージェント
の引数に利用でき、リゾルバはドメイン名と関連した情報を返します。ユーザー
が特定のドメイン名と関連したホストアドレスあるいはメール情報を求めるかも
しれません。ユーザーに特定のタイプの情報を求めることができるように、ドメ
イン名と共に適切な問合せタイプがでリゾルバに渡されます。ユーザーとってド
メインツリーはひとつの情報空間です；リゾルバはユーザーからネームサーバー
間のデータ分散を隠す責任があります。
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 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.
リゾルバから見ると、ドメイン空間を構成するデータベースは様々なネームサー
バーに分配されます。ドメイン空間の異なる部分が異なるネームサーバーに登録
されます、特定のデータ項目は重複して２あるいはそれ以上のネームサーバーに
登録されます。リゾルバは少なくとも１つのネームサーバーの知識を持って起動
します。リゾルバがユーザーの問合せを処理する時、周知のネームサーバーに情
報をを求めます；回答で、リゾルバは望ましい情報か他のネームサーバの紹介を
受けます。これらの紹介を使って、リゾルバは他のネームサーバーとネームサー
バーの内容を学習します。リゾルバはドメイン空間の分散を扱い、他のサーバー
の重複するデータベースを調べることで、ネームサーバーの障害に影響を避ける
責任があります。
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
"pruned" 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.
ネームサーバーが２種類のデータを処理します。データの最初の種類はゾーンと
呼ばれます；各ゾーンがドメイン空間の特定の「切り取った」部分木の完全なデー
タベースです。このデータは正式と呼ばれます。ネームサーバーがそのゾーンが
最新か確認するため周期的に調査を行い、もし最新でなければローカルに又は他
のネームサーバに登録された最新のゾーンコピーを得ます。２番目の種類のデー
タはローカルリゾルバによって得られたキャッシュデータです。このデータは不
完全かもしれませんが、ローカルでないデータに繰り返しアクセスする際に、検
索プロセスの効率を改善します。キャッシュデータがタイムアウトメカニズムに
よって捨てられます。
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.
この機能構造はユーザ・インタフェースと障害回復とリゾルバの分散の問題を分
離し、ネームサーバーのデータベース更新とリフレッシュ問題を離します。
2.2. Common configurations
2.2. 普通の設定
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 | |Foreign |
| User |-------------->| |---------|->| Name |
| Program | | Resolver | | | Server |
| ユーザプ|<--------------| リゾルバ |<--------|--|遠方ネー|
| ログラム| user responses| |responses| |ムサーバ|
+---------+ ユーザ回答 +----------+回答 | +--------+
| A |
cache additions | | references |
キャッシュ追加 V | 参照 |
+----------+ |
| cache | |
|キャッシュ| |
+----------+ |
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 cache 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 the local cache.
ユーザープログラムがリゾルバを通してドメイン名スペースと相互作用します；
ユーザー問合せとユーザー回答のフォーマットはホストとオペレーティング・シ
ステムに固有です。ユーザー問合せは典型的にオペレーティングシステムコール
電話で、リゾルバとキャッシュはホストオペレーティングシステムの一部でしょ
う。能力の低いホストがリゾルバをそのサービスを必要とするすべてのプログラ
ムでリンクされるサブルーチンとして実装するかもしれません。遠方のネームサー
バーへの問合せとローカルなキャッシュで得た情報で、リゾルバがユーザーの問
合せに答えます。
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.
リゾルバがあるユーザー問合せに答えるためにいくつかの異なるネームサーバー
に問合せをしなければならないかもしれなく、ユーザー問合せの解決がいくつか
のネットワークアクセスとある程度の時間が必要なことに注意してください。他
のネームサーバーへの問合せと対応する回答は標準フォーマットがこのメモで記
述され、データグラムになるでしょう。
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:
その能力によって、ネームサーバーは専用マシン上の単体プログラムだったり、
大きなタイムシェアリングホスト上のプロセスの１つだったりします。単純な設
定が以下のとおりです：
Local Host ローカルホスト | Foreign 遠方
|
+---------+ |
/ /| |
+---------+ | +----------+回答 | +--------+
| | | | |responses| |Foreign |
| Master | | | Name |---------|->|Resolver|
| files |-------------->| Server | | | 遠方 |
| マスター| | | ネーム |<--------|--|リゾルバ|
| ファイル|/ | サーバー| queries | +--------+
+---------+ +----------+ 問合せ |
Here a primary 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.
ここでプライマリネームサーバーがローカルファイルシステムからマスターファ
イルを読込んで１つ以上のゾーンの情報を得て、遠方のリゾルバから来るゾーン
に関する問合せに答えます。
The DNS requires that all zones be redundantly supported by more than
one name server. Designated secondary servers can acquire zones and
check for updates from the primary server using the zone transfer
protocol of the DNS. This configuration is shown below:
ＤＮＳはすべてのゾーンが１つ以上のネームサーバーで維持することを要求しま
す。選定されたセカンダリサーバーがＤＮＳのゾーン転送プロトコルを使い、主
要なサーバーからゾーンを得て更新したか調べることができます。この設定は以
下のとおりです：
Local Host ローカルホスト | Foreign 遠方
|
+---------+ |
/ /| |
+---------+ | +----------+ 回答 | +--------+
| | | | | responses | |Foreign |
| Master | | | Name |--------------|->|Resolver|
| files |--------->| Server | | |遠方 |
| マスター| | | ネーム |<-------------|--|リゾルバ|
| ファイル|/ | サーバー| queries | +--------+
+---------+ +----------+ 問合せ |
A |メンテナンス問合せ | +--------+
| |maintenance queries | |Foreign |
| +--------------------|->| Name |
| | | Server |
+------------------------|--|遠方ネー|
maintenance responses | |ムサーバ|
メンテナンス回答 | +--------+
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.
この設定でネームサーバーはゾーンのコピーを得るか、あるいは既存のコピーに
変更がないことを調べるため遠方のネームサーバーに周期的に仮想回路を確立し
ます。これらの維持活動のために送るメッセージの問合せと回答は以下と同じ形
ですが、メッセージのシーケンスは幾分異なっています。
The information flow in a host that supports all aspects of the domain
name system is shown below:
すべてのドメインネームシステムをサポートするホストでの情報フローは以下に
示されます：
Local Host ローカルホスト | Foreign 遠方
|
+---------+ ユーザ問合せ +----------+問合せ | +--------+
| | user queries | |queries | |Foreign |
| User |-------------->| |---------|->| Name |
| Program | | Resolver | | | Server |
| ユーザプ|<--------------| リゾルバ |<--------|--|遠方ネー|
| ログラム| user responses| |responses| |ムサーバ|
+---------+ ユーザ回答 +----------+回答 | +--------+
| A |
cache additions | | references |
キャッシュ追加 V | 参照 |
+-----------------+ |
| Shared database | |
| 共有データベース| |
+-----------------+ |
更新 A | 参照 |
+---------+ refreshes | | references |
/ /| | V |
+---------+ | +----------+ 回答 | +--------+
| | | | | responses | |Foreign |
| Master | | | Name |--------------|->|Resolver|
| files |--------->| Server | | |遠方 |
| マスター| | | ネーム |<-------------|--|リゾルバ|
| ファイル|/ | サーバー| queries | +--------+
+---------+ +----------+ 問合せ |
A |メンテナンス問合せ | +--------+
| |maintenance queries | |Foreign |
| +--------------------|->| Name |
| | | Server |
+------------------------|--|遠方ネー|
maintenance responses | |ムサーバ|
メンテナンス回答 | +--------+
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 implementor.
共有データベースはローカルネームサーバとリゾルバのドメイン空間データを持
ちます。共有データベースの中身は一般的にはネームサーバの周期的な更新動作
で維持される正式なデータと、前のリゾルバの問合せのデータキャッシュの混合
です。ドメインデータの構造とネームサーバとリゾルバの間の同期の必要性はこ
のデータベースの一般的な特徴を暗示します、しかし実際のフォーマットはロー
カルな実装者次第です。
Information flow can also be tailored so that a group of hosts act
together to optimize activities. Sometimes this is done to offload less
capable hosts so that they do not have to implement a full resolver.
This can be appropriate for PCs or hosts which want to minimize the
amount of new network code which is required. This scheme can also
allow a group of hosts can share a small number of caches rather than
maintaining a large number of separate caches, on the premise that the
centralized caches will have a higher hit ratio. In either case,
resolvers are replaced with stub resolvers which act as front ends to
resolvers located in a recursive server in one or more name servers
known to perform that service:
情報フローが共同で動作するホストの活動を最適化するよう仕立て直しできます。
時には、能力の低いホストが完全なリゾルバを実装しなくてもいいように変更を
します。これはＰＣや必要な新しいネットワークコードの量を最小にすることを
望むホストに適切であり得ます。この変更は同じくホストグループが、集中形の
キャッシュがより高いヒット率を持つだろうという前提で、多数の個別のキャッ
シュを作るのではなく小数のキャッシュを共有するために使うことができます。
いずれの場合でも、リゾルバがスタブリゾルバで置き換えられ、スタブリゾルバ
は切り株リゾルバが１つ以上のサービスを行うネームサーバーの内の再帰問合せ
サーバーのフロントエンドの役を務めます：
Local Hosts ローカルホスト | Foreign 遠方
|
+---------+ 回答 |
| Stub | responses |
| Resolver|<--------------------+ |
| スタブ | | |
| リゾルバ|----------------+ | |
+---------+ recursive | | |
queries | | |
再帰問合せ V | |
+---------+ recursive +--------------+問合せ | +--------+
| Stub | queries | |queries | |Foreign |
| Resolver|---------->| Recursive |---------|->| Name |
| スタブ | | Server | | | Server |
| リゾルバ|<----------| 再帰 |<--------|--|遠隔ネー|
+---------+ responses | サーバー |responses| |ムサーバ|
回答 +--------------+回答 | +--------+
|Central cache| |
|集中キャッシュ| |
+--------------+ |
In any case, note that domain components are always replicated for
reliability whenever possible.
どんなケースででも、ドメイン構成要素が、可能である時はいつでも、常に信頼
性のために複製されることを注意を払ってください。
2.3. Conventions
2.3. 取り決め
The domain system has several conventions dealing with low-level, but
fundamental, issues. While the implementor is free to violate these
conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
ALL behavior observed from other hosts.
ドメインシステムは低レベルであるが、基本的な、問題を扱っているいくつかの
取り決めを持ちます。実装者が、自分自身のシステム内でこれらの取り決めに破
ることが自由ですが、これらのすべての行動での取り決めが他のホストから観察
されるのに気付かなくてはなりません。
2.3.1. Preferred name syntax
2.3.1. 望ましい名前文法
The DNS specifications attempt to be as general as possible in the rules
for constructing domain names. The idea is that the name of any
existing object can be expressed as a domain name with minimal changes.
ＤＮＳ仕様はドメイン名を組み立てる規則について可能な限り一般的であるよう
に試みます。考え方はどんな既存のオブジェクト名も最小の変更でドメイン名と
して表すことができるということです。
However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.
しかしながら、オブジェクトのドメイン名を割り当てる時、慎重なユーザーは、
ドメインシステムの規則と、既存の明示的もしくは暗黙の計画による規則の、両
方の規則を満たすようにオブジェクトの名前を選ぶでしょう。
For example, when naming a mail domain, the user should satisfy both the
rules of this memo and those in RFC-822. When creating a new host name,
the old rules for HOSTS.TXT should be followed. This avoids problems
when old software is converted to use domain names.
例えば、メールドメインを名づけるときに、ユーザーはRFC-822とこのメモの両
方の規則を満たすべきです。新しいホスト名を作る時HOSTS.TXTでの古い規則に
従うべきです。これは、古いソフトウェアをドメイン名を使うように変更する際、
トラブルを避けます。
The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET).
次の文法はドメイン名を使う多くのアプリケーションでの問題を少なくするでしょ
う（例えば、メール、TELNET）。
<domain> ::= <subdomain> | " "
<domain> ::= ドットで区切った<label>の列か、空文字列
<subdomain> ::= <label> | <subdomain> "." <label>
<subdomain> ::= ドットで区切った<label>の列
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<label> ::= アルファベットで始まり、アルファベットか数字かハイフンが続き、
アルファベットか数字で終わる文字列
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<ldh-str> ::= アルファベットか数字かハイフンからなる文字列
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig-hyp> ::= アルファベットか数字かハイフン
<let-dig> ::= <letter> | <digit>
<let-dig> ::= アルファベットか数字
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<letter> ::= 大文字のAからZと小文字のaからzの52個の文字のどれか
<digit> ::= any one of the ten digits 0 through 9
<digit> ::= 0から9の10個の数字のどれか
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.
ラベルはARPANET ホスト名の規則に従わなければなりません。これらは文字から
始まり、文字か数字で終わり、途中は文字と数字とハイフンからなります。長さ
についても同じくいくらかの制限があります。ラベルは６３の文字以下に違いあ
りません。
For example, the following strings identify hosts in the Internet:
例えば、次の文字列はインターネットでホストを識別します：
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
2.3.2. Data Transmission Order
2.3.2. データ転送順序
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
オクテットが数値を示すときは図の最も左のビットが最上位ビットです。つまり
０と示されるビットが最上位ビットです。例えば、次の図は数値１７０（10進数）
を表します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
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.
同様に、マルチオクテットのフィールドが数値を示すときは、ビットフィールド
全体の最も左が最上位ビットです。複数オクテットの数値が転送されるとき、最
上位オクテットが最初に転送されます。
2.3.3. Character Case
2.3.3. 文字
For all parts of the DNS that are part of the official protocol, all
comparisons between character strings (e.g., labels, domain names, etc.)
are done in a case-insensitive manner. At present, this rule is in
force throughout the domain system without exception. However, future
additions beyond current usage may need to use the full binary octet
capabilities in names, so attempts to store domain names in 7-bit ASCII
or use of special bytes to terminate labels, etc., should be avoided.
公式のプロトコルの一部であるＤＮＳのすべての部分で、すべての文字列（例え
ば、ラベル、ドメイン名など）の比較は大文字小文字の違いを無視する方法でさ
れます。目下、この規則は例外なくドメインシステムで効果をもっています。し
かし、将来完全な２進数のオクテット能力を使う必要があるかもしれません、そ
のためドメイン名を７ビットのASCIIや端末ラベルなどの特殊なバイトにするこ
とは避けられるべきです。
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 RRs are stored in a database, one at x.y and
one at X.Y, they are actually stored at the same place in the database,
and hence only one casing would be preserved. 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.
データがドメインシステムに参加する時、その元の大文字小文字は、可能な限り、
維持されるべきです。ある特定の状況でこれはできません。例えば、もし２つの
ＲＲ（資源レコード）がデータベースに登録され、一方がx.yで、他方がX.Yであ
れば、この２つはデータベースの同じ場所に置かれ、一方だけが保存されるでしょ
う。基本的な規則で大文字小文字はデータがデータベースで構造を定義する時に
のみ無視され、２つの名前が大文字小文字の違いを無視する方法で比較される時
同じとみなされます。
Loss of case sensitive data must be minimized. Thus while data for x.y
and X.Y may both be stored under a single location x.y or X.Y, data for
a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In
general, this preserves the case of the first label of a domain name,
but forces standardization of interior node labels.
大文字小文字の違いを識別するデータの損失は最小にしなければなりません。こ
のため、x.yとX.Yのデータが共にひとつの場所x.yあるいはX.Yに保管されても、
a.xとB.Xのデータが決してA.xやA.Xやb.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.
データをドメインデータベースの中に入力するシステム管理者が、もし彼らのシ
ステムが大文字小文字の違いを識別するなら、大文字小文字を一貫した方法でド
メインシステムに供給するデータ表現を注意すべきです。ドメインシステムでの
データ分配システムは一貫した表示が維持されることを保証するでしょう。
2.3.4. Size limits
2.3.4. サイズの上限
Various objects and parameters in the DNS have size limits. They are
listed below. Some could be easily changed, others are more
fundamental.
ＤＮＳの種々なオブジェクトがパラメータサイズの限界を持っています。それら
は以下にリストアップされます。いくらかが容易に変えられますが、他のものは
より基本的です。
labels 63 octets or less
ラベル ６３オクテット以下
names 255 octets or less
名前 ２５５オクテット以下
TTL positive values of a signed 32 bit number.
生存時間 符号付３２ビット整数の正の値
UDP messages 512 octets or less
ＵＤＰメッセージ ５１２オクテット以下
3. DOMAIN NAME SPACE AND RR DEFINITIONS
3. ドメイン名空間とＲＲ定義
3.1. Name space definitions
3.1. 名前空間定義
Domain names in 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 domain name is terminated by a length byte of zero. The
high order two bits of every length octet must be zero, and the
remaining six bits of the length field limit the label to 63 octets or
less.
メッセージでのドメイン名がラベルの連続として表現されます。各ラベルが１オ
クテットの長さフィールドと、それに続く長さの数だけのオクテットで表されま
す。すべてのドメイン名がルートのゼロのラベルで終わるので、ドメイン名がゼ
ロの長さバイトで終わります。すべての長さオクテットの上位２ビットはゼロで
あるり、そして長さフィールドの残り６ビットがラベルの長さを６３オクテット
以下に制限します。
To simplify implementations, the total length of a domain name (i.e.,
label octets and label length octets) is restricted to 255 octets or
less.
実装を単純化するために、ドメイン名（すなわち、ラベルオクテットとラベル長
オクテット）の全体の長さは２５５オクテット以下に制限されます。
Although labels can contain any 8 bit values in octets that make up a
label, it is strongly recommended that labels follow the preferred
syntax described elsewhere in 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), assuming ASCII
with zero parity. Non-alphabetic codes must match exactly.
ラベルはラベルの各オクテットにどんな８ビット値も含むことができるが、この
メモで他のところに記述されている望ましい文法従うことが強く推薦され、望ま
しい文法は既存のホストネーミング規定と両立できます。ネームサーバとリゾル
バが大文字小文字の違いを無視する方法でラベルを比較しなくてはならならい（
すなわち、A=a)、ゼロパリティでASCIIを想定します。アルファベットでないコー
ドが正確に一致しなくてはなりません。
3.2. RR definitions
3.2. ＲＲ定義
3.2.1. Format
3.2.1. フォーマット
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 /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NAME an owner name, i.e., the name of the node to which this
resource record pertains.
名前 所有者名、すなわち、この資源レコードに関係するノードの
名前。
TYPE two octets containing one of the RR TYPE codes.
種別 ＲＲタイプコードを含む２オクテット。
CLASS two octets containing one of the RR CLASS codes.
クラス ＲＲクラスコードを含む２オクテット。
TTL a 32 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.
生存時間 ３２ビット符号付整数です。資源レコードの情報源を再び調べ
られるまで、キャッシュできる時間隔を指定します。ゼロの値
がＲＲが現在進行中の処理にだけ使用でき、キャッシュすべき
ではないことを意味します。例えばSOAレコードがキャッシュ
を禁止するために常にゼロTTLで配布されます。ゼロ値が同じ
く非常に揮発しやすいデータで使うことができます。
訳注：RFC2181でＳＯＡのＴＴＬはゼロでなければならないと規定しています。
また、ＴＴＬの値は０以上２１４７４８３６４７以下で、有効桁数３１ビット
と規定しています。
RDLENGTH an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
資源データ長 資源データフィールドのオクテット単位の長さを指定する符号
なし１６ビット整数。
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.
資源データ リソースを記述するオクテット単位の可変長ストリング。この
情報のフォーマットは資源レコードのタイプとクラスに従って
変化します。
3.2.2. TYPE values
3.2.2. 種別値
TYPE fields are used in resource records. Note that these types are a
subset of QTYPEs.
種別フィールドが資源レコードで使われます。これらの種別が質問種別の一部で
あることを注意を払ってください。
TYPE value and meaning
種別 値と意味
A 1 a host address
A 1 ホストアドレス
NS 2 an authoritative name server
NS 2 正式なネームサーバ
MD 3 a mail destination (Obsolete - use MX)
MD 3 メール宛先（時代遅れ、MXを使うこと）
MF 4 a mail forwarder (Obsolete - use MX)
MF 4 メール転送（時代遅れ、MXを使うこと）
CNAME 5 the canonical name for an alias
CNAME 5 別名に対する標準名
SOA 6 marks the start of a zone of authority
SOA 6 正式ゾーンの開始表示
MB 7 a mailbox domain name (EXPERIMENTAL)
MB 7 メールボックスドメイン名（実験的）
MG 8 a mail group member (EXPERIMENTAL)
MG 8 メールグループメンバー（実験的）
MR 9 a mail rename domain name (EXPERIMENTAL)
MR 9 メール改名ドメイン名（実験的）
NULL 10 a null RR (EXPERIMENTAL)
NULL 10 ヌル資源レコード（実験的）
WKS 11 a well known service description
WKS 11 周知のサービス記述
PTR 12 a domain name pointer
PTR 12 ドメイン名ポインタ
HINFO 13 host information
HINFO 13 ホスト情報
MINFO 14 mailbox or mail list information
MINFO 14 メールボックスあるいはメールリスト情報
MX 15 mail exchange
MX 15 メール交換
TXT 16 text strings
TXT 16 テキスト文字列
3.2.3. QTYPE values
3.2.3. 問合せ種別
QTYPE fields appear in the question part of a query. QTYPES are a
superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
following QTYPEs are defined:
問合せ種別フィールドが問合せの質問部分に現われます。問合せ種別は種別値の
全てを含む集合で、それ故すべての種別がが正しい問合せ種別です。さらに次の
問合せ種別が定義されます：
AXFR 252 A request for a transfer of an entire zone
AXFR 252 全部のゾーンの転送の要求
MAILB 253 A request for mailbox-related records (MB, MG or MR)
MAILB 253 メールボックス関連のレコード（MBやMGやMR）の要求
MAILA 254 A request for mail agent RRs (Obsolete - see MX)
MAILA 254 メール代理人資源レコードの要求（時代遅れ、MX参照）
* 255 A request for all records
* 255 すべてのレコードの要求
3.2.4. CLASS values
3.2.4. クラス値
CLASS fields appear in resource records. The following CLASS mnemonics
and values are defined:
クラスフィールドが資源レコードに現われます。次のクラス名称と値が定義され
ます：
IN 1 the Internet
IN 1 インターネット
CS 2 the CSNET class (Obsolete - used only for examples in
some obsolete RFCs)
CS 2 CSNET クラス（時代遅れ−ある時代遅れのRFCで例にだけ使
われた）
CH 3 the CHAOS class
CH 3 カオスクラス
HS 4 Hesiod [Dyer 87]
HS 4 ヘシオド[Dyer 87]
3.2.5. QCLASS values
3.2.5. 問合せクラス値
QCLASS fields appear in the question section of a query. QCLASS values
are a superset of CLASS values; every CLASS is a valid QCLASS. In
addition to CLASS values, the following QCLASSes are defined:
問合せクラスフィールドが問合せの質問部に現われます。問合せクラス値はクラ
ス値の全ての値を含む集合です；すべてのクラスが正当な問合せクラスです。ク
ラス値のほかに、次の問合せクラス値が定義されます：
* 255 any class
* 255 全てのクラス
3.3. Standard RRs
3.3. 標準資源レコード
The following RR definitions are expected to occur, at least
potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
will be used in all classes, and have the same format in all classes.
Because their RDATA format is known, all domain names in the RDATA
section of these RRs may be compressed.
次の資源レコード定義は、少なくとも潜在的に、すべてのクラスで存在すること
を期待されます。特にNSとSOAとCNAMEとPTRはすべてのクラスで使われ、すべて
のクラスで同じフォーマットを持つでしょう。これらの資源データフォーマット
が知られているから、すべてのこれらの資源レコードの資源データ部でドメイン
名は圧縮されるでしょう。
<domain-name> is a domain name represented as a series of labels, and
terminated by a label with zero length. <character-string> is a single
length octet followed by that number of characters. <character-string>
is treated as binary information, and can be up to 256 characters in
length (including the length octet).
<domain-name>ラベルが連続し長さゼロのラベルで終了する形式のドメイン名で
す。<character-string>１オクテットの長さと、その長さの数の文字からなりま
す。<character-string>がバイナリ情報と扱われて、（長さオクテットを含めて）
最大２５６の文字です。
3.3.1. CNAME RDATA format
3.3.1. 標準名資源データフォーマット
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CNAME A <domain-name> which specifies the canonical or primary
name for the owner. The owner name is an alias.
標準名 所有者の標準名または第１名を指定する<domain-name>。所有者
名は別名です。
CNAME RRs cause no additional section processing, but name servers may
choose to restart the query at the canonical name in certain cases. See
the description of name server logic in [RFC-1034] for details.
標準名資源レコードが追加部の処理を起こしませんが、ネームサーバーがある
特定の場合に標準名で問合せを再開してもよいです。ネームサーバーのロジッ
クは[RFC-1034]の記述を見てください。
3.3.2. HINFO RDATA format
3.3.2. ホスト情報資源レコードフォーマット
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CPU /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ OS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CPU A <character-string> which specifies the CPU type.
CPU ＣＰＵ種別を指定する<character-string>。
OS A <character-string> which specifies the operating
system type.
OS オペレーティングシステム種別を指定する<character-string>。
Standard values for CPU and OS can be found in [RFC-1010].
ＣＰＵとOSの標準値が[RFC-1010]にあります。
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レコードがホストの一般的な情報を得るにに使われます。主な使用は、同
じ種類のマシンの間やオペレーティングシステム間で特別な手順を使用できる
FTPのようなプロトコルのためです。
3.3.3. MB RDATA format (EXPERIMENTAL)
3.3.3. メールボックス資源データフォーマット（実験的）
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MADNAME A <domain-name> which specifies a host which has the
specified mailbox.
MADNAME 指定されたメールボックスを持つホストを指定する
<domain-name>。
MB records cause additional section processing which looks up an A type
RRs corresponding to MADNAME.
MBレコードがMADNAMEに対応したアドレス種別資源レコードの追加部の処理をし
ます。
3.3.4. MD RDATA format (Obsolete)
3.3.4. MD資源データフォーマット（時代遅れ）
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MADNAME A <domain-name> which specifies a host which has a mail
agent for the domain which should be able to deliver
mail for the domain.
MADNAME このドメインにメールを配達できるエージェントの持つホスト
を指定する<domain-name>。
MD records cause additional section processing which looks up an A type
record corresponding to MADNAME.
MDレコードがMADNAMEに対応したアドレス種別資源レコードの追加部の処理をし
ます。
MD is obsolete. See the definition of MX and [RFC-974] for details of
the new scheme. The recommended policy for dealing with MD RRs found in
a master file is to reject them, or to convert them to MX RRs with a
preference of 0.
MDは時代遅れです。新しい案の詳細はMXの定義と[RFC-974]を見てください。マ
スターファイルにあるMD資源レコードに対する推薦される手段は、それを拒絶す
るか、優先度０でMX資源レコードを生成するかです。
3.3.5. MF RDATA format (Obsolete)
3.3.5. MF資源データフォーマット（時代遅れ）
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MADNAME A <domain-name> which specifies a host which has a mail
agent for the domain which will accept mail for
forwarding to the domain.
MADNAME このドメインにメールを転送できるエージェントの持つホスト
を指定する<domain-name>。
MF records cause additional section processing which looks up an A type
record corresponding to MADNAME.
MFレコードがMADNAMEに対応したアドレス種別資源レコードの追加部の処理をし
ます。
MF is obsolete. See the definition of MX and [RFC-974] for details ofw
the new scheme. The recommended policy for dealing with MD RRs found in
a master file is to reject them, or to convert them to MX RRs with a
preference of 10.
MDは時代遅れです。新しい案の詳細はMXの定義と[RFC-974]を見てください。マ
スターファイルにあるMD資源レコードに対する推薦される手段は、それを拒絶す
るか、優先度１０でMX資源レコードを生成するかです。
3.3.6. MG RDATA format (EXPERIMENTAL)
3.3.6. メールグループ資源データフォーマット（実験的）
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MGMNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MGMNAME A <domain-name> which specifies a mailbox which is a
member of the mail group specified by the domain name.
メールグループメンバー名 ドメイン名で指定されるメールグループのメンバー
のメールボックスを指定する<domain-name>。
MG records cause no additional section processing.
メールグループレコードが追加部の処理を起こしません。
3.3.7. MINFO RDATA format (EXPERIMENTAL)
3.3.7. メール情報資源レコードフォーマット（実験的）
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RMAILBX /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EMAILBX /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
RMAILBX A <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.
責任者メールボックス メーリングリストあるいはメールボックスの責任者を指
定する<domain-name>。もしこのドメイン名がルートを示すな
ら、MINFO資源レコードの所有者は自分自身が責任者です。多
くの既存のメーリングリストでメーリングリストXの責任者に
X-requestを使う、例えばMsgroupの責任者がMsgroup-request
を使うことに注意してください。このフィールドはより一般的
なメカニズムを供給します。
EMAILBX A <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資源レコードの所有者に指定されたメーリングリス
トやメールボックスに関するエラーメッセージを受け取るメー
ルボックスを指定<domain-name>（推薦されているERRORS-TO:
フィールドに類似しています）。もしこのドメイン名がルート
を示すなら、エラーがメッセージの送信者に返されるべきです。
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.
MINFOレコードが追加部の処理を起こしません。このレコードを単純なメールボッ
クスと関連づけることができるが、それらは通常メーリングリストで使われます。
3.3.8. MR RDATA format (EXPERIMENTAL)
3.3.8. メール改名資源データフォーマット
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NEWNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NEWNAME A <domain-name> which specifies a mailbox which is the
proper rename of the specified mailbox.
新しい名前 指定したメールボックスの適切な改名のメールボックスを指定
する<domain-name>。
MR records cause no additional section processing. The main use for MR
is as a forwarding entry for a user who has moved to a different
mailbox.
MRレコードが追加の部処理を起こしません。MRの主な用途は異なるメールボック
スに移転したユーザーの転送項目としてです。
3.3.9. MX RDATA format
3.3.9. メール交換資源データフォーマット
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGE /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PREFERENCE A 16 bit integer which specifies the preference given to
this RR among others at the same owner. Lower values
are preferred.
優先度 同じ所有者の資源レコードの中で、この資源レコードに与えら
れた優先度を示す１６ビットの整数。より低い値が優先されま
す。
EXCHANGE A <domain-name> which specifies a host willing to act as
a mail exchange for the owner name.
交換 所有者名のためにメール交換をするホストを示す<domain-name>。
MX records cause type A additional section processing for the host
specified by EXCHANGE. The use of MX RRs is explained in detail in
[RFC-974].
メール交換レコードが交換で指定されたホストのアドレス種別の追加部の処理を
もたらします。MX資源レコードの使い方は[RFC-974]で詳細で説明されます。
3.3.10. NULL RDATA format (EXPERIMENTAL)
3.3.10. ヌル資源データフォーマット（実験的）
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ <anything> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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. NULLs are used as placeholders in some
experimental extensions of the DNS.
ヌルレコードが追加部の処理を起こしません。ヌル資源レコードがマスターファ
イルで許されません。ヌルはあるＤＮＳの実験的な拡張で場所確保に用いられま
す。
3.3.11. NS RDATA format
3.3.11. ネームサーバ資源データフォーマット
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NSDNAME A <domain-name> which specifies a host which should be
authoritative for the specified class and domain.
ネームサーバードメイン名 指定されたクラスとドメインの正式なホストを指定
する<domain-name>。
NS records cause both the usual additional section processing to locate
a type A record, and, when used in a referral, a special search of the
zone in which they reside for glue information.
ネームサーバレコードが通常のアドレス種別レコードの追加部の処理と、参照に
使われるときは、接着剤情報に存在するゾーン検索を、発生させます。
The NS RR states that the named host should be expected to have a zone
starting at owner name of the specified class. Note that the class may
not indicate the protocol family which should be used to communicate
with the host, although it is typically a strong hint. For example,
hosts which are name servers for either Internet (IN) or Hesiod (HS)
class information are normally queried using IN class protocols.
ネームサーバ資源レコードは指定したホストが、指定クラスの所有者名で始まる
ゾーンを持つことが期待される、と明示します。クラスは一般に強いヒントにな
るが、ホストと通信に使われるべきプロトコルファミリーを示さないことに注意
してください。例えば、インターネット（IN）やヘシオド（HS）クラス情報のネー
ムサーバであるホストが通常インターネットクラスプロトコルで質問されます。
3.3.12. PTR RDATA format
3.3.12. ポインタ資源データフォーマット
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ PTRDNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PTRDNAME A <domain-name> which points to some location in the
domain name space.
ポインタドメイン名 ドメイン名空間である場所を指し示す<domain-name>。
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. See the
description of the IN-ADDR.ARPA domain for an example.
PTRレコードが追加の部処理を起こしません。この資源レコードはドメイン空間
のある他の場所を示すのに使われます。これらのレコードは単純なデータで、
CNAMEの行うような特別な処理を暗示せず、別名を識別します。例として
IN-ADDR.ARPAドメインの記述を参照してください。
3.3.13. SOA RDATA format
3.3.13. SOA資源データ
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SERIAL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| REFRESH |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RETRY |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EXPIRE |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MINIMUM |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MNAME The <domain-name> of the name server that was the
original or primary source of data for this zone.
マスター名 このゾーンデータの起源または第１の情報源であるネームサー
バの<domain-name>。
RNAME A <domain-name> which specifies the mailbox of the
person responsible for this zone.
責任者名 このゾーンの担当者のメールボックスを指定する<domain-name>。
SERIAL The unsigned 32 bit version number of the original copy
of the zone. Zone transfers preserve this value. This
value wraps and should be compared using sequence space
arithmetic.
シリアル番号 符号なし３２ビットのゾーンの原本のバージョン番号。ゾーン
転送がこの値を維持します。この値は巡回していて、連続空間
演算を使って比較されるべきです。
REFRESH A 32 bit time interval before the zone should be
refreshed.
リフレッシュ ３２ビットのゾーンリフレッシュの間隔。
RETRY A 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.
期限切れ ３２ビットのゾーンが正式でなくなる上限時間。
MINIMUM The unsigned 32 bit minimum TTL field that should be
exported with any RR from this zone.
最小値 このゾーンの資源レコードを送信する場合に指定される最小の
生存時間を示す３２ビット符号なし数。
SOA records cause no additional section processing.
SOAレコードが追加部の処理を起こしません。
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. Note that this use of
MINIMUM should occur when the RRs are copied into the response and not
when the zone is loaded from a master file or via a zone transfer. The
reason for this provison is to allow future dynamic update facilities to
change the SOA RR with known semantics.
これらのフィールドの大部分がネームサーバ保守運用にだけ関係があります。し
かし、最小限はゾーンから資源レコードを返す全ての問合せ操作で使われます。
資源レコードが問合せの回答で送られる時に常に生存時間フィールドに資源レコー
ドの最大値と適切なSOAの最小値が設定されます。つまり最小値はゾーン内の全
ての資源レコードの生存時間フィールドの下限です。この最小値は資源レコード
が回答に設定される時に使用され、マスターファイルからゾーンを読み込んだり、
ゾーン転送をする際に使用されないことに注意してください。この準備の理由は
将来のダイナミック更新機能で既存のSOA資源レコードの意味を変えれるように
です。
3.3.14. TXT RDATA format
3.3.14. テキスト資源データフォーマット
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ TXT-DATA /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
TXT-DATA One or more <character-string>s.
テキストデータ １つ以上の<character-string>
TXT RRs are used to hold descriptive text. The semantics of the text
depends on the domain where it is found.
テキスト資源レコードはが記述したテキストを持つために使われます。テキスト
の意味はそれが存在するドメインに頼ります。
3.4. Internet specific RRs
3.4. インターネット特有資源レコード
3.4.1. A RDATA format
3.4.1. アドレス資源データフォーマット
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS A 32 bit Internet address.
アドレス ３２ビットインターネットアドレス
Hosts that have multiple 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").
Ａレコードが追加部の処理を起こしません。マスターファイル内のアドレス行の
資源データは部は、スペース無しドットで分割された４つの１０進数で表される
インターネットアドレスです（例えば"10.2.0.52"や"192.0.5.6"）。
3.4.2. WKS RDATA format
3.4.2. 仕事資源データフォーマット
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS An 32 bit Internet address
アドレス ３２ビットインターネットアドレス
PROTOCOL An 8 bit IP protocol number
プロトコル ８ビットＩＰプロトコル番号
<BIT MAP> A variable length bit map. The bit map must be a
multiple of 8 bits long.
ビットマップ 可変長ビットマップ。ビットマップは８ビットの倍数です。
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 the bit map does not include a bit for a
protocol of interest, that bit is assumed zero. The appropriate values
and mnemonics for ports and protocols are specified in [RFC-1010].
仕事レコードは特定のインターネットアドレス上で特定のプロトコルのサポート
する既知サービスを記述するために使います。プロトコルフィールドはＩＰプロ
トコル番号を指定します、ビットマップは指定されたプロトコルのポート毎に１
ビットを持ちます。最初のビットはポート０、２番目はポート１などと対応しま
す。 もしビットマップが知りたいプロトコルのビットを含まないなら、その
ビットはゼロであると思われます。適切な値とポートの名称とプロトコルは
[RFC-1010]で指定されます。
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.
例えば、もしプロトコル＝ＴＣＰ（６）なら、第２６番目のビットはＴＣＰポー
ト２５（ＳＭＴＰ）に対応します。もしこのビットがセットされるなら、ＳＭＴ
ＰサーバーがＴＣＰポート２５上で待っているべきです；もしゼロならＳＭＴＰ
サービスが指定されたアドレス上でサポートされません。
The purpose 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 cause no additional section processing.
仕事資源レコードが追加部の処理を起こしません。
In master files, both ports and protocols are expressed using mnemonics
or decimal numbers.
マスターファイルで、ポートとプロトコル両方が名称か１０進数で表現されます。
3.5. IN-ADDR.ARPA domain
3.5. IN-ADDR.ARPAドメイン
The Internet uses a special domain to support gateway location and
Internet address to host mapping. Other classes may employ a similar
strategy in other domains. The intent of this domain is to provide a
guaranteed method to perform host address to host name mapping, and to
facilitate queries to locate all gateways on a particular network in the
Internet.
インターネットはゲートウェイの場所とインターネットアドレスからホストへの
変換に特別なドメインを使います。他のクラスが他のドメインで類似の方法を使
うかもしれません。このドメインはホストアドレスからホスト名へ変換する保証
された方法の提供と、インターネットの特定のネットワークの上のすべてのゲー
トウェイの場所を突き止める問合せを容易にすることえお、を意図します。
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.
これらのサービスの両方が逆問合せで実行できる機能に類似していることに注意
してください；相違はドメイン名空間のこの部分がアドレスに従って構造化され
ていて、それ故ドメイン空間の徹底的な探索なしで適切なデータの場所を保証す
ることができるということです。
The domain begins at IN-ADDR.ARPA and has a substructure which follows
the Internet addressing structure.
ドメインはIN-ADDR.ARPAから始まり、インターネットアドレス構造に従う構造を
もちます。
Domain names in the IN-ADDR.ARPA domain are defined to have up to four
labels in addition to the IN-ADDR.ARPA suffix. Each label represents
one octet of an Internet address, and is expressed as a character string
for 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).
IN-ADDR.ARPAドメインのドメイン名はIN-ADDR.ARPA以外に４つのラベルを持ちま
す。各ラベルがインターネットアドレスの１オクテットを表し、０から２５５の
範囲の１０進数値の文字列で表されます。（頭のゼロは省略されます、ゼロの値
のオクテットは例外で１つのゼロで表します）。
Host addresses are represented by domain names that have all four labels
specified. Thus data for Internet address 10.2.0.52 is located at
domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to
read, allows zones to be delegated which are exactly one network of
address space. For example, 10.IN-ADDR.ARPA can be a zone containing
data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
MILNET. Address nodes are used to hold pointers to primary host names
in the normal domain space.
ホストアドレスが４つのラベルすべてが指定されたドメイン名で表されます。例
えばインターネットアドレス10.2.0.52のデータはドメイン名52.0.2.10.IN-ADDR.ARPA
にあります。逆順は読みにくいですが、正確にアドレス空間で１つのネットワー
クが委任されるゾーンを許します。例えば、10.IN-ADDR.ARPAはARPANETのデータ
を含むゾーンで、26.IN-ADDR.ARPAはMILNETのための別のゾーンです。アドレス
ノードが標準ドメイン空間の基本ホスト名へのポインタを持つために使われます。
Network numbers correspond to some non-terminal nodes at various depths
in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
2, or 3 octets. Network nodes are used to hold pointers to the primary
host names of gateways attached to that network. Since a gateway is, by
definition, on more than one network, it will typically have two or more
network nodes which point at it. Gateways will also have host level
pointers at their fully qualified addresses.
インターネットネットワーク番号は１か２か３オクテットなので、ネットワーク
番号がIN-ADDR.ARPAドメインの種々な深さのある終わりでないノードに対応しま
す。ネットワークノードがそのネットワークのゲートウェイの基本ホスト名への
ポインタを持つために使われます。ゲートウェイが定義上ネットワークに１つ以
上あるので、一般に２つ以上のネットワークノードがここに位置するでしょう。
ゲートウェイが完全に指定されたアドレスにもホストレベルポインタを持つで
しょう。
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.
ネットワークノードのゲートウェイポインタと完全なアドレスノードの一般ホス
トの両方で対応するホストの基本ドメインを示すポインタ資源レコードを使いま
す。
For example, the IN-ADDR.ARPA domain will contain information about the
ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI
gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
and a name GW.LCS.MIT.EDU, the domain database would contain:
例えば、IN-ADDR.ARPAドメインが、ネット１０とネット２６の間のＩＳＩゲート
ウェイの情報と、ネット１０とＭＩＴのネット１８の間のＭＩＴのゲートウェイ
の情報と、とホストA.ISI.EDUとMULTICS.MIT.EDUの情報をもつとします。ＩＳＩ
ゲートウェイのアドレスが10.2.0.22と26.0.0.103で名前がMILNET- GW.ISI.EDU
で、ＭＩＴゲートウェイが10.0.0.77と18.10.0.4で名前がGW.LCS.MIT.EDUとする
と、ドメインデータベースが以下の名前を含みます：。
10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
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.ARPA. It
would receive two RRs in response:
ネット１０のゲートウェイの場所を知りたいプログラムが問合せ種別=ポインタ、
問合せクラス=インターネット、問合せ名=10.IN-ADDR.ARPA.の問合せをするでしょ
う。それは回答で２つの資源レコードを受け取るでしょう：
10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
these gateways.
プログラムはゲートウェイMILNET-GW.ISI.EDU.とゲートウェイGW.LCS.MIT.EDU.
のインターネットアドレスを発見するために、それから問合せ種別=アドレス、
問合せタイプ=インターネットの問合せができます。
A resolver which wanted to find the host name corresponding to Internet
host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
インターネットホストアドレス10.0.0.6に対応するホスト名を望むリゾルバが問
合せ種別=ポインタ、問合せクラス=インターネット、問合せ名=6.0.0.10.IN-ADDR.ARPA
の問合せをし、以下を受信するでしょう：
6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
Several cautions apply to the use of these services:
いくつかの警告がこれらのサービスの使用に当てはまります：
- Since the IN-ADDR.ARPA 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.ARPA特別ドメインと通常のドメイン
が異なったゾーンにあるので、データが矛盾している可能性があります。
- Gateways will often have two names in separate domains, only
one of which can be primary.
- ゲートウェイがしばしば別のドメインの２つの名前を持つが１つだけが基
本です。
- 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
manner equivalent to the current HOSTS.TXT file. It doesn't
replace the dynamic availability information from GGP or EGP.
- ゲートウェイデータは現在のHOSTS.TXTファイルと同じ方法でゲートウェイ
の存在を反映するだけです。それはＧＧＰやＥＧＰからダイナミックに有
効な情報を取りません。
3.6. Defining new types, classes, and special namespaces
3.6. 新しいタイプ、クラスと特別な名前空間の定義
The previously defined types and classes are the ones in use as of the
date of this memo. New definitions should be expected. This section
makes some recommendations to designers considering additions to the
existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
forum where general discussion of design issues takes place.
前に定義された種別とクラスはこのメモの日付の時点で使用中のものです。新し
い定義が予想されるべきです。この章は既存機能に追加を考えるデザイナーにあ
る推薦をします。メーリングリストNAMEDROPPERS@SRI-NIC.ARPAはデザイン問題
の一般的な論議が起きるフォーラムです。
In general, a new type is appropriate when new information is to be
added to the database about an existing object, or we need new data
formats for some totally new object. Designers should attempt to define
types and their RDATA formats that are generally applicable to all
classes, and which avoid duplication of information. New classes are
appropriate when the DNS is to be used for a new protocol, etc which
requires new class-specific data formats, or when a copy of the existing
name space is desired, but a separate management domain is necessary.
一般に、既存のオブジェクトの新しい情報をデータベースに追加する際や、いず
れかのまったく新しいオブジェクトに新しいデータフォーマットを必要とする時、
適切です。デザイナーが、一般にすべてのクラスに適用でき、情報の重複を避け
るように、種別と資源データフォーマットを定義しようと試みるべきです。新し
いクラスが、ＤＮＳが新しいクラス特定のデータフォーマットを必要とする新し
いプロトコルなどで使われか、既存の名前空間の複製が必要で別の管理ドメイン
が必要な時、新しい種別が適切です。
New types and classes need mnemonics for master files; the format of the
master files requires that the mnemonics for type and class be disjoint.
新しい種別とクラスがマスターファイルのために覚え易い名称を必要とします；
マスターファイルのフォーマットは種別とクラスの名称が共通要素を持たないこ
とを要求します。
TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
respectively.
種別とクラス値はそれぞれ問合せ種別と問合せクラスの適切な部分集合に違いあ
りません。
The present system uses multiple RRs to represent multiple values of a
type rather than storing multiple values in the RDATA section of a
single RR. This is less efficient for most applications, but does keep
RRs shorter. The multiple RRs assumption is incorporated in some
experimental work on dynamic update methods.
現在のシステムは多数の値をひとつの資源レコードの資源データにしまうより、
むしろ多数の種別の値を表すために多数の資源レコードを使います。これはたい
ていのアプリケーションで効率が低いですが、資源レコードをより短い状態に保
ちます。多数の資源レコードの仮定はいずれダイナミック更新方法の実験的な仕
事に取り入れられます。
The present system attempts to minimize the duplication of data in the
database in order to insure consistency. Thus, in order to find the
address of the host for a mail exchange, you map the mail domain name to
a host name, then the host name to addresses, rather than a direct
mapping to host address. This approach is preferred because it avoids
the opportunity for inconsistency.
現在のシステムは一貫性を保障するためデータベースでデータの複製を最小にし
ようと試みます。そのためメール交換のためのホストアドレスを見つけるために、
メールドメイン名をアドレスに直接変換するのではなく、メールドメイン名をホ
スト名に、ホスト名をホストアドレスに変換します。この方法は不整合の可能性
を避けるので好まれます。
In defining a new type of data, multiple RR types should not be used to
create an ordering between entries or express different formats for
equivalent bindings, instead this information should be carried in the
body of the RR and a single type used. This policy avoids problems with
caching multiple types and defining QTYPEs to match multiple types.
新しいタイプのデータを定義する際に、多数の資源レコード種別を項目間に順序
をつけたり、同じ結び付けの異なるフォーマットを表現するために使われるべき
ではありません。この情報は資源レコード本体で運ばれ、１つの種別が使われる
べきです。この方針は多数の種別のキャッシュと多数の種別に対応する巣問合せ
種別を定義する問題を避けます。
For example, the original form of mail exchange binding used two RR
types one to represent a "closer" exchange (MD) and one to represent a
"less close" exchange (MF). The difficulty is that the presence of one
RR type in a cache doesn't convey any information about the other
because the query which acquired the cached information might have used
a QTYPE of MF, MD, or MAILA (which matched both). The redesigned
service used a single type (MX) with a "preference" value in the RDATA
section which can order different RRs. However, if any MX RRs are found
in the cache, then all should be there.
例えば、メール交換の元々の書式は２つの資源レコードを使用し、１つが「近い」
(MD)を表し、もう１つが「近くない」(MF)を表していました。困ったことは、
キャッシュ情報を得た問合せがMFかMDかMAILA（両方に一致）のどれもありえる
ので、キャッシュ上の１つの資源レコード種別の存在が他の資源レコードの存在
に関する情報を持たないことです。変更されたデザインは、異なる資源レコード
間に順序付けができるように資源データ内に優先度をもつ、１つの種別(MX)を使
いうことです。もしMX資源レコードがキャッシュにあるなら、全ての資源レコー
ドがキャッシュにあるでしょう。
4. MESSAGES
4. メッセージ
4.1. Format
4.1. フォーマット
All communications inside of the domain protocol are carried in a single
format called a message. The top level format of message is divided
into 5 sections (some of which are empty in certain cases) shown below:
すべてのドメインプロトコルの内部の通信はメッセージと呼ばれるひとつのフォー
マットで運ばれます。メッセージの最上位フォーマットは以下の５つの部分に分け
られます（ある部分はある場合は空です）：
+---------------------+
| Header ヘッダ |
+---------------------+
| Question 質問 | the question for the name server
+---------------------+ ネームサーバへの問合せ
| Answer 回答 | RRs answering the question
+---------------------+ 問合せの回答の資源レコード
| Authority 正式 | RRs pointing toward an authority
+---------------------+ 正式なネームサーバを示す資源レコード
| Additional 追加 | RRs holding additional information
+---------------------+ 追加情報を持つ資源レコード
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 or a response, a standard query or some
other opcode, etc.
ヘッダ部は常に存在しています。ヘッダーはどの部分が存在するか、メッセージ
が問合せか回答か、標準的な問合せか他の処理かを明示するフィールドを含みま
す。
The names of the sections after the header are derived from their use in
standard queries. 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). 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 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.
ヘッダーの後の部分の名前は標準的な質問での使い方から命名されました。質問
部はネームサーバへの質問を記述するフィールドを含んでいます。これらのフィー
ルドは問合せ種別（QTYPE）、問合せクラス（QCLASS）と問合せドメイン名
（QNAME）です。後の３つの部分は同じフォーマットを持ちます：資源レコード
のリストで空の事もあります。回答部は問合せに答える資源レコードを含みます；
正式部は正式なネームサーバーを示すポイントの資源レコードを含みます、追加
レコード部は問合せに関連しているが、問合せの厳密な答えではない資源レコー
ドを含みます。
4.1.1. Header section format
4.1.1. ヘッダ部フォーマット
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| Z | 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
the corresponding reply and can be used by the requester
to match up replies to outstanding queries.
識別子 問合せを生成するプログラムによって割当てられた１６ビット
識別子。この識別子は対応する応答にコピーされ、応答を未解
決の質問に対応させるのに使用できます。
QR A one bit field that specifies whether this message is a
query (0), or a response (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:
オペレーションコード このメッセージの質問の種類を示す４ビットフィールド。
この値は質問の作成者につけられ、回答にコピーされます。値
は以下です：
0 a standard query (QUERY)
0 標準的な質問（質問）
1 an inverse query (IQUERY)
1 逆問合せ（逆質問）
2 a server status request (STATUS)
2 サーバ状態要求（状態）
3-15 reserved for future use
3-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 question section.
AA 正式な解答−このビットは回答で効力があり、応答したネーム
サーバが質問部のドメイン名の正式なネームサーバかを示しま
す。
Note that the contents of the answer section may have
multiple owner names because of aliases. The AA bit
corresponds to the name which matches the query name, or
the first owner name in the answer section.
解答部の中身が別名のために多数の所有者名を持つかもしれな
いことに注意してください。ＡＡビットは質問の名前か、解答
部の最初の所有者名に対応します。
TC TrunCation - specifies that this message was truncated
due to length greater than that permitted on the
transmission channel.
TC 切り落し−伝送チャンネル上に最大長よりメッセージが長くなっ
たためこのメッセージが切り落とされたことを示します。
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 再帰要望−このビットは問合せで設定され、回答にコピーされ
ます。もし再帰要望が設定されるなら、ネームサーバに再帰問
合せを要望します。再帰回答のサポートは任意です。
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 再帰可能−これは回答で設定かクリアされ、ネームサーバが再
帰的問合せをサポートするかどうかを示します。
Z Reserved for future use. Must be zero in all queries
and responses.
Z 未来の使用のために予約されました。すべての質問と回答でゼ
ロであるに違いありません。
RCODE Response code - this 4 bit field is set as part of
responses. The values have the following
interpretation:
回答コード 回答コード−この４ビットフィールドは回答の一部として設定
されます。値の解釈は次の通りです：。
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 名前エラー−回答の正式なネームサーバーだ
け意味があります、このコードは問合せで参
照されたドメイン名が存在しないことを示し
ます。
4 Not Implemented - The name server does
not support the requested kind of query.
4 実装されていない−ネームサーバは求められ
た種類の問合せをサポートしません。
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 requester,
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 質問部の項目数を示す符号なし１６ビットの整数
ANCOUNT an unsigned 16 bit integer specifying the number of
resource records in the answer section.
ANCOUNT 回答部の項目数を示す符号なし１６ビットの整数
NSCOUNT an unsigned 16 bit integer specifying the number of name
server resource records in the authority records
section.
NSCOUNT 正式部のネームサーバ資源レコードの数を示す符号なし１６
ビットの整数
ARCOUNT an unsigned 16 bit integer specifying the number of
resource records in the additional records section.
ARCOUNT 追加部の項目数を示す符号なし１６ビットの整数
4.1.2. Question section format
4.1.2. 質問部フォーマット
The question section is used to carry the "question" in most queries,
i.e., the parameters that define what is being asked. The section
contains QDCOUNT (usually 1) entries, each of the following format:
質問部はたいていの問合せで「質問」を運ぶために使われ、何が尋ねられている
かを定義します。この部分はQDCOUNT個（通常１個）の項目を含み、次のフォー
マットです：
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 domain name represented as a sequence of labels, where
each label consists of a length octet followed by that
number of octets. The domain name terminates with the
zero length octet for the null label of the root. Note
that this field may be an odd number of octets; no
padding is used.
質問名 ラベルの連続であるドメイン名、各ラベルがオクテット数と、
その数だけのオクテットから成り立ちます。ドメイン名はルー
トを意味するゼロの値の長さオクテットで終わります。この
フィールドが奇数オクテットかもしれないことに注意してくだ
さい；２オクテット単位にするなどの位置調整がされません。
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.
問合せ種別 問合せ種別を指定する２オクテットコード。このフィールドは
全ての正式な種別値か、複数の資源レコードに一致するある一
般的な種別値です。
QCLASS a two octet code that specifies the class of the query.
For example, the QCLASS field is IN for the Internet.
問合せクラス 質問クラスを示す２オクテットコード。例えばインターネット
では質問クラスフィールドにINが設定される。
4.1.3. Resource record format
4.1.3. 資源レコードフォーマット
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 資源データ /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NAME a domain name to which this resource record pertains.
名前 この資源レコードに関係するドメイン名。
TYPE two octets containing one of the RR type codes. This
field specifies the meaning of the data in the RDATA
field.
種別 １つの資源レコード種別を含む２オクテット。このフィールド
は資源データフィールドのデータの意味を指定します。
CLASS two octets which specify the class of the data in the
RDATA field.
クラス 源データフィールドのデータのクラスを指定する２オクテット。
TTL a 32 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.
生存時間 資源レコードをキャッシュしておいてよい時間（秒単位）を示
す３２ビット符号なし整数。ゼロの値が資源レコードがいま進
行中の処理でのみ使えて、キャッシュすべきではないことを意
味します。
RDLENGTH an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
資源データ長 資源データフィールドのオクテット単位の長さを指定する符号
なしの１６ビットの整数。
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.
資源データ 資源を記述するオクテット単位の可変長文字列。この情報の
フォーマットは資源レコード種別とクラスに従って変化します。
例えば、もし種別がＡでクラスがINなら資源データフィールド
は４オクテットのARPAインターネットアドレスである。
4.1.4. Message compression
4.1.4. メッセージ圧縮
In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain names in a
message. In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurance
of the same name.
メッセージの大きさを減らすために、ドメインシステムはメッセージのドメイン
名の反復を削除する圧縮案を利用します。この案で終わりが同じドメイン名やラ
ベルのリストで、ドメイン名の終わりが同じ名前の対応する部分へのポインタで
置き換えられます。
The pointer takes the form of a two octet sequence:
ポインターは２オクテット形式をとります：
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET オフセット |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The first two bits are ones. This allows a pointer to be distinguished
from a label, since the label must begin with two zero bits because
labels are restricted to 63 octets or less. (The 10 and 01 combinations
are reserved for future use.) The OFFSET field specifies an offset from
the start of the message (i.e., the first octet of the ID field in the
domain header). A zero offset specifies the first byte of the ID field,
etc.
最初の２ビットは１です。ラベルが６３オクテット以下に限定され２のゼロのビッ
トから始まる事から、ラベルとポインタを区別できます。（１０と０１の組合せ
は未来の使用のために予約されます。）オフセットフィールドはメッセージの最
初（ドメインヘッダの識別子フィールドの最初のオクテット）からのオフセット
を示します。ゼロオフセットが識別子フィールドの最初のバイトを指定します。
The compression scheme allows a domain name in a message to be
represented as either:
圧縮案はメッセージのドメイン名を以下のいずれかで表現することを許します：
- a sequence of labels ending in a zero octet
- ゼロの値のオクテットで終わるラベル列。
- a pointer
- ポインタ。
- a sequence of labels ending with a pointer
- ポインタで終わるラベル列。
Pointers can only be used for occurances of a domain name where the
format is not class specific. If this were not the case, a name server
or resolver would be required to know the format of all RRs it handled.
As yet, there are no such cases, but they may occur in future RDATA
formats.
ポインタがフォーマットがクラス特有でないドメイン名でだけ使えます。そうで
なければ、ネームサーバーやリゾルバが処理したすべての資源レコードのフォー
マットを知るように要求されるでしょう。まだ、このようなケースはありません
が、しかし未来の資源データフォーマットで起こるかもしれません。
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.
もしドメイン名が（資源レコードの資源データ部のような）メッセージ内の長さ
フィールドの適用を受ける部分にあり、圧縮が使われるなら、長さ計算で圧縮さ
れた名前が使われ、展開された名前の長にはなりません。
Programs are free to avoid using pointers in messages they generate,
although this will reduce datagram capacity, and may cause truncation.
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とルート
を使う必要があるかもしれません。メッセージの他のフィールドを無視すると、
これらのドメイン名の以下のように表現されるかもしれません：。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 1| 26 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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 pointer 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がオフセット２０にあります。ドメイン名FOO.F.ISI.ARPA
がオフセット４０にあります；この定義は前に定義されたF.ISI.ARPAにFOOラベ
ルを連結するポインタを使います。ドメイン名ARPAがオフセット６４で定義され、
名前F.ISI.ARPAのARPA部へのポインタを使います；ARPAに関するこのポインタは
２０の文字列の最後のラベルへのポインタである事に注意してください。ルート
ドメイン名はオフセット９２でゼロの値の１オクテットで定義されます；ルート
ドメイン名はラベルを持ちません。
4.2. Transport
4.2. 転送
The DNS assumes that messages will be transmitted as datagrams or in a
byte stream carried by a virtual circuit. While virtual circuits can be
used for any DNS activity, datagrams are preferred for queries due to
their lower overhead and better performance. Zone refresh activities
must use virtual circuits because of the need for reliable transfer.
ＤＮＳはメッセージがデータグラムか仮想回路のバイト流で運ばれる事を想定し
ます。仮想回路がどんなＤＮＳ活動でも使えますが、データグラムがオーバヘッ
ドは小さくよい性能を出すため問合せで好まれます。ゾーンリフレッシュ活動で
は信頼できる転送が必要なため仮想回路を使わなくてはなりません。
The Internet supports name server access using TCP [RFC-793] on server
port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
port 53 (decimal).
インターネットはネームサーバアクセスをＴＣＰ[RFC-793]のサーバーポート53
（１０進数）とＵＤＰ[RFC-768]のポート53（１０進数）でサポートします。
4.2.1. UDP usage
4.2.1. ＵＤＰ使用法
Messages sent using UDP user server port 53 (decimal).
メッセージがＵＤＰのサーバーポート５３（１０進数）のユーザに送信します。
Messages carried by UDP are restricted to 512 bytes (not counting the IP
or UDP headers). Longer messages are truncated and the TC bit is set in
the header.
ＵＤＰで運ばれるメッセージが（ＩＰやＵＤＰヘッダーを計算に入れないで）
５１２バイトに制限されます。長いメッセージが切り落とされ、ヘッダのＴＣ
ビットが設定されます。
訳注：RFC2181でＴＣビットは解答セクションと権威セクション処理にだけ適用
し、追加セクション処理には適用しないと規定しています。追加セクション処
理中に資源レコード集合を載せるスペースがなくなった場合は、資源レコード
集合を回答に載せずＴＣビットも設定しないという事です。
UDP is not acceptable for zone transfers, but is the recommended method
for standard queries in the Internet. Queries sent using UDP may be
lost, and hence a retransmission strategy is required. Queries or their
responses may be reordered by the network, or by processing in name
servers, so resolvers should not depend on them being returned in order.
ＵＤＰはゾーン転送で使えませんが、インターネットの標準的な問合せの推薦さ
れた方法です。ＵＤＰを使った問合せが失われるかもしれないので、再送戦略が
必要です。ネットワークやネームサーバ処理で問合せや回答の順序が変わるかも
しれないので、リゾルバが返送順序に依存するべきではありません。
The optimal UDP retransmission policy will vary with performance of the
Internet and the needs of the client, but the following are recommended:
最適なＵＤＰ再送方針はインターネットの性能とクライアントの必要で変化する
でしょうが、次のことが勧められます：
- The client should try other servers and server addresses
before repeating a query to a specific address of a server.
- クライアントはサーバーの特定のアドレスに問合せを繰り返す前に他のサー
バーとサーバーアドレスを試みるべきです。
- The retransmission interval should be based on prior
statistics if possible. Too aggressive retransmission can
easily slow responses for the community at large. Depending
on how well connected the client is to its expected servers,
the minimum retransmission interval should be 2-5 seconds.
- 再送間隔は、可能なら、事前の統計値に基づくべきです。あまりにも攻撃
的な再送が一般的な共同体の反応を容易に遅くできます。クライアントが
期待したサーバーにどれぐらい繋がってるかにより、最小再送間隔は２−５
秒であるべきです。
More suggestions on server selection and retransmission policy can be
found in the resolver section of this memo.
サーバー選択と再送方針のより多くの提案がこのメモのリゾルバの章で見つかり
ます。
訳注：RFC2181でさらに応答のＵＤＰパケットのソースアドレスは、問合せの
宛先アドレスでなければならないと規定しています。
4.2.2. TCP usage
4.2.2. ＴＣＰ使用法
Messages sent over TCP connections use server port 53 (decimal). The
message is prefixed with a two byte length field which gives the message
length, excluding the two byte length field. This length field allows
the low-level processing to assemble a complete message before beginning
to parse it.
ＴＣＰ接続で送られるメッセージがサーバーポート５３（１０進数）を使います。
メッセージの前には２バイトのメッセージの長さフィールドが付きます、長さに
は２バイトの長さフィールド自身を含みません。この長さフィールドはメッセー
ジを解析する前に低レベルの処理で完全なメッセージに組み立てることを許しま
す。
Several connection management policies are recommended:
いくつかの接続管理方針が勧められます：
- The server should not block other activities waiting for TCP
data.
- サーバーはＴＣＰデータを待つ間に他の活動を止めるべきではありません。
- The server should support multiple connections.
- サーバーは多数の接続をサポートするべきです。
- The server should assume that the client will initiate
connection closing, and should delay closing its end of the
connection until all outstanding client requests have been
satisfied.
- サーバーはクライアントから接続を終了すると想定するべきで、すべての
未処理のクライアント要求が完了するまで接続を閉じることを延ばすべき
です。
- If the server needs to close a dormant connection to reclaim
resources, it should wait until the connection has been idle
for a period on the order of two minutes. In particular, the
server should allow the SOA and AXFR request sequence (which
begins a refresh operation) to be made on a single connection.
Since the server would be unable to answer queries anyway, a
unilateral close or reset may be used instead of a graceful
close.
- もしサーバーがリソース返還を要求するために休眠中接続を閉じる必要が
あるなら、接続が２分間の何もおきないか待つべきです。特に、サーバー
は１つの接続で（リフレッシュオペレーションを始める）SOAとAXFRの問合
せの連続を許すべきです。サーバーが問合せに答えることが不可能であろ
うから、丁寧な終了ではなく一方的な終了やリセットが使われるかもしま
せん。
5. MASTER FILES
5. マスターファイル
Master files are text files that contain RRs in text form. Since the
contents of a zone can be expressed in the form of a list of RRs a
master file is most often used to define a zone, though it can be used
to list a cache's contents. Hence, this section first discusses the
format of RRs in a master file, and then the special considerations when
a master file is used to create a zone in some name server.
マスターファイルはテキスト形式で資源レコードを含んでいるテキストファイル
です。ゾーンの内容が資源レコードリストのかたちで表現できるので、マスター
ファイルでゾーンを定義するにに使われ、キャッシュ内容のリストアップで使わ
れます。それ故この章は最初にマスターファイルの資源レコードのフォーマット
を論じ、次にマスターファイルがあるネームサーバでゾーンを作るために使う事
を特別な考慮を論じます。
5.1. Format
5.1. フォーマット
The format of these files is a sequence of entries. Entries are
predominantly line-oriented, though parentheses can be used to continue
a list of items across a line boundary, and text literals can contain
CRLF within the text. Any combination of tabs and spaces act as a
delimiter between the separate items that make up an entry. The end of
any line in the master file can end with a comment. The comment starts
with a ";" (semicolon).
ファイルのフォーマットは項目の連続です。項目は基本的に行単位ですが、カッ
コを使うと行の境界を越えて項目を続られ、テキスト文字にCRLFを含むことがで
きます。タブと空白の組合せが項目を作り上げる要素間の区切りになります。マ
スターファイルのどの行もコメントで終了できます。コメントは";"セミコロン
で始まります。
The following entries are defined:
以下の項目が定義されます：
<blank>[<comment>]
$ORIGIN <domain-name> [<comment>]
$INCLUDE <file-name> [<domain-name>] [<comment>]
<domain-name><rr> [<comment>]
<blank><rr> [<comment>]
Blank lines, with or without comments, are allowed anywhere in the file.
コメントの有無に関わらず、ファイル内で空白行が許されます。
Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is
followed by a domain name, and resets the current origin for relative
domain names to the stated name. $INCLUDE inserts the named file into
the current file, and may optionally specify a domain name that sets the
relative domain name origin for the included file. $INCLUDE may also
have a comment. Note that a $INCLUDE entry never changes the relative
origin of the parent file, regardless of changes to the relative origin
made within the included file.
２つの制御装置項目が定義されます：$ORIGINと$INCLUDE。$ORIGINの後にはドメ
イン名が続き、相対的なドメイン名の起点ドメイン名を設定します。$INCLUDEが
指定されたファイルを現在のファイルに挿入し、オプションで挿入ファイル内の
相対的なドメイン名の起点ドメイン名を指定してもよいです。$INCLUDEがコメン
トを持っているかもしれません。$INCLUDE項目が、挿入ファイル中で相対的な起
点を変更しても、決して親ファイルの相対的なドメインの起点を変えないことを
指摘します。
The last two forms represent RRs. If an entry for an RR begins with a
blank, then the RR is assumed to be owned by the last stated owner. If
an RR entry begins with a <domain-name>, then the owner name is reset.
最後の２つの書式は資源レコードの代理を務めます。もし資源レコード項目が空
白で始まるなら、資源レコードは最後に出てきた所有者に所有されると考えられ
ます。もし資源レコード項目が<domain-name>から始まるなら、所有者名はリセッ
トされます。
<rr> contents take one of the following forms:
<rr>内容が次の書式の１つをとります：
[<TTL>] [<class>] <type> <RDATA>
[<class>] [<TTL>] <type> <RDATA>
The RR begins with optional TTL and class fields, followed by a type and
RDATA field appropriate to the type and class. Class and type use the
standard mnemonics, TTL is a decimal integer. Omitted class and TTL
values are default to the last explicitly stated values. Since type and
class mnemonics are disjoint, the parse is unique. (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とクラスフィールドと種別と、種別とクラスに適
切な資源データフィールドから始まります。クラスとタイプは標準名称を使い
TTLは１０進法の整数です。省略されたクラスとTTL値は最後の明示的に述べられ
た値がデフォルトです。タイプとクラス名称が共通要素を持たないので、品詞分
解はユニークです。（この例で使った順序が実際に使わてる資源レコードでの順
序と異なることに注意してください；所定の順序は文の解析を容易にし、デフォ
ルトを許します。）
<domain-name>s make up a large share of the data in the master file.
The labels in the domain name are expressed as character strings and
separated by dots. Quoting conventions allow arbitrary characters to be
stored in domain names. Domain names that end in a dot are called
absolute, and are taken as complete. Domain names which do not end in a
dot are called relative; the actual domain name is the concatenation of
the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
an argument to the master file loading routine. A relative name is an
error when no origin is available.
<domain-name>はマスターファイルでデータの大きな共有をします。ドメイン名
のラベルは点で区切られた文字列で表されます。クォートの規則が任意の文字を
ドメイン名に設定することを許します。点に終わるドメイン名が絶対と呼ばれて、
完全と思われます。点に終わらないドメイン名が相対的で呼ばれます；実際のド
メイン名は、$ORIGINや$INCLUDEやマスターファイルをロードするルーチンの引
数に指定さる起点と相対的部分の結合です。相対的な名前が、起点が利用可能で
はない時エラーです。
<character-string> is expressed in one or two ways: as a contiguous set
of characters without interior spaces, or as a string beginning with a "
and ending with a ". Inside a " delimited string any character can
occur, except for a " itself, which must be quoted using \ (back slash).
<character-string>は２種類の方法で表現されます：内部のスペースがない連続
文字、あるいは"で始まり"で終わる文字列。"で区切られた文字列の内部は"以外
のどんな文字も設定でき、"自身は\（バックスラッシュ）で引用できます。
Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded. In particular:
これらのファイルがテキストファイルであるから、いくつかの特別なコード化が
任意のデータにロードされることを許すために必要です。特に：
of the root.
ルートについて
@ A free standing @ is used to denote the current origin.
@ 単独の@が現在の起点を意味するために使われます。
\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 １０が桁（０-９）以外のキャラクタで、特別な意味を適用せ
ずに、その文字を引用するために使われます。例えば、"\."が
ラベル内にドット文字を置くために使えます。
\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.
\DDD 各Ｄが数字でＤＤＤの１０進数で示されるオクテットです。結
果として生じるオクテットはテキストと考えられ、そして特別
な意味がチェックされません。
( ) 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.
; セミコロンがコメントを始めるために使われます；ラインの残
りが無視されます。
5.2. Use of master files to define zones
5.2. ゾーンを定義するためのマスターファイルの使用
When a master file is used to load a zone, the operation should be
suppressed if any errors are encountered in the master file. The
rationale for this is that a single error can have widespread
consequences. For example, suppose that the RRs defining a delegation
have syntax errors; then the server will return authoritative name
errors for all names in the subzone (except in the case where the
subzone is also present on the server).
マスターファイルがゾーンを読み込むのに使われる時、マスターファイルにエラー
があるならば、操作は中止されるべきです。中止する理由はひとつのエラーが広
範囲に影響をあたえることがあるからです。例えば、委任を定義している資源レ
コードが文法エラーになってると考えてください；するとサーバーは委任先のゾー
ンのすべての名前について正式名エラーを返します（サブゾーンが同じサーバー
上にある場合を除きます）。
Several other validity checks that should be performed in addition to
insuring that the file is syntactically correct:
ファイル構文が正しいことを保証するため、他の追加の正当性チェックが行われ
るべきです：
1. All RRs in the file should have the same class.
1. ファイル中の全ての資源レコードは同じクラスを持つべきです。
2. Exactly one SOA RR should be present at the top of the zone.
2. ゾーンの最初に正確に１つのSOA資源レコードがあるべきです。
3. If delegations are present and glue information is required,
it should be present.
3. もし委任があり、接着剤情報が必要なら、それは存在するべきです。
4. Information present outside of the authoritative nodes in the
zone should be glue information, rather than the result of an
origin or similar error.
4. 存在しているがゾーンの正式なノードでない情報は接着剤情報であるべき
で、起点や同様のエラーではありません。
5.3. Master file example
5.3. マスターファイルの例
The following is an example file which might be used to define the
ISI.EDU zone.and is loaded with an origin of ISI.EDU:
次のものはISI.EDUゾーンを定義し、ISI.EDU出身情報をロードするのに使われる
ファイルの例です：
@ IN SOA VENERA Action\.domains (
20 ; SERIAL
7200 ; REFRESH
600 ; RETRY
3600000; EXPIRE
60) ; MINIMUM
NS A.ISI.EDU.
NS VENERA
NS VAXA
MX 10 VENERA
MX 20 VAXA
A A 26.3.0.103
VENERA A 10.1.0.52
A 128.9.0.32
VAXA A 10.2.0.27
A 128.9.0.33
$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
ファイル<SUBSYS>ISI-MAILBOXES.TXTは次のとおりです：
MOE MB A.ISI.EDU.
LARRY MB A.ISI.EDU.
CURLEY MB A.ISI.EDU.
STOOGES MG MOE
MG LARRY
MG CURLEY
Note the use of the \ character in the SOA RR to specify the responsible
person mailbox "Action.domains@E.ISI.EDU".
責任者のがメールボックス「Action.domains@E.ISI.EDU」を指定するためにSOA
資源レコードで\キャラクタの使用に注意してください。
6. NAME SERVER IMPLEMENTATION
6. ネームサーバー情報
6.1. Architecture
6.1. 構造
The optimal structure for the name server will depend on the host
operating system and whether the name server is integrated with resolver
operations, either by supporting recursive service, or by sharing its
database with a resolver. This section discusses implementation
considerations for a name server which shares a database with a
resolver, but most of these concerns are present in any name server.
ネームサーバの最適な構造はホストオペレーティングシステムに依存するでしょ
う、そしてネームサーバであるか否かにかかわらず、再帰的サービスをサポート
することで、あるいはリゾルバとデータベースを共有することで、リゾルバと統
合されます。この章はリゾルバとデータベースを共有するネームサーバーに対す
る実装の考慮を論じます、しかしこれらの事は大部分のネームサーバにも言えま
す。
6.1.1. Control
6.1.1. 制御
A name server must employ multiple concurrent activities, whether they
are implemented as separate tasks in the host's OS or multiplexing
inside a single name server program. It is simply not acceptable for a
name server to block the service of UDP requests while it waits for TCP
data for refreshing or query activities. Similarly, a name server
should not attempt to provide recursive service without processing such
requests in parallel, though it may choose to serialize requests from a
single client, or to regard identical requests from the same client as
duplicates. A name server should not substantially delay requests while
it reloads a zone from master files or while it incorporates a newly
refreshed zone into its database.
ネームサーバーは、ホストＯＳ上の複数のタスクとして実装されるか、複数の処
理をする１つのタスクとして実装されるかで、多数の同時の処理を行えなければ
なりません。ネームサーバが、リフレッシュＴＣＰデータや問合せを待つ間に、
ＵＤＰ問合せサービスを止めるべきでありません。同様に、ネームサーバーが並
列に問合せ処理をしないで再帰的なサービスを提供したり、１つのクライアント
からの連続する問合せや、同じクライアントからの同じ問合せを重複した問合せ
とみなすべきではありません。ネームサーバーが、マスターファイルからゾーン
を再ロードする間や、データベースにリフレッシュゾーンを取り込む際に、問合
せを遅らすべきではありません。
6.1.2. Database
6.1.2. データベース
While name server implementations are free to use any internal data
structures they choose, the suggested structure consists of three major
parts:
ネームサーバ実装者はどんな内部データ構造を選択してもいいが、提案された構
造は３つの主要なパーツから成り立ちます：
- A "catalog" data structure which lists the zones available to
this server, and a "pointer" to the zone data structure. The
main purpose of this structure is to find the nearest ancestor
zone, if any, for arriving standard queries.
- このサーバーの扱うゾーンをリストアップする「カタログ」データ構造と
ゾーンデータ構造への「ポインタ」。この構造の主な目的は、もし標準問
合せが来たときに、最も近い先祖ゾーンを見つけることです。
- Separate data structures for each of the zones held by the
name server.
- ネームサーバーの持つゾーンそれぞれの並列データ構造。
- A data structure for cached data. (or perhaps separate caches
for different classes)
- キャッシュデータのデータ構造。（多分クラス別に異なるキャッシュ）。
All of these data structures can be implemented an identical tree
structure format, with different data chained off the nodes in different
parts: in the catalog the data is pointers to zones, while in the zone
and cache data structures, the data will be RRs. In designing the tree
framework the designer should recognize that query processing will need
to traverse the tree using case-insensitive label comparisons; and that
in real data, a few nodes have a very high branching factor (100-1000 or
more), but the vast majority have a very low branching factor (0-1).
すべてデータ構造で、ノードの異る部分で異なるデータが繋がる、同一のツリー
構造フォーマットを実装します：カタログでデータはゾーンへのポインタで、ゾー
ンととキャッシュデータ構造で、データは資源レコードでしょう。デザイナーが
木機構を設計する際に以下を認識するべきである、問合せ処理は大文字小文字の
違いを無視するラベル比較を使いツリーをくまなく渡り歩く必要があるでしょう；
実データで、少数のノードが非常に多くの分岐ファクター（１００−１０００あ
るいはそれ以上）を持つでしょう、けれどもほとんどは少ない数の分岐ファクター
（０−１）を持ちます。
One way to solve the case problem is to store the labels for each node
in two pieces: a standardized-case representation of the label where all
ASCII characters are in a single case, together with a bit mask that
denotes which characters are actually of a different case. The
branching factor diversity can be handled using a simple linked list for
a node until the branching factor exceeds some threshold, and
transitioning to a hash structure after the threshold is exceeded. In
any case, hash structures used to store tree sections must insure that
hash functions and procedures preserve the casing conventions of the
DNS.
大文字小文字の問題を解く一つの方法はノードのラベルを２つの部分で登録する
ことです：アスキー文字の大文字小文字がどちらかになっている標準化した大文
字小文字のラベルと、各文字の大文字小文字が異なっているビット列。分岐ファ
クターの多様性は、分岐している要素がある閾値を超えるまで、ノードの単純な
リンクリストで対処し、閾値を超えたらハッシュ構造に移行できます。どんな場
合でも、記憶木部で使うハッシュ構造が、ハッシュ機能と手順がＤＮＳの約束を
保持することを保証しなくてはなりません。
The use of separate structures for the different parts of the database
is motivated by several factors:
データベースの異なる部分の個々の構造の用途はいくつかの要素によってきまり
ます：
- The catalog structure can be an almost static structure that
need change only when the system administrator changes the
zones supported by the server. This structure can also be
used to store parameters used to control refreshing
activities.
- カタログ構造は、ただシステム管理者がサーバーの扱うゾーンを変える時
だけ変化をするほとんど静的な構造です。この構造はリフレッシュ活動を
コントロールするパラメータの記憶に使うことができます。
- The individual data structures for zones allow a zone to be
replaced simply by changing a pointer in the catalog. Zone
refresh operations can build a new structure and, when
complete, splice it into the database via a simple pointer
replacement. It is very important that when a zone is
refreshed, queries should not use old and new data
simultaneously.
- ゾーン個別のデータ構造は、カタログのポインタを変えることで変更でき
ます。ゾーンリフレッシュ操作が新しい構造を生成し完成したときに、単
純なポインタ変更でデータベースの変更ができます。ゾーンリフレッシュ
の時、問合せで古いデータと新しいデータの両方を使ってはなりません。
- With the proper search procedures, authoritative data in zones
will always "hide", and hence take precedence over, cached
data.
- 正確な探索手順で、ゾーンの正式なデータが常にキャッシュされたデータ
を「隠し」、正式なデータが優先されるでしょう。
- Errors in zone definitions that cause overlapping zones, etc.,
may cause erroneous responses to queries, but problem
determination is simplified, and the contents of one "bad"
zone can't corrupt another.
- 重複ゾーンを生じるゾーン定義のエラーなどで問合せ対する誤った回答が
あるかもしれませんが、問題解決は単純で、「悪い」ゾーン内容はよいゾー
ンを悪くすることができません。
- Since the cache is most frequently updated, it is most
vulnerable to corruption during system restarts. It can also
become full of expired RR data. In either case, it can easily
be discarded without disturbing zone data.
- キャッシュがしばしばアップデートされるので、システム再開で壊れやす
いです。キャッシュが期限切れ資源データで埋まることがあります。どの
場合も、ゾーンデータを乱すことなく容易に削除できます。
A major aspect of database design is selecting a structure which allows
the name server to deal with crashes of the name server's host. State
information which a name server should save across system crashes
includes the catalog structure (including the state of refreshing for
each zone) and the zone data itself.
データベースデザインの主な観点は、ネームサーバーがネームサーバのホストの
障害に対応できる構造を選ぶ事です。ネームサーバーがシステム障害に備えて保
存するべき状態情報は、カタログ構造（各ゾーンのリフレッシュ状態を含めて）
とゾーンデータそれ自身です。
6.1.3. Time
6.1.3. 時間
Both the TTL data for RRs and the timing data for refreshing activities
depends on 32 bit timers in units of seconds. Inside the database,
refresh timers and TTLs for cached data conceptually "count down", while
data in the zone stays with constant TTLs.
資源レコードの生存時間データとリフレッシュ活動のタイミングデータは秒単位
の３２のビットタイマーに依存します。データベース内部で、リフレッシュタイ
マーとキャッシュデータの生存時間は概念的に「カウントダウン」され、ゾーン
の生存時間データが一定値のままです。
A recommended implementation strategy is to store time in two ways: as
a relative increment and as an absolute time. One way to do this is to
use positive 32 bit numbers for one type and negative numbers for the
other. The RRs in zones use relative times; the refresh timers and
cache data use absolute times. Absolute numbers are taken with respect
to some known origin and converted to relative values when placed in the
response to a query. When an absolute TTL is negative after conversion
to relative, then the data is expired and should be ignored.
推薦される実装戦略は時間を２つの方法で記憶するはずです：相対的時間と絶対
時で。これをする一つの方法が一方で３２ビット番号の正の値を使い、他方で負
の値を使うことです。ゾーンの資源レコードは相対時を使います；リフレッシュ
タイマーとキャッシュデータは絶対時を使います。絶対時がある周知の起点を基
準に設定され、問合せに対する回答に設定するとき、相対的な値に変換されます。
絶対時間の生存時間を相対時に変換した際に値が負になったらデータは期限切れ
で無視されるべきです。
6.2. Standard query processing
6.2. 標準問合せ処理
The major algorithm for standard query processing is presented in
[RFC-1034].
標準問合せ処理のための主要なアルゴリズムは[RFC-1034]にあります。
When processing queries with QCLASS=*, or some other QCLASS which
matches multiple classes, the response should never be authoritative
unless the server can guarantee that the response covers all classes.
問合せクラス=*または複数のクラスに一致する問合せを処理する時、サーバーが
回答の全てのクラスを保証できない限り回答は正式になりません。
When composing a response, RRs which are to be inserted in the
additional section, but duplicate RRs in the answer or authority
sections, may be omitted from the additional section.
回答を作る際に、追加部に資源レコードが入るかもしれませんが、回答部や正式
部にある資源レコードと重複する資源レコードは追加部から除かれるかもしれま
せん。
When a response is so long that truncation is required, the truncation
should start at the end of the response and work forward in the
datagram. Thus if there is any data for the authority section, the
answer section is guaranteed to be unique.
回答が切り落としが必要なほど長い時は、切り落としは回答の終わりから始め、
データグラムで前方方向へ行うべきです。そして正式部のデータがあるなら、回
答部は完全なことが保証されます。
The MINIMUM value in the SOA should be used to set a floor on the TTL of
data distributed from a zone. This floor function should be done when
the data is copied into a response. This will allow future dynamic
update protocols to change the SOA MINIMUM field without ambiguous
semantics.
SOAの最小値はゾーンから配布されるデータの生存時間の下限を設定するために
使われるべきです。この下限は、データが回答にコピーされる時、されるべき
です。これは未来のダイナミック更新プロトコルで意味が不明瞭になることな
くSOA最小限フィールドの変更を許すでしょう。
6.3. Zone refresh and reload processing
6.3. ゾーン更新と読み直し処理
In spite of a server's best efforts, it may be unable to load zone data
from a master file due to syntax errors, etc., or be unable to refresh a
zone within the its expiration parameter. In this case, the name server
should answer queries as if it were not supposed to possess the zone.
サーバーの最善の努力にもかかわらず、マスターファイルの構文誤りや、満期タ
イマー時にゾーンリフレッシュができないなど、ゾーンデータを読めない場合が
あります。この場合、ネームサーバーはそのゾーンを所有していないかのように、
問合せに答えるべきです。
If a master is sending a zone out via AXFR, and a new version is created
during the transfer, the master should continue to send the old version
if possible. In any case, it should never send part of one version and
part of another. If completion is not possible, the master should reset
the connection on which the zone transfer is taking place.
もしマスターがAXFRでゾーンを送てる最中に、そして新しい版が作られるなら、
マスターは、可能なら、古い版を送り続けるべきです。どんな場合でも、ある部
分は新しい版で、ある部分は古い版であるようなものを送るべきではありません。
もしゾーン転送を続けられないなら、マスターはゾーン転送をしている接続をリ
セットするべきです。
6.4. Inverse queries (Optional)
6.4. 逆問合せ（任意)
Inverse queries are an optional part of the DNS. Name servers are not
required to support any form of inverse queries. 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.
逆問合せはＤＮＳの任意の部分です。ネームサーバが逆問合せ形式の実装を要求
されません。もしネームサーバが実装していない逆問合せを受け取るなら、ヘッ
ダーに「実装されてない」エラーを設定しエラー回答を返します。逆問合せの実
装が任意ですが、すべてのネームサーバーは少なくともエラー回答を返せなけれ
ばなりません。
6.4.1. The contents of inverse queries and responses
6.4.1. 逆の質問と回答の中身
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 queries take the form of a single RR in the answer section of
the message, with an empty question section. The owner name of the
query RR and its TTL are not significant. The response carries
questions in the question section which identify all names possessing
the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows
about all of the domain name space, the response can never be assumed to
be complete. Thus inverse queries are primarily useful for database
management and debugging activities. Inverse queries are NOT an
acceptable method of mapping host addresses to host names; use the IN-
ADDR.ARPA domain instead.
逆問合せメッセージの回答部の１つの資源レコードと、空の質問部からなります。
問合せ資源レコードの所有者名と生存時間は意味がありません。回答はネームサー
バーが知っているすべての問合せ資源レコードを所有している名前を質問部に設
定したものです。ネームサーバーがドメイン名空間のすべてを知っているのでな
いので、回答は決して完全なものと考えられません。このため逆問合せは主にデー
タベース管理とデバッグ活動に役立ちます。逆問合せはホストアドレスをホスト
名に変換するよい方法ではありません；その代わりIN-ADDR.ARPAドメインを使い
ます。
Where possible, name servers should provide case-insensitive comparisons
for inverse queries. Thus an inverse query asking for an MX RR of
"Venera.isi.edu" should get the same response as a query for
"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
produce the same result as an inverse query for "IBM-pc unix". However,
this cannot be guaranteed because name servers may possess RRs that
contain character strings but the name server does not know that the
data is character.
可能な場合、ネームサーバが逆問合せに大文字小文字の違いを無視する比較を提
供するべきです。それでMX資源レコード"Venera.isi.edu"を求める逆問合せが
"VENERA.ISI.EDU"の逆質問と同じ回答を手に入れるべきです；"IBM-PC UNIX"ホ
スト情報資源レコードの逆問合せが"IBM-pc unix"の逆問合せと同じ結果を起こ
すべきです。しかし、ネームサーバが文字列を含む資源レコードを所有するかも
しれないが、ネームサーバーがデータが文字かどうかを知らないので保証はでき
ません。
When a name server processes an inverse query, it either returns:
ネームサーバーが逆問合せを処理する時、以下を返すかもしれません：
1. zero, one, or multiple domain names for the specified
resource as QNAMEs in the question section
1. ０個以上の質問部の問合せ名で指定した資源のドメイン名。
2. an error code indicating that the name server doesn't support
inverse mapping of the specified resource type.
2. ネームサーバが指定された資源種別の逆変換を実装していないことを
示すエラーコード。
When the response to an inverse query contains one or more QNAMEs, the
owner name and TTL of the RR in the answer section which defines the
inverse query is modified to exactly match an RR found at the first
QNAME.
逆の質問に対する回答が１つ以上の問合せ名を含む時、逆の質問を定義する回答
部の資源レコードの所有者名と生存時間は最初の問合せ名で見つかる資源レコー
ドのと正確に一致ように修正されます。
RRs returned in the inverse queries cannot be cached using the same
mechanism as is used for the replies to standard queries. One reason
for this is that a name might have multiple RRs of the same type, and
only one would appear. For example, an inverse query for a single
address of a multiply homed host might create the impression that only
one address existed.
逆の質問で返された資源レコードが標準的な質問で使われているキャッシュメカ
ニズムでキャッシュできません。この１つの理由は名前が同じタイプの多数の資
源レコード持つかもしれないが、ただ１だけが現われるためです。例えば、マル
チホームホストのひとつのアドレスの逆問合せが、ホストにアドレスが１つだけ
あるような印象を与えるかもしれません。
6.4.2. Inverse query and response example
6.4.2. 逆問合せと回答例
The overall structure of an inverse query for retrieving the domain
name that corresponds to Internet address 10.1.0.52 is shown below:
インターネットアドレス10.1.0.52に対応するドメイン名を返す逆問合せの全体
的な構造は下に見せられます：
+-----------------------------------------+
Header | OPCODE=IQUERY, ID=997 |
ヘッダ +-----------------------------------------+
Question | <empty> |
質問 +-----------------------------------------+
Answer | <anyname> A IN 10.1.0.52 |
回答 +-----------------------------------------+
Authority | <empty> |
正式 +-----------------------------------------+
Additional | <empty> |
追加 +-----------------------------------------+
This query asks for a question whose answer is the Internet style
address 10.1.0.52. Since the owner name is not known, any domain name
can be used as a placeholder (and is ignored). A single octet of zero,
signifying the root, is usually used because it minimizes the length of
the message. The TTL of the RR is not significant. The response to
this query might be:
この問合せは、どんな質問の答えがインターネットスタイルアドレス10.1.0.52
であるか尋ねます。所有者名が知られてないの、任意のドメイン名が穴埋めに利
用できます（そして無視されます）。ゼロの値の１つのオクテットがルートを意
味し、メッセージ長を最小にするため通常使われます。資源レコードの生存時間
は意味がありません。この質問に対する回答は以下かもしれません：
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=997 |
ヘッダ +-----------------------------------------+
Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
質問 +-----------------------------------------+
Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
回答 +-----------------------------------------+
Authority | <empty> |
正式 +-----------------------------------------+
Additional | <empty> |
追加 +-----------------------------------------+
訳注：RFC誤植情報によるとOPCODEにRESPONSEという値はないので、
上記のヘッダの記載は"OPCODE=IQUERY, ID=997, QR=1"が正しいそうです。
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. If the question section in the response is not empty, then the
RR in the answer section is modified to correspond to be an exact copy
of an RR at the first QNAME.
逆問合せに対する回答で質問種別が逆問合せの回答部の種別フィールドと同じこ
とに注意してください。逆問合せに対する回答が、逆が一意ではない時、多数の
質問を含むかもしれません。もし回答メッセージの質問部が空ではないなら、回
答部の資源レコードは最初の問合せ名の資源レコードの正確なコピーに対応する
ように修正されます。
6.4.3. Inverse query processing
6.4.3. 逆問合せ処理
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 zone. When a
particular zone is changed during a refresh, only its inversions need to
be redone.
多数のゾーンと大量のデータをサポートするネームサーバの推薦された手段は各
ゾーン毎の逆検索です。特定のゾーンがリフレッシュで変わった時、そのゾーン
の裏返しだけをやり直せばいいです。
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.
この裏返しの種類のタ転送の実装がドメインシステムの未来の版に含められるか
もしれませんが、この版には含めません。
6.5. Completion queries and responses
6.5. 完成問合せと回答
The optional completion services described in RFC-882 and RFC-883 have
been deleted. Redesigned services may become available in the future.
RFC-882とRFC-883で記述された任意の完成サービスは削除されました。デザイン
を変更したサービスが将来利用可能になるかもしれません。
7. RESOLVER IMPLEMENTATION
7. リゾルバの実装
The top levels of the recommended resolver algorithm are discussed in
[RFC-1034]. This section discusses implementation details assuming the
database structure suggested in the name server implementation section
of this memo.
推薦されたリゾルバアルゴリズムの概念は[RFC-1034]で論じられます。この章は
このメモのネームサーバ実装部で提案されたデータベース構造を想定している実
装の詳細を論じます。
7.1. Transforming a user request into a query
7.1. ユーザ要求の質問への変換
The first step a resolver takes is to transform the client's request,
stated in a format suitable to the local OS, into a search specification
for RRs at a specific name which match a specific QTYPE and QCLASS.
Where possible, the QTYPE and QCLASS should correspond to a single type
and a single class, because this makes the use of cached data much
simpler. The reason for this is that the presence of data of one type
in a cache doesn't confirm the existence or non-existence of data of
other types, hence the only way to be sure is to consult an
authoritative source. If QCLASS=* is used, then authoritative answers
won't be available.
リゾルバの最初の手順は、ローカルＯＳに適したフォーマットで記述されたクラ
イアント要求を、指定した名前に一致する質問種別と質問クラス資源レコードを
検索仕様へ変換することです。キャッシュデータの利用を単純にするので、可能
な場合、質問種別と質問クラスはひとつの種別とひとつのクラスに対応するべき
です。この理由はキャッシュ中のある種類のデータの存在が他の種類のデータの
存在の有無の確認に使えないということで、それ故確認する唯一の方法は正式な
情報源を調べることです。もしQCLASS=*なら正式な答えは利用可能でないでしょ
う。
Since a resolver must be able to multiplex multiple requests if it is to
perform its function efficiently, each pending request is usually
represented in some block of state information. This state block will
typically contain:
リゾルバが、効率的に機能を実行するなら、多数の要求を同時に送信できなけれ
ばならないので、各未決定の問合せが通常ある状態情報で表されます。状態情報
が一般に以下を含みます：
- A timestamp indicating the time the request began.
The timestamp is used to decide whether RRs in the database
can be used or are out of date. This timestamp uses the
absolute time format previously discussed for RR storage in
zones and caches. Note that when an RRs TTL indicates a
relative time, the RR must be timely, since it is part of a
zone. When the RR has an absolute time, it is part of a
cache, and the TTL of the RR is compared against the timestamp
for the start of the request.
- 要求を始めた時間を示すタイムスタンプ。タイムスタンプはデータベース
中の資源レコードで使えるか、古いかを決めるために使われます。このタ
イムスタンプは前のゾーンとキャッシュの資源レコードの登録で論じた絶
対時間フォーマットを使います。資源レコード生存時間が相対的な時を示
すが、資源レコードがゾーンの一部なので、最新に違いないことに注意し
てください。資源レコードが絶対時間を持つ時、それはキャッシュの一部
です、そして資源レコードの生存時間は要求を行ったタイムスタンプを基
準にして判断されます。
Note that using the timestamp is superior to using a current
time, since it allows RRs with TTLs of zero to be entered in
the cache in the usual manner, but still used by the current
request, even after intervals of many seconds due to system
load, query retransmission timeouts, etc.
生存時間がゼロの資源レコードが通常の方法でキャッシュに入れることが
できるが、システム負荷や再送タイムアウトなどで数秒間処理が遅れるか
もしれないいま実行中の問合せでまだ資源レコードを使うので、現在時刻
ではなくタイムスタンプを使うことに注意してください。
- Some sort of parameters to limit the amount of work which will
be performed for this request.
- 要求を行う仕事量を制限するある種のパラメータ
The amount of work which a resolver will do in response to a
client request must be limited to guard against errors in the
database, such as circular CNAME references, and operational
problems, such as network partition which prevents the
resolver from accessing the name servers it needs. While
local limits on the number of times a resolver will retransmit
a particular query to a particular name server address are
essential, the resolver should have a global per-request
counter to limit work on a single request. The counter should
be set to some initial value and decremented whenever the
resolver performs any action (retransmission timeout,
retransmission, etc.) If the counter passes zero, the request
is terminated with a temporary error.
リゾルバがクライアント要求に応えてするであろう仕事の量は限定されて
いるに違いありません。巡回した基本名参照のようなデータベースでエラー
や、リゾルバが必要なネームサーバーにアクセスするのを阻止するネット
ワーク分割などの運用問題を警戒するために。リゾルバが特定のネームサー
バアドレスに特定の問合せを再送するときの数の局部的制限が不可欠なの
で、リゾルバは要求ごとの仕事を制限するためにグローバルなカウンター
を持つべきです。カウンターはある初期値が設定されリゾルバがなにか動
作（再送タイムアウト、再送など）するたびに減算されます。カウンター
がゼロになったら要求は一時的なエラーで終ります。
Note that if the resolver structure allows one request to
start others in parallel, such as when the need to access a
name server for one request causes a parallel resolve for the
name server's addresses, the spawned request should be started
with a lower counter. This prevents circular references in
the database from starting a chain reaction of resolver
activity.
もしリゾルバの構造が複数の要求を並列に行えるのであれば、例えばある
ネームサーバへの要求がネームサーバーのアドレスの解決を生成した際、
平行した要求がより少ないカウンター値ではじめられるべき事に注意して
ください。これはデータベースの巡回参照がリゾルバ活動の連鎖反応を始
めるのを阻止します。
- The SLIST data structure discussed in [RFC-1034].
- サーバリストデータ構造は[RFC-1034]で論じらます。
This structure keeps track of the state of a request if it
must wait for answers from foreign name servers.
この構造は、もし外のネームサーバの応答を待たなければならないなら、
リクエストの状態を記録・追跡します。
7.2. Sending the queries
7.2. 問合せの送信
As described in [RFC-1034], the basic task of the resolver is to
formulate a query which will answer the client's request and direct that
query to name servers which can provide the information. The resolver
will usually only have very strong hints about which servers to ask, in
the form of NS RRs, and may have to revise the query, in response to
CNAMEs, or revise the set of name servers the resolver is asking, in
response to delegation responses which point the resolver to name
servers closer to the desired information. In addition to the
information requested by the client, the resolver may have to call upon
its own services to determine the address of name servers it wishes to
contact.
[RFC-1034]で記述されるように、リゾルバの基本的な仕事はクライアントの要求
に答えるであろう問合せを生成し、問合せを情報を供給するネームサーバに向け
る事です。解答者は通常ただネームサーバ資源レコードの形式でどのサーバーに
尋ねるべきか非常に強力なヒントを持つだけでしょう、そして基本名に応じて問
合せを修正したり、リゾルバに望ましい情報により近いネームサーバを示す委任
応答に応えてリゾルバが尋ねるネームサーバの集合を修正しなければならないか
もしれません。クライアントによって求められた情報のほかに、リゾルバは連絡
を取りたいネームサーバのアドレスを決定するため要求しなければならないかも
しれません。
In any case, the model used in this memo assumes that the resolver is
multiplexing attention between multiple requests, some from the client,
and some internally generated. Each request is represented by some
state information, and the desired behavior is that the resolver
transmit queries to name servers in a way that maximizes the probability
that the request is answered, minimizes the time that the request takes,
and avoids excessive transmissions. The key algorithm uses the state
information of the request to select the next name server address to
query, and also computes a timeout which will cause the next action
should a response not arrive. The next action will usually be a
transmission to some other server, but may be a temporary error to the
client.
どんな場合でも、このメモで使われたモデルはそれを仮定します。リゾルバはク
ライアントから要求された要求と内部で生成された要求の、多重の要求を処理し
ます。各要求がある状態情報で表され、そして望ましい行動はリクエストが答え
られる可能性を最大にする方法でリゾルバがネームサーバに問合せを伝達するこ
とで、リクエストが要する時間を最小にし、極端な送信を避けます。鍵アルゴリ
ズムは照会する次のネームサーバアドレスを選ぶために要求状態情報を使い、そ
して回答が到着しなかった次の行動を起こすタイムアウトを計算します。次の行
動は通常何か他のサーバーへの転送であろが、クライアントへ一時的エラーを送
るかもしれません。
The resolver always starts with a list of server names to query (SLIST).
This list will be all NS RRs which correspond to the nearest ancestor
zone that the resolver knows about. To avoid startup problems, the
resolver should have a set of default servers which it will ask should
it have no current NS RRs which are appropriate. The resolver then adds
to SLIST all of the known addresses for the name servers, and may start
parallel requests to acquire the addresses of the servers when the
resolver has the name, but no addresses, for the name servers.
リゾルバは常に照会するべきサーバー名のリスト（SLIST）から始めます。この
リストはリゾルバが知っている最も近くの先祖ゾーンに対応するすべてのネーム
サーバ資源レコードでしょう。起動時の問題を避けるため、もし適切な現在の
ネームサーバ資源レコードを持たなければ、リゾルバはそれを尋ねるデフォルト
サーバーのセットを持つべきです。リゾルバはサーバーリストにネームサーバの
周知の全てのアドレスを加え、リゾルバがネームサーバの名前以外アドレスを持
たないならば、サーバーのアドレスを獲得する平行した要求を始めてもよいです。
To complete initialization of SLIST, the resolver attaches whatever
history information it has to the each address in SLIST. This will
usually consist of some sort of weighted averages for the response time
of the address, and the batting average of the address (i.e., how often
the address responded at all to the request). Note that this
information should be kept on a per address basis, rather than on a per
name server basis, because the response time and batting average of a
particular server may vary considerably from address to address. Note
also that this information is actually specific to a resolver address /
server address pair, so a resolver with multiple addresses may wish to
keep separate histories for each of its addresses. Part of this step
must deal with addresses which have no such history; in this case an
expected round trip time of 5-10 seconds should be the worst case, with
lower estimates for the same local network, etc.
サーバーリストの初期化を完了するために、リゾルバはサーバリストの各アドレ
スに履歴情報を付加します。これは通常アドレスの応答時間とアドレス回答率
（そのアドレスがどのぐらい要求に応答したか）の順序付けがされるでしょう。
あるサーバの応答時間や回答率はアドレス毎に差があるので、応答時間や回答率
はネームサーバ毎ではなくアドレス毎に保管されるべきです。またこの情報がリ
ゾルバアドレスとサーバーアドレスの対毎に特有なことに注意してください、多
数のアドレスを持つリゾルバが各アドレス毎の履歴の保持を望むかもしれない。
このステップで履歴を持たないアドレスも扱わなくてはなりません；この場合
５−１０秒の往復時間が最悪の場合で、ローカルネットワークではより低く見積
もるべきです。
Note that whenever a delegation is followed, the resolver algorithm
reinitializes SLIST.
委任が行われる時はいつでも、リゾルバアルゴリズムがサーバーリストを再初期
化することに注意してください。
The information establishes a partial ranking of the available name
server addresses. Each time an address is chosen and the state should
be altered to prevent its selection again until all other addresses have
been tried. The timeout for each transmission should be 50-100% greater
than the average predicted value to allow for variance in response.
情報は利用可能なネームサーバアドレスの部分的な順位を確立します。アドレス
が選択されると、すべての他のアドレスが試されるまで再び同じアドレスを選択
しないように、状態を変化させます。各転送のタイムアウトは分散を考慮して平
均予測値より５０-１００％大きくあるべきです。
Some fine points:
ある微妙なポイント：
- The resolver may encounter a situation where no addresses are
available for any of the name servers named in SLIST, and
where the servers in the list are precisely those which would
normally be used to look up their own addresses. This
situation typically occurs when the glue address RRs have a
smaller TTL than the NS RRs marking delegation, or when the
resolver caches the result of a NS search. The resolver
should detect this condition and restart the search at the
next ancestor zone, or alternatively at the root.
- リゾルバはサーバーリストで指定されたネームサーバの全てが利用可能で
なく、リスト中のサーバーがそのサーバ自身のアドレスに問い合わせない
と検索でき名状態に遭遇するかもしれません。この状態は一般に、接着剤
アドレス資源レコードの生存時間が委任を作るネームサーバ資源レコード
の生存時間より小さいときや、リそる場がネームサーバ検索をキャッシュ
してる場合に、存在します。リゾルバはこの状態を検出し、次の先祖ゾー
ンから、あるいはルートから捜索を再開するべきです。
- If a resolver gets a server error or other bizarre response
from a name server, it should remove it from SLIST, and may
wish to schedule an immediate transmission to the next
candidate server address.
- もしリゾルバがネームサーバーからサーバーエラーや他の奇異な反応を得
るなら、そのネームサーバをサーバリストから除き、次の候補サーバーア
ドレスに即刻送信することを望むかもしれません。
7.3. Processing responses
7.3. 処理回答
The first step in processing arriving response datagrams is to parse the
response. This procedure should include:
受け取った回答データグラムを処理する最初の手順は回答を解析することです。
この手順が以下を含むべきです：
- Check the header for reasonableness. Discard datagrams which
are queries when responses are expected.
- ヘッダが合理的かチェックします。回答が期待されるのに問合せであるデー
タグラムを捨ててください。
- Parse the sections of the message, and insure that all RRs are
correctly formatted.
- メッセージの各部を解析し、すべての資源レコードが正確フォーマットで
あることを保証してください。
- As an optional step, check the TTLs of arriving data looking
for RRs with excessively long TTLs. If a RR has an
excessively long TTL, say greater than 1 week, either discard
the whole response, or limit all TTLs in the response to 1
week.
- 意の手順として、生存時間が著しく長い資源レコードがないか確認してく
ださい。もし資源レコードの生存時間が著しく長いなら、例えば１週間以
上なら、回答全体を捨てるか、すべての回答の生存時間を１週間に制限し
てください。
The next step is to match the response to a current resolver request.
The recommended strategy is to do a preliminary matching using the ID
field in the domain header, and then to verify that the question section
corresponds to the information currently desired. This requires that
the transmission algorithm devote several bits of the domain ID field to
a request identifier of some sort. This step has several fine points:
次の手順は現在のリゾルバ要求に対する回答と一致することです。推薦された戦
略はドメインヘッダーで識別子フィールドを使って一致するものを事前検査し、
次に質問部が望ましい情報に対応することを確かめる事です。これは送信アルゴ
リズムがドメイン識別子の何ビットかをメッセージの分類に使えることを要求し
ます。この手順にはいくつかの微妙なポイントがあります：
- Some name servers send their responses from different
addresses than the one used to receive the query. That is, a
resolver cannot rely that a response will come from the same
address which it sent the corresponding query to. This name
server bug is typically encountered in UNIX systems.
- あるネームサーバーが問合せを受信するのに使ったのと異なるアドレスか
ら回答を送ります。すなわち、質問と同じアドレスで回答を待つリゾルバ
が応答できません。このネームサーババグはＵＮＩＸシステムで典型的に
遭遇します。
- If the resolver retransmits a particular request to a name
server it should be able to use a response from any of the
transmissions. However, if it is using the response to sample
the round trip time to access the name server, it must be able
to determine which transmission matches the response (and keep
transmission times for each outgoing message), or only
calculate round trip times based on initial transmissions.
- もしリゾルバがネームサーバにあるリクエストを再送するなら、どの回答
のも使えるようにすべきです。しかし、回答をしたネームサーバーにアク
セスする往復時間を調べるなら、どの送信とどの回答が対応するか決定で
きるようにするか（そして全ての送信メッセージの送信時間を保持する）、
最初の送信に基づいて往復時間を計算しなければなりません。
- A name server will occasionally not have a current copy of a
zone which it should have according to some NS RRs. The
resolver should simply remove the name server from the current
SLIST, and continue.
- ネームサーバが時折あるネームサーバ資源レコードに関するゾーンの最新
のコピーを持たないでしょう。リゾルバはただネームサーバを現在のサー
バリストから除き、継続するべきです。
7.4. Using the cache
7.4. キャッシュの使用
In general, we expect a resolver to cache all data which it receives in
responses since it may be useful in answering future client requests.
However, there are several types of data which should not be cached:
一般に、リゾルバは未来のクライアント要求に答える際に有用かもしれないので、
回答で受け取るすべてのデータをキャッシュすることを期待します。しかしなが
ら、キャッシュすべきではないいくつかの種類のデータがあります：
- When several RRs of the same type are available for a
particular owner name, the resolver should either cache them
all or none at all. When a response is truncated, and a
resolver doesn't know whether it has a complete set, it should
not cache a possibly partial set of RRs.
- ある所有者名の同じ種類のいくつかの資源レコードが利用可能な時、リゾ
ルバはそれら全てをキャッシュするか、全てキャッシュしないかとすべき
です。回答が切り落とされ、リゾルバが完全な回答集合を持っているか知
らない時、部分的な資源レコード集合をキャッシュすべきではありません。
- Cached data should never be used in preference to
authoritative data, so if caching would cause this to happen
the data should not be cached.
- キャッシュされたデータが決して正式なデータに対して優先的に使われる
べきでありません、もしキャッシュでこれが生じるなら、データはキャッ
シュすべきではありません。
- The results of an inverse query should not be cached.
- 逆問合せの結果はキャッシュすべきではありません。
- The results of standard queries where the QNAME contains "*"
labels if the data might be used to construct wildcards. The
reason is that the cache does not necessarily contain existing
RRs or zone boundary information which is necessary to
restrict the application of the wildcard RRs.
- ワイルドカードを作る目的の問合せ名に"*"ラベルを含む標準問合せの、結
果。理由はキャッシュがワイルドカード資源レコードのアプリケーション
を限定するために必要な既存の資源レコードやゾーン限界の情報を含んで
いないからです。
- RR data in responses of dubious reliability. When a resolver
receives unsolicited responses or RR data other than that
requested, it should discard it without caching it. The basic
implication is that all sanity checks on a packet should be
performed before any of it is cached.
- 信頼性の疑わしい回答の資源レコードデータ。リゾルバが望まない回答や
求められたもの以外の資源レコードＲＲデータを受けとる時、それをキャッ
シュしない捨てるべきです。基本的な意味はすべてのパケットの安全点検
が、それをキャッシュする前に行うべきであるということです。
In a similar vein, when a resolver has a set of RRs for some name in a
response, and wants to cache the RRs, it should check its cache for
already existing RRs. Depending on the circumstances, either the data
in the response or the cache is preferred, but the two should never be
combined. If the data in the response is from authoritative data in the
answer section, it is always preferred.
類似の傾向で、リゾルバがある名前の資源レコードの回答得て、その資源レコー
ドをキャッシュすることを望む時、すでに既存の資源レコードがないかキャッシュ
をチェックするべきです。状況によって、回答のデータかキャッシュのデータが
優先されます、しかしこの２つは結合されるべきではありません。もし回答のデー
タが回答部で正式なデータなら、常に優先されます。
8. MAIL SUPPORT
8. メールサポート
The domain system defines a standard for mapping mailboxes into domain
names, and two methods for using the mailbox information to derive mail
routing information. The first method is called mail exchange binding
and the other method is mailbox binding. The mailbox encoding standard
and mail exchange binding are part of the DNS official protocol, and are
the recommended method for mail routing in the Internet. Mailbox
binding is an experimental feature which is still under development and
subject to change.
ドメインシステムはドメイン名の中にメールボックスをマップする標準と、メー
ル配信情報を得るためのメールボックス情報を使う２つの方法を定義します。最
初の方法はメール交換割付と呼ばれ、他の方法はメールボックス割付です。メー
ルボックスコーディング標準とメール交換割付はＤＮＳ公式プロトコルの一部で
あり、インターネットでメール配信の推薦された方法です。メールボックス割付
が実験的機能で開発中であり変化の可能性があります。
The mailbox encoding standard assumes a mailbox name of the form
"<local-part>@<mail-domain>". While the syntax allowed in each of these
sections varies substantially between the various mail internets, the
preferred syntax for the ARPA Internet is given in [RFC-822].
メールボックスコーディング標準は"<local-part>@<mail-domain>"形式のメール
ボックス名を想定します。これらの章の構文はインターネットメールの多様性の
ため十分多様ですが、ARPAインターネットの望ましい構文は[RFC-822]にあります。
The DNS encodes the <local-part> as a single label, and encodes the
<mail-domain> as a domain name. The single label from the <local-part>
is prefaced to the domain name from <mail-domain> to form the domain
name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-
NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the
<local-part> contains dots or other special characters, its
representation in a master file will require the use of backslash
quoting to ensure that the domain name is properly encoded. For
example, the mailbox Action.domains@ISI.EDU would be represented as
Action\.domains.ISI.EDU.
ＤＮＳはひとつのラベルとして<local-part>をコード化し、ドメイン名として
<mail-domain>をコード化します。メールボックスに対応しているドメイン名を
構成するために、<mail-domain>の前に<local-part>が付きます。それでメール
ボックスHOSTMASTER@SRI- NIC.ARPAはドメイン名HOSTMASTER.SRI-NIC.ARPA.に変
換されます。もし<local-part>がドットや他の特別な文字を含むなら、マスター
ファイル内でバックスラッシュで引用して表現することでドメイン名が正確にコー
ド化されることを保証するように要求されます。例えば、メールボックス
Action.domains@ISI.EDUはAction\.domains.ISI.EDUと表現されます。
8.1. Mail exchange binding
8.1. メール交換割付
Mail exchange binding uses the <mail-domain> part of a mailbox
specification to determine where mail should be sent. The <local-part>
is not even consulted. [RFC-974] specifies this method in detail, and
should be consulted before attempting to use mail exchange support.
メール交換割当でメールボックス仕様書の<mail-domain>部分がメールの送り先
を決定するのに使います。<local-part>は調べられません。[RFC-974]がこの方
法の詳細を指定し、メール交換を使う前に調べられるべきです。
One of the advantages of this method is that it decouples mail
destination naming from the hosts used to support mail service, at the
cost of another layer of indirection in the lookup function. However,
the addition layer should eliminate the need for complicated "%", "!",
etc encodings in <local-part>.
この方法の利点の１つが、メールサービスに使うホストとメールの宛先名を切り
離す時、検索機能で遠まわし層を使うコストです。しかし追加層は<local-part>
のコーディングで複雑な"%"や"!"の必要性を排除するべきである。
The essence of the method is that the <mail-domain> is used as a domain
name to locate type MX RRs which list hosts willing to accept mail for
<mail-domain>, together with preference values which rank the hosts
according to an order specified by the administrators for <mail-domain>.
方法の本質は、<mail-domain>はメール交換資源レコード内にでドメイン名とし
て用いられ、資源レコードは<mail-domain>のメールを受入れホストをリストアッ
プし、<mail-domain>管理者の指定した順序を示す優先値でホストを並べること
です。
In this memo, the <mail-domain> ISI.EDU is used in examples, together
with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would
route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name
VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
addresses.
このメモで<mail-domain>ISI.EDUが例に使い、ホストVENERA.ISI.EDUと
VAXA.ISI.EDUがISI.EDUのメールを交換します。もしメール送信者が
Mockapetris@ISI.EDUへのメッセージを持っていたら、ISI.EDUのメール交換資源
レコードを調べて配信経路を決めるでしょう。ISI.EDUのメール交換資源レコー
ドはVENERA.ISI.EDUとVAXA.ISI.EDUの名前を示し、アドレス種別の質問でホスト
アドレスを見つけだすことができます。
8.2. Mailbox binding (Experimental)
8.2. メールボックス割付(実験的）
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.
メールボックス割付で、メール送信者はドメイン名を組み立てるために全部のメー
ル宛先仕様を使います。メールボックスのためのコード化されたドメイン名は問
合せ種別＝MAILBの問合せ種別フィールドを用います。
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. 問合せはメールボックスがドメイン名として存在しないことを示す名前エ
ラーを返すことができます。
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 exchange binding at
this point.
長期間、これは指定されたメールボックスが存在しないことを示すでしょ
う。しかし、メールボックス割付の使用が一般的になるまで、このエラー
条件はメールアドレスのグローバルな部分に示される組織がメールボック
ス割当を使用していないことを意味すると解釈されるべきです。適切な手
順がこの時点で交換割付に逆戻りするはずです。
2. The query can return a Mail Rename (MR) RR.
2. 問合せはメール改名（MR）資源レコードを返すことができます。
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 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., b,SMTP.
メールボックス資源レコードが資源データフィールドでホストのドメイン
名を運びます。メール送信者は、適用可能なプロトコルで、例えばＳＭＴ
Ｐで、ホストへメッセージを届けるべきです。
4. The query can return one or more Mail Group (MG) RRs.
4. 問合せは１つ以上のメールグループ資源レコードを返すことができます。
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 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. 問合せはメールボックス資源レコードと１つ以上のメールグループ資源レ
コードを返すことができます。
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.
これらの場合のいずれも回答にメール情報（MINFO）資源レコードを含むかもし
れません。この資源レコードは通常メールグループと結び付きますが、メールボッ
クスでも正しいです。メール情報資源レコードは２つのメールボックスを識別し
ます。１つがオリジナルのメールボックス名の責任者を指定します。このメール
ボックスはメールグループに加入を要求するなどに使われるべきです。メール情
報資源レコードの２番目のメールボックス名はメール障害のエラーメッセージを
受け取るべきメールボックスを指定します。これは特にメーリングリストで、メ
ンバー名のエラーを、リストにメッセージを送る以外の、ある人に送る時に適切
です。
New fields may be added to this RR in the future.
新しいフィールドが将来この資源レコードに加えられるかもしれません。
9. REFERENCES and BIBLIOGRAPHY
9. 参考文献と文献目録
[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
Technical Plan - Name Service, April 1987, version 1.9.
Describes the fundamentals of the Hesiod name service.
ヘシオドネームサービスの基本を記述します。
[IEN-116] J. Postel, "Internet Name Server", IEN-116,
USC/Information Sciences Institute, August 1979.
A name service obsoleted by the Domain Name System, but
still in use.
ドメインネームシステムで時代遅れになるが、まだ使用中のネー
ムサービス。
[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
Communications of the ACM, October 1986, volume 29, number
10.
[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
Information Center, SRI International, December 1977.
[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
USC/Information Sciences Institute, August 1980.
[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
USC/Information Sciences Institute, September 1981.
[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
September 1981.
Suggests introduction of a hierarchy in place of a flat
name space for the Internet.
インターネットにフラットな名前空間の代わりに階層の導入を
勧めます。
[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
USC/Information Sciences Institute, February 1982.
[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
Internet Host Table Specification", RFC-810, Network
Information Center, SRI International, March 1982.
Obsolete. See RFC-952.
時代遅れ。RFC-952参照。
[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
Server", RFC-811, Network Information Center, SRI
International, March 1982.
Obsolete. See RFC-953.
時代遅れ。RFC-953参照。
[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
Network Information Center, SRI International, March
1982.
[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC-819, Network
Information Center, SRI International, August 1982.
Early thoughts on the design of the domain system.
Current implementation is completely different.
ドメインシステムのデザインについての初期の考え。現在の実
装は完全に異なっています。
[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
USC/Information Sciences Institute, August 1980.
[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
RFC-830, Network Information Center, SRI International,
October 1982.
Early thoughts on the design of the domain system.
Current implementation is completely different.
ドメインシステムのデザインについての初期の考え。現在の実
装は完全に異なっています。
[RFC-882] P. Mockapetris, "Domain names - Concepts and
Facilities," RFC-882, USC/Information Sciences
Institute, November 1983.
Superceeded by this memo.
このメモに取って変わられました。
[RFC-883] P. Mockapetris, "Domain names - Implementation and
Specification," RFC-883, USC/Information Sciences
Institute, November 1983.
Superceeded by this memo.
このメモに取って変わられました。
[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
RFC-920, USC/Information Sciences Institute,
October 1984.
Explains the naming scheme for top level domains.
最上位ドメインの命名案を説明します。
[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
Table Specification", RFC-952, SRI, October 1985.
Specifies the format of HOSTS.TXT, the host/address
table replaced by the DNS.
HOSTS.TXT のフォーマットを指定します、ホスト／アドレステー
ブルはＤＮＳで置き換えらます。
[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
RFC-953, SRI, October 1985.
This RFC contains the official specification of the
hostname server protocol, which is obsoleted by the DNS.
This TCP based protocol accesses information stored in
the RFC-952 format, and is used to obtain copies of the
host table.
このＲＦＣはホスト名サーバープロトコルの公式仕様書を含み、
ＤＮＳで時代遅れにされます。このＴＣＰベースプロトコルは
RFC-952フォーマットで記憶された情報へのアクセスをし、ホス
トテーブルのコピーを得るために使われます。
[RFC-973] P. Mockapetris, "Domain System Changes and
Observations", RFC-973, USC/Information Sciences
Institute, January 1986.
Describes changes to RFC-882 and RFC-883 and reasons for
them.
RFC-882とRFC-883への変更とその理由を記述します。
[RFC-974] C. Partridge, "Mail routing and the domain system",
RFC-974, CSNET CIC BBN Labs, January 1986.
Describes the transition from HOSTS.TXT based mail
addressing to the more powerful MX system used with the
domain system.
HOSTS.TXTベースのメールからより強力なドメインシステムで
使われるMXたシステムへの移行を記述します。
[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Concepts and Methods",
RFC-1001, March 1987.
This RFC and RFC-1002 are a preliminary design for
NETBIOS on top of TCP/IP which proposes to base NetBIOS
name service on top of the DNS.
このRFCとRFC-1002はTCP/IP上のNETBIOSの予備デザインで、
DNS上でのNetBIOS名前サービスを提案します。
[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Detailed
Specifications", RFC-1002, March 1987.
[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
USC/Information Sciences Institute, May 1987.
Contains socket numbers and mnemonics for host names,
operating systems, etc.
ホスト名、オペレーティングシステムのためのソケット番号と
名称を含んでいます。
[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
November 1987.
Describes a plan for converting the MILNET to the DNS.
MILNETをＤＮＳに変換する計画を記述します。
[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
Administrators", RFC-1032, November 1987.
Describes the registration policies used by the NIC to
administer the top level domains and delegate subzones.
最上位ドメインの管理とサブドメイン委任をするためにＮＩＣ
によって使われた登録方針を記述します。
[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
RFC-1033, November 1987.
A cookbook for domain administrators.
ドメイン管理者のための料理の本
[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
Name Server", Computer Networks, vol 6, nr 3, July 1982.
Describes a name service for CSNET which is independent
from the DNS and DNS use in the CSNET.
ＤＮＳに依存しないCSNETのネームサービスとCSNETでのＤＮＳ
使用を記述します。
Index
索引
*
;
<character-string>
<domain-name>
@
\
A
Byte order
CH
Character case
CLASS
CNAME
Completion
CS
Hesiod
HINFO
HS
IN
IN-ADDR.ARPA domain
Inverse queries
Mailbox names
MB
MD
MF
MG
MINFO
MINIMUM
MR
MX
NS
NULL
Port numbers
Primary server
PTR
QCLASS
QTYPE
RDATA
RDLENGTH
Secondary server
SOA
Stub resolvers
TCP
TXT
TYPE
UDP
WKS