DNS/RFC1035/2
| /1 /2 /3 /4 /6 /7 |
Contents
2. はじめに INTRODUCTION
2.1. 概要 Overview
The goal of domain names is to provide a mechanism for naming resources in such a way that the names are usable in different hosts, networks, protocol families, internets, and administrative organizations.
ドメイン名の目標は資源に名前付けを行う仕組みを提供することである。 さまざまなホスト、ネットワーク、プロトコルファミリ、 インターネット、管理組織などにおいて名前が利用できるようにしたい。
From the user's point of view, domain names are useful as arguments to a local agent, called a resolver, which retrieves information associated with the domain name. Thus a user might ask for the host address or mail information associated with a particular domain name. To enable the user to request a particular type of information, an appropriate query type is passed to the resolver with the domain name. To the user, the domain tree is a single information space; the resolver is responsible for hiding the distribution of data among name servers from the user.
利用者から見るなら、 ドメイン名はリゾルバと呼ばれるローカルエージェントの引数として役立つ。 リゾルバはドメイン名に付随する情報を検索するものである。
利用者はドメイン名に対応したホストアドレスやメール情報を求めるだろう。 利用者がタイプを指定して情報を求められるように、リゾルバへは ドメイン名とともに問合せタイプが渡される。 利用者のとってはメイン木はひとつの情報空間である; リゾルバはネームサーバ間でデータ分散されていることを 利用者には見えないようにする責任がある。
From the resolver's point of view, the database that makes up the domain space is distributed among various name servers. Different parts of the domain space are stored in different name servers, although a particular data item will be stored redundantly in two or more name servers. The resolver starts with knowledge of at least one name server. When the resolver processes a user query it asks a known name server for the information; in return, the resolver either receives the desired information or a referral to another name server. Using these referrals, resolvers learn the identities and contents of other name servers. Resolvers are responsible for dealing with the distribution of the domain space and dealing with the effects of name server failure by consulting redundant databases in other servers.
リゾルバから見ると、 ドメイン空間を成り立たせているデータベースは様々なネームサーバ上に 分散されている。 ドメイン空間の部分部分はそれぞれのネームサーバに配置されているが、 ひとつのデータ項目を見れば、冗長性をもたせるために、 複数のネームサーバに置かれているだろう。 リゾルバは少なくともひとつのネームサーバを知っていて開始される。 リゾルバは問合せを処理する時、周知のネームサーバに情報を求める; リゾルバは返答として求めていた情報か、あるいは他のネームサーバの 参照情報(referral)を受けとる。 リゾルバはこれらの参照情報を使って、他のネームサーバの同定 (名前とアドレス)と内容とを学習する。 リゾルバには分散配置されているドメイン空間を取り扱うことと ネームサーバに障害があった場合に 他のサーバにある冗長なデータベースを調べて、 障害の影響をやわらげることの責任がある。
Name servers manage two kinds of data. The first kind of data held in sets called zones; each zone is the complete database for a particular 'pruned' subtree of the domain space. This data is called authoritative. A name server periodically checks to make sure that its zones are up to date, and if not, obtains a new copy of updated zones from master files stored locally or in another name server. The second kind of data is cached data which was acquired by a local resolver. This data may be incomplete, but improves the performance of the retrieval process when non-local data is repeatedly accessed. Cached data is eventually discarded by a timeout mechanism.
ネームサーバは 2種類のデータを管理する。 第一種のデータはゾーンと呼ばれる集合中にある; 各ゾーンはドメイン空間から「切り取られた」部分木に対する 完全なデータベースである。 このデータは権威あるデータと呼ばれる。 ネームサーバは自分が管理するゾーンが最新であるかを定期的に調べて、 もし最新でなければローカルに持っているマスターファイルか、 もしくは他のネームサーバから最新のゾーンのコピーを入手する。 第二種のデータとはローカルリゾルバによって得たデータをキャッシュしたものである。 このデータは不完全なこともあるが、 ローカルでないデータに繰り返しアクセスする場合に検索プロセスの効率を高める。 キャッシュデータはタイムアウト機構によっていずれ捨てられる。
This functional structure isolates the problems of user interface, failure recovery, and distribution in the resolvers and isolates the database update and refresh problems in the name servers.
この機能構造はユーザインタフェース、障害回復、リゾルバ中の分散 などの問題を分離する。 そして、ネームサーバにおけるデータベース更新とリフレッシュ問題を分離する。
2.2. よくある構成 Common configurations
A host can participate in the domain name system in a number of ways, depending on whether the host runs programs that retrieve information from the domain system, name servers that answer queries from other hosts, or various combinations of both functions. The simplest, and perhaps most typical, configuration is shown below:
ホストはいくつかのやりかたで DNS に関与できる。 ホストで DNS から検索するプログラムを実行するかどうか、 他のホストからの問合せに返答するネームサーバを走らせるかどうか、 これらの機能を様々に組み合わせて実行するかどうか、 などによりやり方がいろいろある。
最も単純で典型的な構成を示す：
Local Host ローカルホスト | Foreign
|
+---------+ ユーザ問合せ +----------+ 問合せ | +--------+
| | user queries | |queries | |Foreign |
| User |-------------->| |---------|->| Name |
| Program | | Resolver | | | Server |
| ユーザプ|<--------------| リゾルバ |<--------|--| ネー|
| ログラム| user responses| |responses| |ムサーバ|
+---------+ ユーザ返答 +----------+返答 | +--------+
| A |
cache additions | | references |
キャッシュ追加 V | 参照 |
+----------+ |
| cache | |
|キャッシュ| |
+----------+ |User programs interact with the domain name space through resolvers; the format of user queries and user responses is specific to the host and its operating system. User queries will typically be operating system calls, and the resolver and its cache will be part of the host operating system. Less capable hosts may choose to implement the resolver as a subroutine to be linked in with every program that needs its services. Resolvers answer user queries with information they acquire via queries to foreign name servers and the local cache.
ユーザプログラムはリゾルバを通してドメイン名スペースに作用する; ユーザ問合せの形式とユーザ返答の形式はホストと OS 依存である。 ユーザ問合せは普通はシステムコールであり、 リゾルバとそのキャッシュは OS の一部である。
リゾルバサービスを必要とするすべてのプログラムに リゾルバをサブルーチンとしてリンクするような実装を選ぶ ホストもあるだろう。 リゾルバは外部ネームサーバーへの問合せで得た情報と ローカルキャッシュを使って、ユーザの問合せに答える。
Note that the resolver may have to make several queries to several different foreign name servers to answer a particular user query, and hence the resolution of a user query may involve several network accesses and an arbitrary amount of time. The queries to foreign name servers and the corresponding responses have a standard format described in this memo, and may be datagrams.
リゾルバはユーザ問合せひとつに答えるのに複数の外部ネームサーバに 複数の問合せをすることもあるので、ひとつのユーザ問合せの解決のために 数回のネットワークアクセスとある程度の時間が必要となりうる。 外部ネームサーバへの問合せと対応する返答は標準の形式があり、 このメモで記述されている。そして、データグラムが使われるだろう。
Depending on its capabilities, a name server could be a stand alone program on a dedicated machine or a process or processes on a large timeshared host. A simple configuration might be:
能力次第だが、ネームサーバは専用マシン上の単体プログラムだったり、 大きなタイムシェアリングホスト上のプロセスやプロセス群だったりする。 単純な構成を示す：
Local Host ローカルホスト | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+返答 | +--------+
| | | | |responses| |Foreign |
| Master | | | Name |---------|->|Resolver|
| files |-------------->| Server | | | |
| マスター| | | ネーム |<--------|--|リゾルバ|
| ファイル|/ | サーバ | queries | +--------+
+---------+ +----------+ 問合せ |<a name=PrimaryServer></a>
Here a primary name server acquires information about one or more zones by reading master files from its local file system, and answers queries about those zones that arrive from foreign resolvers.
ここではプライマリネームサーバはローカルファイルシステムからマスターファ イルを読込むことでゾーンの情報を得る。そして、これらのゾーンに関しての 外部のリゾルバからやってくる問合せに答える。
<a name=SecondaryServer></a>
The DNS requires that all zones be redundantly supported by more than one name server. Designated secondary servers can acquire zones and check for updates from the primary server using the zone transfer protocol of the DNS. This configuration is shown below:
DNS では冗長性をもたせるために、 すべてのゾーンを複数のネームサーバでサービスするよう要求されている。 セカンダリサーバは DNS のゾーン転送プロトコルを使うことにより、 プライマリサーバからゾーンを取得したり、更新があったかを調べたりできる。 このための設定を示す：
Local Host ローカルホスト | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ 返答 | +--------+
| | | | | responses | |Foreign |
| Master | | | Name |--------------|->|Resolver|
| files |--------->| Server | | | |
| マスター| | | ネーム |<-------------|--|リゾルバ|
| ファイル|/ | サーバ | queries | +--------+
+---------+ +----------+ 問合せ |
A |メンテナンス問合せ | +--------+
| |maintenance queries | |Foreign |
| +--------------------|->| Name |
| | | Server |
+------------------------|--| ネーム |
maintenance responses | | サーバ |
メンテナンス返答 | +--------+In this configuration, the name server periodically establishes a virtual circuit to a foreign name server to acquire a copy of a zone or to check that an existing copy has not changed. The messages sent for these maintenance activities follow the same form as queries and responses, but the message sequences are somewhat different.
この構成では ネームサーバーはゾーンのコピーを得るため、あるいは既存のコピーに 変更がないかを調べるために外部のネームサーバに定期的に TCP接続する。
この保守活動のためのメッセージは問合せと返答と同じ形であるが、 メッセージの順序はやや異なっている。
The information flow in a host that supports all aspects of the domain name system is shown below:
DNS のすべての面をサポートするホストでの情報の流れを示す：
Local Host ローカルホスト | Foreign
|
+---------+ ユーザ問合せ +----------+問合せ | +--------+
| | user queries | |queries | |Foreign |
| User |-------------->| |---------|->| Name |
| Program | | Resolver | | | Server |
| ユーザプ|<--------------| リゾルバ |<--------|--| |
| ログラム| user responses| |responses| | |
+---------+ ユーザ返答 +----------+返答 | +--------+
| A |
cache additions | | references |
キャッシュ追加 V | 参照 |
+-----------------+ |
| Shared database | |
| 共有データベース| |
+-----------------+ |
更新 A | 参照 |
+---------+ refreshes | | references |
/ /| | V |
+---------+ | +----------+ 返答 | +--------+
| | | | | responses | |Foreign |
| Master | | | Name |--------------|->|Resolver|
| files |--------->| Server | | | |
| マスター| | | ネーム |<-------------|--|リゾルバ|
| ファイル|/ | サーバ | queries | +--------+
+---------+ +----------+ 問合せ |
A |メンテナンス問合せ | +--------+
| |maintenance queries | |Foreign |
| +--------------------|->| Name |
| | | Server |
+------------------------|--| ネーム|
maintenance responses | | サーバ|
メンテナンス返答 | +--------+The shared database holds domain space data for the local name server and resolver. The contents of the shared database will typically be a mixture of authoritative data maintained by the periodic refresh operations of the name server and cached data from previous resolver requests. The structure of the domain data and the necessity for synchronization between name servers and resolvers imply the general characteristics of this database, but the actual format is up to the local implementor.
共有データベースはローカルネームサーバとリゾルバが使う ドメイン空間データを持つ。 共有データベースの中身はネームサーバが周期的な更新動作によって 保守する権威あるデータとリゾルバが問合せで得た(キャッシュ)データ とを合わせたものである。 ドメインデータの構造に加えて、 ネームサーバとリゾルバの間で同期をとる必要があることが このデータベースの一般的な特徴をきめる。 しかし実際の形式はローカルな実装者次第である。
<a name=StubResolvers></a>
Information flow can also be tailored so that a group of hosts act together to optimize activities. Sometimes this is done to offload less capable hosts so that they do not have to implement a full resolver. This can be appropriate for PCs or hosts which want to minimize the amount of new network code which is required. This scheme can also allow a group of hosts can share a small number of caches rather than maintaining a large number of separate caches, on the premise that the centralized caches will have a higher hit ratio. In either case, resolvers are replaced with stub resolvers which act as front ends to resolvers located in a recursive server in one or more name servers known to perform that service:
ホスト群が共同して活動を最適化できるように情報フローを対応されられる。 これは能力の低いホストがリゾルバ機能をフルに実装しなくてもいいようして、 ホストの負荷を軽減するのに使われることがある。 このことは必要とされる新しいネットワークコード量を少くしたい PC群やホスト群にむいているだろう。
このやり方によって、ホスト群は個別のキャッシュをそれぞれで維持 するのではなく、少数の共用キャッシュを共同で使えるようになる。 ただし、集中キャッシュがより高いヒット率を持つだろうという前提のもとで。
いずれの場合でも、個々のリゾルバは再帰検索サービスが動作していることが 知られているネームサーバ上のリゾルバに対するフロントエンドとして 動作するスタブリゾルバで置き換えられる。
Local Hosts ローカルホスト | Foreign
|
+---------+ 返答 |
| Stub | responses |
| Resolver|<--------------------+ |
| スタブ | | |
| リゾルバ|----------------+ | |
+---------+ recursive | | |
queries | | |
再帰問合せ V | |
+---------+ recursive +--------------+問合せ | +--------+
| Stub | queries | |queries | |Foreign |
| Resolver|---------->| Recursive |---------|->| Name |
| スタブ | | Server | | | Server |
| リゾルバ|<----------| 再帰 |<--------|--| ネー|
+---------+ responses | サーバ |responses| |ムサーバ|
返答 +--------------+返答 | +--------+
|Central cache| |
|集中キャッシュ| |
+--------------+ |In any case, note that domain components are always replicated for reliability whenever possible.
どの場合も、信頼性のために、ドメイン構成要素は可能なかぎり 複製が作られることに注意せよ。
2.3. 便法 Conventions
The domain system has several conventions dealing with low-level, but fundamental, issues. While the implementor is free to violate these conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in ALL behavior observed from other hosts.
DNS には低レベルであるが基本的な事項を扱った便法がある。 実装者は自身のシステム内ではこれらの便法に従う必要はないが、 外部のホストから読み取れるすべての振舞いを観察すべきである。
2.3.1. 望ましい名前構文 Preferred name syntax
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.
DNS の仕様ではドメイン名を組み立てる規則は最大限に一般的であるものとした。 既存のいかなるオブジェクトの名前も最小限の変更でドメイン名と して表せるようにというものだ。
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.
しかしながら、オブジェクトにドメイン名をつけるときに、 慎重なユーザーなら DNS の規則とオブジェクトについての既存の規則との 両方を満すようにするだろう。 規則が公表されたものだろうが、既存のプログラム中に隠れているものだろうが。
For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names.
例えば、メールドメインの名前なら、 このメモとRFC-822の両方の規則を満たすべきである。 新しいホスト名でも、HOSTS.TXTのための古くからの規則にも従うべきだ。 こうしておけば、ドメイン名を使うように古いソフトウェアを変更するときの トラブルを避けられる。
The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET).
以下の構文規則ならはドメイン名を使うアプリケーション （例えば、メール、TELNET）の多くで問題が少くなる。
<domain> ::= <subdomain> | ' ' <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 <digit> ::= any one of the ten digits 0 through 9
Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical.
ドメイン名には大文字と小文字を使ってよいが、 大文字と小文字には区別されないことに注意せよ。 文字ケースは異なる同じつづりの名前は同じ名前と扱うべきである。
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 ホスト名の規則に従わなければならない。 これらは英字で始まり、英字か数字で終わり、 途中には英字と数字とハイフンを使う。 長さについても制限がある。ラベルは63文字以下であること。
For example, the following strings identify hosts in the Internet:
例えば、次の文字列はインターネットのホストを指す：
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
2.3.2. データ転送順序 Data Transmission Order
The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram, the octets are transmitted in the order they are numbered.
ヘッダとデータの転送順序はこの文書ではオクテットのレベルまで説明される。 オクテットグループを示す図ではオクテットの転送順序は 英語で読まれるときの標準的な順序である。 例えば、次の図では各オクテットは番号の順に転送される。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Whenever an octet represents a numeric quantity, the left most bit in
the diagram is the high order or most significant bit. That is, the bit
labeled 0 is the most significant bit. For example, the following
diagram represents the value 170 (decimal).オクテットが数値を表わすときには左端のビットが最上位ビットである。 つまり 0という表示のついたビットが最上位ビットである。 例として、次の図は数値170（10進数）を表す。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first.
同様に、複数オクテットのフィールドが数値を示すときは 全体のフィールドの左端のビットが最上位ビットである。 複数オクテット値が転送されるときには、最上位オクテットが最初に転送される。
2.3.3. 文字ケース Character Case
For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. At present, this rule is in force throughout the domain system without exception. However, future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in 7-bit ASCII or use of special bytes to terminate labels, etc., should be avoided.
DNS の部分であって、公式のプロトコルの一部であるような部分ではどこでも、 すべての文字列（例えば、ラベル、ドメイン名など）の比較は 大文字小文字の違いは無視して行われる。 現在のところ、DNS 全体でもこの規則には例外がない。 しかし、現状の使い方を越えた追加が将来行われて、 オクテットのすべてのビットを使った名前を使うようになるかもしれない。 そこで、7ビットASCIIを使ったドメイン名の使用や ラベルの終端に特殊なバイトを使うなどは避けるべきである。
When data enters the domain system, its original case should be preserved whenever possible. In certain circumstances this cannot be done. For example, if two RRs are stored in a database, one at x.y and one at X.Y, they are actually stored at the same place in the database, and hence only one casing would be preserved. The basic rule is that case can be discarded only when data is used to define structure in a database, and two names are identical when compared in a case insensitive manner.
データをDNSに入れるとき、元の大文字小文字は可能な限り維持すべきである。 不可能な状況もある。 例えば、2つのRR(資源レコード)がデータベースに登録されるとして、 片方が x.y でもう一方が X.Y であれば、 これらはデータベース中では同じ場所に置かれ、一方だけが保存される。 基本原則として、大文字小文字の違いを無視していいのは データベースで構造を定義ためにデータが使われる時だけである。 そして、名前が同じというのは 大文字小文字の違いを無視して比較したときに同じであるときである。
Loss of case sensitive data must be minimized. Thus while data for x.y and X.Y may both be stored under a single location x.y or X.Y, data for a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In general, this preserves the case of the first label of a domain name, but forces standardization of interior node labels.
大文字小文字を区別するデータでは損失は最小にとどめなければならない。 このため、x.yとX.Yのためのデータは共にひとつの場所 x.y か X.Yに保管される ことがあるが、a.x と B.Xのデータは決してA.x, A.X, b.x, b.X には保管しては ならない。 一般に、ドメイン名の最初のラベルの大文字小文字は維持するが、内部ノードラ ベルは標準化を強制される。
Systems administrators who enter data into the domain database should take care to represent the data they supply to the domain system in a case-consistent manner if their system is case-sensitive. The data distribution system in the domain system will ensure that consistent representations are preserved.
ドメインデータベースにデータを入力するシステム管理者は もしシステムが大文字小文字を区別するときには、 DNS に供給するデータを一貫した方法で表現するように注意すべきである。 DNS のデータ分配システムは一貫した表現が維持されることを保証する。
2.3.4. サイズの上限 Size limits
Various objects and parameters in the DNS have size limits. They are listed below. Some could be easily changed, others are more fundamental.
DNS の種々のオブジェクトやパラメータはサイズに制限がある。 以下に列記する。容易に変更できるものもあるが、多くは基本的である。
labels 63 octets or less ラベル 63オクテット以下 names 255 octets or less 名前 255オクテット以下 TTL positive values of a signed 32 bit number. 有効期間 符号付32ビット数、ただし正の値 UDP messages 512 octets or less UDP メッセージ 512オクテット以下
2002-08-01 訳 前野年紀