この文書はRFC1034の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
1. STATUS OF THIS MEMO このメモの状態 2. INTRODUCTION はじめに 2.1. The history of domain names ドメイン名の歴史 2.2. DNS design goals ＤＮＳ構想の目標 2.3. Assumptions about usage 利用に関する仮定 2.4. Elements of the DNS ＤＮＳの要素 3. DOMAIN NAME SPACE and RESOURCE RECORDS ドメイン空間と資源レコード 3.1. Name space specifications and terminology 名前空間仕様と用語 3.2. Administrative guidelines on use 利用上の管理ガイドライン 3.3. Technical guidelines on use 利用上の技術的ガイドライン 3.4. Example name space 名前空間の例 3.5. Preferred name syntax 望ましい名前文法 3.6. Resource Records 資源レコード 3.6.1. Textual expression of RRs 資源レコードのテキスト表現 3.6.2. Aliases and canonical names 別名と標準名 3.7. Queries 問合せ 3.7.1. Standard queries 標準問合せ 3.7.2. Inverse queries (Optional) 逆問合せ（任意） 3.8. Status queries (Experimental) 状態問合せ（実験的） 3.9. Completion queries (Obsolete) 完成の質問（時代遅れ） 4. NAME SERVERS ネームサービス 4.1. Introduction はじめに 4.2. How the database is divided into zones データベースをゾーンに分ける方法 4.2.1. Technical considerations 技術的な考慮 4.2.2. Administrative considerations 管理上の考慮 4.3. Name server internals ネームサーバの内部 4.3.1. Queries and responses 問合せと回答 4.3.2. Algorithm アルゴリズム 4.3.3. Wildcards ワイルドカード 4.3.4. Negative response caching (Optional) 否定応答のキャッシュ（任意） 4.3.5. Zone maintenance and transfers ゾーン維持と転送 5. RESOLVERS リゾルバ 5.1. Introduction はじめに 5.2. Client-resolver interface クライアント−リゾルバインターフェース 5.2.1. Typical functions 典型的な機能 5.2.2. Aliases 別名 5.2.3. Temporary failures 一時的障害 5.3. Resolver internals リゾルバの内部 5.3.1. Stub resolvers 低機能リゾルバ 5.3.2. Resources 資源 5.3.3. Algorithm アルゴリズム 6. A SCENARIO 筋書き 6.1. C.ISI.EDU name server C.ISI.EDUネームサーバ 6.2. Example standard queries 標準問合せ 6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A 質問名=SRI-NIC.ARPA, 質問タイプ=A 6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=* 質問名=SRI-NIC.ARPA, 質問タイプ=* 6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX 質問名=SRI-NIC.ARPA, 質問タイプ=MX 6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS 質問名=SRI-NIC.ARPA, 質問タイプ=NS 6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A 質問名=SIR-NIC.ARPA, 質問タイプ=A 6.2.6. QNAME=BRL.MIL, QTYPE=A 質問名=BRL.MIL, 質問タイプ=A 6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A 質問名=USC-ISIC.ARPA, 質問タイプ=A 6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME 質問名=USC-ISIC.ARPA, 質問タイプ=CNAME 6.3. Example resolution 解決例 6.3.1. Resolve MX for ISI.EDU. ISI.EDUのMXの解決 6.3.2. Get the host name for address 26.6.0.65 アドレス26.6.0.65のホスト名を得る 6.3.3. Get the host address of poneria.ISI.EDU poneria.ISI.EDUのホストアドレスを得る 7. REFERENCES and BIBLIOGRAPHY 参考文献と文献目録 Index 索引
Network Working Group P. Mockapetris
Request for Comments: 1034 ISI
Obsoletes: RFCs 882, 883, 973 November 1987
DOMAIN NAMES - CONCEPTS AND FACILITIES
ドメイン名 − 概念と機能
1. STATUS OF THIS MEMO
1. このメモの状態
This RFC is an introduction to the Domain Name System (DNS), and omits
many details which can be found in a companion RFC, "Domain Names -
Implementation and Specification" [RFC-1035]. That RFC assumes that the
reader is familiar with the concepts discussed in this memo.
このRFCはドメインネームシステム(DNS)の紹介であり、関連するRFC「ドメイン
名−実装と仕様書」[RFC-1035]に記載してる細部は書いていません。RFC1035は
読者がこのメモで論じた概念に精通していると想定します。
A subset of DNS functions and data types constitute an official
protocol. The official protocol includes standard queries and their
responses and most of the Internet class data formats (e.g., host
addresses).
ＤＮＳ機能とデータタイプの一部が公式プロトコルです。公式プロトコルは標準
問合せとその回答とほとんどのインターネットクラスデータフォーマットを含み
ます（例えば、ホストアドレス）。
However, the domain system is intentionally extensible. Researchers are
continuously proposing, implementing and experimenting with new data
types, query types, classes, functions, etc. Thus while the components
of the official protocol are expected to stay essentially unchanged and
operate as a production service, experimental behavior should always be
expected in extensions beyond the official protocol. 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.
手本に示す値は教育的な目的で記載してるので、読者はそれが現在の値であると
か正しい値であるとか思わないように注意してください。このメモの配布は無制
限です。
2. INTRODUCTION
2. はじめに
This RFC introduces domain style names, their use for Internet mail and
host address support, and the protocols and servers used to implement
domain name facilities.
このＲＦＣはドメインスタイル名を導入し、これはインターネットメールやホス
トアドレス検索やドメイン名機能を使うプロトコルやサービスで使われます。
2.1. The history of domain names
2.1. ドメイン名の歴史
The impetus for the development of the domain system was growth in the
Internet:
ドメインシステムの開発のきっかけはインターネットの増加でした：
- Host name to address mappings were maintained by the Network
Information Center (NIC) in a single file (HOSTS.TXT) which
was FTPed by all hosts [RFC-952, RFC-953]. The total network
bandwidth consumed in distributing a new version by this
scheme is proportional to the square of the number of hosts in
the network, and even when multiple levels of FTP are used,
the outgoing FTP load on the NIC host is considerable.
Explosive growth in the number of hosts didn't bode well for
the future.
- ホスト名とアドレスの対応はネットワーク情報センター(NIC)で維持され、
これは１つのファイル(HOSTS.TXT)を全てのホストへFTPで送ることで行っ
ていました[RFC-952,RFC-953]。この方法で新版を配るために消費された全
体のネットワークバンド幅はネットワークホスト数の２乗に比例します、
そして多段レベルのＦＴＰを使ていても、NICホストの外へのFTP負荷はか
なりです。ホスト数の爆発的増加は将来の良い前兆ではありませんでした。
- The network population was also changing in character. The
timeshared hosts that made up the original ARPANET were being
replaced with local networks of workstations. Local
organizations were administering their own names and
addresses, but had to wait for the NIC to change HOSTS.TXT to
make changes visible to the Internet at large. Organizations
also wanted some local structure on the name space.
- ネットワーク利用者の性格も同じく変化していました。昔のARPANETを構成
したタイムシェアリングホストはワークステーションを使ったローカルネッ
トワークで置き換えられていました。ローカル組織が自分自身の名前とア
ドレスを管理していました、しかしインターネットから見えるようにする
にはNICのHOSTS.TXTが変わるまで待たなければなりませんでした。組織が
名前空間になんらかのローカルな空間を欲していました。
- The applications on the Internet were getting more
sophisticated and creating a need for general purpose name
service.
- インターネット上のアプリケーションはより凝ったものになり、汎用のネー
ムサービスの要求が生まれました。
The result was several ideas about name spaces and their management
[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a
common thread was the idea of a hierarchical name space, with the
hierarchy roughly corresponding to organizational structure, and names
using "." as the character to mark the boundary between hierarchy
levels. A design using a distributed database and generalized resources
was described in [RFC-882, RFC-883]. Based on experience with several
implementations, the system evolved into the scheme described in this
memo.
名前空間とその管理に関する数々のアイデアが出ました[IEN-116, RFC-799,
RFC-819, RFC-830]。提案はいろいろ変わりましたが、階層的な名前空間を使う
ことと、階層が組織に対応した構造にする事と、名前に"."の文字を使い階層の
区切りとすることが、共通認識となりました。分散データベースと一般化された
資源を使うデザインが[RFC-882, RFC-883]で記述されました。いくつかの実装経
験に基づいて、システムはこのメモで記述された形に発展しました。
The terms "domain" or "domain name" are used in many contexts beyond the
DNS described here. Very often, the term domain name is used to refer
to a name with structure indicated by dots, but no relation to the DNS.
This is particularly true in mail addressing [Quarterman 86].
用語「ドメイン」あるいは「ドメイン名」がここで記述されたＤＮＳ以外で多く
の文脈で使われます。非常によく、ドメイン名という用語はＤＮＳの関係ではな
く、点で区切られた構造の名前に使われます。これはメールアドレスで特に本当
です[Quarterman 86]。
2.2. DNS design goals
2.2. ＤＮＳ構想の目標
The design goals of the DNS influence its structure. They are:
ＤＮＳ構想の目標はその構造に影響を与えます。これは：
- The primary goal is a consistent name space which will be used
for referring to resources. In order to avoid the problems
caused by ad hoc encodings, names should not be required to
contain network identifiers, addresses, routes, or similar
information as part of the name.
- 主要な目標は資源を参照するのに使う一貫した名前空間です。特別なコー
ディングにより起こる問題を避けるために、名前の一部にネットワーク識
別子、アドレス、ルート、あるいは類似の情報を含むように要求されるべ
きではありません。
- The sheer size of the database and frequency of updates
suggest that it must be maintained in a distributed manner,
with local caching to improve performance. Approaches that
attempt to collect a consistent copy of the entire database
will become more and more expensive and difficult, and hence
should be avoided. The same principle holds for the structure
of the name space, and in particular mechanisms for creating
and deleting names; these should also be distributed.
- データベースの薄い大きさと更新の頻度は、データベースが分散的に管理
されなければならないことを示唆し、ローカルキャッシュが性能を改善し
ます。全部のデータベースの完全なコピーを集める方法は高くつくし難し
いので避けるべきです。同じ事は名前空間の構造でも真実で、特に名前を
作るのと削除する方法は、これも分散して行えるべきです。
- Where there tradeoffs between the cost of acquiring data, the
speed of updates, and the accuracy of caches, the source of
the data should control the tradeoff.
- データ獲得のコストと更新の速さとキャッシュの正確さのトレードオフが
あり、データ生成源がトレードオフをコントロールするべきです。
- The costs of implementing such a facility dictate that it be
generally useful, and not restricted to a single application.
We should be able to use names to retrieve host addresses,
mailbox data, and other as yet undetermined information. All
data associated with a name is tagged with a type, and queries
can be limited to a single type.
- このような機能を実装するコストは、これがひとつのアプリケーションに
限定されず、一般的に有用なことを必要とします。名前がホストアドレス
とメールボックスデータと他のまだ存在しない情報を検索するための名前
に利用可能であるべきです。ある名前と関連する全てのデータが種別札を
つけられ、問合せが１つの札に限定できます。
- Because we want the name space to be useful in dissimilar
networks and applications, we provide the ability to use the
same name space with different protocol families or
management. For example, host address formats differ between
protocols, though all protocols have the notion of address.
The DNS tags all data with a class as well as the type, so
that we can allow parallel use of different formats for data
of type address.
- 我々が異なるネットワークとアプリケーションで利用できる名前空間を欲
するので、我々は異なるプロトコルファミリーや管理で同じ名前空間を使
う能力に提供します。例えば、ホストアドレスフォーマットはプロトコル
毎に異なりますが、すべてのプロトコルがアドレスの考えを持ちます。Ｄ
ＮＳはデータに種別札だけでなくクラス札もつけます、これで我々は異なっ
たフォーマットのアドレス種別データを平行して扱えます。
- We want name server transactions to be independent of the
communications system that carries them. Some systems may
wish to use datagrams for queries and responses, and only
establish virtual circuits for transactions that need the
reliability (e.g., database updates, long transactions); other
systems will use virtual circuits exclusively.
- 我々はネームサーバ処理がそれを運ぶ通信システムから独立していること
を望みます。あるシステムが問合せと回答にデータグラムを使い、そして
信頼性が必要な処理にだけ仮想回路を接続するのを望むかもしれません
（例えば、データベース更新、長い処理）；他のシステムが排他的に仮想
の回路を使うでしょう。
- The system should be useful across a wide spectrum of host
capabilities. Both personal computers and large timeshared
hosts should be able to use the system, though perhaps in
different ways.
- システムは様々な能力のホストで使えるべきです。パーソナル・コンピュー
タと大きなタイムシェアリングホストの両方が、多分異なった方法ですが、
システムを使えるべきです。
2.3. Assumptions about usage
2.3. 利用に関する仮定
The organization of the domain system derives from some assumptions
about the needs and usage patterns of its user community and is designed
to avoid many of the the complicated problems found in general purpose
database systems.
ドメインシステムの組織は、ユーザ共同体の要求と使い方のパターンにある仮定
をし、一般的な目的のデータベースシステムの複雑な問題を避けています。
The assumptions are:
その仮定は：
- The size of the total database will initially be proportional
to the number of hosts using the system, but will eventually
grow to be proportional to the number of users on those hosts
as mailboxes and other information are added to the domain
system.
- 完全なデータベースの大きさは、当初はシステムを使うホスト数に比例す
るでしょうが、最終的にはメールボックスや他の情報がドメインシステム
に追加されるので、ホスト上のユーザー数に比例していくでしょう。
- Most of the data in the system will change very slowly (e.g.,
mailbox bindings, host addresses), but that the system should
be able to deal with subsets that change more rapidly (on the
order of seconds or minutes).
- システムのデータの大部分が非常にゆっくりと変化するでしょう（例えば、
メールボックス割当て、ホストアドレス）が、システムのある部分では急
激に変化するデータを扱えるべきでしょう（秒単位や分単位の変化）。
- The administrative boundaries used to distribute
responsibility for the database will usually correspond to
organizations that have one or more hosts. Each organization
that has responsibility for a particular set of domains will
provide redundant name servers, either on the organization's
own hosts or other hosts that the organization arranges to
use.
- データベースの分散した責務の管理境界は通常１つ以上のホストを持つ組
織に対応するでしょう。ドメインある部分に責任をもつ組織は、自分自身
でまたはその組織が使えるように整えられたホストで、重複したネームサー
バーを供給するでしょう。
- Clients of the domain system should be able to identify
trusted name servers they prefer to use before accepting
referrals to name servers outside of this "trusted" set.
- ドメインシステムのクライアントは、信頼できるネームサーバ以外に照会
をする前に、信頼できるネームサーバの識別を可能とするべきです。
- Access to information is more critical than instantaneous
updates or guarantees of consistency. Hence the update
process allows updates to percolate out through the users of
the domain system rather than guaranteeing that all copies are
simultaneously updated. When updates are unavailable due to
network or host failure, the usual course is to believe old
information while continuing efforts to update it. The
general model is that copies are distributed with timeouts for
refreshing. The distributor sets the timeout value and the
recipient of the distribution is responsible for performing
the refresh. In special situations, very short intervals can
be specified, or the owner can prohibit copies.
- 情報へのアクセスは瞬間的な更新、首尾一貫性の保証より重要です。その
ため更新プロセスは、一斉に更新を行うのではなく、少しづつドメインシ
ステムユーザへ更新を行うことを許します。ネットワークはホストの障害
で更新が出来ないときは、データ更新の努力をする間、古い情報を信じる
はずです。一般的なモデルはデータのコピーが更新するためのタイムアウ
ト値と一緒に配布されることです。配布側はタイムアウト値をつけ、受け
取り側は更新を行う責任があります。特別場合、とても短い間隔を指定し
たり、コピーを禁止することができます。
- In any system that has a distributed database, a particular
name server may be presented with a query that can only be
answered by some other server. The two general approaches to
dealing with this problem are "recursive", in which the first
server pursues the query for the client at another server, and
"iterative", in which the server refers the client to another
server and lets the client pursue the query. Both approaches
have advantages and disadvantages, but the iterative approach
is preferred for the datagram style of access. The domain
system requires implementation of the iterative approach, but
allows the recursive approach as an option.
- 分散データベースを持つシステムには、他のネームサーバでないと答えら
れない問合せが来るかもしれません。この問題を扱う２つの一般的な方法
は、最初のサーバーが他のサーバーへクライアントの問合せ転送する「再
帰」と、サーバがクライアントに他のサーバを示して問合せをしなおさせ
る「反復」です。両方の方法とも利点と欠点を持ちますが、反復の方法は
データグラムでのアクセスに向いています。ドメインシステムは反復の方
法の実装を必要としますが、オプションで再帰も許します。
The domain system assumes that all data originates in master files
scattered through the hosts that use the domain system. These master
files are updated by local system administrators. Master files are text
files that are read by a local name server, and hence become available
through the name servers to users of the domain system. The user
programs access name servers through standard programs called resolvers.
ドメインシステムはすべてのデータがあちこちに散らばるドメインシステムを使
うホストのマスターファイルから始まると想定します。これらのマスターファイ
ルはローカルシステム管理者によって更新されます。マスターファイルはローカ
ルネームサーバーに読まれるテキストファイルであり、ネームサーバを通してド
メインシステムのユーザーに入手可能になります。ユーザープログラムはリゾル
バと呼ばれる標準プログラムを通してネームサーバーにアクセスします。
The standard format of master files allows them to be exchanged between
hosts (via FTP, mail, or some other mechanism); this facility is useful
when an organization wants a domain, but doesn't want to support a name
server. The organization can maintain the master files locally using a
text editor, transfer them to a foreign host which runs a name server,
and then arrange with the system administrator of the name server to get
the files loaded.
マスターファイルの標準フォーマットは、マスターファイルをホスト間で交換す
ることを可能にします（FTPやメールや何か他の方法で）；この方法は組織がド
メインは欲しいがネームサーバの運用をしたくないときに有用です。組織はテキ
ストエディタを使ってローカルにマスターファイルを管理し、それをネームサー
バを動かす他のホストに移し、次にネームサーバのシステム管理者がファイルを
ロードできるようにします。
Each host's name servers and resolvers are configured by a local system
administrator [RFC-1033]. For a name server, this configuration data
includes the identity of local master files and instructions on which
non-local master files are to be loaded from foreign servers. The name
server uses the master files or copies to load its zones. For
resolvers, the configuration data identifies the name servers which
should be the primary sources of information.
各ホストのネームサーバとリゾルバはローカルシステム管理者が設定します
[RFC-1033]。ネームサーバの設定データにはローカルマスターファイルの識別と、
ローカルでないマスターファイルを他のサーバから読込む指令を含みます。ネー
ムサーバーはゾーンを読込むのにマスターファイルかそのコピーを使います。リ
ゾルバの設定データは情報の主な情報源であるネームサーバを識別するデータを
含みます。
The domain system defines procedures for accessing the data and for
referrals to other name servers. The domain system also defines
procedures for caching retrieved data and for periodic refreshing of
data defined by the system administrator.
ドメインシステムはデータアクセスと他のネームサーバの参照の手順を定義しま
す。ドメインシステムはキャッシュとシステム管理者に指定されたデータ周期更
新の手順も定義します。
The system administrators provide:
システム管理者が用意：
- The definition of zone boundaries.
- ゾーン境界の定義
- Master files of data.
- データのマスターファイル
- Updates to master files.
- マスターファイルの更新
- Statements of the refresh policies desired.
- 要求するリフレッシュポリシーの声明
The domain system provides:
ドメインシステムの提供：
- Standard formats for resource data.
- リソースデータの標準フォーマット。
- Standard methods for querying the database.
- データベースに問合せの標準方法。
- Standard methods for name servers to refresh local data from
foreign name servers.
- ネームサーバーが他のネームサーバから得たローカルデータを更新する標
準方法。
2.4. Elements of the DNS
2.4. ＤＮＳの要素
The DNS has three major components:
ＤＮＳには３つの主要な構成要素があります：
- The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
specifications for a tree structured name space and data
associated with the names. Conceptually, each node and leaf
of the domain name space tree names a set of information, and
query operations are attempts to extract specific types of
information from a particular set. A query names the domain
name of interest and describes the type of resource
information that is desired. For example, the Internet
uses some of its domain names to identify hosts; queries for
address resources return Internet host addresses.
- 木構造のドメイン名空間と名前と結びついた資源レコードの仕様。概念的
に、ドメイン木のノードとリーフが情報の名前で、問合せは特定の情報種
別を抽出する試みです。問合せが興味をもつドメイン名を指定し、要望す
る資源情報の種別を指定します。例えば、インターネットはホストを識別
するドメイン名を使い、アドレス資源を問合せ、インターネットホストア
ドレスを得ます。
- NAME SERVERS are server programs which hold information about
the domain tree's structure and set information. A name
server may cache structure or set information about any part
of the domain tree, but in general a particular name server
has complete information about a subset of the domain space,
and pointers to other name servers that can be used to lead to
information from any part of the domain tree. Name servers
know the parts of the domain tree for which they have complete
information; a name server is said to be an AUTHORITY for
these parts of the name space. Authoritative information is
organized into units called ZONEs, and these zones can be
automatically distributed to the name servers which provide
redundant service for the data in a zone.
- ネームサーバはドメイン木構造と情報を持つサーバープログラムです。ネー
ムサーバーがドメイン木のある部分の構造や情報をキャッシュできます、
しかし一般にあるネームサーバはドメイン空間のある部分木の完全な情報
と、他の部分にある情報を導くポインタを持ちます。ネームサーバーがド
メイン木の一部を知っていて、その部分の完全な情報をもちます；ネーム
サーバが名前空間のこの部分の権威（正式）と言われます。正式情報が
ゾーンと言われる単位で構成され、ゾーンは、ゾーンのデータを重複して
持つネームサーバーへ自動的に配布されます。
- RESOLVERS are programs that extract information from name
servers in response to client requests. Resolvers must be
able to access at least one name server and use that name
server's information to answer a query directly, or pursue the
query using referrals to other name servers. A resolver will
typically be a system routine that is directly accessible to
user programs; hence no protocol is necessary between the
resolver and the user program.
- リゾルバはクライアントの問合せに応えてネームサーバから情報を抽出す
るプログラムです。リゾルバは少なくとも１つのネームサーバにアクセス
して、ネームサーバの情報を直接問合せに答えるか、あるいは他のネーム
サーバを紹介され問合せ続けることができなければなりません。典型的な
リゾルバが直接ユーザープログラムがアクセスできるシステムルーチンで
す；そのためリゾルバとユーザープログラム間のプロトコルは必要であり
ません。
These three components roughly correspond to the three layers or views
of the domain system:
これらの３つの構成要素はだいたいドメインシステムの３つのレイヤあるいは
観点に対応します：
- From the user's point of view, the domain system is accessed
through a simple procedure or OS call to a local resolver.
The domain space consists of a single tree and the user can
request information from any section of the tree.
- ユーザーの観点で、ドメインシステムはローカルリゾルバへの単純な処理
かOS呼出しを通してアクセスされます。ドメイン空間は１つの木からなり、
ユーザーは木のどんな部分からでも情報を求めることができます。
- From the resolver's point of view, the domain system is
composed of an unknown number of name servers. Each name
server has one or more pieces of the whole domain tree's data,
but the resolver views each of these databases as essentially
static.
- リゾルバの観点で、ドメインシステムは数え切れないネームサーバで構成
されています。各ネームサーバが全ドメイン木データの内のいくつかの部
分を持っていますが、リゾルバは各データベースが本質的に静的と見ます。
- From a name server's point of view, the domain system consists
of separate sets of local information called zones. The name
server has local copies of some of the zones. The name server
must periodically refresh its zones from master copies in
local files or foreign name servers. The name server must
concurrently process queries that arrive from resolvers.
- ネームサーバの観点でドメインシステムは、ゾーンと呼ばれるローカル情
報から成り立ちます。ネームサーバはいくつかのゾーンのローカルコピー
を持ちます。ネームサーバーはローカルファイルや他のネームサーバーで
原本から周期的にそのゾーン情報を更新しなくてはなりません。ネームサー
バーは同時にリゾルバから来る問合せを処理しなくてはなりません。
In the interests of performance, implementations may couple these
functions. For example, a resolver on the same machine as a name server
might share a database consisting of the the zones managed by the name
server and the cache managed by the resolver.
処理能力の問題で実際の実装は、複数の機能がつながっているかもしれません。
例えば、同じマシン上のリゾルバとネームサーバーは、ネームサーバの管理す
るゾーンとリゾルバの管理するキャッシュの両データベースを共有するかもし
れません。
3. DOMAIN NAME SPACE and RESOURCE RECORDS
3. ドメイン空間と資源レコード
3.1. Name space specifications and terminology
3.1. 名前空間仕様と用語
The domain name space is a tree structure. Each node and leaf on the
tree corresponds to a resource set (which may be empty). The domain
system makes no distinctions between the uses of the interior nodes and
leaves, and this memo uses the term "node" to refer to both.
ドメイン名空間は木構造です。木の各ノードとリーフが資源（空かもしれない）
に対応します。ドメインシステムは内部ノードとリーフの扱いに区別をせず、
この文書では両者を示すのに「ノード」という用語を使います。
Each node has a label, which is zero to 63 octets in length. Brother
nodes may not have the same label, although the same label can be used
for nodes which are not brothers. One label is reserved, and that is
the null (i.e., zero length) label used for the root.
それぞれのノードがラベルを持ち、その長さは０から６３オクテットです。同じ
階層のノードが異なるラベルを使うだろうし、異なる階層のノードが同じラベル
を使えます。１つのラベルが予約され、これはヌル（つまり長さがゼロ）ラベル
で木の根っ子に使います。
The domain name of a node is the list of the labels on the path from the
node to the root of the tree. By convention, the labels that compose a
domain name are printed or read left to right, from the most specific
(lowest, farthest from the root) to the least specific (highest, closest
to the root).
ノードのドメイン名は、ノードから木の根までのパス上のラベルのリストです。
決まり事として、ドメイン名を構成するラベルを印刷したり読んだりする際は左
から右の順で、最も細かい（下位、根から遠い側）から最も粗い（上位、根に近
い）にします。
Internally, programs that manipulate domain names should represent them
as sequences of labels, where each label is a length octet followed by
an octet string. Because all domain names end at the root, which has a
null string for a label, these internal representations can use a length
byte of zero to terminate a domain name.
ドメイン名を操るプログラムの内部では、ドメイン名をラベルの連続として表現
すべきで、各ラベルは長さオクテットとオクテット列からなるべきです。すべて
のドメイン名がルートで終わり、ルートがヌル文字列なので、内部表現ではドメ
イン名の終わりとしてゼロ値の長さオクテットが使えます。
By convention, domain names can be stored with arbitrary case, but
domain name comparisons for all present domain functions are done in a
case-insensitive manner, assuming an ASCII character set, and a high
order zero bit. This means that you are free to create a node with
label "A" or a node with label "a", but not both as brothers; you could
refer to either using "a" or "A". When you receive a domain name or
label, you should preserve its case. The rationale for this choice is
that we may someday need to add full binary domain names for new
services; existing services would not be changed.
決まり事としてドメイン名には大文字も小文字も設定できます、しかしドメイン
機能のあちこちでドメイン名を比較する際は大文字小文字を同じものとみなし、
ASCII文字と仮定し、最上位ビットがゼロと仮定します。これは"A"というラベル
のノードも"a"というラベルのノードも作ることは出来るけど、これらは兄弟関
係にあるのではなく、どちらもも"A"や"a"として参照される事を意味します。ド
メイン名やラベルを受け取る時に、その大文字小文字を維持するべきです。この
理由はいつか新しいサービスのために完全な２進法のドメイン名を加える必要が
あるかもしれないからです；既存のサービスを変えずに済むでしょう。
When a user needs to type a domain name, the length of each label is
omitted and the labels are separated by dots ("."). Since a complete
domain name ends with the root label, this leads to a printed form which
ends in a dot. We use this property to distinguish between:
ユーザーがドメイン名をタイプする必要がある時、各ラベルの長さはタイプせず、
ラベルはドット(".")で分割されます。完全なドメイン名はルートラベルで終わ
るので、これはドットで終わる印刷書式になります。次の区別にこの特徴を使い
ます：
- a character string which represents a complete domain name
(often called "absolute"). For example, "poneria.ISI.EDU."
- 完全なドメイン名を表す文字列（しばしば「絶対」と呼ばれる）。
例えば、"poneria.ISI.EDU."。
- a character string that represents the starting labels of a
domain name which is incomplete, and should be completed by
local software using knowledge of the local domain (often
called "relative"). For example, "poneria" used in the
ISI.EDU domain.
- 不完全なドメイン名のラベル列を表現する文字列、ローカルソフトウェア
がローカルドメインの知識を使って完全なものにしなければならない（し
ばしば「相対的」と呼ばれる）。例えば、ISI.EDUドメインで"poneria"の
使用。
Relative names are either taken relative to a well known origin, or to a
list of domains used as a search list. Relative names appear mostly at
the user interface, where their interpretation varies from
implementation to implementation, and in master files, where they are
relative to a single origin domain name. The most common interpretation
uses the root "." as either the single origin or as one of the members
of the search list, so a multi-label relative name is often one where
the trailing dot has been omitted to save typing.
相対的な名前に既知の出発点か検索リストと扱われるドメインのリストが使われ
ます。相対的な名前がたいていユーザ・インタフェースで現れ、その解釈は実装
により異なり、マスターファイルでは１つの出発点ドメイン名に関連します。最
も一般的な解釈はルート"."を出発点に使うか検索リストのどれかを使うかで、
相対的なラベルがタイプの手間を省きます。
To simplify implementations, the total number of octets that represent a
domain name (i.e., the sum of all label octets and label lengths) is
limited to 255.
実装を単純化するために、ドメイン名を表すオクテットの合計の数（すべてのラ
ベルオクテットとラベル長の合計）は２５５に制限されます。
A domain is identified by a domain name, and consists of that part of
the domain name space that is at or below the domain name which
specifies the domain. A domain is a subdomain of another domain if it
is contained within that domain. This relationship can be tested by
seeing if the subdomain's name ends with the containing domain's name.
For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
ドメインがドメイン名で識別され、ドメイン名空間の一部で、ドメインを示すド
メイン名に、あるいは下にあります。ドメインは、他のドメインに含まれていれ
ば、他のドメインのサブドメインです。この関係はサブドメインの名前の終わり
がドメインの名前か調べることでわかります。例えば、A.B.C.DはB.C.DとC.DとD
と" "のサブドメインです。
3.2. Administrative guidelines on use
3.2. 利用上の管理ガイドライン
As a matter of policy, the DNS technical specifications do not mandate a
particular tree structure or rules for selecting labels; its goal is to
be as general as possible, so that it can be used to build arbitrary
applications. In particular, the system was designed so that the name
space did not have to be organized along the lines of network
boundaries, name servers, etc. The rationale for this is not that the
name space should have no implied semantics, but rather that the choice
of implied semantics should be left open to be used for the problem at
hand, and that different parts of the tree can have different implied
semantics. For example, the IN-ADDR.ARPA domain is organized and
distributed by network and host address because its role is to translate
from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
1002] are flat because that is appropriate for that application.
ポリシーの問題として、ＤＮＳ技術仕様書は特定の木構造や特定のラベル選択規
則を要求しません；ＤＮＳの目的は可能な限り一般的な事で、これによって任意
のアプリケーションを構築するに使えます。特に、システムは名前空間がネット
ワーク境界線やネームサーバーなどに沿って組織化されなくてもよいように、設
計されました。この根拠は名前空間に暗黙の意味を持たせるのではなく、名前を
身近な問題に使えるようにするべきで、木の異なる部分が名前に異なる意味をも
てる事です。例えば、IN-ADDR.ARPAドメインは、ネットワークやホスト番号から
名前へ翻訳する役割を持つので、ネットワークやホストアドレスにしたがって組
織化されます；NetBIOSドメイン[RFC-1001, RFC- 1002]は、平らなのがアプリケー
ションに適切なので、平らです。
However, there are some guidelines that apply to the "normal" parts of
the name space used for hosts, mailboxes, etc., that will make the name
space more uniform, provide for growth, and minimize problems as
software is converted from the older host table. The political
decisions about the top levels of the tree originated in RFC-920.
Current policy for the top levels is discussed in [RFC-1032]. MILNET
conversion issues are covered in [RFC-1031].
しかしホストやメールボックス等に使われる一般的な部分のガイドラインはあり
ます、ｋろえは名前空間を一様にし、成長に備え、古いホストテーブルのソフト
ウェアを変換する際の問題を最小にします。木の一番上のレベルのポリシーの決
定はRFC920から始まりました。現在の一番上のレベルのポリシーが[RFC-1032]で
論じられます。MILNET変換問題が[RFC-1031]で示されます。
Lower domains which will eventually be broken into multiple zones should
provide branching at the top of the domain so that the eventual
decomposition can be done without renaming. Node labels which use
special characters, leading digits, etc., are likely to break older
software which depends on more restrictive choices.
いずれは複数のドメインに分かれそうな下位のドメインは上位ドメインで分けて
おくべきです、これにより分離するときに名前を変更しなくて済みます。特別な
文字や頭に数字を使うなどのノードラベルは、より制限の厳しい古いソフトウェ
アを壊す可能性が高いです。
3.3. Technical guidelines on use
3.3. 利用上の技術的ガイドライン
Before the DNS can be used to hold naming information for some kind of
object, two needs must be met:
ＤＮＳが何かの種類のオブジェクトの情報の名前を持つのに使う前に、２つの必
要が満たされなくてはなりません：
- A convention for mapping between object names and domain
names. This describes how information about an object is
accessed.
- オブジェクト名とドメイン名の変換規則。これはどのようにオブジェクト
の情報にアクセスされるか記述します。
- RR types and data formats for describing the object.
- 資源レコードタイプとオブジェクトを記述するデータフォーマット。
These rules can be quite simple or fairly complex. Very often, the
designer must take into account existing formats and plan for upward
compatibility for existing usage. Multiple mappings or levels of
mapping may be required.
これらの規則は非常に単純か、あるいはかなり複雑です。通常、デザイナーは既
存のフォーマットを考慮して、既存の使い方の上位互換性を予測して計画を立て
なくてはなりません。多数の変換や、多段変換が必要かもしれません。
For hosts, the mapping depends on the existing syntax for host names
which is a subset of the usual text representation for domain names,
together with RR formats for describing host addresses, etc. Because we
need a reliable inverse mapping from address to host name, a special
mapping for addresses into the IN-ADDR.ARPA domain is also defined.
ホストに関して、変換は既存のホスト名の規則に依存し、これはドメイン名の通
常のテキスト表現の部分集合で、ホストアドレスを表現する資源レコードフォー
マットも同様です、など。我々がアドレスからホスト名への信頼できる逆変換を
必要とするので、アドレスをIN-ADDR.ARPAドメインへ変換する特別な規則が定義
されます。
For mailboxes, the mapping is slightly more complex. The usual mail
address <local-part>@<mail-domain> is mapped into a domain name by
converting <local-part> into a single label (regardles of dots it
contains), converting <mail-domain> into a domain name using the usual
text format for domain names (dots denote label breaks), and
concatenating the two to form a single domain name. Thus the mailbox
HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this
design also must take into account the scheme for mail exchanges [RFC-
974].
訳注：RFC誤植情報によると上記の"(regardles of dots it contains)"は
"(regardless of dots it contains)"が正しいそうです。
メールボックスのための変換は少し複雑です。通常の<local-part>@<mail-domain>
は、<local-part>を１つのラベルに変換し（ドットがあってもかまわない）、
<mail-domain>を通常のテキストフォーマットドメイン名（ドットをラベルの区
切りとする）に変換し、この２つをつないで１つのドメイン名を生成します。こ
れでメールボックスHOSTMASTER@SRI-NIC.ARPAはドメイン名
HOSTMASTER.SRI-NIC.ARPA.に変換されます。このデザインはメール交換案
[RFC-974]を考慮したものです。
The typical user is not concerned with defining these rules, but should
understand that they usually are the result of numerous compromises
between desires for upward compatibility with old usage, interactions
between different object definitions, and the inevitable urge to add new
features when defining the rules. The way the DNS is used to support
some object is often more crucial than the restrictions inherent in the
DNS.
一般的なユーザーはこれらの規則を定義に関わっていませんが、古い使い方との
上位互換性の要望と、異なるオブジェクト定義間の干渉と、新しい規則を定義す
る時に避けられない新しい機能の追加の妥協の結果であると理解するべきです。
あるオブジェクトをサポートするＤＮＳの使い方は、ＤＮＳ固有の制限よりしば
しば決定的になります。
3.4. Example name space
3.4. 名前空間の例
The following figure shows a part of the current domain name space, and
is used in many examples in this RFC. Note that the tree is a very
small subset of the actual name space.
次の図は現在のドメイン名空間の一部を示して、このRFCの多くの例で使われま
す。木が実際の名前空間の非常に小さい一部分であることを注意してください。
|
|
+---------------------+------------------+
| | |
MIL EDU ARPA
| | |
| | |
+-----+-----+ | +------+-----+-----+
| | | | | | |
BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
|
+--------+------------------+---------------+--------+
| | | | |
UCI MIT | UDEL YALE
| ISI
| |
+---+---+ |
| | |
LCS ACHILLES +--+-----+-----+--------+
| | | | | |
XX A C VAXA VENERA Mockapetris
In this example, the root domain has three immediate subdomains: MIL,
EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named
XX.LCS.MIT.EDU. All of the leaves are also domains.
この例で、ルートドメインは３つの直接のサブドメインを持っています：MILと
EDUとARPA。LCS.MIT.EDUドメインはXX.LCS.MIT.EDU という名前の１つの直接の
サブドメインを持っています。全てのリーフがドメインです。
3.5. Preferred name syntax
3.5. 望ましい名前文法
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.
例えば、メールドメインを名付ける時、ユーザーはRFC822とこの文書の両方の規
則を満たすべきです。新しいホスト名を作る時、HOST.TXTの古い規則にも従うべ
きです。これは、古いソフトウェアをドメイン名を使ように変換する時、トラブ
ルを避けます。
The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET).
次の文法はドメイン名を使う多くのアプリケーション（例えば、メール、TELNET）
でより問題が少ないでしょう。
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
大文字のAからZと小文字のaからzの52文字のどれか
<digit> ::= any one of the ten digits 0 through 9
数字の0から9のどれか
Note that while upper and lower case letters are allowed in domain
names, no significance is attached to the case. That is, two names with
the same spelling but different case are to be treated as if identical.
大文字と小文字の両方がドメイン名で許されるが、区別がない事を注意してくだ
さい。同じつづりで大文字と小文字が異なる２つの名前は同じと扱われるはずで
す。
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
3.6. Resource Records
3.6. 資源レコード
A domain name identifies a node. Each node has a set of resource
information, which may be empty. The set of resource information
associated with a particular name is composed of separate resource
records (RRs). The order of RRs in a set is not significant, and need
not be preserved by name servers, resolvers, or other parts of the DNS.
ドメイン名がノードを識別します。各ノードが資源情報をもっています、空かも
しれません。特定の名前の複数の資源情報は資源レコード集合を構成します。資
源レコードの順序は重要でなく、ネームサーバーやリゾルバやＤＮＳの他の部分
で維持される必要がありません。
When we talk about a specific RR, we assume it has the following:
我々が特定の資源レコードの話をする時、次のことを仮定します：
owner which is the domain name where the RR is found.
所有者 資源レコードが見つかるドメイン名
type which is an encoded 16 bit value that specifies the type
of the resource in this resource record. Types refer to
abstract resources.
タイプ １６ビット値で資源レコードの種類を示します。タイプが抽象
的な資源を参照します。
This memo uses the following types:
この文書では以下のタイプを使います：
A a host address
ホストアドレス
CNAME identifies the canonical name of an
alias
別名に対して標準名前を識別します。
HINFO identifies the CPU and OS used by a host
ホストで使われるＣＰＵとＯＳを識別します。
MX identifies a mail exchange for the
domain. See [RFC-974 for details.
ドメインのメール交換を識別します。詳細は
[RFC-974]を参照。
NS
the authoritative name server for the domain
ドメインの権威（正式）ネームサーバ
PTR
a pointer to another part of the domain name space
ドメイン空間の他の部分へのポインタ
SOA
identifies the start of a zone of authority]
正式ゾーンの開始の識別
class which is an encoded 16 bit value which identifies a
protocol family or instance of a protocol.
クラス １６ビット値で、プロトコルファミリーあるいはプロトコルの
例を識別する。
This memo uses the following classes:
この文書では以下のクラスが使われる
IN the Internet system
インターネットシステム
CH the Chaos system
カオスシステム
TTL which is the time to live of the RR. This field is a 32
bit integer in units of seconds, an is primarily used by
resolvers when they cache RRs. The TTL describes how
long a RR can be cached before it should be discarded.
ＴＴＬ 資源レコードの有効な時間。このフィールドは秒単位で３２ビッ
トの整数である、主にリゾルバが資源レコードをキャッシュす
る時に使われる。ＴＴＬはキャッシュを削除する前に、どれだ
けに期間資源レコードをキャッシュできるか記述します。
訳注：RFC2181でＳＯＡのＴＴＬはゼロでなければならないと規定しています。
また、ＴＴＬの値は０以上２１４７４８３６４７以下で、有効桁数３１ビット
と規定しています。
RDATA which is the type and sometimes class dependent data
which describes the resource:
資源データ タイプや時にはクラスに依存する資源を記述するデータ：
A For the IN class, a 32 bit IP address
ＩＮクラスでは３２ビットのＩＰアドレス
For the CH class, a domain name followed
by a 16 bit octal Chaos address.
ＣＨクラスではドメイン名とそれに続く１６
ビットの８進数カオスアドレス
CNAME a domain name.
ドメイン名
MX a 16 bit preference value (lower is
better) followed by a host name willing
to act as a mail exchange for the owner
domain.
１６ビットの優先値（小さいほど優先）と、
所有者ドメインのメール交換の役を務めるホ
スト名
NS a host name.
ホスト名
PTR a domain name.
ドメイン名
SOA several fields.
いろいろなフィールド
The owner name is often implicit, rather than forming an integral part
of the RR. For example, many name servers internally form tree or hash
structures for the name space, and chain RRs off nodes. The remaining
RR parts are the fixed header (type, class, TTL) which is consistent for
all RRs, and a variable part (RDATA) that fits the needs of the resource
being described.
所有者名はしばしば資源レコードの不可欠な部分ではなく暗黙に示されます。例
えば、多くのネームサーバが内部的に名前空間を木やハッシュ構造で表現し、ノー
ドから切り離された資源レコード鎖を形成します。資源レコードの残りの部分は
固定ヘッダ（タイプ、クラス、ＴＴＬ）でこれはすべての資源レコードで同じで
あり、可変部（資源データ）はリソースの記述に適した部分です。
The meaning of the TTL field is a time limit on how long an RR can be
kept in a cache. This limit does not apply to authoritative data in
zones; it is also timed out, but by the refreshing policies for the
zone. The TTL is assigned by the administrator for the zone where the
data originates. While short TTLs can be used to minimize caching, and
a zero TTL prohibits caching, the realities of Internet performance
suggest that these times should be on the order of days for the typical
host. If a change can be anticipated, the TTL can be reduced prior to
the change to minimize inconsistency during the change, and then
increased back to its former value following the change.
ＴＴＬフィールドの意味は、どれほどの期間資源レコードをキャッシュで保持で
きるかを示します。この期限はゾーンの正式データに当てはまりません；正式デー
タはゾーンのポリシーに従って更新されます。ＴＴＬはデータを生成するゾーン
の管理者によって割り当てられます。短いＴＴＬはキャッシュを最小にし、ゼロ
値のＴＴＬがキャッシュを禁止し、インターネットの現実はホストの場合日単位
の値を示唆します。もし変更が予定されているなら、ＴＴＬは変更の際のデータ
の食違いを避けるため少なくすることができ、変更後に元の値に変更できます。
The data in the RDATA section of RRs is carried as a combination of
binary strings and domain names. The domain names are frequently used
as "pointers" to other data in the DNS.
資源レコードの資源データ部のデータはバイナリ列とドメイン名の組み合わせで
運ばれます。ＤＮＳでドメイン名はしばしば他のデータへの「ポインタ」として
用いられます。
3.6.1. Textual expression of RRs
3.6.1. 資源レコードのテキスト表現
RRs are represented in binary form in the packets of the DNS protocol,
and are usually represented in highly encoded form when stored in a name
server or resolver. In this memo, we adopt a style similar to that used
in master files in order to show the contents of RRs. In this format,
most RRs are shown on a single line, although continuation lines are
possible using parentheses.
資源レコードはＤＮＳプロトコルのパケットでバイナリ形式で表現され、ネーム
サーバーやリゾルバに登録される時、通常、高度にコード化された形で表現され
ます。この文書で、我々は資源レコードの記述に、マスターファイルで使われる
形式ににた表現をします。マスターファイルフォーマットで資源レコードは括弧
を使うことで複数行にできますが、ほとんどが１行で表示します。
The start of the line gives the owner of the RR. If a line begins with
a blank, then the owner is assumed to be the same as that of the
previous RR. Blank lines are often included for readability.
行の始めは資源レコードの所有者です。もし行が空白から始まるなら、所有者は
前の資源レコードと同じです。読みやすさのために空白行が含まれます。
Following the owner, we list the TTL, type, and class of the RR. Class
and type use the mnemonics defined above, and TTL is an integer before
the type field. In order to avoid ambiguity in parsing, type and class
mnemonics are disjoint, TTLs are integers, and the type mnemonic is
always last. The IN class and TTL values are often omitted from examples
in the interests of clarity.
所有者の後に資源レコードのＴＴＬとタイプとクラスを書きます。クラスとタイ
プは上に定義された名称を使い、ＴＴＬはタイプフィールドの前にあり整数です。
文を解析する際のあいまい性を避けるために、タイプとクラスで同じ名称を定義
しません、ＴＴＬは整数で、タイプ名は常に最後です。INクラスとTTL値は読み
やすさのために例ではしばしば除かれます。
The resource data or RDATA section of the RR are given using knowledge
of the typical representation for the data.
リソースデータや資源レコードの資源データ部のデータはデータの一般的な表現
で記述します。
For example, we might show the RRs carried in a message as:
例えば、以下のようにメッセージ中の資源レコードを表現するかもしれません：
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A 128.9.0.32
A 10.1.0.52
VAXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33
The MX RRs have an RDATA section which consists of a 16 bit number
followed by a domain name. The address RRs use a standard IP address
format to contain a 32 bit internet address.
MX資源レコードはドメイン名と１６ビットの数から成る資源データ部を持ちます。
アドレス資源レコードは３２ビットのインターネットアドレスを含む標準的な
ＩＰアドレスフォーマットを使います。
This example shows six RRs, with two RRs at each of three domain names.
この例は、３つのドメイン名の２つづず、全部で６つの資源レコードを示します。
Similarly we might see:
同様に：
XX.LCS.MIT.EDU. IN A 10.0.0.44
CH A MIT.EDU. 2420
This example shows two addresses for XX.LCS.MIT.EDU, each of a different
class.
この例はXX.LCS.MIT.EDUの２つのクラスの異なるアドレスです。
3.6.2. Aliases and canonical names
3.6.2. 別名と標準名
In existing systems, hosts and other resources often have several names
that identify the same resource. For example, the names C.ISI.EDU and
USC-ISIC.ARPA both identify the same host. Similarly, in the case of
mailboxes, many organizations provide many names that actually go to the
same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
and PVM@ISI.EDU all go to the same mailbox (although the mechanism
behind this is somewhat complicated).
既存のシステムで、ホストや他の資源が、しばしば同じ資源を識別するいくつか
の名前を持ちます。例えば、名前C.ISI.EDUとUSC-ISIC.ARPAは共に同じホストを
識別します。同様に、メールボックスの場合で、多くの組織が実際には同じメー
ルボックスに転送される多くの名前を供給します；例えばMockapetris@C.ISI.EDU
とMockapetris@B.ISI.EDUとPVM@ISI.EDUが（メカニズムがいくらか複雑ですが）
すべて同じメールボックスに行きます。
Most of these systems have a notion that one of the equivalent set of
names is the canonical or primary name and all others are aliases.
これらの多くのシステムで、これらの名前の１つが標準名もしくは基本名で、そ
のほかが別名という考えをしています。
訳注：この記述はホストは１つしか名前しか持てない様に感じさせますが、
RFC2181で否定されています。ホストは複数の名前を持つことが出来ます
（複数のドメイン名のＡレコードが同じアドレスを示していて問題ありません）
また、１つのアドレス逆引きドメイン名に対して複数のPTRレコードが許されて
います。
The domain system provides such a feature using the canonical name
(CNAME) RR. A CNAME RR identifies its owner name as an alias, and
specifies the corresponding canonical name in the RDATA section of the
RR. If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different. This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.
ドメインシステムはこのような機能を標準名(CNAME)資源レコードを使って供給
します。CNAME資源レコードが別名を所有者名とし、その資源レコードの資源
データ部で対応する標準名を指定します。もしCNAME資源レコードノードにある
ならば、他のデータは存在するべきではありません；これは標準名と別名の
データが異ならないことを保証します。この規則は同じくキャッシュされた
CNAMEが権威（正式）サーバーに問合わずに他の資源レコードタイプに使えるこ
とを保証します。
CNAME RRs cause special action in DNS software. When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
record with a matching class. If so, the name server includes the CNAME
record in the response and restarts the query at the domain name
specified in the data field of the CNAME record. The one exception to
this rule is that queries which match the CNAME type are not restarted.
CNAME資源レコードはＤＮＳソフトウェアに特別な行動を起こします。ネーム
サーバーがドメイン名の資源レコードの中から希望する資源レコードを見つけら
れなかった時、同じクラスのCNAMEレコードがないか調べます。もしあればネー
ムサーバーは回答にCNAMEレコードを含めて、CNAMEレコードのデータフィールド
で指定されたドメイン名で問合せを再開します。この規則の１つの例外はCNAME
タイプに対する問合せは再開されないということです。
For example, suppose a name server was processing a query with for USC-
ISIC.ARPA, asking for type A information, and had the following resource
records:
例えば、ネームサーバーがUSC- ISIC.ARPAのＡタイプ情報を求める問合せを処理
し、次の資源レコードがあると考えてください：
USC-ISIC.ARPA IN CNAME C.ISI.EDU
C.ISI.EDU IN A 10.0.0.52
Both of these RRs would be returned in the response to the type A query,
while a type CNAME or * query should return just the CNAME.
これらの資源レコードの両方がＡタイプの問合せの回答で返されるだろうが、
CNAMEや*問合せがCNAMEだけを返すべきです。
Domain names in RRs which point at another name should always point at
the primary name and not the alias. This avoids extra indirections in
accessing information. For example, the address to name RR for the
above host should be:
他の名前をポイントする資源レコードのドメイン名は常に別名ではなく、基本名
をポイントするべきです。これは遠回りの情報アクセスを避けます。例えば、上
記のホストのアドレスの資源レコードにいれるべきものは以下です：
52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU
rather than pointing at USC-ISIC.ARPA. Of course, by the robustness
principle, domain software should not fail when presented with CNAME
chains or loops; CNAME chains should be followed and CNAME loops
signalled as an error.
USC-ISIC.ARPA.を示すべきでありません。もちろん、安定性のためにドメインソ
フトウェアがCNAME連鎖やループを与えられた時、故障するべきではありません；
CNAME連鎖が続けて検索され、CNAMEループがエラーと報告されるべきです。
3.7. Queries
3.7. 問合せ
Queries are messages which may be sent to a name server to provoke a
response. In the Internet, queries are carried in UDP datagrams or over
TCP connections. The response by the name server either answers the
question posed in the query, refers the requester to another set of name
servers, or signals some error condition.
問合せは回答をするだろうネームサーバーに送られるメッセージです。インター
ネットで、問合せがＵＤＰデータグラムかＴＣＰ接続の上に載せられます。ネー
ムサーバーの回答は問合せられた質問の回答か、他のネームサーバ群の参照か、
エラーの表明です。
In general, the user does not generate queries directly, but instead
makes a request to a resolver which in turn sends one or more queries to
name servers and deals with the error conditions and referrals that may
result. Of course, the possible questions which can be asked in a query
does shape the kind of service a resolver can provide.
一般に、ユーザーは直接問合せを生成しません、その代わりにネームサーバーに
１つ以上の問合せてエラーや参照を扱うリゾルバに問い合わせます。もちろん、
問合せで出来る質問がリゾルバのサービスの種類を決めます。
DNS queries and responses are carried in a standard message format. The
message format has a header containing a number of fixed fields which
are always present, and four sections which carry query parameters and
RRs.
ＤＮＳの問合せと回答が標準的なメッセージフォーマットで送られます。メッセー
ジフォーマットは常に存在している多くの固定フィールドを含むヘッダと問合せ
パラメータと資源レコードを運ぶ４つのセクションを持ちます。
The most important field in the header is a four bit field called an
opcode which separates different queries. Of the possible 16 values,
one (standard query) is part of the official protocol, two (inverse
query and status query) are options, one (completion) is obsolete, and
the rest are unassigned.
ヘッダーでの最も重要なフィールドは異なった問合せを分離するオペコードと呼
ばれる４ビットのフィールドです。可能な１６値について、１つ（標準的な問合
せ）は公式のプロトコルの一部です、２つ（逆の問合せと状態の問合せ）はオプ
ションです、１つ（完成）は時代遅れで、そして残りは割り当てられていません。
The four sections are:
４つのセクションは
Question Carries the query name and other query parameters.
質問 問合せ名と他の問合せパラメータを運びます。
Answer Carries RRs which directly answer the query.
回答 問合せの直接の答えである資源レコードを運びます。
Authority Carries RRs which describe other authoritative servers.
May optionally carry the SOA RR for the authoritative
data in the answer section.
権威（正式） 他の権威（正式）サーバを記述す資源レコード。任意指定で正
式データのＳＯＡ資源レコードを回答セクションで運びます。
Additional Carries RRs which may be helpful in using the RRs in the
other sections.
追加 他のセクションの資源レコードを補助する資源レコードを運び
ます。
Note that the content, but not the format, of these sections varies with
header opcode.
これらのセクションの内容（フォーマットではない）がヘッダのオペコードによ
り変わることに注意してください。
3.7.1. Standard queries
3.7.1. 標準問合せ
A standard query specifies a target domain name (QNAME), query type
(QTYPE), and query class (QCLASS) and asks for RRs which match. This
type of query makes up such a vast majority of DNS queries that we use
the term "query" to mean standard query unless otherwise specified. The
QTYPE and QCLASS fields are each 16 bits long, and are a superset of
defined types and classes.
標準的な問合せは目標ドメイン名（QNAME）と問合せタイプ（QTYPE）と問合せク
ラス（QCLASS）を指定し、一致する資源レコードを求めます。このタイプの問合
せがＤＮＳ問合せの大部分を構成するので、特に指定せずに「問合せ」と言った
場合、標準問合せを意味します。QTYPEとQCLASSフィールドはそれぞれ長さ１６
ビットで、定義されたタイプとクラスの上位集合です。
The QTYPE field may contain:
QTYPEフィールドは以下でしょう：
<any type> matches just that type. (e.g., A, PTR).
そのタイプに一致します（AやPTRなど）
AXFR special zone transfer QTYPE.
特別なゾーン転送問合せタイプ
MAILB matches all mail box related RRs (e.g. MB and MG).
全てのメールボックス関係の資源レコード（MBやMGなど）
* matches all RR types.
全ての資源レコードタイプに一致
The QCLASS field may contain:
QCLASSフィールドは以下でしょう：
<any class> matches just that class (e.g., IN, CH).
そのクラスに一致します（INやCHなど）
* matches aLL RR classes.
全ての資源レコードクラスに一致
Using the query domain name, QTYPE, and QCLASS, the name server looks
for matching RRs. In addition to relevant records, the name server may
return RRs that point toward a name server that has the desired
information or RRs that are expected to be useful in interpreting the
relevant RRs. For example, a name server that doesn't have the
requested information may know a name server that does; a name server
that returns a domain name in a relevant RR may also return the RR that
binds that domain name to an address.
問合せドメイン名とQTYPEとQCLASSを使い、ネームサーバーは一致する資源レコー
ドを探します。適切なレコードのほかに、ネームサーバーは望ましい情報を持つ
ネームサーバをポイントする資源レコードや、適切な資源レコードを解釈するの
に有用と期待される資源レコードを返すかもしれません。例えば、求められた情
報を持たないネームサーバーが持ってるネームサーバーを知っているかもしれま
せん；適切な資源レコードででドメイン名を返すネームサーバーが、そのドメイ
ンに関するアドレス資源レコードを返してもよいです。
For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
ask the resolver for mail information about ISI.EDU, resulting in a
query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer
section would be:
例えばMockapetris@ISI.EDUにメールを送ろうとしているメイラーがリゾルバに
ISI.EDUのメール情報を求め、QNAME=ISI.EDU, QTYPE=MX, QCLASS=INの問合せが
発生したとします。回答の回答セクションは以下でしょう：
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
while the additional section might be:
回答の追加セクションは以下でしょう：
VAXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33
VENERA.ISI.EDU. A 10.1.0.52
A 128.9.0.32
Because the server assumes that if the requester wants mail exchange
information, it will probably want the addresses of the mail exchanges
soon afterward.
サーバーは要求者がメール交換情報を必要とするなら、すぐにメール交換のアド
レスも必要になると想定します。
Note that the QCLASS=* construct requires special interpretation
regarding authority. Since a particular name server may not know all of
the classes available in the domain system, it can never know if it is
authoritative for all classes. Hence responses to QCLASS=* queries can
never be authoritative.
QCLASS=*がデータが正式かどうかに関して特別な解釈をするにに注意してくださ
い。特定のネームサーバーがドメインシステムで利用可能なクラスのすべてを知っ
ているとは限らないので、すべてのクラスに対して正式かどうか知ることができ
ません。そのためQCLASS=*の質問に対する回答が決して正式になりえません。
3.7.2. Inverse queries (Optional)
3.7.2. 逆問合せ（任意）
Name servers may also support inverse queries that map a particular
resource to a domain name or domain names that have that resource. For
example, while a standard query might map a domain name to a SOA RR, the
corresponding inverse query might map the SOA RR back to the domain
name.
ネームサーバが特定の資源をドメイン名に、またはその資源を持つドメイン名に
変換する逆の問合せをサポートするかもしれません。例えば標準的な問合せがド
メイン名をSOA資源レコードに変換するのに対して、対応する逆の問合せはSOA資
源レコードをドメイン名に変換します。
Implementation of this service is optional in a name server, but all
name servers must at least be able to understand an inverse query
message and return a not-implemented error response.
このサービスを実装するかどうかはネームサーバ毎に任意ですが、すべてのネー
ムサーバーは少なくとも逆問合せメッセージを理解して、「実装していない」エ
ラー回答を返でなければなりません。
The domain system cannot guarantee the completeness or uniqueness of
inverse queries because the domain system is organized by domain name
rather than by host address or any other resource type. Inverse queries
are primarily useful for debugging and database maintenance activities.
ドメインシステムがホストアドレスや資源タイプではなくドメイン名で組織化さ
れるので、ドメインシステムは逆の問合せの完全性あるいはユニークさを保証で
きません。逆の問合せは主にデバッグやデータベース管理に有用です。
Inverse queries may not return the proper TTL, and do not indicate cases
where the identified RR is one of a set (for example, one address for a
host having multiple addresses). Therefore, the RRs returned in inverse
queries should never be cached.
逆質問が適切なＴＴＬを返さないかもしれなく、資源レコードがそれだけかどう
かを示しません（例えば、ホストが持つアドレスのうち１つだけ示すなど）。そ
のため逆の質問で返された資源レコードは決してキャッシュされるべきではあり
ません。
Inverse queries are NOT an acceptable method for mapping host addresses
to host names; use the IN-ADDR.ARPA domain instead.
逆の問合せはホストアドレスをホスト名に変換する満足な方法ではありません；
その代わりにIN-ADDR.ARPAドメインを使うべきです。
A detailed discussion of inverse queries is contained in [RFC-1035].
逆の質問の詳細な論議が[RFC-1035]にあります。
3.8. Status queries (Experimental)
3.8. 状態問合せ（実験的）
To be defined.
定義すること。
3.9. Completion queries (Obsolete)
3.9. 完成の質問（時代遅れ）
The optional completion services described in RFCs 882 and 883 have been
deleted. Redesigned services may become available in the future, or the
opcodes may be reclaimed for other use.
RFC882とRFC883で記述された任意の完成サービスは削除されました。デザインを
変更したサービスが将来利用可能になるかもしれません、あるいはオペコードは
他の利用のために返還を要求されるかもしれません。
4. NAME SERVERS
4. ネームサービス
4.1. Introduction
4.1. はじめに
Name servers are the repositories of information that make up the domain
database. The database is divided up into sections called zones, which
are distributed among the name servers. While name servers can have
several optional functions and sources of data, the essential task of a
name server is to answer queries using data in its zones. By design,
name servers can answer queries in a simple manner; the response can
always be generated using only local data, and either contains the
answer to the question or a referral to other name servers "closer" to
the desired information.
ネームサーバはドメインデータベースを構成する情報の倉庫です。データベース
はゾーンと呼ばれる部分に分割され、ネームサーバーに分配されます。ネームサー
バがいくつかの任意の機能とデータソースを持てますが、ネームサーバの基本的
な仕事はそのゾーンのデータを使っている問合せに答える事です。意図的に、名
前サーバーが単純な方法で問合せに答えることができます；回答は常にローカル
なデータだけを使って生成できま、回答には質問の答えか望ましい情報により
「近い」他のネームサーバの紹介を含んでいます。
A given zone will be available from several name servers to insure its
availability in spite of host or communication link failure. By
administrative fiat, we require every zone to be available on at least
two servers, and many zones have more redundancy than that.
あるゾーンはホストや通信リンクの障害にかかわらず利用可能にするために、い
くつかのネームサーバーで利用可能でしょう。管理上の命令で、全てのゾーンで
は少なくとも２つのサーバーが利用可能であり、多くのゾーンではより多くの冗
長性を持っつことが要求されます。
A given name server will typically support one or more zones, but this
gives it authoritative information about only a small section of the
domain tree. It may also have some cached non-authoritative data about
other parts of the tree. The name server marks its responses to queries
so that the requester can tell whether the response comes from
authoritative data or not.
ネームサーバーが通常１つ以上のゾーンをサポートするでしょうが、それぞれは
ドメインツリーの小さい部分にだけ正式な情報を与えます。ネームサーバは木の
他の部分についてキャッシュされた正式でないデータを持っているかもしれませ
ん。ネームサーバーは問合せ者が回答が正式なデータが来たかどうか言える様に、
問合せにの回答に印を付けます。
4.2. How the database is divided into zones
4.2. データベースをゾーンに分ける方法
The domain database is partitioned in two ways: by class, and by "cuts"
made in the name space between nodes.
ドメインデータベースは２つの方法で分割されます：クラスと、ノードで名前空
間を「切る」ことで。
The class partition is simple. The database for any class is organized,
delegated, and maintained separately from all other classes. Since, by
convention, the name spaces are the same for all classes, the separate
classes can be thought of as an array of parallel namespace trees. Note
that the data attached to nodes will be different for these different
parallel classes. The most common reasons for creating a new class are
the necessity for a new data format for existing types or a desire for a
separately managed version of the existing name space.
クラス分割は単純です。どんなクラスのデータベースも、組織化と委任と保守は
他のクラスと独立に行えます。決まり事として、名前空間がすべてのクラスで同
じなので、別のクラスは平行した名前空間木の配列とみなすことができます。ノー
ドに関連するデータが他のクラスのデータと異なることに注意してください。新
しいクラスを作る最も一般的な理由は、既存のタイプの新しいデータフォーマッ
トが必要な場合や、既存の名前空間に別に管理されたバージョンを供給する場合
です。
Within a class, "cuts" in the name space can be made between any two
adjacent nodes. After all cuts are made, each group of connected name
space is a separate zone. The zone is said to be authoritative for all
names in the connected region. Note that the "cuts" in the name space
may be in different places for different classes, the name servers may
be different, etc.
クラスの中で、名前空間の「切断」がどんな２つの隣接したノードの間にでも作
ることができます。すべての切断が行われた後、それぞれの接続された名前空間
グループが別のゾーンです。ゾーンは接続された地域ですべての名前に信頼すべ
きであると言われます。名前空間の「切断」が異なるクラスで異なる場所にある
かもしれないくて、ネームサーバが異なるかもしれないことなどに注意してくだ
さい。
These rules mean that every zone has at least one node, and hence domain
name, for which it is authoritative, and all of the nodes in a
particular zone are connected. Given, the tree structure, every zone
has a highest node which is closer to the root than any other node in
the zone. The name of this node is often used to identify the zone.
これらの規則はすべてのゾーンが少なくとも１つのノードを持つことを意味し、
それゆえ正式なドメイン名とぞのゾーンの中のノードのすべてが接続されていま
す。与えられたツリー構造で、すべてのゾーンはゾーンの他のどのノードよりも
ルートにより近い最上位ノードを持っています。このノードの名前はゾーンを識
別するためにしばしば使われます。
It would be possible, though not particularly useful, to partition the
name space so that each domain name was in a separate zone or so that
all nodes were in a single zone. Instead, the database is partitioned
at points where a particular organization wants to take over control of
a subtree. Once an organization controls its own zone it can
unilaterally change the data in the zone, grow new tree sections
connected to the zone, delete existing nodes, or delegate new subzones
under its zone.
特に有用でないが、名前空間を分割し、各ドメイン名を全て別のゾーンにするこ
とも、全てのノードが１つのゾーンにすることも、可能でしょう。実際はデータ
ベースを特定の組織が部分木の制御を引き継ぐことを望むポイントで分割できま
す。組織がそれ自身の地域を制御できるようになると、そのゾーンのデータを一
方的に変えたり、ゾーンに接続した新しい木の部分を増やしたり、既存のノード
を削除したり、そのゾーンの下に新しいサブゾーンを委任することができます。
If the organization has substructure, it may want to make further
internal partitions to achieve nested delegations of name space control.
In some cases, such divisions are made purely to make database
maintenance more convenient.
もし組織が部分構造を持つなら、内部に名前空間制御を重複委任する部分を望む
かもしれません。ある場合には、このような部分はデータベース管理を単純化し
都合が良い。
4.2.1. Technical considerations
4.2.1. 技術的な考慮
The data that describes a zone has four major parts:
ゾーンを記述するデータは４つ部分を持ちます：
- Authoritative data for all nodes within the zone.
- ゾーン内のすべてのノードの正式なデータ。
- Data that defines the top node of the zone (can be thought of
as part of the authoritative data).
- ゾーンの最上位ノードを定義するデータ（正式なデータの一部であると
考えられる）。
- Data that describes delegated subzones, i.e., cuts around the
bottom of the zone.
- 委任サブゾーンを記述するデータ、すなわち、ゾーンの底での切断。
- Data that allows access to name servers for subzones
(sometimes called "glue" data).
- サブゾーンのネームサーバーアクセスを可能にするデータ（しばしば「接
着剤」と呼ばれる）。
All of this data is expressed in the form of RRs, so a zone can be
completely described in terms of a set of RRs. Whole zones can be
transferred between name servers by transferring the RRs, either carried
in a series of messages or by FTPing a master file which is a textual
representation.
このすべてのデータは資源レコードのかたちで表現されます、そのためゾーンが
資源レコードの集まりで完全に記述できます。ネームサーバー間でのゾーン全体
の転送は資源レコードを移すことででき、メッセージをいくつも送るか、テキス
ト表現のマスターファイルのＦＴＰ転送で実現できます。
The authoritative data for a zone is simply all of the RRs attached to
all of the nodes from the top node of the zone down to leaf nodes or
nodes above cuts around the bottom edge of the zone.
ゾーンの正式なデータは、ゾーンの最上位からリーフか切断の前までの全てのノー
ドにある全ての資源データです。
Though logically part of the authoritative data, the RRs that describe
the top node of the zone are especially important to the zone's
management. These RRs are of two types: name server RRs that list, one
per RR, all of the servers for the zone, and a single SOA RR that
describes zone management parameters.
論理的には正式なデータの部分だが、ゾーンの最上位のノードを記述する資源レ
コードは特にゾーンの管理に重要です。このような資源レコードは２つのタイプ
です：ゾーンネームサーバ毎に１つあるネームサーバ資源レコードと、ゾーン管
理パラメータを記述する１つのＳＯＡ資源レコード。
The RRs that describe cuts around the bottom of the zone are NS RRs that
name the servers for the subzones. Since the cuts are between nodes,
these RRs are NOT part of the authoritative data of the zone, and should
be exactly the same as the corresponding RRs in the top node of the
subzone. Since name servers are always associated with zone boundaries,
NS RRs are only found at nodes which are the top node of some zone. In
the data that makes up a zone, NS RRs are found at the top node of the
zone (and are authoritative) and at cuts around the bottom of the zone
(where they are not authoritative), but never in between.
ゾーンの底を切る資源レコードはサブゾーンのネームサーバを記述するネームサー
バ資源レコードです。切断がノード間で行われるので、これらのネームサーバ資
源レコードはゾーンの正式なデータの一部ではなく、サブゾーンの最上位の対応
する資源レコードと正確に一致しているべきです。ネームサーバが常にゾーン境
界線と結び付いてるので、ネームサーバ資源レコードはいずれかのゾーンの最上
位のノードにだけあるべきです。ゾーンを構成するデータで、ネームサーバ資源
レコードはゾーンの最上位ノード（正式なもの）と、そしてゾーンの底を切る所
（正式ではない）にあり、中間にはありません。
One of the goals of the zone structure is that any zone have all the
data required to set up communications with the name servers for any
subzones. That is, parent zones have all the information needed to
access servers for their children zones. The NS RRs that name the
servers for subzones are often not enough for this task since they name
the servers, but do not give their addresses. In particular, if the
name of the name server is itself in the subzone, we could be faced with
the situation where the NS RRs tell us that in order to learn a name
server's address, we should contact the server using the address we wish
to learn. To fix this problem, a zone contains "glue" RRs which are not
part of the authoritative data, and are address RRs for the servers.
These RRs are only necessary if the name server's name is "below" the
cut, and are only used as part of a referral response.
ゾーン構造の目標の１つが、サブゾーンと通信するにに必要なデータを全て持っ
ている事です。すなわち、親ゾーンはその子供のゾーンのサーバにアクセスする
のに必要な全ての情報を持ちます。サブゾーンのサーバーを指定するネームサー
バー資源レコードは、これがサーバー名を与えるが、アドレスを与えないので、
十分な情報ではありません。特に、もしネームサーバの名前がサブゾーン内の名
前であるなら、ネームサーバーのアドレスを知るためにそのネームサーバにアク
セスしなければアドレスがわからない状況に直面します。この問題を直すために、
ゾーンには正式なデータの一部でないくサーバーのアドレス資源レコードである
「接着剤」資源レコードを含んでいます。これらの資源レコードは、もしネーム
サーバの名前が切った「下」にある時にだけ必要であり、照会回答の一部で用い
られるだけです。
4.2.2. Administrative considerations
4.2.2. 管理上の考慮
When some organization wants to control its own domain, the first step
is to identify the proper parent zone, and get the parent zone's owners
to agree to the delegation of control. While there are no particular
technical constraints dealing with where in the tree this can be done,
there are some administrative groupings discussed in [RFC-1032] which
deal with top level organization, and middle level zones are free to
create their own rules. For example, one university might choose to use
a single zone, while another might choose to organize by subzones
dedicated to individual departments or schools. [RFC-1033] catalogs
available DNS software an discusses administration procedures.
ある組織が自分自身のドメインの管理を望む時、最初の手順は適切な親ゾーンを
認識し、親ゾーンの所有者に制御の委任の同意をとることです。木のどこで委任
するかについて特別な技術的問題がないが、最上位組織の管理上の区分けについ
て[RFC-1032]で論じられ、中間ゾーンはそれぞれの自由な規則を作れます。例え
ば、ある大学がひとつのゾーンを使うと決めるかもしれないが、別の大学は個別
の課や学校にサブゾーンを委任すると決めるかもしれません。[RFC-1033]が利用
可能なＤＮＳソフトと管理手順の一覧を論じます。
Once the proper name for the new subzone is selected, the new owners
should be required to demonstrate redundant name server support. Note
that there is no requirement that the servers for a zone reside in a
host which has a name in that domain. In many cases, a zone will be
more accessible to the internet at large if its servers are widely
distributed rather than being within the physical facilities controlled
by the same organization that manages the zone. For example, in the
current DNS, one of the name servers for the United Kingdom, or UK
domain, is found in the US. This allows US hosts to get UK data without
using limited transatlantic bandwidth.
新しいサブゾーンの名前が選ばれると、新しい所有者は複数のネームサーバの用
意を要求されるべきです。そのゾーンのサーバがそのドメインの名前を持つ必要
がないという必要条件に注意して下さい。多くの場合、ゾーンを管理する組織に
管理された物理的な所に全てのサーバがあるより、インターネット全体に散らばっ
ていたほうがゾーンのアクセス性はよいでしょう。例えば、現在のＤＮＳで、イ
ギリスあるいはＵＫドメインのためのネームサーバの１つがアメリカ合衆国にあ
ります。これはアメリカ合衆国のホストが帯域を限定された太西洋横断回線を使
わずにＵＫのデータを得る事を許します。
As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone. The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.
最後の設置手順として、委任の効果をもたらすために必要な委任ネームサーバ資
源レコードと接着剤資源レコードが親ゾーンに加えられるべきです。両方のゾー
ンの管理者は切断の両側を特徴づけるネームサーバと接着剤資源レコードが一致
し続けることを保証するべきです。
4.3. Name server internals
4.3. ネームサーバの内部
4.3.1. Queries and responses
4.3.1. 問合せと回答
The principal activity of name servers is to answer standard queries.
Both the query and its response are carried in a standard message format
which is described in [RFC-1035]. The query contains a QTYPE, QCLASS,
and QNAME, which describe the types and classes of desired information
and the name of interest.
ネームサーバの主な動作は標準問合せに答える事です。問合せとその回答の両方
が[RFC-1035]に記述される標準メッセージフォーマットにのります。質問はQTYPE
とQCLASSとQNAMEを含み、これは求める情報のタイプとクラスと名前を記述します。
The way that the name server answers the query depends upon whether it
is operating in recursive mode or not:
名前サーバーが問合せに答える方法は、再帰モードで動作してるかどうかにより
ます：
- The simplest mode for the server is non-recursive, since it
can answer queries using only local information: the response
contains an error, the answer, or a referral to some other
server "closer" to the answer. All name servers must
implement non-recursive queries.
- サーバーの最も単純なモードは非再帰モードで、ローカルな情報だけを
使って問合せに答えます：回答は、エラーか、答えか、何か他の「より
近い」サーバーの紹介を含んでいます。すべてのネームサーバーは非再
帰問合せが実行できなければなりません。
- The simplest mode for the client is recursive, since in this
mode the name server acts in the role of a resolver and
returns either an error or the answer, but never referrals.
This service is optional in a name server, and the name server
may also choose to restrict the clients which can use
recursive mode.
- クライアントの最も単純なモードは再帰で、再帰モードでネームサーバー
はリゾルバの役割で行動し、エラーか答えを返し、紹介を返しません。
このサービスの実行はネームサーバの任意で、ネームサーバーは再帰モー
ドを使えるクライアントを限定してもよいです。
Recursive service is helpful in several situations:
再帰サービスはいくつかの状態で役立ちます：
- a relatively simple requester that lacks the ability to use
anything other than a direct answer to the question.
- 質問への直接の答え以外を扱う能力に欠ける比較的単純な要求者
- a request that needs to cross protocol or other boundaries and
can be sent to a server which can act as intermediary.
- 問合せがプロトコルや境界を超える必要があり、それが出来るサーバー
へ問合せを送る場合。
- a network where we want to concentrate the cache rather than
having a separate cache for each client.
- クライアント毎にキャッシュを持つのではなく、キャッシュの集中を
望むネットワーク。
Non-recursive service is appropriate if the requester is capable of
pursuing referrals and interested in information which will aid future
requests.
もし要求者が紹介を扱えて将来の問合せの参考になる情報を得たいなら、非再帰
サービスが適切です。
The use of recursive mode is limited to cases where both the client and
the name server agree to its use. The agreement is negotiated through
the use of two bits in query and response messages:
再帰モードの使用はクライアントとネームサーバーの両方がその使用に同意する
場合に限定されます。合意は問合せと回答メッセージの２ビットの使用を通して
交渉されます：
- The recursion available, or RA bit, is set or cleared by a
name server in all responses. The bit is true if the name
server is willing to provide recursive service for the client,
regardless of whether the client requested recursive service.
That is, RA signals availability rather than use.
- 再帰可能（ＲＡビット）はネームサーバが全ての回答で設定かクリアし
ます。このビットはクライアントが求めたかどうかに関わらず、ネーム
サーバーが再帰サービスを提供できるなら１です。つまりRAは使ったと
いうより使えることを示します。
- Queries contain a bit called recursion desired or RD. This
bit specifies specifies whether the requester wants recursive
service for this query. Clients may request recursive service
from any name server, though they should depend upon receiving
it only from servers which have previously sent an RA, or
servers which have agreed to provide service through private
agreement or some other means outside of the DNS protocol.
- 問合せは再帰要望あるいはＲＤと呼ばれる１ビットを含みます。このビッ
トは問合せ者が再帰サービスを望んでいるかを明示します。クライアント
は過去にＲＡを設定された回答をもらったサーバかプライベートな合意か
ＤＮＳプロトコル以外の何かで示されたサーバにだけ再帰サービスを要請
すべきだが、クライアントは全てのサーバに再帰的サービスを求めてもよ
いです。
The recursive mode occurs when a query with RD set arrives at a server
which is willing to provide recursive service; the client can verify
that recursive mode was used by checking that both RA and RD are set in
the reply. Note that the name server should never perform recursive
service unless asked via RD, since this interferes with trouble shooting
of name servers and their databases.
回帰的なモードは、ＲＤが設定された問合せがサーバに届き、サーバーが再帰サー
ビスを提供している場合におきます；クライアントはRAとRDの両方ビットが答え
設定されていることで再帰が行われたことを確認できます。ネームサーバやデー
タベースのトラブルシューティングのインターフェースはＲＤを設定しないので、
ネームサーバーは再帰サービスを行うべきでないことに注意してください。
If recursive service is requested and available, the recursive response
to a query will be one of the following:
もし再帰サービスが求められて可能なら再帰の回答は以下のどれかでしょう：
- The answer to the query, possibly preface by one or more CNAME
RRs that specify aliases encountered on the way to an answer.
- 問合せの答え、もしかしたら問合せの途中で遭遇したCNAME資源レコー
ドで始まるかもしれません。
- A name error indicating that the name does not exist. This
may include CNAME RRs that indicate that the original query
name was an alias for a name which does not exist.
- 名前が存在しないことを示す名前エラー。これは元の問合せが存在し
ない別名だったことを示すCNAME資源レコードを含むかもしれません。
- A temporary error indication.
- 一時的なエラー表示。
If recursive service is not requested or is not available, the non-
recursive response will be one of the following:
もし再帰サービスが求められないか利用可能ではないなら、非再帰応答は次のど
れかでしょう：
- An authoritative name error indicating that the name does not
exist.
- 名前が存在しないことを示す正式な名前エラー。
- A temporary error indication.
- 一時的なエラー表示。
- Some combination of:
- いずれかの組み合わせ：。
RRs that answer the question, together with an indication
whether the data comes from a zone or is cached.
回答の資源データレコードと、データがゾーンのかキャッシュのかの表示。
A referral to name servers which have zones which are closer
ancestors to the name than the server sending the reply.
答えを送ったサーバーより近い先祖のゾーンを持つネームサーバーの紹介。
- RRs that the name server thinks will prove useful to the
requester.
- ネームサーバーが問合せ者に有用と考えた資源レコード。
4.3.2. Algorithm
4.3.2. アルゴリズム
The actual algorithm used by the name server will depend on the local OS
and data structures used to store RRs. The following algorithm assumes
that the RRs are organized in several tree structures, one for each
zone, and another for the cache:
ネームサーバの実際に使うアルゴリズムはローカルOSと資源レコードを記憶する
構造に依存するでしょう。次のアルゴリズムは資源レコードがいくつかのツリー
構造で組織化され、１つは各ゾーンで、もう１つはキャッシュと想定します：
1. Set or clear the value of recursion available in the response
depending on whether the name server is willing to provide
recursive service. If recursive service is available and
requested via the RD bit in the query, go to step 5,
otherwise step 2.
1. ネームサービスが再帰サービスを提供する意思があるかどうかに従い回答
の再帰可能値を設定します。もし再帰サービスが利用可能で、問合せのＲ
Ｄで求められていればステップ５に遷移します。そうでなければステップ
２に進みます。
2. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3,
otherwise step 4.
2. QNAMEに最も近い利用可能な先祖のゾーンを探してください。もしこのよ
うなゾーンがあればステップ３へ、なければステップ４へ遷移します。
3. Start matching down, label by label, in the zone. The
matching process can terminate several ways:
3. ゾーンのラベルを1個1個比較してください。比較作業はいくつかの方法で
終えることができます：。
a. If the whole of QNAME is matched, we have found the
node.
a. もしQNAME全体が一致するならノードが発見されたという事です。
If the data at the node is a CNAME, and QTYPE doesn't
match CNAME, copy the CNAME RR into the answer section
of the response, change QNAME to the canonical name in
the CNAME RR, and go back to step 1.
もしノードのデータがCNAMEであり、QTYPEとCNAMEが一致しないなら、
CNAME資源レコードを回答の解答セクションにコピーし、QNAMEを
CNAME資源レコードの標準名で置き換えてステップ１に遷移します。
Otherwise, copy all RRs which match QTYPE into the
answer section and go to step 6.
CNAMEでなければQTYPEと一致するすべての資源レコードを解答セク
ションにコピーし、ステップ６に遷移します。
b. If a match would take us out of the authoritative data,
we have a referral. This happens when we encounter a
node with NS RRs marking cuts along the bottom of a
zone.
b. もし一致したのが正式なデータでなければ、これは紹介です。これ
はゾーンの底を切断したのを示すネームサーバ資源レコードに遭遇
した時生じます。
Copy the NS RRs for the subzone into the authority
section of the reply. Put whatever addresses are
available into the additional section, using glue RRs
if the addresses are not available from authoritative
data or the cache. Go to step 4.
答えの権威セクションの中にサブゾーンのネームサーバ資源レコー
ドをコピーしてください。追加セクションに利用可能な全ての（サ
ブゾーンのネームサーバの）アドレスを入れます、もし正式なデー
タやキャッシュにアドレスがなければ、接着剤資源レコードを使い
ます。ステップ４に遷移します。
c. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see if a
the "*" label exists.
c. もしあるラベルの比較に失敗するなら（つまり対応するラベルがな
ければ）、"*"ラベルがあるか探します。
If the "*" label does not exist, check whether the name
we are looking for is the original QNAME in the query
or a name we have followed due to a CNAME. If the name
is original, set an authoritative name error in the
response and exit. Otherwise just exit.
もし"*"ラベルが存在しないなら、いま探しているのが元々の問合
せのQNAMEかCNAMEの標準名かを調べてください。もし名前が元々の
名前であれば、正式な名前エラーを回答に設定し、アルゴリズムを
終了します。元々の名前でなければ単にアルゴリズムを終了します。
If the "*" label does exist, match RRs at that node
against QTYPE. If any match, copy them into the answer
section, but set the owner of the RR to be QNAME, and
not the node with the "*" label. Go to step 6.
もし"*"ラベルが存在するなら、そのノードの資源レコードをQTYPE
と比較します。もしどれかが一致するならば、それを解答セクショ
ンにコピーしてください、資源レコードの所有者は"*"を持つラベ
ルではなくQNAMEにしてください。ステップ６に遷移します。
4. Start matching down in the cache. If QNAME is found in the
cache, copy all RRs attached to it that match QTYPE into the
answer section. If there was no delegation from
authoritative data, look for the best one from the cache, and
put it in the authority section. Go to step 6.
4. キャッシュ内の比較を始めてください。もしQNAMEがキャッシュで発見さ
れるなら、QTYPEと一致する資源レコード全てを解答セクションにコピー
してください。もし正式データからの委任がないので、キャッシュから最
も適当なものを探し出し、権威セクションに入れてください。ステップ６
に遷移します。
5. Using the local resolver or a copy of its algorithm (see
resolver section of this memo) to answer the query. Store
the results, including any intermediate CNAMEs, in the answer
section of the response.
5. ローカルリゾルバを使うか、リゾルバのアルゴリズム（この文書のリゾル
バの章を見てください）を流用して問合せに答えます。途中のCNAMEも含
めて、結果を回答の解答セクションに置きます。
6. Using local data only, attempt to add other RRs which may be
useful to the additional section of the query. Exit.
6. ローカルなデータのみを使い、質問の追加の部分に有用でかもしれない他
の資源レコードを加えようと試みてください。アルゴリズムを終了します。
4.3.3. Wildcards
4.3.3. ワイルドカード
In the previous algorithm, special treatment was given to RRs with owner
names starting with the label "*". Such RRs are called wildcards.
Wildcard RRs can be thought of as instructions for synthesizing RRs.
When the appropriate conditions are met, the name server creates RRs
with an owner name equal to the query name and contents taken from the
wildcard RRs.
前のアルゴリズムで、"*"ラベルで始まる所有者名の資源レコードに特別な処置
がされました。このような資源レコードはワイルドカードと呼ばれます。ワイル
ドカード資源レコードは資源レコードの合成指示と考えられます。適切な条件が
満たされる時、ネームサーバーは、所有者名が問合せの名前と一致し、内容はワ
イルドカード資源レコードと一致する資源レコードを作ります。
This facility is most often used to create a zone which will be used to
forward mail from the Internet to some other mail system. The general
idea is that any name in that zone which is presented to server in a
query will be assumed to exist, with certain properties, unless explicit
evidence exists to the contrary. Note that the use of the term zone
here, instead of domain, is intentional; such defaults do not propagate
across zone boundaries, although a subzone may choose to achieve that
appearance by setting up similar defaults.
この機能はインターネットから何か他のメールシステムへメールを転送する時に
使うゾーンで最も使われます。一般的な考えは、サーバーにゾーン内の名前の問
合せが着たら、明示的に否定されない限り、その名前が存在し、それにはある特
徴が設定されるということです。ここでのゾーンという言葉の使い方は、ドメイ
ンではなく、意図なのに注意してください；このようなデフォルトはゾーン境界
を越えて行われることはありません、サブゾーンが類似のデフォルトを作り同じ
事をするかもしれません。
The contents of the wildcard RRs follows the usual rules and formats for
RRs. The wildcards in the zone have an owner name that controls the
query names they will match. The owner name of the wildcard RRs is of
the form "*.<anydomain>", where <anydomain> is any domain name.
<anydomain> should not contain other * labels, and should be in the
authoritative data of the zone. The wildcards potentially apply to
descendants of <anydomain>, but not to <anydomain> itself. Another way
to look at this is that the "*" label always matches at least one whole
label and sometimes more, but always whole labels.
ワイルドカード資源レコードの中身は資源レコード通常の規則とフォーマットに
従います。ゾーンのワイルドカードは一致する問合せ名を操作する所有者名を持
っています。ワイルドカード資源レコードの所有者名は"*.<anydomain>"形式で
、<anydomain>は任意のドメイン名です。<anydomain>には他の*ラベルを含むべ
きではなく、ゾーンの正式名であるべきです。ワイルドカードは<anydomain>の
子孫に一致する可能性がありますが<anydomain>自身には一致しません。別の見
方をすると、"*"ラベルは１つ以上のラベルに一致するが、全部に一致はしない
ということです。
Wildcard RRs do not apply:
ワイルドカード資源レコードは次に適用しません：
- When the query is in another zone. That is, delegation cancels
the wildcard defaults.
- 問合せが他のゾーンに対するものの場合。つまり委任はワイルドカー
ドデフォルトを中止します。
- When the query name or a name between the wildcard domain and
the query name is know to exist. For example, if a wildcard
RR has an owner name of "*.X", and the zone also contains RRs
attached to B.X, the wildcards would apply to queries for name
Z.X (presuming there is no explicit information for Z.X), but
not to B.X, A.B.X, or X.
- 名前やワールドカードの間の名前を問い合わせる場合、ドメインと問
合せ名が存在することを知ってください。例えば、もしワイルドカー
ド資源レコードの所有者名が"*.X"で、ゾーン内にB.Xの資源レコード
がある場合、ワイルドカードはZ.Xには適用になりますが（Z.Xの明示
された情報がないとします）、C.XやA.B.XやXには適用されません。
A * label appearing in a query name has no special effect, but can be
used to test for wildcards in an authoritative zone; such a query is the
only way to get a response containing RRs with an owner name with * in
it. The result of such a query should not be cached.
問合せ名に現われる*ラベルは特別な効果を持ちませんが、正式なゾーンでワイ
ルドカードのテストを行うために使う事ができます；このような問合せは所有者
名に*を含む資源レコードの回答を得る唯一の方法です。このような質問の結果
はキャッシュされるべきではありません。
Note that the contents of the wildcard RRs are not modified when used to
synthesize RRs.
ワイルドカード資源レコードの中身が、資源レコードを合成するために使われる
時、修正されないことに注意してください。
To illustrate the use of wildcard RRs, suppose a large company with a
large, non-IP/TCP, network wanted to create a mail gateway. If the
company was called X.COM, and IP/TCP capable gateway machine was called
A.X.COM, the following RRs might be entered into the COM zone:
ワイルドカード資源レコードの使用を例として、大きな非IP/TCP網を持つ大きな
会社がメールゲートウェイを作ることを望んだと考えてください。もし会社が
X.COMと呼ばれ、A.X.COMと呼ばれるTP/TCPを持つゲートウェイましがあるなら、
以下の資源レコードがCOMゾーンにあるかもしれません：
X.COM MX 10 A.X.COM
*.X.COM MX 10 A.X.COM
A.X.COM A 1.2.3.4
A.X.COM MX 10 A.X.COM
*.A.X.COM MX 10 A.X.COM
This would cause any MX query for any domain name ending in X.COM to
return an MX RR pointing at A.X.COM. Two wildcard RRs are required
since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
subtree by the explicit data for A.X.COM. Note also that the explicit
MX data at X.COM and A.X.COM is required, and that none of the RRs above
would match a query name of XX.COM.
これでX.COMで終わる全てのドメイン名についてMX問合せをするとA.X.COMを示す
MX資源レコードが返ってきます。A.X.COMの明示的データにより*.X.COMの効果が
A.X.COMとA.C.COM以下への適用されなくなるので、２つのワイルドカード資源レ
コードが必要です。同じくX.COMとA.X.COMに対する明示的なMXデータが必要で、
上記はXX.COMの資源レコードには一致しないことに注意してください。
4.3.4. Negative response caching (Optional)
4.3.4. 否定応答のキャッシュ（任意）
The DNS provides an optional service which allows name servers to
distribute, and resolvers to cache, negative results with TTLs. For
example, a name server can distribute a TTL along with a name error
indication, and a resolver receiving such information is allowed to
assume that the name does not exist during the TTL period without
consulting authoritative data. Similarly, a resolver can make a query
with a QTYPE which matches multiple types, and cache the fact that some
of the types are not present.
ＤＮＳは任意実装のサービスをもちます、ネームサーバはTTL付きで否定回答を
送ることが出来、リゾルバはこれをキャッシュできます。例えば、ネームサー
バーが名前エラー表示とともにTTLを送ることができます、このような情報を受
け取るリゾルバが、名前の正式なデータを調べないでTTL時間の間その名前が存
在しないと想定することを許されます。同様に、リゾルバが多数のタイプと一致
するQTYPEで質問をしてて、いくつかのタイプが存在していないという事実を
キャッシュすることができます。
This feature can be particularly important in a system which implements
naming shorthands that use search lists beacuse a popular shorthand,
which happens to require a suffix toward the end of the search list,
will generate multiple name errors whenever it is used.
一般的な短縮名は、短縮名が捜索リストの終わり方向に接尾辞を必要とし、使用
時に多数の名前エラーを生じるので、この機能は検索リストで使う短縮名を実装
するシステムで特に重要であり得ます。
The method is that a name server may add an SOA RR to the additional
section of a response when that response is authoritative. The SOA must
be that of the zone which was the source of the authoritative data in
the answer section, or name error if applicable. The MINIMUM field of
the SOA controls the length of time that the negative result may be
cached.
その方法はネームサーバーが正式回答の追加セクションにSOA資源レコードを加
えてもよいということです。解答セクションの正式なデータか、可能なら名前エ
ラー、のあるゾーンのSOAがあるに違いありません。SOAの最小フィールドは否定
的な結果をキャッシュする時間の長さをコントロールします。
訳注：RFC2181で、上記の間違えが指摘されています。SOA資源レコードは追加セ
クションではなく権威セクションに設定します
Note that in some circumstances, the answer section may contain multiple
owner names. In this case, the SOA mechanism should only be used for
the data which matches QNAME, which is the only authoritative data in
this section.
ある状況で解答セクションが多数の所有者名を含むかもしれないことに注意して
ください。この場合SOAメカニズムはQNAMEと一致するデータに使われるべきで、
これはこのセクションで唯一の正式なデータです。
Name servers and resolvers should never attempt to add SOAs to the
additional section of a non-authoritative response, or attempt to infer
results which are not directly stated in an authoritative response.
There are several reasons for this, including: cached information isn't
usually enough to match up RRs and their zone names, SOA RRs may be
cached due to direct SOA queries, and name servers are not required to
output the SOAs in the authority section.
名前サーバーとリゾルバは決して正式でない回答の追加セクションにSOAを加え
たり、正式な回答で直接言われていない結果を推論しようと試みみるべきではあ
りません。この理由が以下のようにいくつかあります：キャッシュ情報は資源レ
コードやそのゾーン名を比較するのに十分でない、SOAはSOA資源レコードの要求
により直接キャッシュされることがある、ネームサーバは権威セクションにSOA
を入れることが要求されてない。
This feature is optional, although a refined version is expected to
become part of the standard protocol in the future. Name servers are
not required to add the SOA RRs in all authoritative responses, nor are
resolvers required to cache negative results. Both are recommended.
All resolvers and recursive name servers are required to at least be
able to ignore the SOA RR when it is present in a response.
この機能は特徴は、将来、洗練されたバージョンで標準プロトコルの一部になる
ことが期待されますが任意です。ネームサーバーがすべての正式な回答にSOA資
源レコードを加えるように要求されません、同様にリゾルバに否定的な結果の
キャッシュを要求しません。両方とも推薦されます。すべてのリゾルバと再帰
ネームサーバーは少なくともSOA資源レコードが回答に存在している時、SOA資
源レコードを無視できるように要求されます。
Some experiments have also been proposed which will use this feature.
The idea is that if cached data is known to come from a particular zone,
and if an authoritative copy of the zone's SOA is obtained, and if the
zone's SERIAL has not changed since the data was cached, then the TTL of
the cached data can be reset to the zone MINIMUM value if it is smaller.
This usage is mentioned for planning purposes only, and is not
recommended as yet.
この特徴を使うある実験が提案されました。考え方は、キャッシュされたデータ
があるゾーンから来たとわかっていて、正式なSOAのコピーが得られ、データが
キャッシュされた後にゾーンのシリアル番号が変更されてなければ、キャッシュ
データのTTLが小さければゾーンの最長値で置き換えられる事です。この使用法
は計画目的で言われていて推薦されません。
4.3.5. Zone maintenance and transfers
4.3.5. ゾーン維持と転送
Part of the job of a zone administrator is to maintain the zones at all
of the name servers which are authoritative for the zone. When the
inevitable changes are made, they must be distributed to all of the name
servers. While this distribution can be accomplished using FTP or some
other ad hoc procedure, the preferred method is the zone transfer part
of the DNS protocol.
ゾーン管理者の仕事の一部がゾーンの正式なネームサーバーのすべてのゾーンを
持続することです。変更が行われたときに、それは全てのネームサーバーに配ら
れなくてはなりません。この配布はFTPや他の別の手順でできますが、望ましい
方法はＤＮＳプロトコルのゾーン転送部です。
The general model of automatic zone transfer or refreshing is that one
of the name servers is the master or primary for the zone. Changes are
coordinated at the primary, typically by editing a master file for the
zone. After editing, the administrator signals the master server to
load the new zone. The other non-master or secondary servers for the
zone periodically check for changes (at a selectable interval) and
obtain new zone copies when changes have been made.
自動的なゾーン転送あるいは更新のモデルはネームサーバーの１つがゾーンのマ
スターあるいは主ということです。変更は通常ゾーンのマスターファイルを編集
することに同期します。編集後に管理者はマスターサーバーに新しいゾーンを読
み込むよう指示します。ゾーンの他の非マスターあるいは第２サーバーが定期的
に変更を確認し（間隔は変更可能）、変化してれば新しいゾーンのコピーを得ま
す。
To detect changes, secondaries just check the SERIAL field of the SOA
for the zone. In addition to whatever other changes are made, the
SERIAL field in the SOA of the zone is always advanced whenever any
change is made to the zone. The advancing can be a simple increment, or
could be based on the write date and time of the master file, etc. The
purpose is to make it possible to determine which of two copies of a
zone is more recent by comparing serial numbers. Serial number advances
and comparisons use sequence space arithmetic, so there is a theoretic
limit on how fast a zone can be updated, basically that old copies must
die out before the serial number covers half of its 32 bit range. In
practice, the only concern is that the compare operation deals properly
with comparisons around the boundary between the most positive and most
negative 32 bit numbers.
変更を検出するためにセカンダリはゾーンのSOAのシリアル番号フィールドを確
認します。何か変更があった場合はSOAのシリアル番号は常に増加します。増加
は単純に行われたり、マスターファイルの書き込み日の基づいたりします。目的
はゾーンの２つのコピーのシリアル番号を比較することでどちらが最近か決定を
可能にすることです。シリアル番号の増加と比較が連続空間算術を使います、そ
のためそのぐらい速くゾーンを更新できるかについて理論的な限界があります、
基本的に古いコピーが、シリアル番号の増加が３２ビットの半分を越える前に消
滅しなければなりません。実際は、唯一の関心は比較操作が、32ビットの正の最
大値と負の最小値付近で正確に比較をする事です。
The periodic polling of the secondary servers is controlled by
parameters in the SOA RR for the zone, which set the minimum acceptable
polling intervals. The parameters are called REFRESH, RETRY, and
EXPIRE. Whenever a new zone is loaded in a secondary, the secondary
waits REFRESH seconds before checking with the primary for a new serial.
If this check cannot be completed, new checks are started every RETRY
seconds. The check is a simple query to the primary for the SOA RR of
the zone. If the serial field in the secondary's zone copy is equal to
the serial returned by the primary, then no changes have occurred, and
the REFRESH interval wait is restarted. If the secondary finds it
impossible to perform a serial check for the EXPIRE interval, it must
assume that its copy of the zone is obsolete an discard it.
セカンダリサーバーの定期的な確認はSOA資源レコードのパラメータで制御され、
SOA資源レコードは各確認周期で読みこまれなければなりません。パラメータは
更新(REFRESH)と再試(RETRY)と満期(EXPIRE)と呼ばれます。ゾーンがセカンダリ
に読み込まれるとセカンダリはREFRESH秒間待ち、プライマリの新しいシリアル
番号を確認します。この確認に失敗するとRETRY秒後に再度確認されます。確認
はゾーンのプライマリにSOAの単純な問合せです。もしセカンダリのゾーンのコ
ピーのシリアル番号とプライマリから帰ってきたのシリアル番号が等しいなら、
変更がなく、次の確認までREFRESH秒間待ちます。EXPIRE秒間確認ができなかっ
たら、ゾーンのコピーが時代遅れと考えなければならず廃棄します。
When the poll shows that the zone has changed, then the secondary server
must request a zone transfer via an AXFR request for the zone. The AXFR
may cause an error, such as refused, but normally is answered by a
sequence of response messages. The first and last messages must contain
the data for the top authoritative node of the zone. Intermediate
messages carry all of the other RRs from the zone, including both
authoritative and non-authoritative RRs. The stream of messages allows
the secondary to construct a copy of the zone. Because accuracy is
essential, TCP or some other reliable protocol must be used for AXFR
requests.
ゾーンが変わった時、セカンダリサーバーはAXFRでゾーン転送を要求します。も
しAXFR は拒否などのエラーを起こすかもしれませんが、通常連続的な回答メッ
セージが来ます。最初と最後のメッセージはゾーンの最上位の正式なノードデー
タを含んでいなくてはなりません。途中のメッセージがゾーンの全ての資源レ
コードを運び、これには正式なのも正式でないのも含まれます。メッセージの流
れはセカンダリにゾーンのコピーを作ることを可能にします。正確さが必要なの
で、TCPや何か他の信頼性が高いプロトコルがAXFR要求で使われなくてはなりま
せん。
Each secondary server is required to perform the following operations
against the master, but may also optionally perform these operations
against other secondary servers. This strategy can improve the transfer
process when the primary is unavailable due to host downtime or network
problems, or when a secondary server has better network access to an
"intermediate" secondary than to the primary.
各セカンダリサーバがマスターに対して転送操作を行うように要求されます、し
かしオプションで他のセカンダリサーバーに対してこれらの操作を行ってもよい
です。この戦略は、プライマリがホストダウンやネットワークの問題で利用でき
ない時や、セカンダリが中間セカンダリとの間にプライマリよりよい回線がある
とき、転送プロセスを改善することができます。
5. RESOLVERS
5. リゾルバ
5.1. Introduction
5.1. はじめに
Resolvers are programs that interface user programs to domain name
servers. In the simplest case, a resolver receives a request from a
user program (e.g., mail programs, TELNET, FTP) in the form of a
subroutine call, system call etc., and returns the desired information
in a form compatible with the local host's data formats.
リゾルバはユーザプログラムとドメインネームサーバー間のプログラムです。最
も単純な場合、リゾルバはユーザプログラム（例えば、メールプログラム、
TELNET、FTP）からサブルーチン呼びだしなどの形で問合せを受け取り、ローカ
ルホストのデータフォーマットと互換性がある形式で望ましい情報を返送します。
The resolver is located on the same machine as the program that requests
the resolver's services, but it may need to consult name servers on
other hosts. Because a resolver may need to consult several name
servers, or may have the requested information in a local cache, the
amount of time that a resolver will take to complete can vary quite a
bit, from milliseconds to several seconds.
リゾルバはリゾルバにサービスを求めるプログラムと同じマシンの上に位置しま
すが、他のホストのネームサーバーに相談する必要があるかもしれません。リゾ
ルバはいくつかのネームサーバを調べる必要があるかもしれないし、ローカルな
キャッシュに求められた情報を持つかもしれないので、リゾルバが処理を完了す
るまでの時間はミリ秒単位から秒単位の大きな差がでます。
A very important goal of the resolver is to eliminate network delay and
name server load from most requests by answering them from its cache of
prior results. It follows that caches which are shared by multiple
processes, users, machines, etc., are more efficient than non-shared
caches.
リゾルバの非常に重要な目的が、前の結果のキャッシュを使う事で、ネットワー
クの遅延と大量の要求によるサーバ負荷を避けることです。これは、多数のプロ
セスとユーザとマシンなどに共有されるキャッシュは共有されないキャッシュよ
りより効率的なことを示します。
5.2. Client-resolver interface
5.2. クライアント−リゾルバインターフェース
5.2.1. Typical functions
5.2.1. 典型的な機能
The client interface to the resolver is influenced by the local host's
conventions, but the typical resolver-client interface has three
functions:
リゾルバちクライアント間のインタフェースはローカルホストの慣習によって影
響を受けます、しかし典型的なリゾルバ−クライアントインタフェースは３つの
機能を持ちます：
1. Host name to host address translation.
1. ホスト名からホストアドレスへの翻訳
This function is often defined to mimic a previous HOSTS.TXT
based function. Given a character string, the caller wants
one or more 32 bit IP addresses. Under the DNS, it
translates into a request for type A RRs. Since the DNS does
not preserve the order of RRs, this function may choose to
sort the returned addresses or select the "best" address if
the service returns only one choice to the client. Note that
a multiple address return is recommended, but a single
address may be the only way to emulate prior HOSTS.TXT
services.
この機能は昔のHOSTS.TXTの機能をまねるためにしばしば定義されます。
与えられた文字列に対して、要求者は１つ以上の32ビットＩＰアドレスを
期待します。これはＤＮＳのタイプＡ資源レコード問合せに翻訳されます。
ＤＮＳが資源レコードの順序を維持しないので、この機能はソートしたア
ドレスを返したり、もしサービスがクライアントに答えを１つだけ返すな
ら「最も良い」アドレスを選んだりするかもしれません。複数のアドレス
を返すことが推薦されますが、１つのアドレスを返すのが昔のHOSTS.TXT
サービスを模倣する唯一の方法かもしれないことに注意してください。
2. Host address to host name translation
2. ホストアドレスからホスト名への変換
This function will often follow the form of previous
functions. Given a 32 bit IP address, the caller wants a
character string. The octets of the IP address are reversed,
used as name components, and suffixed with "IN-ADDR.ARPA". A
type PTR query is used to get the RR with the primary name of
the host. For example, a request for the host name
corresponding to IP address 1.2.3.4 looks for PTR RRs for
domain name "4.3.2.1.IN-ADDR.ARPA".
この機能はしばしば昔の機能の形に従います。与えられた３２ビット
ＩＰアドレスに対して、要求者はｈ文字列を求めます。ＩＰアドレス
のオクテットの順序を逆にした名前要素の後に"IN-ADDR.ARPA"をつけ
たものが使われます。タイプPTRの問合せがホストの基本名の資源レ
コードを得るために使われます。例えばＩＰアドレス１.２.３.４に
対応するホスト名の問合せはドメイン名"4.3.2.1.IN-ADDR.ARPA"の
PTR資源レコードを探します。
3. General lookup function
3. 一般的な検索機能
This function retrieves arbitrary information from the DNS,
and has no counterpart in previous systems. The caller
supplies a QNAME, QTYPE, and QCLASS, and wants all of the
matching RRs. This function will often use the DNS format
for all RR data instead of the local host's, and returns all
RR content (e.g., TTL) instead of a processed form with local
quoting conventions.
この機能はＤＮＳから任意の情報を検索します、昔のシステムに対応する
機能はありません。要求者はQNAMEとQTYPEとQCLASSを指定し、一致する資
源レコードのすべてを要求します。この機能はしばしばローカルホストの
形式でなくすべてのＤＮＳ資源レコードデータの形式を使い、ローカルな
習慣で処理されるのではなく全ての資源レコードの内容（例えばＴＴＬ）
を返します。
When the resolver performs the indicated function, it usually has one of
the following results to pass back to the client:
リゾルバが機能を実行する時、クライアントに次のどれかを返すでしょう：
- One or more RRs giving the requested data.
- 要求されたデータを与える１つ以上の資源レコード
In this case the resolver returns the answer in the
appropriate format.
この場合リゾルバは適切なフォーマットで答えを返します。
- A name error (NE).
- 名前エラー(NE)
This happens when the referenced name does not exist. For
example, a user may have mistyped a host name.
これは、参照された名前が存在しない時におきます。例えば、ユーザーが
ホスト名を打ち間違えたかもしれません。
- A data not found error.
- データなしエラー
This happens when the referenced name exists, but data of the
appropriate type does not. For example, a host address
function applied to a mailbox name would return this error
since the name exists, but no address RR is present.
これは、参照された名前が存在するが適切なタイプのデータがない時にお
きます。例えば、メールボックス名に対してホストアドレスを検索すると、
名前が存在するがアドレス資源レコードが存在しないので、このエラーを
返すでしょう。
It is important to note that the functions for translating between host
names and addresses may combine the "name error" and "data not found"
error conditions into a single type of error return, but the general
function should not. One reason for this is that applications may ask
first for one type of information about a name followed by a second
request to the same name for some other type of information; if the two
errors are combined, then useless queries may slow the application.
ホスト名とアドレスの間の翻訳機能は、「名前エラー」と「データなし」はひと
つのエラーでいいように思えますが、一般的には分けるべきことは重要です。こ
の理由の１つはアプリケーションがある名前のある情報を求め、次に同じ名前の
他のタイプの情報を求めるかもしれないからです；もし２つのエラーが区別され
なければ、無用な問合せがアプリケーションを遅くするかもしれません。
5.2.2. Aliases
5.2.2. 別名
While attempting to resolve a particular request, the resolver may find
that the name in question is an alias. For example, the resolver might
find that the name given for host name to address translation is an
alias when it finds the CNAME RR. If possible, the alias condition
should be signalled back from the resolver to the client.
特定の問合せを解決しようと試みる際に、リゾルバは質問の名前が別名であるこ
とに気付くかもしれません。例えば、リゾルバはホスト名からアドレスへの翻訳
でCNAME資源レコードを見つけたときに別名に気付くかもしれません。もし可能
なら別名だという事がリゾルバからクライアントに示されるべきです。
In most cases a resolver simply restarts the query at the new name when
it encounters a CNAME. However, when performing the general function,
the resolver should not pursue aliases when the CNAME RR matches the
query type. This allows queries which ask whether an alias is present.
For example, if the query type is CNAME, the user is interested in the
CNAME RR itself, and not the RRs at the name it points to.
たいていの場合リゾルバがCNAME出会うと新しい名前で問合せを再開します。し
かし、一般的な機能を実行する時、リゾルバはCNAME資源レコードが質問タイプ
と一致する時は新しい名前で問合せを再開するべきではありません。これは別
名が存在しているか尋ねる質問を許します。例えば、もし質問タイプがCNAMEな
ら、ユーザーはCNAMEが示す名前の資源レコードではなくCNAME資源レコード自
身に興味を持っています。
Several special conditions can occur with aliases. Multiple levels of
aliases should be avoided due to their lack of efficiency, but should
not be signalled as an error. Alias loops and aliases which point to
non-existent names should be caught and an error condition passed back
to the client.
いくつかの特別な状態が別名に存在します。別名の別名は効率を悪化させるので
避けるべきです、しかしエラーとして示されるべきではありません。別名のルー
プと実在しない名前を示す別名の検査をすべきで、エラーをクライアントに返す
べきです。
5.2.3. Temporary failures
5.2.3. 一時的障害
In a less than perfect world, all resolvers will occasionally be unable
to resolve a particular request. This condition can be caused by a
resolver which becomes separated from the rest of the network due to a
link failure or gateway problem, or less often by coincident failure or
unavailability of all servers for a particular domain.
世の中は完全ではないので、リゾルバは時には問合せの解決が不可能でしょう。
この状態は、ネットワークのリンク故障やゲートウェーの問題や、同時故障や特
定のドメインの全てのサーバが使えなくなると発生します。
It is essential that this sort of condition should not be signalled as a
name or data not present error to applications. This sort of behavior
is annoying to humans, and can wreak havoc when mail systems use the
DNS.
この種の状態が、名前やデータなしのエラーとしてがアプリケーション通知され
ないことが必要です。この様な行動は人をいらいらさせ、メールシステムがＤＮ
Ｓを使う時、破壊を引き起こすことができます。
While in some cases it is possible to deal with such a temporary problem
by blocking the request indefinitely, this is usually not a good choice,
particularly when the client is a server process that could move on to
other tasks. The recommended solution is to always have temporary
failure as one of the possible results of a resolver function, even
though this may make emulation of existing HOSTS.TXT functions more
difficult.
ある場合はいつまでも要求を留めておくことでこのような一時的な問題を扱うこ
とが可能ですが、これは、特にクライアントが他の仕事ができるサーバープロセ
スである時、通常良い選択ではありません。推薦された解決方法は、これが既存
のHOSTS.TXT機能のまねを難しくしますが、リゾルバが一時的な失敗を返せるよ
うにすることです。
5.3. Resolver internals
5.3. リゾルバの内部
Every resolver implementation uses slightly different algorithms, and
typically spends much more logic dealing with errors of various sorts
than typical occurances. This section outlines a recommended basic
strategy for resolver operation, but leaves details to [RFC-1035].
すべてのリゾルバ実装がわずかずつ異なったアルゴリズムを使い、通常、一般的
な事象より多くの種類のエラーを扱い、より多くの計算をします。この章はリゾ
ルバの推薦された基本戦略を解説します、詳細は[RFC1035]に任せます。
5.3.1. Stub resolvers
5.3.1. 低機能リゾルバ
One option for implementing a resolver is to move the resolution
function out of the local machine and into a name server which supports
recursive queries. This can provide an easy method of providing domain
service in a PC which lacks the resources to perform the resolver
function, or can centralize the cache for a whole local network or
organization.
リゾルバの実装方法の１つはローカルマシンから解決機能を外し、再帰問合せを
サポートするネームサーバに移すことです。これはリゾルバを動かす能力に欠け
るＰＣやネットーワークか組織の全てのキャッシュを１箇所に集めたい時に簡単
な方法を提供できます。
All that the remaining stub needs is a list of name server addresses
that will perform the recursive requests. This type of resolver
presumably needs the information in a configuration file, since it
probably lacks the sophistication to locate it in the domain database.
The user also needs to verify that the listed servers will perform the
recursive service; a name server is free to refuse to perform recursive
services for any or all clients. The user should consult the local
system administrator to find name servers willing to perform the
service.
残りの機能が必要なのは再帰問合せをサポートするネームサーバアドレスのリス
トです。この種のリゾルバは、おそらくドメインデータベースの場所を突き止め
る機能が欠けてるので、設定ファイルの情報を必要とします。ユーザーはリスト
アップしたサーバーが再帰サービスを行うことを確かめる必要があります；ネー
ムサーバが一部か全部のクライアントに対して再帰サービスを拒否する自由があ
ります。ユーザーはサービスをするネームサーバーをローカル管理者に相談する
べきです。
This type of service suffers from some drawbacks. Since the recursive
requests may take an arbitrary amount of time to perform, the stub may
have difficulty optimizing retransmission intervals to deal with both
lost UDP packets and dead servers; the name server can be easily
overloaded by too zealous a stub if it interprets retransmissions as new
requests. Use of TCP may be an answer, but TCP may well place burdens
on the host's capabilities which are similar to those of a real
resolver.
この種のサービスがある欠点を持ちます。再帰問合せを行うのにかかる時間は不
明なので、低機能リゾルバはＵＤＰパケットが失われたのとサーバがとまってる
場合の再送間隔を最適化に困るかもしれません；ネームサーバは再送間隔が短い
リゾルバにより過負荷になりやすいです。ＴＣＰを使うのが答えかもしれません
が、ＴＣＰはホストとリゾルバ自身にも負荷をかけるでしょう。
5.3.2. Resources
5.3.2. 資源
In addition to its own resources, the resolver may also have shared
access to zones maintained by a local name server. This gives the
resolver the advantage of more rapid access, but the resolver must be
careful to never let cached information override zone data. In this
discussion the term "local information" is meant to mean the union of
the cache and such shared zones, with the understanding that
authoritative data is always used in preference to cached data when both
are present.
自分自身の資源以外に、リゾルバがローカルネームサーバーの保守するゾーンに
アクセスできるかもしれません。これはリゾルバに速いアクセスの利点を与えま
す、しかしリゾルバは決してキャッシュ情報をゾーンデータより優先しないよう
に気を使わなくてはなりません。この議論で用語「ローカル情報」はキャッシュ
と共有ゾーンの組み合わせを意味することを意図し、正式データとキャッシュデー
タがあるときは正式データが優先されることを意図します。
The following resolver algorithm assumes that all functions have been
converted to a general lookup function, and uses the following data
structures to represent the state of a request in progress in the
resolver:
次のリゾルバアルゴリズムはすべての機能が一般的な検索機能に変換されたと想
定して、そしてリゾルバで処理中の問合せの状態を表すための次のデータ構造体
を使います：
SNAME the domain name we are searching for.
探してるドメイン名
STYPE the QTYPE of the search request.
検索問合せの問合せタイプ
SCLASS the QCLASS of the search request.
検索問合せの問合せクラス
SLIST a structure which describes the name servers and the
zone which the resolver is currently trying to query.
This structure keeps track of the resolver's current
best guess about which name servers hold the desired
information; it is updated when arriving information
changes the guess. This structure includes the
equivalent of a zone name, the known name servers for
the zone, the known addresses for the name servers, and
history information which can be used to suggest which
server is likely to be the best one to try next. The
zone name equivalent is a match count of the number of
labels from the root down which SNAME has in common with
the zone being queried; this is used as a measure of how
"close" the resolver is to SNAME.
リゾルバが現在尋ねようとしているネームサーバとゾーンを記
述する構造体。この構造体はどのネームサーバが望ましい情報
を持つかについて現在の最も良い推測を記録・追跡します；こ
れは受信情報が推測を変更する時に更新されます。この構造体
はゾーン名とゾーンの既知ネームサーバーとネームサーバの既
知アドレスと次にどのネームサーバを利用すべきかを示す履歴
情報と同じものを持ちます。ゾーン名とSNAMEでルート方向か
らの一致するラベルの数はリゾルバにとってゾーンがSNAMEに
どれだけ近いかの基準です。
SBELT a "safety belt" structure of the same form as SLIST,
which is initialized from a configuration file, and
lists servers which should be used when the resolver
doesn't have any local information to guide name server
selection. The match count will be -1 to indicate that
no labels are known to match.
SLISTと同じ形式の「シートベルト」構造体、これは設定ファ
イルで初期化され、リゾルバがネームサーバ選択をするための
ローカル情報がない時に使うべきサーバーをリストアップしま
す。一致数はラベルが一致するか知らないことを示すために
−１でしょう。
CACHE A structure which stores the results from previous
responses. Since resolvers are responsible for
discarding old RRs whose TTL has expired, most
implementations convert the interval specified in
arriving RRs to some sort of absolute time when the RR
is stored in the cache. Instead of counting the TTLs
down individually, the resolver just ignores or discards
old RRs when it runs across them in the course of a
search, or discards them during periodic sweeps to
reclaim the memory consumed by old RRs.
昔の回答を記録する構造体。リゾルバはTTLが期限が切れの古
い資源レコードを捨てる責任があるので、たいていの実装で受
信した資源レコードの相対時間を何らかの種類の絶対時間に変
えてキャッシュに記録します。個々のＴＴＬをカウントダウン
する代わりに、リゾルバは検索時に古い資源レコードを見つけ
るとそれを無視するか捨てるかし、古い資源レコードの消費す
るメモリを回収するために周期的に広域検索を行います。
5.3.3. Algorithm
5.3.3. アルゴリズム
The top level algorithm has four steps:
最上位アルゴリズムは４ステップです：
1. See if the answer is in local information, and if so return
it to the client.
1. 答えがローカル情報にある見て、もしあればクライアントに返します。
2. Find the best servers to ask.
2. 尋ねるのに最も良いいくつかのサーバーを見つけます。
3. Send them queries until one returns a response.
3. どれかが回答を返すまで、それらに質問を送ります。
4. Analyze the response, either:
4. 回答を分析してます：
a. if the response answers the question or contains a name
error, cache the data as well as returning it back to
the client.
a. もし回答が質問の答えか名前エラーなら、それをクライアントに返
しデータをキャッシュしてください。
b. if the response contains a better delegation to other
servers, cache the delegation information, and go to
step 2.
b. もし回答が他のもっとよいサーバーへの委任を含むなら、委任情報
をキャッシュしてステップ２に遷移します。
c. if the response shows a CNAME and that is not the
answer itself, cache the CNAME, change the SNAME to the
canonical name in the CNAME RR and go to step 1.
C. もし回答がCNAMEを示し、CNAMEが答えではないなら、CNAMEをキャッ
シュして、SNAMEをCNAME資源レコードの標準名で置き換えて、ス
テップ１に遷移します。
d. if the response shows a servers failure or other
bizarre contents, delete the server from the SLIST and
go back to step 3.
d. もし回答がサーバー故障か他の奇異な内容を示すなら、SLISTから
サーバーを削除し、ステップ３に遷移します。
Step 1 searches the cache for the desired data. If the data is in the
cache, it is assumed to be good enough for normal use. Some resolvers
have an option at the user interface which will force the resolver to
ignore the cached data and consult with an authoritative server. This
is not recommended as the default. If the resolver has direct access to
a name server's zones, it should check to see if the desired data is
present in authoritative form, and if so, use the authoritative data in
preference to cached data.
ステップ１はキャッシュから望ましいデータを検索します。もしデータがキャッ
シュにあるなら、通常の利用に十分と考えられます。あるリゾルバがキャッシュ
されたデータを無視し、正式なサーバーと問合せるユーザインタフェースのオプ
ションを持ちます。これはデフォルトで推薦されません。もしリゾルバがネーム
サーバのゾーンに直接アクセスするなら、リゾルバは望ましいデータが正式な形
式で存在するか確認し、もし正式なデータがあれば、キャッシュされたデータよ
り優先して正式なデータを使うべきです。
Step 2 looks for a name server to ask for the required data. The
general strategy is to look for locally-available name server RRs,
starting at SNAME, then the parent domain name of SNAME, the
grandparent, and so on toward the root. Thus if SNAME were
Mockapetris.ISI.EDU, this step would look for NS RRs for
Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
These NS RRs list the names of hosts for a zone at or above SNAME. Copy
the names into SLIST. Set up their addresses using local data. It may
be the case that the addresses are not available. The resolver has many
choices here; the best is to start parallel resolver processes looking
for the addresses while continuing onward with the addresses which are
available. Obviously, the design choices and options are complicated
and a function of the local host's capabilities. The recommended
priorities for the resolver designer are:
ステップ２が必要なデータを求めるためのネームサーバを探します。一般的な戦
略は、SNAMEからルートに向かって順番にローカルに知っているネームサーバ資
源レコードの検索です。例えばもしSNAMEがMockapetris.ISI.EDUなら、このス
テップはMockapetris.ISI.EDUのネームサーバ資源レコード、次に ISI.EDUのネー
ムサーバ資源レコード、次にEDUのネームサーバ資源レコード、次にルートのネー
ムサーバ資源レコードを探すでしょう。これらのネームサーバ資源レコードは
SNAMEかその先祖のゾーンのホスト名をリストアップします。この名前をSLISTに
コピーします。ローカルデータを使って各名前のアドレスを設定します。アドレ
スが見つからないかもしれません。リゾルバはここでいくつかの選択があります；
最もよいのは、見つかったアドレスで検索を進めるのと平行して、見つからなかっ
たアドレスの検索を行うことです。明らかに、デザインや複雑さの選択はローカ
ルホストの能力に依存します。リゾルバデザイナーへ推薦する優先順位は以下で
す：
1. Bound the amount of work (packets sent, parallel processes
started) so that a request can't get into an infinite loop or
start off a chain reaction of requests or queries with other
implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
SOME DATA.
1. 誰かが間違ってデータを設定した場合でも、問合せが無限ループに入っ
たり、他の実装で問合せの連鎖反応が生じないように、行う仕事（送
信パケット数、平行プロセス数）の量を制限します。
2. Get back an answer if at all possible.
2. 可能なら全ての答えを得ます。
3. Avoid unnecessary transmissions.
3. 不必要な転送を避けます。
4. Get the answer as quickly as possible.
4. 可能な限り速く答えを得ます。
If the search for NS RRs fails, then the resolver initializes SLIST from
the safety belt SBELT. The basic idea is that when the resolver has no
idea what servers to ask, it should use information from a configuration
file that lists several servers which are expected to be helpful.
Although there are special situations, the usual choice is two of the
root servers and two of the servers for the host's domain. The reason
for two of each is for redundancy. The root servers will provide
eventual access to all of the domain space. The two local servers will
allow the resolver to continue to resolve local names if the local
network becomes isolated from the internet due to gateway or link
failure.
もしネームサーバ資源レコードの探索が失敗するなら、リゾルバはシートベルト
SBELTでSLISTを初期化します。基本的な考えはリゾルバがどのサーバーに尋ねる
べきかわからない時のために、設定ファイルでその助けが期待できるいくつかの
サーバーをリストアップすることです。特別な状態があるが、通常はホストドメ
インの２つのサーバとルートサーバー２つです。各２つは冗長性のためです。ルー
トサーバーはドメイン空間のすべてに最終的なアクセスを供給するでしょう。２
つのローカルサーバーは、ローカルネットワークがゲートウェイかリンク故障で
インターネットから切り離されても局部的な名前を変換を続けられるようにしま
す。
In addition to the names and addresses of the servers, the SLIST data
structure can be sorted to use the best servers first, and to insure
that all addresses of all servers are used in a round-robin manner. The
sorting can be a simple function of preferring addresses on the local
network over others, or may involve statistics from past events, such as
previous response times and batting averages.
さらに、SLISTデータ構造体にはサーバーの名前とアドレス以外に、サーバのア
ドレスをラウンドロビン法で使うため使用する順に並べておくことが出来ます。
並べ替えは単純にローカルネットワークアドレスを優先したり、前回の回答率な
ど過去のイベントの統計を利用してもよいです。
Step 3 sends out queries until a response is received. The strategy is
to cycle around all of the addresses for all of the servers with a
timeout between each transmission. In practice it is important to use
all addresses of a multihomed host, and too aggressive a retransmission
policy actually slows response when used by multiple resolvers
contending for the same name server and even occasionally for a single
resolver. SLIST typically contains data values to control the timeouts
and keep track of previous transmissions.
ステップ３は回答を得るまで質問を送ります。戦略は各送信毎のタイムアウトで、
全てのサーバーのアドレスに順番に問合せることです。特にマルチホームホスト
の全てのアドレスを使うときにあまりにも攻撃的な送信戦略は、複数のリゾルバ
が争ったり、場合によっては１つのリゾルバが攻撃的でも、サーバーの反応を遅
くします。一般にSLISTはタイムアウトを制御し、過去の送信の記録・追跡をす
るデータ値を含んでいます。
Step 4 involves analyzing responses. The resolver should be highly
paranoid in its parsing of responses. It should also check that the
response matches the query it sent using the ID field in the response.
The ideal answer is one from a server authoritative for the query which
either gives the required data or a name error. The data is passed back
to the user and entered in the cache for future use if its TTL is
greater than zero.
ステップ４が回答の分析をします。リゾルバは回答を解釈する際に慎重になるべ
きです。回答の識別子が質問と一致するか調べるべきです。理想的な答えは正式
なサーバーからの問合せたデータか名前エラーが返ることです。データはユーザー
に渡されて、ＴＴＬがゼロ以上なら将来の利用に備えてキャッシュにいれられま
す。
If the response shows a delegation, the resolver should check to see
that the delegation is "closer" to the answer than the servers in SLIST
are. This can be done by comparing the match count in SLIST with that
computed from SNAME and the NS RRs in the delegation. If not, the reply
is bogus and should be ignored. If the delegation is valid the NS
delegation RRs and any address RRs for the servers should be cached.
The name servers are entered in the SLIST, and the search is restarted.
もし回答が委任を示すなら、リゾルバ委任がSLIST中のサーバーより「近い」か
確認すべきです。これはSLISTとSNAMEの一致数と、委任とSNAMEの一致数を比較
することでできます。もし近くなければ答えは嘘で無視されるべきです。もし委
任が正当なら、ネームサーバ委任資源レコードとサーバーのアドレス資源レコー
ドはキャッシュされるべきです。ネームサーバはSLISTに入力され、探索は再開
されます。
If the response contains a CNAME, the search is restarted at the CNAME
unless the response has the data for the canonical name or if the CNAME
is the answer itself.
もし回答がCNAMEを含んでいるなら、回答に標準名がなかったりCNAME自身が答え
でなければ、捜索はCNAMEから再開されます。
Details and implementation hints can be found in [RFC-1035].
詳細と実装の助言が[RFC-1035]にあります。
6. A SCENARIO
6. 筋書き
In our sample domain space, suppose we wanted separate administrative
control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might
allocate name servers as follows:
サンプルのドメイン空間で、ルートとMILとEDUとMIT.EDUとISI.EDUゾーンで個別
の管理制御をしたと考えてください。例えば次のようにネームサーバを割り当て
ます：。
|(C.ISI.EDU,SRI-NIC.ARPA
| A.ISI.EDU)
+---------------------+------------------+
| | |
MIL EDU ARPA
|(SRI-NIC.ARPA, |(SRI-NIC.ARPA, |
| A.ISI.EDU | C.ISI.EDU) |
+-----+-----+ | +------+-----+-----+
| | | | | | |
BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
|
+--------+------------------+---------------+--------+
| | | | |
UCI MIT | UDEL YALE
|(XX.LCS.MIT.EDU, ISI
|ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
+---+---+ | A.ISI.EDU)
| | |
LCS ACHILLES +--+-----+-----+--------+
| | | | | |
XX A C VAXA VENERA Mockapetris
In this example, the authoritative name server is shown in parentheses
at the point in the domain tree at which is assumes control.
この例で、ドメイン木の制御点でネームサーバを括弧で示します.
Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The
EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers
may have zones which are contiguous or disjoint. In this scenario,
C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU
has contiguous zones at the root and MIL domains, but also has a non-
contiguous zone at ISI.EDU.
ルートネームサーバはC.ISI.EDUとSRI-NIC.ARPAとA.ISI.EDUにあります。MILド
メインはSRI-NIC.ARPAとA.ISI.EDUが果たします。EDUドメインはSRI-NIC.ARPA.
とC.ISI.EDUが果たします。サーバーがつながったあるいはつながっていない複
数のゾーンを持つかもしれないことに注意してください。この筋書きでC.ISI.EDU
はルートとEDUドメインのつながったゾーンを持っています。A.ISI.EDUはルー
トとMILドメインのつながったゾーンを持ちます、しかしISI.EDUのつながって
いないゾーンも持ちます。
6.1. C.ISI.EDU name server
6.1. C.ISI.EDUネームサーバ
C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
class, and would have zones for these domains. The zone data for the
root domain might be:
C.ISI.EDUはＩＮクラスのルートとMILとEDUドメインのネームサーバでこれらの
ドメインのゾーンを持つでしょう。ルートドメインのゾーンデータは以下かもし
れません：
. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
870611 ;serial
1800 ;refresh every 30 min
300 ;retry every 5 min
604800 ;expire after a week
86400) ;minimum of a day
NS A.ISI.EDU.
NS C.ISI.EDU.
NS SRI-NIC.ARPA.
MIL. 86400 NS SRI-NIC.ARPA.
86400 NS A.ISI.EDU.
EDU. 86400 NS SRI-NIC.ARPA.
86400 NS C.ISI.EDU.
SRI-NIC.ARPA. A 26.0.0.73
A 10.0.0.51
MX 0 SRI-NIC.ARPA.
HINFO DEC-2060 TOPS20
ACC.ARPA. A 26.6.0.65
HINFO PDP-11/70 UNIX
MX 10 ACC.ARPA.
USC-ISIC.ARPA. CNAME C.ISI.EDU.
73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA.
51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU.
103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
A.ISI.EDU. 86400 A 26.3.0.103
C.ISI.EDU. 86400 A 10.0.0.52
This data is represented as it would be in a master file. Most RRs are
single line entries; the sole exception here is the SOA RR, which uses
"(" to start a multi-line RR and ")" to show the end of a multi-line RR.
Since the class of all RRs in a zone must be the same, only the first RR
in a zone need specify the class. When a name server loads a zone, it
forces the TTL of all authoritative RRs to be at least the MINIMUM field
of the SOA, here 86400 seconds, or one day. The NS RRs marking
delegation of the MIL and EDU domains, together with the glue RRs for
the servers host addresses, are not part of the authoritative data in
the zone, and hence have explicit TTLs.
このデータはマスターファイル表現で示されています。ほとんどの資源レコード
が１行の項目です；ここの唯一の例外はSOA資源レコードで、"("で複数行資源レ
コードの始まりを示し")"で終わりを示します。ゾーンの全ての資源レコードの
クラスが同じであるに違いないので、ゾーンの中の最初の資源レコードだけでク
ラスを指定する必要があります。ネームサーバーがゾーンを読み込む時、それは
すべての正式な資源レコードのTTLをSOAフィールドのMINIMUM以上にします、こ
こでは８６４００秒あるいは１日です。MILとEDUドメインの委任を示すネーム
サーバ資源レコードと、サーバホストアドレスの接着剤資源レコードはゾーンの
正式データの一部ではなく、そのため明示的なＴＴＬを持ちます。
Four RRs are attached to the root node: the SOA which describes the root
zone and the 3 NS RRs which list the name servers for the root. The
data in the SOA RR describes the management of the zone. The zone data
is maintained on host SRI-NIC.ARPA, and the responsible party for the
zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400
second minimum TTL, which means that all authoritative data in the zone
has at least that TTL, although higher values may be explicitly
specified.
４つの資源レコードがルートノードに付けられます：ルートゾーンを記述する
SOAと、ルートゾーンの３つのネームサーバを記述するネームサーバ資源レコー
ド。SOA資源レコードのデータはゾーンの管理を記述します。ゾーンデータはホ
ストSRI - NIC.ARPAで管理され、ゾーンの責任グループは
HOSTMASTER@SRI-NIC.ARPAです。SOAのキー項目は、最小ＴＴＬ８６４００秒で、
これはゾーンの正式なデータがこれ以上の値を持つことを示します、より高い値
を明示的に指定するかもしれません。
The NS RRs for the MIL and EDU domains mark the boundary between the
root zone and the MIL and EDU zones. Note that in this example, the
lower zones happen to be supported by name servers which also support
the root zone.
MILとEDUドメインのネームサーバ資源レコードはルートゾーンとMILとEDUゾーン
間の境界を示します。この例で下のゾーンがたまたまルートゾーンを扱うネーム
サーバーで扱われていることに注意してください。
The master file for the EDU zone might be stated relative to the origin
EDU. The zone data for the EDU domain might be:
EDUゾーンのマスターファイルはEDUを起源とするでしょう。EDUドメインのゾー
ンデータは以下かもしれません：
EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
870729 ;serial
1800 ;refresh every 30 minutes
300 ;retry every 5 minutes
604800 ;expire after a week
86400 ;minimum of a day
)
NS SRI-NIC.ARPA.
NS C.ISI.EDU.
UCI 172800 NS ICS.UCI
172800 NS ROME.UCI
ICS.UCI 172800 A 192.5.19.1
ROME.UCI 172800 A 192.5.19.31
ISI 172800 NS VAXA.ISI
172800 NS A.ISI
172800 NS VENERA.ISI.EDU.
VAXA.ISI 172800 A 10.2.0.27
172800 A 128.9.0.33
VENERA.ISI.EDU. 172800 A 10.1.0.52
172800 A 128.9.0.32
A.ISI 172800 A 26.3.0.103
UDEL.EDU. 172800 NS LOUIE.UDEL.EDU.
172800 NS UMN-REI-UC.ARPA.
LOUIE.UDEL.EDU. 172800 A 10.0.0.96
172800 A 192.5.39.3
YALE.EDU. 172800 NS YALE.ARPA.
YALE.EDU. 172800 NS YALE-BULLDOG.ARPA.
MIT.EDU. 43200 NS XX.LCS.MIT.EDU.
43200 NS ACHILLES.MIT.EDU.
XX.LCS.MIT.EDU. 43200 A 10.0.0.44
ACHILLES.MIT.EDU. 43200 A 18.72.0.8
Note the use of relative names here. The owner name for the ISI.EDU. is
stated using a relative name, as are two of the name server RR contents.
Relative and absolute domain names may be freely intermixed in a master
ここで相対的な名前の使用に気付いてください。ISI.EDU.の所有者名は相対的な
名前で記述され、２つのネームサーバ資源レコード中身も相対的な名前で記述さ
れます。相対的なドメイン名と絶対的なドメイン名がマスターファイルで自由に
混在できます。
6.2. Example standard queries
6.2. 標準問合せ
The following queries and responses illustrate name server behavior.
Unless otherwise noted, the queries do not have recursion desired (RD)
in the header. Note that the answers to non-recursive queries do depend
on the server being asked, but do not depend on the identity of the
requester.
次の問合せと回答はネームサーバ動作例を示します。特に注記しなければ、問合
せのヘッダーで再帰要望(RD)は設定されません。再帰でない問合せの答えが尋ね
るサーバーに依存するが、問合せ者に依存しないことに注意してください。
6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
6.2.1. 質問名=SRI-NIC.ARPA, 質問タイプ=A
The query would look like:
問合せは以下のとおりです：
+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
The response from C.ISI.EDU would be:
C.ISI.EDUからの回答は以下のとおりです：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
| 86400 IN A 10.0.0.51 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
The header of the response looks like the header of the query, except
that the RESPONSE bit is set, indicating that this message is a
response, not a query, and the Authoritative Answer (AA) bit is set
indicating that the address RRs in the answer section are from
authoritative data. The question section of the response matches the
question section of the query.
回答のヘッダーは問合せのヘッダーとほぼ同じです、RESPONSEはメッセージが応
答をなのを示すため設定されます、正式回答(AA)ビットは回答のアドレス資源レ
コードが正式データから来たことを示しため設定されます。回答の質問セクショ
ンは質問の質問セクションと一致します。
If the same query was sent to some other server which was not
authoritative for SRI-NIC.ARPA, the response might be:
もし同じ質問がSRI-NIC.ARPAの正式でない他のサーバーに送られたなら回答は
以下かもしれません：
+---------------------------------------------------+
Header | OPCODE=SQUERY,RESPONSE |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 |
| 1777 IN A 26.0.0.73 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
This response is different from the previous one in two ways: the header
does not have AA set, and the TTLs are different. The inference is that
the data did not come from a zone, but from a cache. The difference
between the authoritative TTL and the TTL here is due to aging of the
data in a cache. The difference in ordering of the RRs in the answer
section is not significant.
この回答は前回答と２箇所違っています：ヘッダーのＡＡは設定されず、TTLは
異なっています。これはデータがゾーンからでなくキャッシュから来たからです。
正式なTTLとこのTTLの差はキャッシュ内でのデータの老化のためです。解答セク
ションの中の資源レコードの順番の違いは意味がありません。
6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
6.2.2. 質問名=SRI-NIC.ARPA, 質問タイプ=*
A query similar to the previous one, but using a QTYPE of *, would
receive the following response from C.ISI.EDU:
前のに似てるが、*の質問タイプを使うとC.ISI.EDUから次の回答を受け取るで
しょう：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
| A 10.0.0.51 |
| MX 0 SRI-NIC.ARPA. |
| HINFO DEC-2060 TOPS20 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
If a similar query was directed to two name servers which are not
authoritative for SRI-NIC.ARPA, the responses might be:
もし同様な問合せがSRI-NIC.ARPAの正式なサーバでない２つのネームサーバーに
送られたら回答は以下かもしれません：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 |
| A 10.0.0.51 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
and
と
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
Neither of these answers have AA set, so neither response comes from
authoritative data. The different contents and different TTLs suggest
that the two servers cached data at different times, and that the first
server cached the response to a QTYPE=A query and the second cached the
response to a HINFO query.
これらの答えはＡＡが設定されず、いずれの回答も正式なデータでから来ていま
せん。異なった内容と異なったTTLは２つのサーバーが異なった時にデータを
キャッシュし、そして最初のサーバーが質問タイプ=Aの問合せをキャッシュし、
２つめがHINFO問合せの結果ををキャッシュしたことを示します。
6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
6.2.3. 質問名=SRI-NIC.ARPA, 質問タイプ=MX
This type of query might be result from a mailer trying to look up
routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
The response from C.ISI.EDU would be:
このタイプの問合せはメールの宛先HOSTMASTER@SRI-NIC.ARPAのルーティング情
報を検索しようとしているメイラーからの問合せかもしれません。C.ISI.EDUか
らの回答は以下でしょう：。
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.|
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
| A 10.0.0.51 |
+---------------------------------------------------+
This response contains the MX RR in the answer section of the response.
The additional section contains the address RRs because the name server
at C.ISI.EDU guesses that the requester will need the addresses in order
to properly use the information carried by the MX.
この回答の解答セクションはMX資源レコードを含みます。C.ISI.EDUのネームサー
バーが要求者がすぐにMXの示す情報を使うためにアドレスが必要と考えたため、
追加セクションはアドレス資源レコードを含んでいます。
6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
6.2.4. 質問名=SRI-NIC.ARPA, 質問タイプ=NS
C.ISI.EDU would reply to this query with:
C.ISI.EDUはこの問合せに以下の回答をするでしょう：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
The only difference between the response and the query is the AA and
RESPONSE bits in the header. The interpretation of this response is
that the server is authoritative for the name, and the name exists, but
no RRs of type NS are present there.
回答と問合せの唯一の違いはヘッダーのＡＡとRESPONSEビットです。この回答の
解釈は、名前は正式で、名前は存在するが、ネームサーバタイプの資源レコード
が存在しないという事です。
6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
6.2.5. 質問名=SIR-NIC.ARPA, 質問タイプ=A
If a user mistyped a host name, we might see this type of query.
C.ISI.EDU would answer it with:
もしユーザーがホスト名をタイプミスしたら、このタイプの問合せが出るかもし
れません。C.ISI.EDU以下の様に答えるでしょう：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE |
+---------------------------------------------------+
Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. |
| 870611 1800 300 604800 86400 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
This response states that the name does not exist. This condition is
signalled in the response code (RCODE) section of the header.
この回答は名前が存在しないと述べます。この状態はヘッダーの回答コード
（RCODE）で示されます。
The SOA RR in the authority section is the optional negative caching
information which allows the resolver using this response to assume that
the name will not exist for the SOA MINIMUM (86400) seconds.
権威セクションでのSOA資源レコードは任意のネガティブキャッシュ情報で、こ
の回答を使うリゾルバがその名前はSOA最小限（８６４００）秒間存在しないと
キャッシュできるようにします。
6.2.6. QNAME=BRL.MIL, QTYPE=A
6.2.6. 質問名=BRL.MIL, 質問タイプ=A
If this query is sent to C.ISI.EDU, the reply would be:
もしこの問合せがC.ISI.EDUに送られたなら、以下の様に回答するでしょう：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | MIL. 86400 IN NS SRI-NIC.ARPA. |
| 86400 NS A.ISI.EDU. |
+---------------------------------------------------+
Additional | A.ISI.EDU. A 26.3.0.103 |
| SRI-NIC.ARPA. A 26.0.0.73 |
| A 10.0.0.51 |
+---------------------------------------------------+
This response has an empty answer section, but is not authoritative, so
it is a referral. The name server on C.ISI.EDU, realizing that it is
not authoritative for the MIL domain, has referred the requester to
servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
for the MIL domain.
この回答は空の解答セクションを持ちますが、正式ではなく紹介です。C.ISI.EDU
のネームサーバーは、自分がMILドメインの権威（正式）でないことを知ってい
てMILドメインの権威（正式）を知ってるであろうと思われるA.ISI.EDUと
SRI-NIC.ARPAのサーバーを要求者に知らせました。
6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
6.2.7. 質問名=USC-ISIC.ARPA, 質問タイプ=A
The response to this query from A.ISI.EDU would be:
この問合せに対するA.ISI.EDUからの答えは以下でしょう：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
| C.ISI.EDU. 86400 IN A 10.0.0.52 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
Note that the AA bit in the header guarantees that the data matching
QNAME is authoritative, but does not say anything about whether the data
for C.ISI.EDU is authoritative. This complete reply is possible because
A.ISI.EDU happens to be authoritative for both the ARPA domain where
USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
found.
ヘッダのAAビットはQNAMEと一致する名前が正式なことを保障しますが、
C.ISI.EDUのどのデータが正式かは何も言わないことに注意してください。この
完全な答えは、A.ISI.EDUがたまたまUSC-ISIC.ARPAのあるARPAドメインと
C.ISI.EDUのあるSI.EDUドメイン両方の権威（正式）なため可能です。
If the same query was sent to C.ISI.EDU, its response might be the same
as shown above if it had its own address in its cache, but might also
be:
もし同じ質問がC.ISI.EDUに送られたら、キャッシュにアドレスを持っていれば
上記と同じ答えを返すでしょうが、多分以下を返すでしょう：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
+---------------------------------------------------+
Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
| NS A.ISI.EDU. |
| NS VENERA.ISI.EDU. |
+---------------------------------------------------+
Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
| 172800 A 128.9.0.33 |
| VENERA.ISI.EDU. 172800 A 10.1.0.52 |
| 172800 A 128.9.0.32 |
| A.ISI.EDU. 172800 A 26.3.0.103 |
+---------------------------------------------------+
This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
plus a referral to the name servers for ISI.EDU. This sort of reply
isn't very likely given that the query is for the host name of the name
server being asked, but would be common for other aliases.
この答えはUSC-ISIC.ARPAの別名の正式回答と、ISI.EDUのネームサーバの紹介を
含んでいます。この種の答えはネームサーバのホスト名を聞いたのでないので適
当な答えでないのですが、別名の場合普通です。
6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
6.2.8. 質問名=USC-ISIC.ARPA, 質問タイプ=CNAME
If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
be:
もしこの質問がA.ISI.EDUかC.ISI.EDUに送らたら答えは以下でしょう：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
server doesn't attempt to look up anything for C.ISI.EDU. (Except
possibly for the additional section.)
質問タイプ=CNAMEなので、CNAME資源レコードはそれ自身が問合せの答えです、
そのためネームサーバーはC.ISI.EDUの何も調べようと試みません。（追加セク
ションを除きます）。
6.3. Example resolution
6.3. 解決例
The following examples illustrate the operations a resolver must perform
for its client. We assume that the resolver is starting without a
cache, as might be the case after system boot. We further assume that
the system is not one of the hosts in the data and that the host is
located somewhere on net 26, and that its safety belt (SBELT) data
structure has the following information:
次の例はリゾルバがクライアントに行う動作を例示します。リゾルバがシステム
ブート直後でキャッシュ無しで始めたと想定します。システムがデータ内のホス
トのどれかではなく、ホストがネット２６の上にあり、シートベルト（SBELT）
データ構造体が次の情報を持つと想定します：。
Match count = -1
SRI-NIC.ARPA. 26.0.0.73 10.0.0.51
A.ISI.EDU. 26.3.0.103
This information specifies servers to try, their addresses, and a match
count of -1, which says that the servers aren't very close to the
target. Note that the -1 isn't supposed to be an accurate closeness
measure, just a value so that later stages of the algorithm will work.
この情報は問合せるサーバーのアドレスと−１の一致カウントを指定し、これは
サーバーが目標から非常に遠い事を示します。−１はアルゴリズムの最後で使わ
れるようにするためであり、正確な近さの値でないことに注意してください。
The following examples illustrate the use of a cache, so each example
assumes that previous requests have completed.
次の例はキャッシュの使用を説明します、各例が前の問合せが完了したと想定し
ます。
6.3.1. Resolve MX for ISI.EDU.
6.3.1. ISI.EDUのMXの解決
Suppose the first request to the resolver comes from the local mailer,
which has mail for PVM@ISI.EDU. The mailer might then ask for type MX
RRs for the domain name ISI.EDU.
リゾルバへの最初の問合せがPVM@ISI.EDUへのメールを持つローカルメイラーか
ら来ると考えてください。メイラーはドメイン名ISI.EDUのタイプMX資源レコー
ドを求めるでしょう。
The resolver would look in its cache for MX RRs at ISI.EDU, but the
empty cache wouldn't be helpful. The resolver would recognize that it
needed to query foreign servers and try to determine the best servers to
query. This search would look for NS RRs for the domains ISI.EDU, EDU,
and the root. These searches of the cache would also fail. As a last
resort, the resolver would use the information from the SBELT, copying
it into its SLIST structure.
リゾルバはキャッシュからISI.EDUのMX資源レコードを探しますが、見つからな
いでしょう。リゾルバは外のサーバーに問い合わせが必要で、質問に最も良い
サーバーを決める必要性を認識するでしょう。この決定はISI.EDUとEDUとルート
のネームサーバ資源レコードを検索するでしょう。キャッシュからこれらの捜索
は失敗するでしょう。最後の手段としてリゾルバはSBELTの情報を使うためSBELT
をSLIST構造にコピーします。
At this point the resolver would need to pick one of the three available
addresses to try. Given that the resolver is on net 26, it should
choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would
then send off a query of the form:
この時点でリゾルバは３つのアドレスの１つを選ぶ必要があるでしょう。リゾル
バがネットワーク２６にいるとすれば、最初に26.0.0.73か26.3.0.103を選択す
るべきです。これは以下の形式の質問を送るでしょう：
+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
The resolver would then wait for a response to its query or a timeout.
If the timeout occurs, it would try different servers, then different
addresses of the same servers, lastly retrying addresses already tried.
It might eventually receive a reply from SRI-NIC.ARPA:
リゾルバはその質問の答えかタイムアウトを待つでしょう。もしタイムアウトが
起きれば他のサーバを試し、他のサーバがだめなら同じサーバの他のアドレスを
試しま、最後に同じアドレスで再度試します。そして結局はSRI-NIC.ARPAから答
えを受け取るかもしれません：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
| NS A.ISI.EDU. |
| NS VENERA.ISI.EDU.|
+---------------------------------------------------+
Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
| 172800 A 128.9.0.33 |
| VENERA.ISI.EDU. 172800 A 10.1.0.52 |
| 172800 A 128.9.0.32 |
| A.ISI.EDU. 172800 A 26.3.0.103 |
+---------------------------------------------------+
The resolver would notice that the information in the response gave a
closer delegation to ISI.EDU than its existing SLIST (since it matches
three labels). The resolver would then cache the information in this
response and use it to set up a new SLIST:
リゾルバは回答の情報が（３つのラベルが一致するので）、ISI.EDUが今のSLIST
よりもより近い委任を与えたことに気付くでしょう。リゾルバはこの回答の情報
をキャッシュし、かつ新しいSLISTに設定して使うでしょう：
Match count = 3
A.ISI.EDU. 26.3.0.103
VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
VENERA.ISI.EDU. 10.1.0.52 128.9.0.32
A.ISI.EDU appears on this list as well as the previous one, but that is
purely coincidental. The resolver would again start transmitting and
waiting for responses. Eventually it would get an answer:
A.ISI.EDUは前のと同じくこのリストに現われますが、偶然の一致です。リゾル
バは再び信号を送って、そして反応を待ち始めるでしょう。結局は答えを得るで
しょう：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
+---------------------------------------------------+
Answer | ISI.EDU. MX 10 VENERA.ISI.EDU. |
| MX 20 VAXA.ISI.EDU. |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
| 172800 A 128.9.0.33 |
| VENERA.ISI.EDU. 172800 A 10.1.0.52 |
| 172800 A 128.9.0.32 |
+---------------------------------------------------+
The resolver would add this information to its cache, and return the MX
RRs to its client.
リゾルバはキャッシュにこの情報を加えて、クライアントにMX資源レコードを
返すでしょう。
6.3.2. Get the host name for address 26.6.0.65
6.3.2. アドレス26.6.0.65のホスト名を得る
The resolver would translate this into a request for PTR RRs for
65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the
resolver would look for foreign servers to ask. No servers would match,
so it would use SBELT again. (Note that the servers for the ISI.EDU
domain are in the cache, but ISI.EDU is not an ancestor of
65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
リゾルバは問合せを65.0.6.26.IN-ADDR.ARPAのPTR資源レコードの要求に変換す
るでしょう。この情報はキャッシュにないので、リゾルバは外のサーバーを探す
でしょう。サーバーが一致しないので、再びSBELTを使うでしょう。（ISI.EDUド
メインのサーバーがキャッシュにありますが、しかしISI.EDUが
65.0.6.26.IN-ADDR.ARPAの先祖ではないので、SBELTが使われることに注意して
ください。）
Since this request is within the authoritative data of both servers in
SBELT, eventually one would return:
この問い合わせSBELTの両方のサーバーの正式なデータにあるので、結局は以下
が返ってくるでしょう：
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
+---------------------------------------------------+
Answer | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
6.3.3. Get the host address of poneria.ISI.EDU
6.3.3. poneria.ISI.EDUのホストアドレスを得る
This request would translate into a type A request for poneria.ISI.EDU.
The resolver would not find any cached data for this name, but would
find the NS RRs in the cache for ISI.EDU when it looks for foreign
servers to ask. Using this data, it would construct a SLIST of the
form:
この問合せはponeria.ISI.EDUのタイプAの問合せに翻訳するでしょう。リゾルバ
はこの名前のキャッシュされたデータを見つけないでしょうが、尋ねるべき外の
サーバーを探す時、ISI.EDUのネームサーバ資源レコードを見つけるでしょう。
このデータを使ってSLISTを作るでしょう：
Match count = 3
A.ISI.EDU. 26.3.0.103
VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
VENERA.ISI.EDU. 10.1.0.52
A.ISI.EDU is listed first on the assumption that the resolver orders its
choices by preference, and A.ISI.EDU is on the same network.
A.ISI.EDUはリゾルバが優先順位順に選択をするという仮定で最初にリストアッ
プされ、A.ISI.EDUは同じネットワークにいます。
One of these servers would answer the query.
これらのサーバーの１つが質問に答えるでしょう。
7. REFERENCES and BIBLIOGRAPHY
7. 参考文献と文献目録
[Dyer 87] Dyer, S., and F. Hsu, "Hesiod", Project Athena
Technical Plan - Name Service, April 1987, version 1.9.
Describes the fundamentals of the Hesiod name service.
Hesiod ネームサービスの基本を記述します
[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] Quarterman, J., 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.
時代遅れ。RFC952参照。
[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
Server", RFC-811, Network Information Center, SRI
International, March 1982.
Obsolete. See RFC-953.
時代遅れ。RFC953参照。
[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. Now obsolete.
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. K. 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. K. 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
索引
A 12
Absolute names 8
Aliases 14, 31
Authority 6
AXFR 17
Case of characters 7
CH 12
CNAME 12, 13, 31
Completion queries 18
Domain name 6, 7
Glue RRs 20
HINFO 12
IN 12
Inverse queries 16
Iterative 4
Label 7
Mailbox names 9
MX 12
Name error 27, 36
Name servers 5, 17
NE 30
Negative caching 44
NS 12
Opcode 16
PTR 12
QCLASS 16
QTYPE 16
RDATA 13
Recursive 4
Recursive service 22
Relative names 7
Resolvers 6
RR 12
Safety belt 33
Sections 16
SOA 12
Standard queries 22
Status queries 18
Stub resolvers 32
TTL 12, 13
Wildcards 25
Zone transfers 28
Zones 19