原文：ftp://ftp.rfc-editor.org/in-notes/rfc1035.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
サイト内関連リンク：RFC 1034 DNS 概念と機能
This RFC describes the details of the domain system and protocol, and assumes that the reader is familiar with the concepts discussed in a companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034]. この RFC はドメインシステムとプロトコルとの詳細を説明しており、対になる RFC "Domain Names - Concepts and Facilities" [RFC-1034] で議論されている概念に読者が精通していることを前提としている。
The domain system is a mixture of functions and data types which are an official protocol and functions and data types which are still experimental. Since the domain system is intentionally extensible, new data types and experimental behavior should always be expected in parts of the system beyond the official protocol. The official protocol parts include standard queries, responses and the Internet class RR data formats (e.g., host addresses). Since the previous RFC set, several definitions have changed, so some previous definitions are obsolete. ドメインシステムには、公式プロトコルである機能およびデータ型と、いまだ実験中の機能およびデータ型とが混在する。ドメインシステムは意図的に拡張可能であるため、公式プロトコルを超えるシステムの一部として、新しいデータ型と実験的な動作とは常に期待されるべきものである。公式プロトコルの部分は、標準問合せと応答、およびインターネットクラスの RR 情報のフォーマット(例えばホストアドレス)を含む。過去の RFC が定められて以来いくつかの定義が変更されたため、過去の定義の一部は非推奨となっている。
Experimental or obsolete features are clearly marked in these RFCs, and such information should be used with caution. 実験的または非推奨の機能はこれらの RFC において明示されており、そのような情報は注意深く使用されるべきである。
The reader is especially cautioned not to depend on the values which appear in examples to be current or complete, since their purpose is primarily pedagogical. Distribution of this memo is unlimited. 例に示されている値は主として教育目的のものであるため、読者はそれらが最新あるいは完全なものとして頼らないように、特に注意してほしい。この文書の配布に制限はない。
The goal of domain names is to provide a mechanism for naming resources in such a way that the names are usable in different hosts, networks, protocol families, internets, and administrative organizations. ドメイン名の目的は、異なるホスト・ネットワーク・プロトコルファミリ・インターネット・管理組織において名前を利用できる方法で、リソースに名前を付けるメカニズムを提供することである。
From the user's point of view, domain names are useful as arguments to a local agent, called a resolver, which retrieves information associated with the domain name. Thus a user might ask for the host address or mail information associated with a particular domain name. To enable the user to request a particular type of information, an appropriate query type is passed to the resolver with the domain name. To the user, the domain tree is a single information space; the resolver is responsible for hiding the distribution of data among name servers from the user. ユーザーの視点から見ると、ドメイン名はドメイン名に関連する情報を取得するローカルエージェント(リゾルバと呼ばれる)への引数として使えるものである。つまりユーザーは、特定のドメイン名に関連するホストアドレスまたはメール情報を要求することができる。ユーザーが特定のタイプの情報を要求できるように、ドメイン名とともに適切な問合せタイプがリゾルバに渡される。ユーザーにとってドメインツリーは単一の情報空間である。リゾルバはネームサーバー間の情報の分散をユーザーから隠蔽する責任を持つ。
From the resolver's point of view, the database that makes up the domain space is distributed among various name servers. Different parts of the domain space are stored in different name servers, although a particular data item will be stored redundantly in two or more name servers. The resolver starts with knowledge of at least one name server. When the resolver processes a user query it asks a known name server for the information; in return, the resolver either receives the desired information or a referral to another name server. Using these referrals, resolvers learn the identities and contents of other name servers. Resolvers are responsible for dealing with the distribution of the domain space and dealing with the effects of name server failure by consulting redundant databases in other servers. リゾルバの視点から見ると、ドメイン空間を構成するデータベースはさまざまなネームサーバー間に分散されている。特定のデータ項目は二つ以上のネームサーバーに重複して保持されるだろうが、ドメイン空間の異なる部分は異なるネームサーバーに保持される。リゾルバは、少なくともひとつのネームサーバーの知識から始める。リゾルバがユーザーの問合せを処理するとき、既知のネームサーバーにその情報を尋ね、応答として目的の情報か別のネームサーバーへの参照かを受け取る。それらの参照を使用して、リゾルバは他のネームサーバーの身元と内容とを知る。リゾルバはドメイン空間の分散を処理し、他のサーバー内の冗長データベースを調べることでネームサーバーの障害の影響に対処する責任を持つ。
Name servers manage two kinds of data. The first kind of data held in sets called zones; each zone is the complete database for a particular "pruned" subtree of the domain space. This data is called authoritative. A name server periodically checks to make sure that its zones are up to date, and if not, obtains a new copy of updated zones from master files stored locally or in another name server. The second kind of data is cached data which was acquired by a local resolver. This data may be incomplete, but improves the performance of the retrieval process when non-local data is repeatedly accessed. Cached data is eventually discarded by a timeout mechanism. ネームサーバーは二種類の情報を管理する。ひとつめの情報はゾーンと呼ばれる集合に保持される。各ゾーンは、ドメイン空間の特定の "切り取られた(pruned)" サブツリーのための完全なデータベースである。この情報は、権威があると言われる。ネームサーバーは定期的にそのゾーンが最新かどうかを確認し、もし最新でなければ、ローカルまたは別のネームサーバーに保存されているマスターファイルから、更新されたゾーンの新しいコピーを取得する。ふたつめの情報は、ローカルのリゾルバによって取得されるキャッシュ情報である。この情報は不完全である可能性があるが、非ローカルの情報に繰り返しアクセスするときの取得プロセスのパフォーマンスを改善する。キャッシュされた情報は、最終的にタイムアウトによって破棄される。
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. この機能上の構造は、ユーザーインターフェイスの問題と障害回復とリゾルバにおける分布とを分離し、さらにネームサーバーにおけるデータベースの更新とリフレッシュの問題を分離する。
A host can participate in the domain name system in a number of ways, depending on whether the host runs programs that retrieve information from the domain system, name servers that answer queries from other hosts, or various combinations of both functions. The simplest, and perhaps most typical, configuration is shown below: ホストは、そのホストがドメインシステムから情報を取得するプログラムを実行したり、他のホストからの問合せに回答するネームサーバーを実行したり、またはその両方をさまざまに組み合わせたりしているかどうかに依存して、さまざまな方法でドメインネームシステムに参加することができる。もっとも単純な(そしておそらくもっとも典型的な)構成を以下に示す：
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| cache | |
+----------+ |
ローカルホスト | 外部
|
+----------+ +----------+ | +--------+
| | ユーザー問合せ| |問合せ | | |
|ユーザー |-------------->| |---------|->| 外部 |
|プログラム| | リゾルバ | | | ネーム |
| |<--------------| |<--------|--|サーバー|
| | ユーザー応答 | |応答 | | |
+----------+ +----------+ | +--------+
| A |
キャッシュ追加 | | 参照 |
V | |
+----------+ |
|キャッシュ| |
+----------+ |
User programs interact with the domain name space through resolvers; the format of user queries and user responses is specific to the host and its operating system. User queries will typically be operating system calls, and the resolver and its cache will be part of the host operating system. Less capable hosts may choose to implement the resolver as a subroutine to be linked in with every program that needs its services. Resolvers answer user queries with information they acquire via queries to foreign name servers and the local cache. ユーザープログラムはリゾルバを通してドメイン名空間と情報をやりとりする。ユーザー問合せとユーザー応答のフォーマットは、ホストとそのオペレーティングシステムとに固有である。ユーザー問合せは一般にオペレーティングシステムコールであり、リゾルバとそれが保持するキャッシュとはホストのオペレーティングシステムの一部になるだろう。より能力の低いホストは、サービスを必要とするすべてのプログラムにリンクされるサブルーチンとしてリゾルバを実装する選択をしてもよい。リゾルバはユーザー問合せに対し、外部ネームサーバーへの問合せから取得した情報とローカルキャッシュとから答える。
Note that the resolver may have to make several queries to several different foreign name servers to answer a particular user query, and hence the resolution of a user query may involve several network accesses and an arbitrary amount of time. The queries to foreign name servers and the corresponding responses have a standard format described in this memo, and may be datagrams. リゾルバは、ある特定のユーザー問合せに答える複数の外部ネームサーバーへ複数の問合せを行わなければならない可能性があり、したがって、ユーザー問合せの解決は複数のネットワークアクセスと不定な時間とを必要とする可能性があることに注意してほしい。外部ネームサーバーへの問合せとその応答とはこの文書で説明される標準フォーマットを持ち、データグラムであってもよい。
Depending on its capabilities, a name server could be a stand alone program on a dedicated machine or a process or processes on a large timeshared host. A simple configuration might be: 能力に応じて、ネームサーバーはスタンドアロンのプログラムであったり、巨大なタイムシェアリングホスト上の単一または複数のプロセスであったりしてよい。単純な構成は以下のようになるだろう：
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
ローカルホスト | 外部
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |応答 | | |
| | | | ネーム |---------|->|外部 |
|マスター |-------------->| サーバー | | |リゾルバ|
| ファイル| | | |<--------|--| |
| |/ | | 問合せ | +--------+
+---------+ +----------+ |
Here a primary name server acquires information about one or more zones by reading master files from its local file system, and answers queries about those zones that arrive from foreign resolvers. ここでプライマリネームサーバーはローカルファイルシステムからマスターファイルを読み取ることでひとつ以上のゾーンに関する情報を取得し、外部リゾルバから来るそれらのゾーンに付いての問合せに回答する。
The DNS requires that all zones be redundantly supported by more than one name server. Designated secondary servers can acquire zones and check for updates from the primary server using the zone transfer protocol of the DNS. This configuration is shown below: DNS は、すべてのゾーンが二つ以上のネームサーバーによって冗長的にサポートされることを要求する。指定されたセカンダリサーバーは、DNS のゾーン転送プロトコルを使用してプライマリサーバーからの更新を確認し、ゾーンを取得することができる。この構成を以下に示す：
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
+------------------|--| Server |
maintenance responses | +--------+
ローカルホスト | 外部
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |応答 | | |
| | | | ネーム |---------|->|外部 |
|マスター |-------------->| サーバー | | |リゾルバ|
| ファイル| | | |<--------|--| |
| |/ | | 問合せ | +--------+
+---------+ +----------+ |
A | 保守 | +--------+
| +------------|->| |
| 問合せ | |外部 |
| | |ネーム |
+------------------|--|サーバー|
保守応答 | +--------+
In this configuration, the name server periodically establishes a virtual circuit to a foreign name server to acquire a copy of a zone or to check that an existing copy has not changed. The messages sent for these maintenance activities follow the same form as queries and responses, but the message sequences are somewhat different. この構成においてネームサーバーは定期的に外部ネームサーバーへの仮想通信路を確立し、ゾーンのコピーの取得、または既存のコピーが変更されたかどうかの確認を行う。これらの保守活動のためのメッセージは取得と応答とで同じ形式にしたがうが、メッセージの順序は若干異なる。
The information flow in a host that supports all aspects of the domain name system is shown below: ドメインネームシステムのすべての機能をサポートするホストにおける情報の流れを以下に示す：
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| Shared | |
| database | |
+----------+ |
A | |
+---------+ refreshes | | references |
/ /| | V |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
+------------------|--| Server |
maintenance responses | +--------+
ローカルホスト | 外部
|
+---------+ +----------+ | +--------+
| | ユーザー問合せ| |問合せ | | |
|ユーザー |-------------->| |---------|->|外部 |
|プログラ | | リゾルバ | | |ネーム |
|ム |<--------------| |<--------|--|サーバー|
| | ユーザー応答 | |応答 | | |
+---------+ +----------+ | +--------+
| A |
キャッシュ追加 | | 参照 |
V | |
+----------+ |
|共有データ| |
|ベース | |
+----------+ |
A | |
+---------+ リフレッシュ| | 参照 |
/ /| | V |
+---------+ | +----------+ | +--------+
| | | | |応答 | | |
| | | | ネーム |---------|->|外部 |
|マスター |-------------->| サーバー | | |リゾルバ|
| ファイル| | | |<--------|--| |
| |/ | | 問合せ | +--------+
+---------+ +----------+ |
A | 保守 | +--------+
| +------------|->| |
| 問合せ | |外部 |
| | |ネーム |
+------------------|--|サーバー|
保守応答 | +--------+
The shared database holds domain space data for the local name server and resolver. The contents of the shared database will typically be a mixture of authoritative data maintained by the periodic refresh operations of the name server and cached data from previous resolver requests. The structure of the domain data and the necessity for synchronization between name servers and resolvers imply the general characteristics of this database, but the actual format is up to the local implementor. 共有データベースは、ローカルのネームサーバーとリゾルバとのためのドメイン空間情報を保持する。一般に共有データベースの内容は、ネームサーバーの定期的なリフレッシュ操作により維持される権威情報と、リゾルバの過去のリクエストに由来するキャッシュ情報とが混在したものである。ドメイン情報の構造とネームサーバー・リゾルバ間の同期の必要性とは、このデータベースの一般的な特性を暗示するが、実際のフォーマットはローカルの実装者次第である。
Information flow can also be tailored so that a group of hosts act together to optimize activities. Sometimes this is done to offload less capable hosts so that they do not have to implement a full resolver. This can be appropriate for PCs or hosts which want to minimize the amount of new network code which is required. This scheme can also allow a group of hosts can share a small number of caches rather than maintaining a large number of separate caches, on the premise that the centralized caches will have a higher hit ratio. In either case, resolvers are replaced with stub resolvers which act as front ends to resolvers located in a recursive server in one or more name servers known to perform that service: 動作を最適化するためにホストのグループが協働するように、情報の流れを協調させることもできる。これは比較的能力の劣るホストが完全なリゾルバを実装しなくてもよいようにするために行われる場合があり、必要とされるネットワークコードの量を最小化したい PC やホストのために適切なことがある。集中型のキャッシュはより高いヒット率を持つことを前提として、この仕組みによりホストのグループは、多数の個別のキャッシュを維持するのではなく、少数のキャッシュを共有することが可能になる。どちらの場合もリゾルバは、サービスを実行していることが分かっているひとつ以上のネームサーバー内の再帰サーバーに設置されたリゾルバへのフロントエンドとして動作するスタブリゾルバに置き換えられる。
Local Hosts | Foreign
|
+---------+ |
| | responses |
| Stub |<--------------------+ |
| Resolver| | |
| |----------------+ | |
+---------+ recursive | | |
queries | | |
V | |
+---------+ recursive +----------+ | +--------+
| | queries | |queries | | |
| Stub |-------------->| Recursive|---------|->|Foreign |
| Resolver| | Server | | | Name |
| |<--------------| |<--------|--| Server |
+---------+ responses | |responses| | |
+----------+ | +--------+
| Central | |
| cache | |
+----------+ |
ローカルホスト | 外部
|
+---------+ |
| | 応答 |
| スタブ |<--------------------+ |
| リゾルバ| | |
| |----------------+ | |
+---------+ 再帰 | | |
問合せ | | |
V | |
+---------+ 再帰 +----------+ | +--------+
| | 問合せ | |問合せ | | |
| スタブ |-------------->| 再帰 |---------|->|外部 |
| リゾルバ| | サーバー | | |ネーム |
| |<--------------| |<--------|--|サーバー|
+---------+ 応答 | |応答 | | |
+----------+ | +--------+
|中央 | |
|キャッシュ| |
+----------+ |
In any case, note that domain components are always replicated for reliability whenever possible. いずれにしてもドメインの構成要素は、可能な場合には常に信頼性のために複製されることに注意してほしい。
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. ドメインシステムは、低レベルの(しかし基本的な)問題を扱ういくつかの慣例を持つ。実装者が自身のシステムの範囲内でこれらの慣例に違反するのは自由だが、他のホストから観測される振る舞いはすべてこれらの慣例を順守したものでなければならない。
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. しかしながらあるオブジェクトにドメイン名を割当てるとき、慎重なユーザーはそのオブジェクトに、ドメインシステムの規則と既存の規則(それが公開されているものであろうと、既存プログラムによって必要とされているものであろうと)との両方を満足する名前を選択するだろう。
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
<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> ::= A から Z までの大文字と a から z までの小文字のうち、
任意の 1 文字
<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
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. 同じように、複数オクテットのフィールドが数量を表す場合、常にそのフィールド全体のもっとも左のビットが最上位ビットを表す。複数オクテットの値が転送される場合、最上位オクテットから先に転送される。
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 の公式プロトコルのすべてにおいて、文字列(例えばラベルやドメイン名など)同士の比較はすべて大文字・小文字を区別せずに行われる。今のところこの規則はドメインシステム全体を通して例外なく効力を持つ。しかしながら現在の使用法を越える将来の追加機能が、名前において完全なバイナリオクテットを使用する能力を必要とする可能性がある。そのため、ドメイン名を 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. データがドメインシステムに入るとき、可能な場合には常にもとの大文字・小文字が保持されるべきである。特定の状況ではこれは不可能である。例えばデータベース内に二つの 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. ドメインデータベースにデータを投入するシステム管理者は、彼らのシステムが大文字・小文字を区別するのであれば、ドメインシステムに提供するデータを大文字・小文字の一貫した方法で表現するよう注意すべきである。ドメインシステム内のデータ分散システムは、一貫した表現が維持されることを保証するだろう。
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 names 255 octets or less TTL positive values of a signed 32 bit number. UDP messages 512 octets or less
ラベル 63 オクテット以下 名前 255 オクテット以下 TTL 32 ビットの正の値 UDP メッセージ 512 オクテット以下
Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less. メッセージ内のドメイン名は一連のラベルで表現される。各ラベルはの先頭には 1 オクテットのレングスフィールドが置かれ、その後にその数だけオクテットが続く。すべてのドメイン名はルートを表すヌルラベルで終了するため、ドメイン名はレングスバイト・ゼロで終了する。すべてのレングスオクテットの上位 2 ビットはゼロでなければならず、レングスフィールドの残りが 6 ビットのため、ラベルは 63 オクテット以下に制限される。
To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less. 実装を簡単にするために、ドメイン名の全長(つまりラベルオクテットとレングスオクテットとの合計)は 255 オクテット以下に制限される。
Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. Name servers and resolvers must compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII with zero parity. Non-alphabetic codes must match exactly. ラベルを構成するオクテットには任意の 8 ビット値を含むことができるが、この文書の別のところで説明されている好ましい文法(既存のホスト名の命名規則と互換性を持つ)にしたがうことが推奨される。ネームサーバーとリゾルバとは、ゼロパリティの ASCII を前提として、大文字・小文字を区別しない方法(つまり A=a)でラベルを比較しなければならない。非アルファベットコードは正確に一致しなければならない。
All RRs have the same top level format shown below: すべての RR は以下に示す同一の上位レベルフォーマットを持つ：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
TYPE fields are used in resource records. Note that these types are a subset of QTYPEs. TYPE フィールドはリソースレコード内で使用される。これらのタイプは QTYPE のサブセットであることに注意してほしい。
TYPE value and meaning A 1 a host address NS 2 an authoritative name server MD 3 a mail destination (Obsolete - use MX) MF 4 a mail forwarder (Obsolete - use MX) CNAME 5 the canonical name for an alias SOA 6 marks the start of a zone of authority MB 7 a mailbox domain name (EXPERIMENTAL) MG 8 a mail group member (EXPERIMENTAL) MR 9 a mail rename domain name (EXPERIMENTAL) NULL 10 a null RR (EXPERIMENTAL) WKS 11 a well known service description PTR 12 a domain name pointer HINFO 13 host information MINFO 14 mailbox or mail list information MX 15 mail exchange TXT 16 text strings
TYPE 値と意味 A 1 ホストアドレス NS 2 権威ネームサーバー MD 3 メールの宛先 (非推奨 - MX を使用すること) MF 4 メールの転送者 (非推奨 - MX を使用すること) CNAME 5 エイリアスの正規名 SOA 6 権威ゾーンの開始を表す MB 7 メールボックスドメイン名 (試験的) MG 8 メールグループメンバー (試験的) MR 9 メールリネームドメイン名 (試験的) NULL 10 ヌル RR (試験的) WKS 11 よく知られているサービスの記述 PTR 12 ドメイン名ポインタ HINFO 13 ホスト情報 MINFO 14 メールボックスまたはメールリストの情報 MX 15 メールエクスチェンジ TXT 16 テキスト文字列
QTYPE fields appear in the question part of a query. QTYPES are a superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the following QTYPEs are defined: QTYPE フィールドは問合せの Question 部に現れる。QTYPE は TYPE の上位集合である。そのためすべての TYPE は有効な QTYPE である。加えて、以下の QTYPE が定義されている：
AXFR 252 A request for a transfer of an entire zone MAILB 253 A request for mailbox-related records (MB, MG or MR) MAILA 254 A request for mail agent RRs (Obsolete - see MX) * 255 A request for all records
AXFR 252 ゾーン全体を転送するためのリクエスト MAILB 253 メールボックス関連レコードの(MB、MG、MR)のためのリクエスト MAILA 254 メールエージェント RR のためのリクエスト (非推奨 - MX 参照) * 255 全レコードのためのリクエスト
CLASS fields appear in resource records. The following CLASS mnemonics and values are defined: CLASS フィールドはリソースレコード内に現れる。以下の CLSSS ニーモニックと値とが定義されている：
IN 1 the Internet
CS 2 the CSNET class (Obsolete - used only for examples in
some obsolete RFCs)
CH 3 the CHAOS class
HS 4 Hesiod [Dyer 87]
IN 1 インターネット
CS 2 CSNET クラス (非推奨 - 一部の廃止された RFC において例として
のみ使用されている
CH 3 CHAOS クラス
HS 4 Hesiod [Dyer 87]
QCLASS fields appear in the question section of a query. QCLASS values are a superset of CLASS values; every CLASS is a valid QCLASS. In addition to CLASS values, the following QCLASSes are defined: QCLASS フィールドは問合せの Question セクションに現れる。QCLASS の値は CLASS の値の上位集合である。そのためすべての CLASS は有効な QTYPE である。CLASS の値に加えて、以下の QCLASS が定義されている：
* 255 any class
* 255 すべてのクラス
The following RR definitions are expected to occur, at least potentially, in all classes. In particular, NS, SOA, CNAME, and PTR will be used in all classes, and have the same format in all classes. Because their RDATA format is known, all domain names in the RDATA section of these RRs may be compressed. 以下の RR の定義は、(少なくとも潜在的には)すべてのクラスにおいて現れることを期待される。具体的にいうと、NS・SOA・CNAME・PTR はすべてのクラスにおいて使用され、すべてのクラスにおいて同じフォーマットを持つ。これらの RDATA のフォーマットは既知であるため、RDATA セクション内のすべてのドメイン名を圧縮することができる。
<domain-name> is a domain name represented as a series of labels, and terminated by a label with zero length. <character-string> is a single length octet followed by that number of characters. <character-string> is treated as binary information, and can be up to 256 characters in length (including the length octet). <domain-name> は一連のラベルとして表現されるドメイン名であり、長さゼロのラベルで終了する。<character-string> は長さを表す単一オクテットのあとに、その数だけ文字が続く。<character-string> はバイナリ情報として扱われ、(レングスオクテットを含めて)256 文字までの長さを取ることができる。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CNAME RRs cause no additional section processing, but name servers may choose to restart the query at the canonical name in certain cases. See the description of name server logic in [RFC-1034] for details. CNAME RR は追加のセクション処理を引き起こさないが、特定の状況においてネームサーバーは正規名から問合せを再開する選択をしてもよい。詳細は [RFC-1034] のネームサーバーロジックの説明を参照してほしい。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CPU /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ OS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
Standard values for CPU and OS can be found in [RFC-1010]. CPU・OS のための標準的な値は [RFC-1010] に示されている。
HINFO records are used to acquire general information about a host. The main use is for protocols such as FTP that can use special procedures when talking between machines or operating systems of the same type. HINFO レコードは、ホストに関する一般的な情報を取得するために使用される。主な用途は、同種のマシン間またはオペレーティングシステム間で対話するときに特別な手続きを使用できる FTP などのプロトコル用である。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MB records cause additional section processing which looks up an A type RRs corresponding to MADNAME. MB レコードは、MADNAME に対応するタイプ A の RR を検索する追加のセクション処理を引き起こす。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MD records cause additional section processing which looks up an A type record corresponding to MADNAME. MD レコードは、MADNAME に対応するタイプ A のレコードを検索する追加のセクション処理を引き起こす。
MD is obsolete. See the definition of MX and [RFC-974] for details of the new scheme. The recommended policy for dealing with MD RRs found in a master file is to reject them, or to convert them to MX RRs with a preference of 0. MD は非推奨である。新しい仕組みの詳細に付いては、MX の定義と [RFC-974] とを参照してほしい。マスターファイルに見つかった MD RR を扱う際に推奨されるポリシーは、それらを拒否するか、優先度 0 の MX RR に変換することである。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MF records cause additional section processing which looks up an A type record corresponding to MADNAME. MF レコードは、MADNAME に対応するタイプ A のレコードを検索する追加のセクション処理を引き起こす。
F is obsolete. See the definition of MX and [RFC-974] for details of the new scheme. The recommended policy for dealing with MD RRs found in a master file is to reject them, or to convert them to MX RRs with a preference of 10. MF は非推奨である。新しい仕組みの詳細に付いては、MX の定義と [RFC-974] とを参照してほしい。マスターファイルに見つかった MD RR を扱う際に推奨されるポリシーは、それらを拒否するか、優先度 10 の MX RR に変換することである。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MGMNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MG records cause no additional section processing. MG レコードは追加のセクション処理を引き起こさない。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RMAILBX /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EMAILBX /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MINFO records cause no additional section processing. Although these records can be associated with a simple mailbox, they are usually used with a mailing list. MINFO は追加のセクション処理を引き起こさない。これらのレコードを単純なメールボックスに関連付けることもできるが、通常はメーリングリストとともに使用される。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NEWNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MR records cause no additional section processing. The main use for MR is as a forwarding entry for a user who has moved to a different mailbox. MR レコードは追加のセクション処理を引き起こさない。MR の主な使用法は、別のメールボックスに移動したユーザーのための転送エントリとしてである。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGE /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MX records cause type A additional section processing for the host specified by EXCHANGE. The use of MX RRs is explained in detail in [RFC-974]. MX レコードは、EXCHANGE により特定されるホストのための、タイプ A の追加のセクション処理を引き起こす。MX RR の使用法は [RFC-974] で詳細に説明されている。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ <anything> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Anything at all may be in the RDATA field so long as it is 65535 octets or less. 65535 オクテット以下であれば、RDATA に何が入れられてもよい。
NULL records cause no additional section processing. NULL RRs are not allowed in master files. NULLs are used as placeholders in some experimental extensions of the DNS. NULL レコードは追加のセクション処理を引き起こさない。マスターファイル内では NULL RR は許可されない。NULL は、DNS の試験的拡張の一部におけるプレースホルダーとして使用される。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NS records cause both the usual additional section processing to locate a type A record, and, when used in a referral, a special search of the zone in which they reside for glue information. NS レコードは、タイプ A のレコードを検索するための通常の追加のセクション処理と、参照の場合には、グルー情報が存在するゾーンの特殊な検索とを引き起こす。
The NS RR states that the named host should be expected to have a zone starting at owner name of the specified class. Note that the class may not indicate the protocol family which should be used to communicate with the host, although it is typically a strong hint. For example, hosts which are name servers for either Internet (IN) or Hesiod (HS) class information are normally queried using IN class protocols. NS RR は、指名されたホストが、指定された所有者名から始まるゾーンを持っているはずであることを宣言する。クラスはホストとの通信に使用されるべきプロトコルファミリを表さなくてもよいが、一般に大きなヒントになることに注意してほしい。例えば、インターネット(IN) または Hesiod (HS) のどちらかのクラス情報のネームサーバーであるホストは、通常 IN クラスプロトコルを使用して問合せられる。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ PTRDNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PTR records cause no additional section processing. These RRs are used in special domains to point to some other location in the domain space. These records are simple data, and don't imply any special processing similar to that performed by CNAME, which identifies aliases. See the description of the IN-ADDR.ARPA domain for an example. PTR レコードは追加のセクション処理を引き起こさない。これらの RR は、ドメイン空間内の他の場所を指し示す特殊なドメインにおいて使用される。これらのレコードは単純なデータであり、エイリアスを表す CNAME によって実行されるような特別な処理を含まない。例に付いては IN-ADDR.ARPA ドメインの説明を参照してほしい。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SERIAL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| REFRESH |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RETRY |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EXPIRE |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MINIMUM |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
SOA records cause no additional section processing. SOA レコードは追加のセクション処理を引き起こさない。
All times are in units of seconds. 時間はすべて秒単位である。
Most of these fields are pertinent only for name server maintenance operations. However, MINIMUM is used in all query operations that retrieve RRs from a zone. Whenever a RR is sent in a response to a query, the TTL field is set to the maximum of the TTL field from the RR and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower bound on the TTL field for all RRs in a zone. Note that this use of MINIMUM should occur when the RRs are copied into the response and not when the zone is loaded from a master file or via a zone transfer. The reason for this provison is to allow future dynamic update facilities to change the SOA RR with known semantics. これらのフィールドの大部分は、ネームサーバーのメンテナンス操作にのみ関連する。しかしながら MINIMUM は、ゾーンに由来する RR を取得するすべての問合せ操作において使用される。問合せに応えて RR が送信される場合には常に、TTL フィールドはその RR の TTL フィールドと適切な SOA 内の MINIMUM フィールドとのうちの最大値がセットされる。したがって MINIMUM は、ゾーン内のすべての RR のための TTL フィールドの下限値である。この MINIMUM の使用法は、RR が応答にコピーされる場合に行われるべきであり、ゾーンがマスターファイルから読み込まれたり、ゾーン転送によって読み込まれたりした場合には行われないべきである。この規定の理由は、将来の動的な更新機能に、既存の動作を取る SOA RR の変更を許可するためである。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ TXT-DATA /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
TXT RRs are used to hold descriptive text. The semantics of the text depends on the domain where it is found. TXT RR は説明用テキストを保持するために使用される。このテキストの意味は、そのテキストが見つかるドメインに依存する。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
Hosts that have multiple Internet addresses will have multiple A records. 複数のインターネットアドレスを持つホストは、複数の A レコードを持つことになる。
A records cause no additional section processing. The RDATA section of an A line in a master file is an Internet address expressed as four decimal numbers separated by dots without any imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6"). A レコードは追加のセクション処理を引き起こさない。マスターファイル内の A の行の RDATA セクションはインターネットアドレスであり、ドット区切りで空白を埋め込まない 4 つの 10 進数として表現される。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
The WKS record is used to describe the well known services supported by a particular protocol on a particular internet address. The PROTOCOL field specifies an IP protocol number, and the bit map has one bit per port of the specified protocol. The first bit corresponds to port 0, the second to port 1, etc. If the bit map does not include a bit for a protocol of interest, that bit is assumed zero. The appropriate values and mnemonics for ports and protocols are specified in [RFC-1010]. WKS レコードは、特定のインターネットアドレス上で特定のプロトコルによってサポートされる既知のサービスを説明するために使用される。PROTOCOL フィールドは IP プロトコル番号を特定し、ビットマップはその指定されたプロトコルのポートごとに 1 ビットを持つ。第 1 ビットがポート 0、第 2 ビットがポート 1、などと対応する。関心のあるプロトコルのためのビットがビットマップに含まれない場合、そのビットはゼロと見なされる。ポートとプロトコルとのための適切な値とニーモニックとは、[RFC-1010] で規定されている。
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port 25 (SMTP). If this bit is set, a SMTP server should be listening on TCP port 25; if zero, SMTP service is not supported on the specified address. 例えば PROTOCOL=TCP (6) の場合、26 番目のビットは TCP ポート 25 (SMTP) に対応する。そのビットが 1 であれば、TCP ポート 25 上で SMTP サーバーがリスニングしているはずである。ゼロであれば、指定されたアドレス上で SMTP サービスはサポートされていない。
The purpose of WKS RRs is to provide availability information for servers for TCP and UDP. If a server supports both TCP and UDP, or has multiple Internet addresses, then multiple WKS RRs are used. WKS RR の目的は、サーバーの TCP および UDP の利用可能情報を提供することである。サーバーが TCP と UDP とを両方サポートするか、複数のインターネットアドレスを持つ場合、複数の WKS RR が使用される。
WKS RRs cause no additional section processing. WKS RR は追加のセクション処理を引き起こさない。
In master files, both ports and protocols are expressed using mnemonics or decimal numbers. マスターファイル内においてポートおよびプロトコルは、ニーモニックまたは 10 進数値を使用して表される。
The Internet uses a special domain to support gateway location and Internet address to host mapping. Other classes may employ a similar strategy in other domains. The intent of this domain is to provide a guaranteed method to perform host address to host name mapping, and to facilitate queries to locate all gateways on a particular network in the Internet. ゲートウェイの位置とインターネットアドレスからホストへのマッピングとをサポートするために、インターネットは特殊なドメインを使用する。他のクラスも他のドメイン内で同じような戦略を採用することができる。このドメインの目的は、ホストアドレスからホスト名へのマッピングを実行するための保証された手段を提供することと、インターネットにおいて特定のネットワーク上のすべてのゲートウェイを位置付けるための問合せを手助けすることである。
Note that both of these services are similar to functions that could be performed by inverse queries; the difference is that this part of the domain name space is structured according to address, and hence can guarantee that the appropriate data can be located without an exhaustive search of the domain space. これらのサービスは逆問合せによって行われる機能に似ている。違いは、ドメイン名空間のこの部分がアドレスに従って構造化されており、したがってドメイン空間の網羅的な検索を行わなくても適切な情報が検索できることを保証できることである。
The domain begins at IN-ADDR.ARPA and has a substructure which follows the Internet addressing structure. このドメインは IN-ADDR.ARPA に位置し、インターネットのアドレッシング構造に従う構造を持つ。
Domain names in the IN-ADDR.ARPA domain are defined to have up to four labels in addition to the IN-ADDR.ARPA suffix. Each label represents one octet of an Internet address, and is expressed as a character string for a decimal value in the range 0-255 (with leading zeros omitted except in the case of a zero octet which is represented by a single zero). IN-ADDR.ARPA 内のドメイン名は、接頭辞 IN-ADDR.ARPA に加えて最大 4 つのラベルを持つと定義される。各ラベルはインターネットアドレスの 1 オクテットを表し、0-255 の範囲の 10 進数値の文字列として表現される(先行するゼロは省略されるが、例外としてゼロのオクテットは単独のゼロで表される)。
Host addresses are represented by domain names that have all four labels specified. Thus data for Internet address 10.2.0.52 is located at domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to read, allows zones to be delegated which are exactly one network of address space. For example, 10.IN-ADDR.ARPA can be a zone containing data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for MILNET. Address nodes are used to hold pointers to primary host names in the normal domain space. ホストアドレスは 4 つのラベルすべてを持つドメイン名によって表現される。したがって、インターネットアドレス 10.2.0.52 のための情報は、ドメイン名 52.0.2.10.IN-ADDR.ARPA に位置する。(読みにくいにもかかわらず)反転されていることにより、アドレス空間内のちょうどひとつのネットワークに当たるゾーンを委譲することができる。例えば、10.IN-ADDR.ARPA は ARPANET のための情報を含むゾーンである一方、26.IN-ADDR.ARPA は MILNET のための別のゾーンであることができる。アドレスノードは、通常のドメイン空間における主要なホスト名へのポインタを保持するために使用される。
Network numbers correspond to some non-terminal nodes at various depths in the IN-ADDR.ARPA domain, since Internet network numbers are either 1, 2, or 3 octets. Network nodes are used to hold pointers to the primary host names of gateways attached to that network. Since a gateway is, by definition, on more than one network, it will typically have two or more network nodes which point at it. Gateways will also have host level pointers at their fully qualified addresses. インターネットのネットワーク番号は 1 ～ 3 オクテットの何れかであるため、ネットワーク番号は IN-ADDR.ARPA ドメインにおける様々な深さの非終端ノードに対応する。ネットワークノードは、そのネットワークに接続するゲートウェイの主要なホスト名へのポインタを保持するために使用される。ゲートウェイは原理的に二つ以上のネットワーク上に属するため、一般にそれを指し示す二つまたはそれ以上のネットワークノードを持つ。またゲートウェイは、完全限定アドレスによるホストレベルのポインタも持つ。
Both the gateway pointers at network nodes and the normal host pointers at full address nodes use the PTR RR to point back to the primary domain names of the corresponding hosts. ネットワークノードにおけるゲートウェイポインタも、完全アドレスノードにおける通常のホストポインタも、対応するホストの主要なドメイン名を指し示すために PTR RR を使用する。
For example, the IN-ADDR.ARPA domain will contain information about the ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET- GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4 and a name GW.LCS.MIT.EDU, the domain database would contain: 例えば IN-ADDR.ARPA ドメインは、ネット 10 と 26 との間の ISI ゲートウェイ、ネット 10 から MIT のネット 18 への MIT ゲートウェイ、そしてホスト A.ISI.EDU と MULTICS.MIT.EDU とに関する情報を含むだろう。ISI のゲートウェイがアドレス 10.2.0.22 と 26.0.0.103、名前 MILNET-GW.ISI.EDU を持ち、MIT のゲートウェイがアドレス 10.0.0.77 と 18.10.0.4、名前 GW.LCS.MIT.EDU を持つと仮定すると、ドメインデータベースは以下の内容を含むことになるだろう：
10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
Thus a program which wanted to locate gateways on net 10 would originate a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It would receive two RRs in response: ネット 10 上のゲートウェイを検索したいプログラムは、QTYPE=PTR、QCLASS=IN、QNAME=10.IN-ADDR.ARPA の形の問合せを発行するだろう。そのプログラムは応答内で二つの RR を受け取るだろう：
10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
The program could then originate QTYPE=A, QCLASS=IN queries for MILNET- GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of these gateways. 次にプログラムは、これらのゲートウェイのインターネットアドレスを探すために、MILNET-GW.ISI.EDU. と GW.LCS.MIT.EDU とのための、QTYPE=A、QCLASS=IN の問合せを発行できるだろう。
A resolver which wanted to find the host name corresponding to Internet host address 10.0.0.6 would pursue a query of the form QTYPE=PTR, QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive: インターネットホストアドレス 10.0.0.6 に対応するホスト名を探したいリゾルバは、QTYPE=PTR、QCLASS=IN、QNAME=6.0.0.10.IN-ADDR.ARPA の形の問合せを行い、以下の内容を受け取るだろう：
6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
Several cautions apply to the use of these services: これらのサービスを使用するにあたり、いくつかの注意事項が適用される：
The previously defined types and classes are the ones in use as of the date of this memo. New definitions should be expected. This section makes some recommendations to designers considering additions to the existing facilities. The mailing list [email protected] is the forum where general discussion of design issues takes place. 先に定義したタイプとクラスとは、この文書の日付現在において使用されているものである。新しい定義が期待されるべきである。このセクションは、既存の機能への追加を考える設計者に対する提言を行う。メーリングリスト [email protected] は、一般的な設計の議論が行われるフォーラムである。
In general, a new type is appropriate when new information is to be added to the database about an existing object, or we need new data formats for some totally new object. Designers should attempt to define types and their RDATA formats that are generally applicable to all classes, and which avoid duplication of information. New classes are appropriate when the DNS is to be used for a new protocol, etc which requires new class-specific data formats, or when a copy of the existing name space is desired, but a separate management domain is necessary. 一般に新しいタイプは、既存オブジェクトに関するデータベースに新しい情報を追加する場合や、完全に新しいオブジェクトのための新しいデータフォーマットを追加する必要がある場合に適切である。設計者は、ほとんどの場合にすべてのクラスに適用可能で、情報の重複を避けるようなタイプとその RDATA とを定義するよう試みるべきである。新しいクラスは、新しいクラス固有のデータフォーマットを必要とする新しいプロトコルなどで DNS が使用されることになった場合や、既存の名前空間のコピーが求められるが別の管理ドメインを必要とする場合に適切である。
New types and classes need mnemonics for master files; the format of the master files requires that the mnemonics for type and class be disjoint. 新しいタイプおよびクラスは、マスターファイルのためのニーモニックを必要とする。マスターファイルのフォーマットは、タイプおよびクラスのニーモニックが異なることを必要とする。
TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes respectively. TYPE および CLASS の値は、それぞれ QTYPE および QCLASS の適切な部分集合でなければならない。
The present system uses multiple RRs to represent multiple values of a type rather than storing multiple values in the RDATA section of a single RR. This is less efficient for most applications, but does keep RRs shorter. The multiple RRs assumption is incorporated in some experimental work on dynamic update methods. 複数のタイプの値を表す場合、現在のシステムは単一の RR の RDATA セクションに複数の値を保存するのではなく、複数の RR を使用する。これは大部分のアプリケーションにとって効率に劣るが、RR を短く保持できる。複数 RR の条件は、動的な更新方法についての実験研究に組み込まれている。
The present system attempts to minimize the duplication of data in the database in order to insure consistency. Thus, in order to find the address of the host for a mail exchange, you map the mail domain name to a host name, then the host name to addresses, rather than a direct mapping to host address. This approach is preferred because it avoids the opportunity for inconsistency. 現在のシステムは、一貫性を保証するためにデータベース内の情報の重複を最小限にすることを試みている。したがって、メールエクスチェンジのためのホストアドレスを見つけるためには、メールドメイン名を直接ホストアドレスにマップするのではなく、メールドメイン名をホスト名にマップし、次にホスト名をアドレスにマップする。このアプローチは矛盾を回避するために好ましい。
In defining a new type of data, multiple RR types should not be used to create an ordering between entries or express different formats for equivalent bindings, instead this information should be carried in the body of the RR and a single type used. This policy avoids problems with caching multiple types and defining QTYPEs to match multiple types. データの新しいタイプの定義において、エントリ間の順序付けを生成したり、同等のひも付けのための異なるフォーマットを表したりするためには、複数の RR タイプを使用するべきではなく、代わりに単一のタイプを使用し、その情報は RR のボディ内で伝えられるべきである。このポリシーにより、複数のタイプをキャッシュする場合、および複数のタイプに一致する QTYPE を定義する場合の問題を避けられる。
For example, the original form of mail exchange binding used two RR types one to represent a "closer" exchange (MD) and one to represent a "less close" exchange (MF). The difficulty is that the presence of one RR type in a cache doesn't convey any information about the other because the query which acquired the cached information might have used a QTYPE of MF, MD, or MAILA (which matched both). The redesigned service used a single type (MX) with a "preference" value in the RDATA section which can order different RRs. However, if any MX RRs are found in the cache, then all should be there. 例えば、メールエクスチェンジのひも付けのオリジナルの形式は二つの RR を使用しており、ひとつは "より近い(closer)" エクスチェンジ(MD)を表し、ひとつは "それほど近くない(less close)" エクスチェンジ(MF)を表していた。問題は、キャッシュ情報を取得したときの問合せが QTYPE に MF、MD、または MAILA(両方に一致する)を使用していたかもしれないため、キャッシュ内に一方の RR タイプが存在しても、もう一方に付いての情報を何も伝えないことである。再設計されたサービスは単一のタイプ(MX)を使用し、RDATA に "優先順位(preference)" 値を持ち、異なる RR を順位付けることができる。しかしながらキャッシュ内に何れかの MX RR が見つかった場合、そこにすべてが存在するべきである。
All communications inside of the domain protocol are carried in a single format called a message. The top level format of message is divided into 5 sections (some of which are empty in certain cases) shown below: ドメインプロトコル内部のすべての通信は、メッセージと呼ばれる単一フォーマットで運ばれる。メッセージの最上位レベルは以下の 5 つのセクションに分けられる(いくつかは空になる場合もある)：
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | RRs answering the question
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding additional information
+---------------------+
+---------------------+
| Header |
+---------------------+
| Question | ネームサーバーへの質問
+---------------------+
| Answer | 質問に答える RR
+---------------------+
| Authority | 権威を指す RR
+---------------------+
| Additional | 付加情報を持つ RR
+---------------------+
The header section is always present. The header includes fields that specify which of the remaining sections are present, and also specify whether the message is a query or a response, a standard query or some other opcode, etc. Header セクションは常に提供される。ヘッダは、残りのセクションのどれが提供されているかや、そのメッセージが問合せなのか回答なのか、標準問合せなのか他の opcode なのかなどを特定するフィールドを含む。
The names of the sections after the header are derived from their use in standard queries. The question section contains fields that describe a question to a name server. These fields are a query type (QTYPE), a query class (QCLASS), and a query domain name (QNAME). The last three sections have the same format: a possibly empty list of concatenated resource records (RRs). The answer section contains RRs that answer the question; the authority section contains RRs that point toward an authoritative name server; the additional records section contains RRs which relate to the query, but are not strictly answers for the question. ヘッダに続く各セクションの名前は、標準問合せにおける使われ方に由来している。Question セクションは、ネームサーバーへの質問を表すフィールド群を含む。そのフィールドは、問合せタイプ(QTYPE)、問合せクラス(QCLASS)、問合せドメイン名(QNAME)である。最後の三つのセクションは、連結されたリソースレコード(RR)のリスト(空の場合もある)という同じフォーマットを持つ。Answer セクションは質問に答える RR を含む。Authority セクションは権威ネームサーバーを指す RR を含む。Additional セクションは、厳密には質問の回答ではないが、質問に関係のある RR を含む。
The header contains the following fields: Header セクションは以下のフィールドを含む：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
The question section is used to carry the "question" in most queries, i.e., the parameters that define what is being asked. The section contains QDCOUNT (usually 1) entries, each of the following format: Question セクションは、ほとんどの問合せにおいてその "質問(question)" (つまり尋ねられている内容を定義するパラメータ)を伝えるために使用される。このセクションは QDCOUNT 個(通常は 1)のエントリを含み、それぞれ以下のフォーマットを持つ：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
The answer, authority, and additional sections all share the same format: a variable number of resource records, where the number of records is specified in the corresponding count field in the header. Each resource record has the following format: Answer セクション、Authority セクション、Additional セクションは、同じフォーマットを共有する：可変個のリソースレコードで、レコード数はヘッダ内の対応するカウントフィールドで指定される。各リソースレコードは以下のフォーマットを持つ：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
In order to reduce the size of messages, the domain system utilizes a compression scheme which eliminates the repetition of domain names in a message. In this scheme, an entire domain name or a list of labels at the end of a domain name is replaced with a pointer to a prior occurance of the same name. メッセージサイズを削減するために、メッセージ内のドメイン名の繰り返しを排除する圧縮法を使用する。この方法では、ドメイン名全体またはドメイン名の末尾のラベルのリストが、前に同じ名前の出現した位置を指すポインタに置き換えられる。
The pointer takes the form of a two octet sequence: ポインタは連続する 2 オクテットの形式を取る：
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The first two bits are ones. This allows a pointer to be distinguished from a label, since the label must begin with two zero bits because labels are restricted to 63 octets or less. (The 10 and 01 combinations are reserved for future use.) The OFFSET field specifies an offset from the start of the message (i.e., the first octet of the ID field in the domain header). A zero offset specifies the first byte of the ID field, etc. 先頭の 2 ビットはともに 1 である。ラベルは 63 オクテット以下に制限されていることで二つの 0 ビットから始まらなければならないため、ラベルとポインタとを区別することができる。(ビットの組み合わせ 10 と 01 とは将来のために予約されている。) OFFSET フィールドはメッセージの先頭(つまり、ドメインヘッダ内の ID フィールドの先頭オクテット)からのオフセットを表す。例えばオフセット 0 は ID フィールドの先頭バイトを表す。
The compression scheme allows a domain name in a message to be represented as either: この圧縮方法により、メッセージ内のドメイン名は以下のいずれかとして表現できる：
Pointers can only be used for occurances of a domain name where the format is not class specific. If this were not the case, a name server or resolver would be required to know the format of all RRs it handled. As yet, there are no such cases, but they may occur in future RDATA formats. ポインタは、フォーマットがクラス固有でないドメイン名の場合にのみ使用できる。そうでない場合、ネームサーバーまたはリゾルバは、処理するすべての RR のフォーマットを知る必要があるだろう。現在のところそのようなケースはないが、将来の RDATA フォーマットで発生する可能性がある。
If a domain name is contained in a part of the message subject to a length field (such as the RDATA section of an RR), and compression is used, the length of the compressed name is used in the length calculation, rather than the length of the expanded name. レングスフィールドに従うメッセージの一部(例えば RR の RDATA セクション)にドメイン名が含まれており、かつ圧縮が使用される場合、長さの計算には展開された名前ではなく圧縮後の名前が使用される。
Programs are free to avoid using pointers in messages they generate, although this will reduce datagram capacity, and may cause truncation. However all programs are required to understand arriving messages that contain pointers. ポインタはデータグラム容量を削減するが、プログラムは生成するメッセージにおいてポインタを使用しなくてもよく、その場合には切捨てが発生するかもしれない。しかしながらプログラムは、ポインタを含むメッセージを理解しなければならない。
For example, a datagram might need to use the domain names F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the message, these domain names might be represented as: 例えばあるデータグラムは、ドメイン名 F.ISI.ARPA、FOO.F.ISI.ARPA、ARPA、そしてルートを必要とするかもしれない。メッセージの他のフィールドを無視すると、これらのドメイン名は次のように表現できる：
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 1 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 3 | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | S | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 4 | A |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | R | P |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30 | A | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | 3 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | O | O |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1| 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 1| 26 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
92 | 0 | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The domain name for F.ISI.ARPA is shown at offset 20. The domain name FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to concatenate a label for FOO to the previously defined F.ISI.ARPA. The domain name ARPA is defined at offset 64 using a pointer to the ARPA component of the name F.ISI.ARPA at 20; note that this pointer relies on ARPA being the last label in the string at 20. The root domain name is defined by a single octet of zeros at 92; the root domain name has no labels. ドメイン名 F.ISI.ARPA はオフセット 20 に現れている。ドメイン名 FOO.F.ISI.ARPA はオフセット 40 に現れており、先に定義されている F.ISI.ARPA にラベル FOO を繋げるためのポインタを使用している。ドメイン名 ARPA はオフセット 64 に定義されており、F.ISI.ARPA の構成要素である ARPA へのポインタを使用している。このポインタは、オフセット 20 からの文字列の最終ラベルである ARPA に依存していることに注意してほしい。ルートドメイン名はオフセット 32 のオクテット 0 により定義されている。ルートドメインはラベルを持たない。
The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance. Zone refresh activities must use virtual circuits because of the need for reliable transfer. DNS は、メッセージがデータグラムとして転送されるか、または仮想回線を運ばれるバイトストリームによって転送されると仮定する。仮想回線は任意の DNS 操作に使用できるが、データグラムの方がオーバーヘッドが少なく、またパフォーマンスにも優れているため好ましい。ゾーンのリフレッシュは信頼できる転送を必要とするため、仮想回線を使用するべきである。
The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal). インターネットは、サーバーポート 53(10進) 上の TCP [RFC-793] によるネームサーバーへのアクセスと、UDP ポート 53(10進)上での UDP [RFC-768] によるデータグラムアクセスとをサポートする。
Messages sent using UDP user server port 53 (decimal). UDP を使用して送信されるメッセージは、サーバーポート 53(10進)を使用する。
Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header. UDP によって運ばれるメッセージは 512 バイト(IP ヘッダ・UDP ヘッダを除く)までに制限される。それより長いメッセージは切り捨てられ、ヘッダの TC ビットがセットされる。
UDP is not acceptable for zone transfers, but is the recommended method for standard queries in the Internet. Queries sent using UDP may be lost, and hence a retransmission strategy is required. Queries or their responses may be reordered by the network, or by processing in name servers, so resolvers should not depend on them being returned in order. UDP はゾーン転送には受け入れられないが、インターネットにおける標準問合せには推奨される手段である。UDP を使用して送信される問合せは喪失する可能性があるため、再送信の戦略が必要となる。問合せとその応答は、ネットワークやネームサーバー内の処理によって並び替えられる可能性がある。そのためリゾルバは、応答が返される順序に依存してはならない。
The optimal UDP retransmission policy will vary with performance of the Internet and the needs of the client, but the following are recommended: 最善の UDP 再送信ポリシーはインターネットのパフォーマンスとクライアントの要求とによって異なるが、以下のポリシーが推奨される：
More suggestions on server selection and retransmission policy can be found in the resolver section of this memo. サーバーの選択と再送信ポリシーとに関するさらなる提案は、この文書のリゾルバセクションに見られる。
Messages sent over TCP connections use server port 53 (decimal). The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field. This length field allows the low-level processing to assemble a complete message before beginning to parse it. TCP 接続上を送信されるメッセージは、サーバーポート 53(10進)を使用する。メッセージの先頭に 2 バイトのレングスフィールドが置かれ、レングスフィールドの 2 バイトを除いたメッセージの長さを持つ。このレングスフィールドにより、メッセージの解析を開始する前に、低水準の処理がメッセージ全体を組み立てることができる。
Several connection management policies are recommended: いくつかの接続管理ポリシーが推奨される：
Master files are text files that contain RRs in text form. Since the contents of a zone can be expressed in the form of a list of RRs a master file is most often used to define a zone, though it can be used to list a cache's contents. Hence, this section first discusses the format of RRs in a master file, and then the special considerations when a master file is used to create a zone in some name server. マスターファイルはテキスト形式の RR を含むテキストファイルである。ゾーンの内容は RR のリストという形式で表現できるため、キャッシュの内容をリストするためにマスターファイルを使用することもできるが、ほとんどの場合はゾーンを定義するために使用される。そのためこのセクションは、最初にマスターファイル内の RR のフォーマットについて議論し、その後で、ネームサーバー内にゾーンを生成するためにマスターファイルが使用される場合の特別な考慮事項について議論する。
The format of these files is a sequence of entries. Entries are predominantly line-oriented, though parentheses can be used to continue a list of items across a line boundary, and text literals can contain CRLF within the text. Any combination of tabs and spaces act as a delimiter between the separate items that make up an entry. The end of any line in the master file can end with a comment. The comment starts with a ";" (semicolon). これらのファイルのフォーマットは一連のエントリである。エントリは主に行指向だが、括弧を使用することで項目のリストに行をまたがせることもできるし、テキストリテラルに CRLF を含むこともできる。タブと空白との任意の組み合わせは、エントリを形成する個々の項目の間の区切りの役目を果たす。マスターファイル内の任意の行の終端は、コメントで終わらせることができる。コメントは ";" (セミコロン)から始まる。
The following entries are defined: 以下のエントリが定義されている：
<blank>[<comment>]
$ORIGIN <domain-name> [<comment>]
$INCLUDE <file-name> [<domain-name>] [<comment>]
<domain-name><rr> [<comment>]
<blank><rr> [<comment>]
Blank lines, with or without comments, are allowed anywhere in the file. 空行は(コメントの有無に関係なく)、ファイル内のどこにでも許される。
Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is followed by a domain name, and resets the current origin for relative domain names to the stated name. $INCLUDE inserts the named file into the current file, and may optionally specify a domain name that sets the relative domain name origin for the included file. $INCLUDE may also have a comment. Note that a $INCLUDE entry never changes the relative origin of the parent file, regardless of changes to the relative origin made within the included file. 二つの制御エントリ、$ORIGIN および $INCLUDE が定義されている。$ORIGIN の後にはドメイン名が続き、相対ドメイン名のための現在の基点をそのドメイン名にリセットする。$INCLUDE は指定されたファイルを現在のファイルに挿入し、挿入されるファイルのための相対ドメイン名の基点を設定するドメイン名をオプションで指定する。$INCLUDE もコメントを持つことができる。挿入されるファイル内での相対基点の変更にかかわらず、$INCLUDE エントリは親ファイルの相対基点を変更しないことに注意してほしい。
The last two forms represent RRs. If an entry for an RR begins with a blank, then the RR is assumed to be owned by the last stated owner. If an RR entry begins with a <domain-name>, then the owner name is reset. 最後の二つの形式は RR を表す。RR のためのエントリが空白で始まる場合、その RR は最後に記述された所有者が所有すると見なされる。RR エントリが <domain-name> で始まる場合、所有者名はリセットされる。
<rr> contents take one of the following forms: <rr> の内容は以下のどちらかの形式を取る：
[<TTL>] [<class>] <type> <RDATA>
[<class>] [<TTL>] <type> <RDATA>
The RR begins with optional TTL and class fields, followed by a type and RDATA field appropriate to the type and class. Class and type use the standard mnemonics, TTL is a decimal integer. Omitted class and TTL values are default to the last explicitly stated values. Since type and class mnemonics are disjoint, the parse is unique. (Note that this order is different from the order used in examples and the order used in the actual RRs; the given order allows easier parsing and defaulting.) RR はオプションの TTL と クラスフィールドとから始まり、そのタイプとクラスに適したタイプと RDATA フィールドが続く。クラスとタイプとは標準的ニーモニックを使用し、TTL は 10 進整数値である。クラスと TTL 値とを省略すると、最後に明示的に記述された値がデフォルトになる。タイプおよびクラスのニーモニックは互いに素であるため、解析は個別に行われる。(この要件は、例で使用されている要件とも実際の RR で使用されている要件とも異なることに注意してほしい。この要件により、より簡単な解析とデフォルト設定とが可能となる。)
<domain-name>s make up a large share of the data in the master file. The labels in the domain name are expressed as character strings and separated by dots. Quoting conventions allow arbitrary characters to be stored in domain names. Domain names that end in a dot are called absolute, and are taken as complete. Domain names which do not end in a dot are called relative; the actual domain name is the concatenation of the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as an argument to the master file loading routine. A relative name is an error when no origin is available. <domain-name> はマスターファイル内の情報の大部分を占める。ドメイン名の中のラベルは文字列として表され、ドットで区切られる。引用法によりドメイン名に任意の文字を保持できる。ドットで終了するドメイン名は絶対ドメイン名と呼ばれ、完全なものと見なされる。ドットで終了しないドメイン名は相対ドメイン名と呼ばれ、実際のドメイン名は、その相対名に $ORIGIN・$INCLUDE で指定される基点、またはマスターファイル読み込みルーチンの引数として指定された基点を連結したものとなる。基点を使用できない場合、相対名はエラーとなる。
<character-string> is expressed in one or two ways: as a contiguous set of characters without interior spaces, or as a string beginning with a " and ending with a ". Inside a " delimited string any character can occur, except for a " itself, which must be quoted using \ (back slash). <character-string> はひとつまたは二つの方法で表される：空白文字を含まない連続する文字列として、または " で始まり " で終わる文字列としてである。" で区切られた文字列の内側には任意の文字が現れてよいが、" 自体は \ (バックスラッシュ)によりエスケープされなければならない。
Because these files are text files several special encodings are necessary to allow arbitrary data to be loaded. In particular: これらのファイルはテキストファイルであるため、任意の情報を読み込めるようにするためにはいくつかの特別なエンコードが必要となる。具体的には以下の通り：
When a master file is used to load a zone, the operation should be suppressed if any errors are encountered in the master file. The rationale for this is that a single error can have widespread consequences. For example, suppose that the RRs defining a delegation have syntax errors; then the server will return authoritative name errors for all names in the subzone (except in the case where the subzone is also present on the server). マスターファイルがゾーンの読み込みに使用されるとき、マスターファイル内でエラーに遭遇した場合には操作が抑制されるべきである。その論理的根拠は、単一のエラーが広範囲に影響し得るということである。例えば委譲を定義する RR に文法エラーがあったとすると、サーバーはそのサブゾーン内のすべての名前に対して権威ある名前エラーを返すことになる(ただしサブゾーンもそのサーバー上にある場合を除く)。
Several other validity checks that should be performed in addition to insuring that the file is syntactically correct: ファイルの文法的な正しさを保証することに加えて、実行されるべき妥当性確認がいくつかある：
The following is an example file which might be used to define the ISI.EDU zone.and is loaded with an origin of ISI.EDU: 以下に示すのは、ISI.EDU ゾーンを定義するために使用され、基点 ISI.EDU とともに読み込まれるであろうファイルの例である：
@ IN SOA VENERA Action\.domains (
20 ; SERIAL
7200 ; REFRESH
600 ; RETRY
3600000; EXPIRE
60) ; MINIMUM
NS A.ISI.EDU.
NS VENERA
NS VAXA
MX 10 VENERA
MX 20 VAXA
A A 26.3.0.103
VENERA A 10.1.0.52
A 128.9.0.32
VAXA A 10.2.0.27
A 128.9.0.33
$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
Where the file <SUBSYS>ISI-MAILBOXES.TXT is: ここでファイル <SUBSYS>ISI-MAILBOXES.TXT は以下の通りである：
MOE MB A.ISI.EDU.
LARRY MB A.ISI.EDU.
CURLEY MB A.ISI.EDU.
STOOGES MG MOE
MG LARRY
MG CURLEY
Note the use of the \ character in the SOA RR to specify the responsible person mailbox "[email protected]". 責任者のメールボックス "[email protected]" を表すために SOA RR 内ので使用されている \ 記号に注意してほしい。
The optimal structure for the name server will depend on the host operating system and whether the name server is integrated with resolver operations, either by supporting recursive service, or by sharing its database with a resolver. This section discusses implementation considerations for a name server which shares a database with a resolver, but most of these concerns are present in any name server. ネームサーバーのための最適な構造は、ホストのオペレーティングシステムと、ネームサーバーがリゾルバの働きを(再帰サービスをサポートするか、データベースをリゾルバと共有するか、どちらかによって)統合するかどうかとに依存するだろう。このセクションでは、データベースをリゾルバと共有するネームサーバーのための実装の考慮事項を議論するが、これらの懸念事項の大部分はあらゆるネームサーバーにあてはまる。
A name server must employ multiple concurrent activities, whether they are implemented as separate tasks in the host's OS or multiplexing inside a single name server program. It is simply not acceptable for a name server to block the service of UDP requests while it waits for TCP data for refreshing or query activities. Similarly, a name server should not attempt to provide recursive service without processing such requests in parallel, though it may choose to serialize requests from a single client, or to regard identical requests from the same client as duplicates. A name server should not substantially delay requests while it reloads a zone from master files or while it incorporates a newly refreshed zone into its database. ネームサーバーは、ホスト OS 内の個別タスクとしてであろうと、単独のネームサーバープログラム内部の多重化としてであろうと、複数同時動作を採用しなければならない。ネームサーバーがリフレッシュまたは問合せの動作のために TCP データを待つ間、UDP リクエストのサービスをブロックすることは絶対に受け入れられない。同じようにネームサーバーは、そのようなリクエストを同時に処理せずに再帰サービスを提供しようと試みるべきではないが、単一のクライアントからのリクエストを直列化することを選択したり、あるいは同じクライアントからの同一のリクエストを重複と見なすことを選択したりしてもよい。マスターファイルからゾーンを再読み込みする間、または新しくリフレッシュされたゾーンをデータベースに取り込む間、ネームサーバーはリクエストを大きく遅延させるようなことがないべきである。
While name server implementations are free to use any internal data structures they choose, the suggested structure consists of three major parts: ネームサーバーの実装はどのような内部データ構造を使用してもよいが、推奨される構造は三つの主要な要素を持つ：
All of these data structures can be implemented an identical tree structure format, with different data chained off the nodes in different parts: in the catalog the data is pointers to zones, while in the zone and cache data structures, the data will be RRs. In designing the tree framework the designer should recognize that query processing will need to traverse the tree using case-insensitive label comparisons; and that in real data, a few nodes have a very high branching factor (100-1000 or more), but the vast majority have a very low branching factor (0-1). これらのデータ構造はすべて、異なるデータが異なる部分のノードに繋がれる同一のツリー構造フォーマットで実装できる：カタログの場合のデータはゾーンへのポインタ、ゾーンおよびキャッシュの場合のデータは RR になるだろう。このツリーフレームワークの設計において設計者は、問合せ処理が大文字・小文字を区別しないラベル比較を用いてそのツリーを横断する必要があること、そして実際のデータにおいては、少数のノードが非常に多く(100 ～ 1000 またはそれ以上)の枝を持つが、大部分は非常に少数(0 ～ 1)の枝しか持たないことを認識するべきである。
One way to solve the case problem is to store the labels for each node in two pieces: a standardized-case representation of the label where all ASCII characters are in a single case, together with a bit mask that denotes which characters are actually of a different case. The branching factor diversity can be handled using a simple linked list for a node until the branching factor exceeds some threshold, and transitioning to a hash structure after the threshold is exceeded. In any case, hash structures used to store tree sections must insure that hash functions and procedures preserve the casing conventions of the DNS. 大文字・小文字の問題を解決する方法のひとつは、各ノードのためのラベルを二つの断片として保存することである：すべての ASCII 文字を大文字または小文字に標準化した表現で、実際の大文字・小文字と異なる文字を表すビットマスクを持たせる。分岐要素の多様性は、分岐要素がなんらかの閾値を超えるまでノードの単純なリンクリストを使用し、閾値を超過した後でハッシュ構造に移行することで処理できる。どんな場合でも、ツリー部を保存するのに使用されるハッシュ構造は、ハッシュ関数またはハッシュ手続きが DNS の大文字・小文字を保存することを保証しなければならない。
The use of separate structures for the different parts of the database is motivated by several factors: データベースの異なる部分のために個別の構造体を使用することは、いくつかの要因に動機付けられている：
A major aspect of database design is selecting a structure which allows the name server to deal with crashes of the name server's host. State information which a name server should save across system crashes includes the catalog structure (including the state of refreshing for each zone) and the zone data itself. データベース設計の主要な側面は、ネームサーバーのホストの故障を扱える構造を選択することである。システムの故障をまたいでネームサーバーが維持するべき状態情報には、カタログ構造(各ゾーンのリフレッシュ状態を含む)と、ゾーン情報そのものとが含まれる。
Both the TTL data for RRs and the timing data for refreshing activities depends on 32 bit timers in units of seconds. Inside the database, refresh timers and TTLs for cached data conceptually "count down", while data in the zone stays with constant TTLs. RR のための TTL 情報とリフレッシュ動作のためのタイミング情報とはともに、秒単位の 32 ビットタイマーに依存する。データベース内部において、ゾーン内の情報が一定の TTL を伴なって留まるのに対し、リフレッシュタイマーとキャッシュ情報のための TTL は、概念的に "カウントダウン(count down)" する。
A recommended implementation strategy is to store time in two ways: as a relative increment and as an absolute time. One way to do this is to use positive 32 bit numbers for one type and negative numbers for the other. The RRs in zones use relative times; the refresh timers and cache data use absolute times. Absolute numbers are taken with respect to some known origin and converted to relative values when placed in the response to a query. When an absolute TTL is negative after conversion to relative, then the data is expired and should be ignored. 推奨される実装戦略は、時間を二つの方法、相対的増分および絶対時間として保持することである。これを行う方法のひとつは、一方に正の 32 ビット値を使用し、他方に負の数値を使用することである。ゾーン内の RR は相対時間を使用し、リフレッシュタイマーとキャッシュデータとは絶対時間を使用する。絶対数値は何らかの既知の基点に対して取られ、問合せに対する応答に置かれるときには相対値に変換される。絶対 TTL を相対値に変換した結果が負になった場合、その情報は期限切れであり、無視されるべきである。
The major algorithm for standard query processing is presented in [RFC-1034]. 標準問合せの処理のための主要なアルゴリズムは [RFC-1034] に示されている。
When processing queries with QCLASS=*, or some other QCLASS which matches multiple classes, the response should never be authoritative unless the server can guarantee that the response covers all classes. QCLASS=*、または複数クラスに一致する QCLASS を持つ問合せを処理するとき、応答がすべてのクラスを網羅していることをサーバーが保証できるのでない限り、その応答は権威を持たないべきである。
When composing a response, RRs which are to be inserted in the additional section, but duplicate RRs in the answer or authority sections, may be omitted from the additional section. 応答を組み立てるとき、Additional セクションに挿入される(しかし Answer セクションまたは Authority セクションに複写される) RR は、Additional セクションから省かれてもよい。
When a response is so long that truncation is required, the truncation should start at the end of the response and work forward in the datagram. Thus if there is any data for the authority section, the answer section is guaranteed to be unique. 応答が長すぎて切捨てを必要とする場合、切り捨ては応答の終端からデータグラムの前方に向かって行われるべきである。したがって、Authority セクションに何らかのデータがあれば、Answer セクションは一意であることが保証される。
The MINIMUM value in the SOA should be used to set a floor on the TTL of data distributed from a zone. This floor function should be done when the data is copied into a response. This will allow future dynamic update protocols to change the SOA MINIMUM field without ambiguous semantics. SOA 内の MINIMUM 値は、ゾーンから配布されるデータの TTL の下限として使用されるべきである。この下限の機能は、データが応答にコピーされるときに実行されるべきである。これにより将来の動的更新プロトコルは、あいまいな動作なしに SOA の MINIMUM フィールドを変更できるだろう。
In spite of a server's best efforts, it may be unable to load zone data from a master file due to syntax errors, etc., or be unable to refresh a zone within the its expiration parameter. In this case, the name server should answer queries as if it were not supposed to possess the zone. サーバーの最善の努力にもかかわらず、文法エラーなどのためにマスターファイルからゾーン情報を読み込めない可能性や、期限切れパラメータの時間内にゾーンをリフレッシュできない可能性がある。その場合ネームサーバーは、そのゾーンを保有していないかのように問合せに答えるべきである。
If a master is sending a zone out via AXFR, and a new version is created during the transfer, the master should continue to send the old version if possible. In any case, it should never send part of one version and part of another. If completion is not possible, the master should reset the connection on which the zone transfer is taking place. マスターが AXFR によってゾーンを送信しており、その転送中に新しいバージョンが生成された場合、可能であればマスターは古いバージョンを送信し続けるべきである。どんな場合でも、マスターはあるバージョンの一部と別のバージョンの一部とを合せて送信するべきではない。完了できない場合、マスターはゾーン転送の行われている接続をリセットするべきである。
Inverse queries are an optional part of the DNS. Name servers are not required to support any form of inverse queries. If a name server receives an inverse query that it does not support, it returns an error response with the "Not Implemented" error set in the header. While inverse query support is optional, all name servers must be at least able to return the error response. 逆問合せは DNS のオプション機能である。ネームサーバーは、どのような形式であれ逆問合せをサポートすることを要求されない。ネームサーバーがサポートしない逆問合せを受け取った場合、ヘッダに "Not Implemented(未実装)" エラーを持つエラー応答を返す。逆問合せのサポートがオプションである一方、すべてのネームサーバーは少なくともこのエラー応答を返すことができなければならない。
Inverse queries reverse the mappings performed by standard query operations; while a standard query maps a domain name to a resource, an inverse query maps a resource to a domain name. For example, a standard query might bind a domain name to a host address; the corresponding inverse query binds the host address to a domain name. 逆問合せは標準問合せ操作によって行われるマッピングを逆転する。標準問合せがドメイン名をリソースにマップする一方で、逆問合せはリソースをドメイン名にマップする。例えば標準問合せはドメイン名をホストアドレスにひも付けし、対応する逆問合せはそのホストアドレスをドメイン名にひも付けする。
Inverse queries take the form of a single RR in the answer section of the message, with an empty question section. The owner name of the query RR and its TTL are not significant. The response carries questions in the question section which identify all names possessing the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows about all of the domain name space, the response can never be assumed to be complete. Thus inverse queries are primarily useful for database management and debugging activities. Inverse queries are NOT an acceptable method of mapping host addresses to host names; use the IN- ADDR.ARPA domain instead. 逆問合せはメッセージの Answer セクションに単独の RR を持ち、空の Question セクションを持つ形式である。問合せ RR の所有者名とその TTL とは重要ではない。応答は、そのネームサーバーが知っている問合せ RR を所有するすべての名前を特定する質問を Question セクションで伝える。すべてのドメイン名空間を知るサーバーは存在しないため、応答を完全であると見なすことはできない。そのため逆問合せは、主にデータベース管理やデバッグ作業の役に立つ。逆問合せはホストアドレスからホスト名へのマッピング手段としては受け入れられない。代わりに IN-ADDR.ARPA ドメインを使用するべきである。
Where possible, name servers should provide case-insensitive comparisons for inverse queries. Thus an inverse query asking for an MX RR of "Venera.isi.edu" should get the same response as a query for "VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should produce the same result as an inverse query for "IBM-pc unix". However, this cannot be guaranteed because name servers may possess RRs that contain character strings but the name server does not know that the data is character. 可能であれば、ネームサーバーは逆問合せに大文字・小文字を区別しない比較を提供するべきである。したがって、"Venera.isi.edu" の MX RR を求める逆問合せは、"VENERA.ISI.EDU"; に対する問合せと同じ応答を返すべきだし、"IBM-PC UNIX" の HINFO RR を求める逆問合せは "IBM-pc unix" に対する逆問合せと同じ結果を提供するべきである。しかしながら、文字列を含む RR を所有していても、そのデータが文字であることをネームサーバーが知らない可能性があるため、これは保証され得ない。
When a name server processes an inverse query, it either returns: ネームサーバーが逆問合せを処理したとき、以下のどちらかを返す：
When the response to an inverse query contains one or more QNAMEs, the owner name and TTL of the RR in the answer section which defines the inverse query is modified to exactly match an RR found at the first QNAME. 逆問合せへの応答がひとつ以上の QNAME を含む場合、逆問合せを定義する Answer セクション内の RR の所有者と TTL とは、先頭の QNAME で見つかった RR に正確に一致するように修正される。
RRs returned in the inverse queries cannot be cached using the same mechanism as is used for the replies to standard queries. One reason for this is that a name might have multiple RRs of the same type, and only one would appear. For example, an inverse query for a single address of a multiply homed host might create the impression that only one address existed. 逆問合せにおいて返される RR を、標準問合せに対するリプライに使用されるのと同じメカニズムを使用してキャッシュすることはできない。その理由のひとつは、名前が同じタイプの複数の RR を持つ可能性があり、そのひとつだけが返されるかもしれないためである。例えば、マルチホームホストのアドレスのひとつに対する逆問合せは、アドレスがただひとつだけ存在している印象を与えるかもしれない。
The overall structure of an inverse query for retrieving the domain name that corresponds to Internet address 10.1.0.52 is shown below: インターネットアドレス 10.1.0.52 に対応するドメイン名を取得するための逆問合せの全体的な構造は、以下のようになる：
+-----------------------------------------+
Header | OPCODE=IQUERY, ID=997 |
+-----------------------------------------+
Question | <empty> |
+-----------------------------------------+
Answer | <anyname> A IN 10.1.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
+-----------------------------------------+
Header | OPCODE=IQUERY, ID=997 |
+-----------------------------------------+
Question | <空> |
+-----------------------------------------+
Answer | <任意の名前> A IN 10.1.0.52 |
+-----------------------------------------+
Authority | <空> |
+-----------------------------------------+
Additional | <空> |
+-----------------------------------------+
This query asks for a question whose answer is the Internet style address 10.1.0.52. Since the owner name is not known, any domain name can be used as a placeholder (and is ignored). A single octet of zero, signifying the root, is usually used because it minimizes the length of the message. The TTL of the RR is not significant. The response to this query might be: この問合せは、回答がインターネット形式アドレス 10.1.0.52 となる質問を求めている。所有者名は分かっていないため、代替として任意のドメイン名を使用できる(そして無視される)。メッセージの長さを最小化するために、通常はルートを表す単一のゼロオクテットが使用される。RR の TTL は重要ではない。この問合せに対する応答は以下のようになるだろう：
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=997 |
+-----------------------------------------+
Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
+-----------------------------------------+
Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=997 |
+-----------------------------------------+
Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
+-----------------------------------------+
Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
+-----------------------------------------+
Authority | <空> |
+-----------------------------------------+
Additional | <空> |
+-----------------------------------------+
Note that the QTYPE in a response to an inverse query is the same as the TYPE field in the answer section of the inverse query. Responses to inverse queries may contain multiple questions when the inverse is not unique. If the question section in the response is not empty, then the RR in the answer section is modified to correspond to be an exact copy of an RR at the first QNAME. 逆問合せへの応答における QTYPE は、逆問合せの Answer セクションにおける TYPE フィールドと同じである。逆問合せに対する応答は、その結果が一意でない場合に複数の質問を含む可能性がある。応答内の Question セクションが空でない場合、Answer セクション内の RR は、先頭の QNAME の RR の正確なコピーに対応するように修正される。
Name servers that support inverse queries can support these operations through exhaustive searches of their databases, but this becomes impractical as the size of the database increases. An alternative approach is to invert the database according to the search key. 逆問合せをサポートするネームサーバーは、データベースの網羅的な検索によってそれらの操作をサポートすることができるが、データベースのサイズの増加に伴なって実行不可能になる。代替のアプローチは、検索キーにしたがってデータベースを反転させることである。
For name servers that support multiple zones and a large amount of data, the recommended approach is separate inversions for each zone. When a particular zone is changed during a refresh, only its inversions need to be redone. ネームサーバーが複数ゾーンと大量データとをサポートする場合に推奨されるアプローチは、各ゾーンのための個別の逆引き情報を持つことである。リフレッシュ中に特定のゾーンが変更された場合、その部分の反転だけをやり直す必要がある。
Support for transfer of this type of inversion may be included in future versions of the domain system, but is not supported in this version. このバージョンではサポートされないが、ドメインシステムの将来のバージョンでは反転情報の転送がサポートされてもよい。
The optional completion services described in RFC-882 and RFC-883 have been deleted. Redesigned services may become available in the future. RFC-882 および RFC-883 に記述されているオプションの補完サービスは削除された。将来、再設計されたサービスが利用可能になってもよい。
The top levels of the recommended resolver algorithm are discussed in [RFC-1034]. This section discusses implementation details assuming the database structure suggested in the name server implementation section of this memo. 上位水準の推奨されるリゾルバアルゴリズムは [RFC-1034] で議論されている。このセクションでは、この文書のネームサーバー実装セクションにおいて提案されているデータベース構造を前提として、実装の詳細を議論する。
The first step a resolver takes is to transform the client's request, stated in a format suitable to the local OS, into a search specification for RRs at a specific name which match a specific QTYPE and QCLASS. Where possible, the QTYPE and QCLASS should correspond to a single type and a single class, because this makes the use of cached data much simpler. The reason for this is that the presence of data of one type in a cache doesn't confirm the existence or non-existence of data of other types, hence the only way to be sure is to consult an authoritative source. If QCLASS=* is used, then authoritative answers won't be available. リゾルバが取る最初のステップは、ローカル OS に適したフォーマットで記述されたクライアントのリクエストを、特定の名前において特定の QTYPE と QCLASS とに一致する RR を求める検索指定に変換することである。キャッシュ情報の活用をより簡単にするために、可能であれば QTYPE と QCLASS とは単一のタイプと単一のクラスとに対応するべきである。その理由は、あるタイプの情報がキャッシュに存在することが、他のタイプの情報が存在することも存在しないことも裏付けず、したがって保証する唯一の方法は、権威を持つ情報源に当たることだからである。QCLASS=* が使用された場合、権威ある回答は利用できないだろう。
Since a resolver must be able to multiplex multiple requests if it is to perform its function efficiently, each pending request is usually represented in some block of state information. This state block will typically contain: リゾルバが自身の機能を効率的に処理するつもりであれば複数のリクエストを多重化できなければならないため、通常それぞれの保留リクエストは何らかの状態情報ブロック内に表現される。この状態ブロックは一般に以下の内容を含むだろう：
The amount of work which a resolver will do in response to a client request must be limited to guard against errors in the database, such as circular CNAME references, and operational problems, such as network partition which prevents the resolver from accessing the name servers it needs. While local limits on the number of times a resolver will retransmit a particular query to a particular name server address are essential, the resolver should have a global per-request counter to limit work on a single request. The counter should be set to some initial value and decremented whenever the resolver performs any action (retransmission timeout, retransmission, etc.) If the counter passes zero, the request is terminated with a temporary error. クライアントリクエストに答えてリゾルバが実行する作業量は、CNAME の循環参照などのデータベース内のエラーや、リゾルバが必要とするネームサーバーへのアクセスを妨げるネットワークの分断などの運用上の問題から保護するために、制限されなければならない。リゾルバが特定のネームサーバーアドレスに特定の問合せを再送信する回数についてのローカルの制限は必須だが、リゾルバは単一のリクエストに対する作業を制限するための、リクエストごとの大域的なカウンタを持つべきである。このカウンタは何らかの初期値をセットされ、リゾルバが何らかのアクション(再送信タイムアウト、再送信など)を実行すると常にデクリメントされるべきである。カウンタがゼロに達すると、そのリクエストは一時的エラーで終了する。
Note that if the resolver structure allows one request to start others in parallel, such as when the need to access a name server for one request causes a parallel resolve for the name server's addresses, the spawned request should be started with a lower counter. This prevents circular references in the database from starting a chain reaction of resolver activity. 例えば、あるリクエストのためにネームサーバーにアクセスする必要性がそのネームサーバーのアドレスの並行解決を引き起こす場合などのために、リゾルバの構造があるリクエストと並行して別のリクエストを開始することを許可する場合、生み出された側のリクエストはより低いカウンタから開始されるべきである。これは、データベース内の循環参照がリゾルバ活動の連鎖反応を始めるのを防ぐ。
This structure keeps track of the state of a request if it must wait for answers from foreign name servers. この構造体は、外部のネームサーバーからの回答を待たなければいけない場合に、リクエストの状態を追跡する。
As described in [RFC-1034], the basic task of the resolver is to formulate a query which will answer the client's request and direct that query to name servers which can provide the information. The resolver will usually only have very strong hints about which servers to ask, in the form of NS RRs, and may have to revise the query, in response to CNAMEs, or revise the set of name servers the resolver is asking, in response to delegation responses which point the resolver to name servers closer to the desired information. In addition to the information requested by the client, the resolver may have to call upon its own services to determine the address of name servers it wishes to contact. [RFC-1034] で議論されている通り、リゾルバの基本的な仕事は、クライアントのリクエストに答えるであろう問合せを組み立て、その情報を提供できるネームサーバーにその問合せを向けることである。通常リゾルバは、どのサーバに問い合わせるべきかについて NS RR 形式の非常に強力なヒントを持つだけであり、CNAME に応えて問合せを修正したり、求める情報により近いネームサーバーにリゾルバを向かわせる委譲応答に応えて問い合わせるネームサーバーの集合を修正したりしなければならない可能性がある。クライアントによって要求された情報に加えて、連絡を取りたいネームサーバーのアドレスを決定するために、リゾルバは自分自身のサービスを呼び出さなければならないかもしれない。
In any case, the model used in this memo assumes that the resolver is multiplexing attention between multiple requests, some from the client, and some internally generated. Each request is represented by some state information, and the desired behavior is that the resolver transmit queries to name servers in a way that maximizes the probability that the request is answered, minimizes the time that the request takes, and avoids excessive transmissions. The key algorithm uses the state information of the request to select the next name server address to query, and also computes a timeout which will cause the next action should a response not arrive. The next action will usually be a transmission to some other server, but may be a temporary error to the client. 何れにしてもこの文書で使用されているモデルは、リゾルバが複数のリクエスト(クライアントからのものや、内部的に生成されたもの)の間で注意を多重化することを前提としている。各リクエストは何らかの状態情報によって表され、その望まれる振る舞いは、リクエストに答えられる可能性を最大化し、リクエストに要する時間を最小化し、過度な通信を避けるような方法でネームサーバーに問合せを送信することである。主要なアルゴリズムは、問い合わせるべき次のネームサーバーアドレスを選択するためにリクエストの状態情報を使用し、応答が届かなかった場合に次のアクションを起こすタイムアウトを再計算するというものである。通常、次のアクションは別のサーバーへの送信になるが、クライアントへの一時的エラーであってもよい。
The resolver always starts with a list of server names to query (SLIST). This list will be all NS RRs which correspond to the nearest ancestor zone that the resolver knows about. To avoid startup problems, the resolver should have a set of default servers which it will ask should it have no current NS RRs which are appropriate. The resolver then adds to SLIST all of the known addresses for the name servers, and may start parallel requests to acquire the addresses of the servers when the resolver has the name, but no addresses, for the name servers. 通常、リゾルバは問い合わせるべきサーバー名のリスト(SLIST)から開始する。このリストは、リゾルバの知っている直近の上位ゾーンに対応するすべての NS RR になるだろう。開始時の問題を回避するために、リゾルバは適切な最新の NS RR を持たない場合に問い合わせるデフォルトサーバーの集合を持つべきである。次にリゾルバは、そのネームサーバーの既知のアドレスをすべて SLIST に追加し、リゾルバがそのネームサーバーの名前を知っているがアドレスを知らない場合には、そのサーバーのアドレスを取得するために並行リクエストを開始してよい。
To complete initialization of SLIST, the resolver attaches whatever history information it has to the each address in SLIST. This will usually consist of some sort of weighted averages for the response time of the address, and the batting average of the address (i.e., how often the address responded at all to the request). Note that this information should be kept on a per address basis, rather than on a per name server basis, because the response time and batting average of a particular server may vary considerably from address to address. Note also that this information is actually specific to a resolver address / server address pair, so a resolver with multiple addresses may wish to keep separate histories for each of its addresses. Part of this step must deal with addresses which have no such history; in this case an expected round trip time of 5-10 seconds should be the worst case, with lower estimates for the same local network, etc. SLIST の初期化を完了するために、リゾルバは SLIST 内の各アドレスに、何であれ自身の持つ履歴情報を付加する。通常これは、そのアドレスの応答時間に対するある種の加重平均と、そのアドレスの成功率(つまり、すべてのリクエストに対してどのくらいの頻度でアドレスを答えられたか)である。この情報はネームサーバーごとにではなく、アドレスごとに保持されるべきであることに注意してほしい。これは、あるサーバーの応答時間と成功率とは、そのアドレスごとに相当に異なる可能性があるためである。またこの情報は実際にはリゾルバアドレス/サーバーアドレスのペアに固有のものとなり、したがって複数のアドレスを持つリゾルバは、各アドレスごとに個別の履歴を保持することを望んでもよいことにも注意してほしい。このステップはこのような履歴を持たないアドレスを扱わなければならない。この場合、期待される往復時間は 5 ～ 10 秒が最悪のケースとなるべきであり、同じローカルネットワークなどの場合はより短く見積もるべきである。
Note that whenever a delegation is followed, the resolver algorithm reinitializes SLIST. 委譲を追跡する場合、リゾルバアルゴリズムは常に SLIST を再初期化することに注意してほしい。
The information establishes a partial ranking of the available name server addresses. Each time an address is chosen and the state should be altered to prevent its selection again until all other addresses have been tried. The timeout for each transmission should be 50-100% greater than the average predicted value to allow for variance in response. この情報は、利用可能なネームサーバーアドレスの偏向順位を確立する。その都度アドレスが選択され、他のすべてのアドレスが試されるまで再び選択されないように状態が変更されるべきである。各送信のタイムアウトは、応答における変化を考慮するための平均予測値より 50 ～ 100% 大きいべきである。
Some fine points: 詳細の詳細を以下に示す：
The first step in processing arriving response datagrams is to parse the response. This procedure should include: 到着した応答データグラムの処理における最初のステップは、その応答の解析である。この手順は以下の内容を含むべきである：
The next step is to match the response to a current resolver request. The recommended strategy is to do a preliminary matching using the ID field in the domain header, and then to verify that the question section corresponds to the information currently desired. This requires that the transmission algorithm devote several bits of the domain ID field to a request identifier of some sort. This step has several fine points: 次のステップは、その応答を進行中のリゾルバリクエストに対応させることである。推奨される戦略は、ドメインヘッダ内の ID フィールドを使用して予備的なマッチングを行い、次に Question セクションが現在求めている情報に対応することを確認する方法である。これには、送信アルゴリズムがドメイン ID フィールドのいくつかのビットを何らかのリクエスト識別子に充てることを必要とする。このステップにはいくつかの詳細がある：
In general, we expect a resolver to cache all data which it receives in responses since it may be useful in answering future client requests. However, there are several types of data which should not be cached: 一般に私たちは、応答において受信したすべての情報が、将来のクライアントリクエストに答える際に役に立つ可能性があるため、リゾルバによってキャッシュされることを期待する。しかしながら、キャッシュされるべきではない種類の情報もいくつか存在する：
In a similar vein, when a resolver has a set of RRs for some name in a response, and wants to cache the RRs, it should check its cache for already existing RRs. Depending on the circumstances, either the data in the response or the cache is preferred, but the two should never be combined. If the data in the response is from authoritative data in the answer section, it is always preferred. 同じように、リゾルバが応答内に何らかの名前のための RR の集合を持ち、その RR をキャッシュしたい場合、リゾルバはすでにその RR がキャッシュに存在するかどうかを確認する。状況に依存して、応答内の情報またはキャッシュのどちらか一方が優先されるが、決して二つが組み合わせられるべきではない。応答内の情報が Answer セクション内の権威情報に由来する場合、常にそちらが優先する。
The domain system defines a standard for mapping mailboxes into domain names, and two methods for using the mailbox information to derive mail routing information. The first method is called mail exchange binding and the other method is mailbox binding. The mailbox encoding standard and mail exchange binding are part of the DNS official protocol, and are the recommended method for mail routing in the Internet. Mailbox binding is an experimental feature which is still under development and subject to change. ドメインシステムはメールボックスをドメイン名にマッピングするための標準と、メールルーティング情報を抽出するためのメールボックス情報を使用する二つの方法とを定義する。ひとつめの方法はメールエクスチェンジバインディングと呼ばれ、もうひとつの方法はメールボックスバインディングと呼ばれる。メールボックスのエンコード標準とメールエクスチェンジバインディングは DNS の公式プロトコルの一部であり、インターネット上のメールルーティングのために推奨される方法である。メールボックスバインディングは実験的機能でいまだ開発中であり、変更される可能性がある。
The mailbox encoding standard assumes a mailbox name of the form "<local-part>@<mail-domain>". While the syntax allowed in each of these sections varies substantially between the various mail internets, the preferred syntax for the ARPA Internet is given in [RFC-822]. メールボックスのエンコード標準は、"<local-part>@<mail-domain>" の形式のメールボックス名を前提としている。これらの各部分に許される構文はさまざまなメールシステム間で相当に異なるが、ARPA インターネットのために好ましい構文は [RFC-822] に示されている。
The DNS encodes the <local-part> as a single label, and encodes the <mail-domain> as a domain name. The single label from the <local-part> is prefaced to the domain name from <mail-domain> to form the domain name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI- NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the <local-part> contains dots or other special characters, its representation in a master file will require the use of backslash quoting to ensure that the domain name is properly encoded. For example, the mailbox [email protected] would be represented as Action\.domains.ISI.EDU. DNS は <local-part> を単一のラベルとしてエンコードし、<mail-domain> をドメイン名としてエンコードする。<local-part> に由来する単一のラベルは、そのメールボックスに対応するドメイン名を形成するために、<mail-domain> に由来するドメイン名の前に置かれる。したがってメールボックス [email protected] は、ドメイン名 HOSTMASTER.SRI-NIC.ARPA にマップされる。<local-part> がドットまたは他の特殊文字を含む場合、マスターファイル内でのその表現は、ドメイン名が適切にエンコードされることを保証するために、バックスラッシュによる引用を必要とするだろう。例えばメールボックス [email protected] は、Action\.domains.ISI.EDU と表現されるだろう。
Mail exchange binding uses the <mail-domain> part of a mailbox specification to determine where mail should be sent. The <local-part> is not even consulted. [RFC-974] specifies this method in detail, and should be consulted before attempting to use mail exchange support. メールエクスチェンジバインディングは、メールが送信されるべき場所を決定するために、メールボックス指定の <mail-domain> 部分を使用する。<local-part> は調べられることすらない。メールエクスチェンジのサポートを使おうとする前に、この方法の詳細を規定している [RFC-974] を参照するべきである。
One of the advantages of this method is that it decouples mail destination naming from the hosts used to support mail service, at the cost of another layer of indirection in the lookup function. However, the addition layer should eliminate the need for complicated "%", "!", etc encodings in <local-part>. この方法の利点のひとつは、検索機能における別レイヤの間接指定を犠牲にして、メールサービスをサポートするために使われるホストから、メールの宛先の命名を分離することである。しかしながら追加レイヤは、<local-part> における "%"、"!" などの複雑なエンコードの必要性を削減するべきである。
The essence of the method is that the <mail-domain> is used as a domain name to locate type MX RRs which list hosts willing to accept mail for <mail-domain>, together with preference values which rank the hosts according to an order specified by the administrators for <mail-domain>. この方法の本質は、<mail-domain> 宛てのメールを受け入れる用意のあるホストを、<mail-domain> の管理者の指定による優先順位値とともにリストする MX タイプの RR を位置付けるドメイン名として、<mail-domain> が使用されることである。
In this memo, the <mail-domain> ISI.EDU is used in examples, together with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for ISI.EDU. If a mailer had a message for [email protected], it would route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host addresses. この文書では例として <mail-domain> ISI.EDU を使用し、ISI.EDU のためのメールエクスチェンジとしてホスト VENERA.ISI.EDU と VAXA.ISI.EDU とを持つとする。メーラーが [email protected] 宛てのメッセージを持つ場合、ISI.EDU のための MX RR を検索することでそれをルーティングするだろう。ISI.EDU における MX RR は VENERA.ISI.EDU と VAXA.ISI.EDU とを指定し、タイプ A の問合せによりそのホストアドレスを見つけられる。
In mailbox binding, the mailer uses the entire mail destination specification to construct a domain name. The encoded domain name for the mailbox is used as the QNAME field in a QTYPE=MAILB query. メールボックスバインディングにおいて、メーラーはドメイン名を構築するためにメールの宛先指定全体を使用する。メールボックスのためにエンコードされたドメイン名は、QTYPE=MAILB の問合せにおける QNAME フィールドとして使用される。
Several outcomes are possible for this query: この問合せにはいくつかの結果があり得る：
In the long term, this would indicate that the specified mailbox doesn't exist. However, until the use of mailbox binding is universal, this error condition should be interpreted to mean that the organization identified by the global part does not support mailbox binding. The appropriate procedure is to revert to exchange binding at this point. 将来的には、これは指定されたメールボックスが存在しないことを表すだろう。しかしながらメールボックスバインディングの使用が一般的になるまで、このエラーはグローバル部分で指定された組織がメールボックスバインディングをサポートしないという意味に解釈されるべきである。現時点での適切な手順は、エクスチェンジバインディングに復帰することである。
The MR RR carries new mailbox specification in its RDATA field. The mailer should replace the old mailbox with the new one and retry the operation. MR RR は RDATA フィールドで新しいメールボックス指定を伝える。メーラーは古いメールボックスを新しいものに置き換え、操作を再試行するべきである。
The MB RR carries a domain name for a host in its RDATA field. The mailer should deliver the message to that host via whatever protocol is applicable, e.g., b,SMTP. MB RR は RDATA フィールドでホストのためのドメイン名を伝える。メーラーは、何であれ適切なプロトコル(例えば SMTP)を通して、そのホストにメッセージを配送するべきである。
This condition means that the mailbox was actually a mailing list or mail group, rather than a single mailbox. Each MG RR has a RDATA field that identifies a mailbox that is a member of the group. The mailer should deliver a copy of the message to each member. この状況は、そのメールボックスが単独のメールボックスではなく、実際はメーリングリストまたはメールグループであったことを表す。各 MG RR は、そのグループのメンバーであるメールボックスを表す RDATA フィールドを持つ。メーラーは各メンバーにメッセージのコピーを配送するべきである。
This condition means the the mailbox was actually a mailing list. The mailer can either deliver the message to the host specified by the MB RR, which will in turn do the delivery to all members, or the mailer can use the MG RRs to do the expansion itself. この状況は、メールボックスが実際にはメーリングリストだったことを表す。メーラーは MB RR で指定されたホストにメッセージを配送する(次にすべてのメンバーへの配送が行われるだろう)か、自身でその展開を行うために MB RR を使用することができる。
In any of these cases, the response may include a Mail Information (MINFO) RR. This RR is usually associated with a mail group, but is legal with a MB. The MINFO RR identifies two mailboxes. One of these identifies a responsible person for the original mailbox name. This mailbox should be used for requests to be added to a mail group, etc. The second mailbox name in the MINFO RR identifies a mailbox that should receive error messages for mail failures. This is particularly appropriate for mailing lists when errors in member names should be reported to a person other than the one who sends a message to the list. New fields may be added to this RR in the future. 上記の何れの場合も、応答は Mail Information (MINFO) RR を含む可能性がある。通常この RR はメールグループと関連するが、MB に伴なうのも正しい。MINFO RR は二つのメールボックスを特定する。その内のひとつは、元のメールボックス名に責任を持つ人物を特定する。このメールボックスは、メールグループへの追加要求などに使用されるべきである。MINFO RR の二つめのメールボックス名は、メール障害のためのエラーメッセージを受信するべきメールボックスを特定する。これは、メンバーの名前においてエラーが発生したとき、メーリングリストにメッセージを送信した人物ではなく、ある特定の人物にエラーが送られるべき場合に特に適している。将来、この RR に新しいフィールドが追加されてもよい。
* 13
; 33, 35
<character-string> 35
<domain-name> 34
@ 35
\ 35
A 12
Byte order 8
CH 13
Character case 9
CLASS 11
CNAME 12
Completion 42
CS 13
Hesiod 13
HINFO 12
HS 13
IN 13
IN-ADDR.ARPA domain 22
Inverse queries 40
Mailbox names 47
MB 12
MD 12
MF 12
MG 12
MINFO 12
MINIMUM 20
MR 12
MX 12
NS 12
NULL 12
Port numbers 32
Primary server 5
PTR 12, 18
QCLASS 13
QTYPE 12
RDATA 12
RDLENGTH 11
Secondary server 5
SOA 12
Stub resolvers 7
TCP 32
TXT 12
TYPE 11
UDP 32
WKS 12
*
; 2
<character-string>
<domain-name>
@
\
A
バイトオーダー(Byte order)
CH
文字のケース(Character case)
CLASS
CNAME
補完(Completion)
CS
Hesiod
HINFO
HS
IN
IN-ADDR.ARPA ドメイン
逆問合せ(Inverse queries)
メールボックス名(Mailbox names)
MB
MD
MF
MG
MINFO
MINIMUM
MR
MX
NS
NULL
ポート番号(Port numbers)
プライマリサーバー(Primary server)
PTR 2
QCLASS
QTYPE
RDATA
RDLENGTH
セカンダリサーバー(Secondary server)
SOA
スタブリゾルバ(Stub resolvers)
TCP
TXT
TYPE
UDP
WKS