原文:ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt
原文との対訳として読みたい方へ:このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。


サイト内関連リンク:RFC 1035 DNS 実装と仕様


Network Working Group
Request for Comments: 1034
Obsoletes: RFCs 882, 883, 973

P. Mockapetris
ISI
November 1987

DOMAIN NAMES - CONCEPTS AND FACILITIES ドメイン名- 概念と機能

1. STATUS OF THIS MEMO 1. この文書の位置付け

This RFC is an introduction to the Domain Name System (DNS), and omits many details which can be found in a companion RFC, "Domain Names - Implementation and Specification" [RFC-1035]. That RFC assumes that the reader is familiar with the concepts discussed in this memo. この RFC は Domain Name System (DNS) の紹介であり、対になる RFC "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" [RFC-1035] に見られる多くの詳細を省略している。RFC 1035 は、読者がこの文書で議論されている概念を知っていることを前提としている。

A subset of DNS functions and data types constitute an official protocol. The official protocol includes standard queries and their responses and most of the Internet class data formats (e.g., host addresses). DNS の機能とデータ型とのサブセットが公式なプロトコルを構成している。公式なプロトコルは標準問合せとその応答、そしてインターネットクラス(例えばホストアドレス)のデータフォーマットの大部分を含んでいる。

However, the domain system is intentionally extensible. Researchers are continuously proposing, implementing and experimenting with new data types, query types, classes, functions, etc. Thus while the components of the official protocol are expected to stay essentially unchanged and operate as a production service, experimental behavior should always be expected in extensions beyond the official protocol. Experimental or obsolete features are clearly marked in these RFCs, and such information should be used with caution. しかしながら、ドメインシステムは任意に拡張可能である。研究者は新しいデータ型・問合せ型・クラス・機能などの提案、実装、実験を続けている。したがってこの公式なプロトコルの構成要素は本質的に変化せず、生産的サービスとして提供されることを期待される一方で、実験的作業は常にこの公式なプロトコルを越える拡張を期待されるべきである。試験的機能または非推奨の機能はこれらの RFC において明示されており、それらの情報は注意深く使用されるべきである。

The reader is especially cautioned not to depend on the values which appear in examples to be current or complete, since their purpose is primarily pedagogical. Distribution of this memo is unlimited. 例に示されている値は主として教育目的のものであるため、読者はそれらを最新あるいは完全なものとして頼らないように、特に注意してほしい。この文書の配布に制限はない。

2. INTRODUCTION 2. 導入

This RFC introduces domain style names, their use for Internet mail and host address support, and the protocols and servers used to implement domain name facilities. この RFC はドメイン形式の名前、インターネットメールとホストアドレスとのためのその使用法、そしてドメイン名の機能を実装するために使用されるプロトコルとサーバーとを紹介する。

2.1. The history of domain names 2.1. ドメイン名の歴史

The impetus for the development of the domain system was growth in the Internet: ドメインシステムの開発の推進力は、インターネットの成長であった:

The result was several ideas about name spaces and their management [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a common thread was the idea of a hierarchical name space, with the hierarchy roughly corresponding to organizational structure, and names using "." as the character to mark the boundary between hierarchy levels. A design using a distributed database and generalized resources was described in [RFC-882, RFC-883]. Based on experience with several implementations, the system evolved into the scheme described in this memo. その結果、名前空間とその管理とに関するいくつかのアイデア [IEN-116, RFC-799, RFC-819, RFC-830] が生まれた。それらの提案はさまざまであったが、共通するのは階層型の名前空間で、組織の構造に大雑把に対応する階層と、階層レベル間の境界を表す文字として "." を使用する名前とを持っていた。分散されたデータベースと一般化されたリソースとを使用するための設計は [RFC-882, RFC-883] に記述された。いくつかの実装による経験を基に、そのシステムはこの文書で説明されている仕組みへと進化した。

The terms "domain" or "domain name" are used in many contexts beyond the DNS described here. Very often, the term domain name is used to refer to a name with structure indicated by dots, but no relation to the DNS. This is particularly true in mail addressing [Quarterman 86]. "ドメイン(domain)" または "ドメイン名(domain name)" という用語は、ここで説明される DNS 全体に渡り、多くの文脈で使用される。たいていの場合、ドメイン名という用語はドットで示される構造を持つ名前を参照するために使われるが、DNS とは無関係である。これはメールのアドレッシング [Quarterman 86] において特に顕著である。

2.2. DNS design goals 2.2. DNS の設計目標

The design goals of the DNS influence its structure. They are: DNS の設計目標はその構造に影響を与えている。それらは以下の通り:

2.3. Assumptions about usage 2.3. 使用法に関する仮定

The organization of the domain system derives from some assumptions about the needs and usage patterns of its user community and is designed to avoid many of the the complicated problems found in general purpose database systems. ドメインシステムの組織化は、ユーザーコミュニティの必要性と利用パターンとに関するいくつかの仮定に由来しており、汎用目的のデータベースシステムに見られる複雑な問題の多くを避けるように設計されている。

The assumptions are: その仮定は以下の通り:

The domain system assumes that all data originates in master files scattered through the hosts that use the domain system. These master files are updated by local system administrators. Master files are text files that are read by a local name server, and hence become available through the name servers to users of the domain system. The user programs access name servers through standard programs called resolvers. ドメインシステムでは、すべての情報はドメインシステムを利用するホスト間に分散されたマスターファイルにその起源を持つものと仮定する。マスターファイルはローカルのシステム管理者によって更新される。マスターファイルはローカルのネームサーバーによって読み込まれるテキストファイルであり、したがってドメインシステムの利用者からはネームサーバーを通して利用可能となる。ユーザープログラムは、リゾルバと呼ばれる標準プログラムを通してネームサーバーにアクセスする。

The standard format of master files allows them to be exchanged between hosts (via FTP, mail, or some other mechanism); this facility is useful when an organization wants a domain, but doesn't want to support a name server. The organization can maintain the master files locally using a text editor, transfer them to a foreign host which runs a name server, and then arrange with the system administrator of the name server to get the files loaded. マスターファイルの標準フォーマットはホスト間での(FTP、メール、またはその他のメカニズムを介しての)交換を可能にしている。ドメインを利用したいがネームサーバーはサポートしたくない組織の場合に、この機能が役に立つ。そのような組織はテキストファイルを用いてローカルのマスターファイルを保守し、ネームサーバーを実行している外部のホストにそれを送った後、そのネームサーバーのシステム管理者にファイルを読み込んでもらうように手配することができる。

Each host's name servers and resolvers are configured by a local system administrator [RFC-1033]. For a name server, this configuration data includes the identity of local master files and instructions on which non-local master files are to be loaded from foreign servers. The name server uses the master files or copies to load its zones. For resolvers, the configuration data identifies the name servers which should be the primary sources of information. 各ホストのネームサーバーとリゾルバは、ローカルのシステム管理者によって設定される[RFC-1033]。ネームサーバーの設定情報には、ローカルのマスターファイルの識別と、非ローカルのマスターファイルを外部サーバーから読み込む手順とが含まれる。ネームサーバーは自身のゾーンを読み込むために、マスターファイルまたはそのコピーを使用する。リゾルバの設定情報は、主要な情報源となるべきネームサーバーを特定する。

The domain system defines procedures for accessing the data and for referrals to other name servers. The domain system also defines procedures for caching retrieved data and for periodic refreshing of data defined by the system administrator. ドメインシステムは、情報にアクセスするための手続きと、他のネームサーバーを参照するための手続きとを定義する。またドメインシステムは、取得した情報をキャッシュする手続きと、システム管理者によって決められる定期的な情報のリフレッシュの手続きも定義する。

The system administrators provide: システム管理者が提供するもの:

The domain system provides: ドメインシステムが提供するもの:

2.4. Elements of the DNS 2.4. DNS の要素

The DNS has three major components: DNS は三つの主要な構成要素を持つ:

These three components roughly correspond to the three layers or views of the domain system: これら三つの構成要素は、おおよそドメインシステムの三つのレイヤ、またはビューに対応する:

In the interests of performance, implementations may couple these functions. For example, a resolver on the same machine as a name server might share a database consisting of the the zones managed by the name server and the cache managed by the resolver. パフォーマンスのために、実装はこれらの機能を合わせ持ってもよい。例えばネームサーバーと同じマシン上のリゾルバは、そのネームサーバーの管理するゾーンから構成されるデータベースと、リゾルバによって管理されるキャッシュとを共有してもよい。

3. DOMAIN NAME SPACE and RESOURCE RECORDS 3. ドメイン名空間(DOMAIN NAME SPACE)とリソースレコード(RESOURCE RECORDS)

3.1. Name space specifications and terminology 3.1. 名前空間の仕様と用語

The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). The domain system makes no distinctions between the uses of the interior nodes and leaves, and this memo uses the term "node" to refer to both. ドメイン名空間はツリー構造である。ツリー上の各ノードとリーフとはリソース集合(空でもよい)に対応する。ドメインシステムは内部のノードとリーフとの使用を区別しない。この文書ではこの両方を参照するために "ノード" という用語を使用する。

Each node has a label, which is zero to 63 octets in length. Brother nodes may not have the same label, although the same label can be used for nodes which are not brothers. One label is reserved, and that is the null (i.e., zero length) label used for the root. 各ノードは、0 〜 63 オクテット長のラベルを持つ。兄弟でないノードは同じラベルを使用できるが、兄弟ノードは同じラベルを持ってはならない。ルートのために使用されるヌルラベル(すなわち長さゼロのラベル)は予約されている。

The domain name of a node is the list of the labels on the path from the node to the root of the tree. By convention, the labels that compose a domain name are printed or read left to right, from the most specific (lowest, farthest from the root) to the least specific (highest, closest to the root). あるノードのドメイン名は、そのノードからツリーのルートまでのパス上のラベルをリストしたものである。習慣的に、ドメイン名を構成するラベルは左から右へ、つまりもっとも特化した部分(最下位で、もっともルートから遠い部分)から、もっとも特化していない部分(最上位で、もっともルートに近い部分)へと、印字されたり読まれたりする。

Internally, programs that manipulate domain names should represent them as sequences of labels, where each label is a length octet followed by an octet string. Because all domain names end at the root, which has a null string for a label, these internal representations can use a length byte of zero to terminate a domain name. 内部的には、ドメイン名を扱うプログラムはドメイン名を一連のラベルとして表現するべきである。各々のラベルはレングスオクテットの後にオクテット文字列が続く。すべてのドメイン名はラベルにヌル文字列を持つルートで終了するため、内部表現はドメイン名を終わらせるためのゼロのレングスバイトを使用することができる。

By convention, domain names can be stored with arbitrary case, but domain name comparisons for all present domain functions are done in a case-insensitive manner, assuming an ASCII character set, and a high order zero bit. This means that you are free to create a node with label "A" or a node with label "a", but not both as brothers; you could refer to either using "a" or "A". When you receive a domain name or label, you should preserve its case. The rationale for this choice is that we may someday need to add full binary domain names for new services; existing services would not be changed. 習慣的にドメイン名は自由に大文字・小文字で保存できるが、現状のドメインの機能は、すべて ASCII 文字セットで高次ビットが 0 であると仮定し、大文字・小文字を区別せずに実行する。これは、ラベル "A" を持つノードもラベル "a" を持つノードも自由に生成できるが、両方を兄弟として生成することは出来ず、"a" でも "A" でも参照できることを意味する。ドメイン名またはラベルを受け取ったとき、その大文字・小文字を保持しておくべきである。その論理的根拠は、いつか新しいサービスのために完全にバイナリのドメイン名を追加するかもしれず、その時に既存のサービスを変更しなくても良いようにするためである。

When a user needs to type a domain name, the length of each label is omitted and the labels are separated by dots ("."). Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot. We use this property to distinguish between: ユーザーがドメイン名をタイプしなければならない場合、ラベルの長さは省略され、各ラベルはドット(".")で分離される。完全なドメイン名はルートラベルで終了するため、印刷形式ではドットで終了することになる。私たちは以下のものを区別するためにこの特徴を使用する:

Relative names are either taken relative to a well known origin, or to a list of domains used as a search list. Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation, and in master files, where they are relative to a single origin domain name. The most common interpretation uses the root "." as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing. 相対名は、既知の基点か検索リストとして使用されるドメインリストかに対する相対と見なされる。相対名が見られるのは主に、実装によって解釈の異るユーザーインターフェイスと、単一の基点ドメイン名への相対名となるマスターファイル中とである。もっとも一般的な解釈では、ルートの "." を単独の基点または検索リストのメンバーのひとつとして使用するため、複数ラベルから成る相対名は、しばしばタイピングを減らすために最後のドットを省略した形になる。

To simplify implementations, the total number of octets that represent a domain name (i.e., the sum of all label octets and label lengths) is limited to 255. 実装を簡単にするために、ドメイン名を表す総オクテット数(すなわち、すべてのラベルオクテットとラベル長の合計)は 255 までに制限される。

A domain is identified by a domain name, and consists of that part of the domain name space that is at or below the domain name which specifies the domain. A domain is a subdomain of another domain if it is contained within that domain. This relationship can be tested by seeing if the subdomain's name ends with the containing domain's name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". ドメインはドメイン名によって識別され、そのドメインを特定するドメイン名そのもの、またはその下位のドメイン名空間の該当部分から構成される。あるドメインが別のドメインの中に含まれる場合、それはそのドメインのサブドメインである。サブドメインの名前がそれを含むドメイン名で終わっているかどうかを見ることで、この関係を確認することができる。例えば A.B.C.D は、B.C.D、C.D、D、" " のサブドメインである。

3.2. Administrative guidelines on use 3.2. 利用上の管理ガイドライン

As a matter of policy, the DNS technical specifications do not mandate a particular tree structure or rules for selecting labels; its goal is to be as general as possible, so that it can be used to build arbitrary applications. In particular, the system was designed so that the name space did not have to be organized along the lines of network boundaries, name servers, etc. The rationale for this is not that the name space should have no implied semantics, but rather that the choice of implied semantics should be left open to be used for the problem at hand, and that different parts of the tree can have different implied semantics. For example, the IN-ADDR.ARPA domain is organized and distributed by network and host address because its role is to translate from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- 1002] are flat because that is appropriate for that application. ポリシーの問題として、DNS の技術的仕様は、特定のツリー構造やラベル選択のための規則を強制しない。その意図は、任意のアプリケーションを構築するのに使用できるように、できる限り一般化することである。特にこのシステムは、名前空間をネットワーク境界やネームサーバー等の区分に沿ってまとめる必要が無いように設計された。その論理的根拠は、名前空間が暗黙の意味を持たないべきであるという事ではなく、むしろ暗黙の意味の選択がその問題のためにすぐに使用され得るようオープンであるべきという事である。つまり、ツリーの異なる部分では異なる暗黙の意味を持つことが可能ということである。例えばドメイン IN-ADDR.ARPA は、その役割がネットワークまたはホストの番号を名前に変換することなので、ネットワークとホストとのアドレスによってまとめられ、配布される。NetBIOS ドメイン [RFC-1001, RFC-1002] はフラットである。なぜなら、それがそのアプリケーションに適しているためである。

However, there are some guidelines that apply to the "normal" parts of the name space used for hosts, mailboxes, etc., that will make the name space more uniform, provide for growth, and minimize problems as software is converted from the older host table. The political decisions about the top levels of the tree originated in RFC-920. Current policy for the top levels is discussed in [RFC-1032]. MILNET conversion issues are covered in [RFC-1031]. しかしながら、ホストやメールボックス等に使用される名前空間の "通常(normal)" の部分に適用されるガイドラインがいくつか存在しており、それは名前空間を画一化し、成長に備え、ソフトウェアを過去のホストテーブルから変換する場合の問題を最小化する。ツリーのトップレベルに関する政治的決定は RFC-920 を基礎にしている。トップレベルに対する現在のポリシーは [RFC-1032] で議論されている。MILNET 変換の問題は [RFC-1031] で網羅されている。

Lower domains which will eventually be broken into multiple zones should provide branching at the top of the domain so that the eventual decomposition can be done without renaming. Node labels which use special characters, leading digits, etc., are likely to break older software which depends on more restrictive choices. いずれ複数のゾーンに分割されるであろう下位ドメインは、最終的な分割を改名なしに実行できるように、そのドメインの最上位で分岐を提供しておくべきである。特殊文字や数字で始まるようなノードラベルは、より限定的な選択に依存する古いソフトウェアに問題を起こさせる可能性がある。

3.3. Technical guidelines on use 3.3. 使用に関する技術的ガイドライン

Before the DNS can be used to hold naming information for some kind of object, two needs must be met: DNS が何らかのオブジェクトの名前情報を保持できるようになる前に、二つの要求事項を満たさなければならない:

These rules can be quite simple or fairly complex. Very often, the designer must take into account existing formats and plan for upward compatibility for existing usage. Multiple mappings or levels of mapping may be required. これらの規則は非常に単純にすることも、極めて複雑にすることもできる。多く場合、設計者は既存のフォーマットを考慮したり、既存の利用法に対する上位互換性を計画したりしなければならない。複数のマッピングやマッピングの階層が要求されてもよい。

For hosts, the mapping depends on the existing syntax for host names which is a subset of the usual text representation for domain names, together with RR formats for describing host addresses, etc. Because we need a reliable inverse mapping from address to host name, a special mapping for addresses into the IN-ADDR.ARPA domain is also defined. ホストの場合のマッピングは、ドメイン名の通常のテキスト表現のサブセットであるホスト名のための既存文法に基き、ホストアドレス等を記述するための RR フォーマットを伴う。私たちはアドレスからホスト名への信頼できる逆マッピングも必要とするので、ドメイン IN-ADDR.ARPA への特殊なマッピングも定義されている。

For mailboxes, the mapping is slightly more complex. The usual mail address <local-part>@<mail-domain> is mapped into a domain name by converting <local-part> into a single label (regardless of dots it contains), converting <mail-domain> into a domain name using the usual text format for domain names (dots denote label breaks), and concatenating the two to form a single domain name. Thus the mailbox HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this design also must take into account the scheme for mail exchanges [RFC- 974]. メールボックスのマッピングは少し複雑である。通常のメールアドレス <local-part>@<mail-domain> は、<local-part> を(その中のドットに関係なく)単独のラベルに変換し、さらに <mail-domain> をドメイン名の通常のテキストフォーマットを使用してドメイン名に変換し、そして単一のドメイン名を形成するためにその二つをつなげることで、ドメイン名へとマップされる。したがってメールボックス HOSTMASTER@SRI-NIC.ARPA は、HOSTMASTER.SRI-NIC.ARPA というドメイン名として表現される。この設計を正しく評価するには、メールエクスチェンジ [RFC-974] の仕組みを考慮しなければならない。

The typical user is not concerned with defining these rules, but should understand that they usually are the result of numerous compromises between desires for upward compatibility with old usage, interactions between different object definitions, and the inevitable urge to add new features when defining the rules. The way the DNS is used to support some object is often more crucial than the restrictions inherent in the DNS. 典型的なユーザーがこれらの規則の定義を意識することはない。しかしこれらが、過去の習慣との上位互換性の要望に対する多くの妥協と、異なるオブジェクト定義間の相互関係と、この規則を定義する際に新しい機能を追加するという避け難い衝動との結果だということを理解するべきである。何らかのオブジェクトをサポートするために DNS が使用される方法は、DNS 固有の制約よりも、しばしばより重要である。

3.4. Example name space 3.4. 名前空間の例

The following figure shows a part of the current domain name space, and is used in many examples in this RFC. Note that the tree is a very small subset of the actual name space. 以下の図は現在のドメイン名空間の一部を示しており、この RFC の多くの例で使用されている。このツリーは実際の名前空間の非常に小さいサブセットであることに注意してほしい。

                                   |
                                   |
             +---------------------+------------------+
             |                     |                  |
            MIL                   EDU                ARPA
             |                     |                  |
             |                     |                  |
       +-----+-----+               |     +------+-----+-----+
       |     |     |               |     |      |           |
      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
                                   |
       +--------+------------------+---------------+--------+
       |        |                  |               |        |
      UCI      MIT                 |              UDEL     YALE
                |                 ISI
                |                  |
            +---+---+              |
            |       |              |
           LCS  ACHILLES  +--+-----+-----+--------+
            |             |  |     |     |        |
            XX            A  C   VAXA  VENERA Mockapetris

In this example, the root domain has three immediate subdomains: MIL, EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named XX.LCS.MIT.EDU. All of the leaves are also domains. この例において、ルートドメインは三つの直接のサブドメイン MIL・EDU・ARPA を持つ。ドメイン LCS.MIT.EDU は直接のサブドメイン XX.LCS.MIT.EDU を持つ。またリーフもすべてドメインである。

3.5. Preferred name syntax 3.5. 好ましい名前構文

The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. DNS 仕様はドメイン名の構築の規則において、可能な限り一般化されるように試みられている。どの既存オブジェクトの名前も、最小限の変更でドメイン名として表現できるようにするという考え方である。しかしながらあるオブジェクトにドメイン名を割当てるとき、慎重なユーザーはそのオブジェクトに、ドメインシステムの規則と既存の規則(それが公開されているものであろうと、既存プログラムによって必要とされているものであろうと)との両方を満足する名前を選択するだろう。

For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. 例えばメールドメインに名前を付ける場合、ユーザーはこの文書の規則と RFC-822 の規則との両方を満足させるべきである。また新しいホスト名を作成する場合、HOSTS.TXT のための過去の規則にしたがうべきである。これによって、過去のソフトウェアをドメイン名を使用するように変更する際の問題を避けられる。

The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET). 以下の構文にしたがうと、ドメイン名を使用する多くのアプリケーション(例えばメールや TELNET)において、問題がより少なくなるだろう。

<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case

<digit> ::= any one of the ten digits 0 through 9
<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 の、アルファベット
52 文字の内の任意の一文字

<digit> ::= 0 から 9 までの 10 個の数字の内の任意の一文字

Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. ドメイン名には大文字も小文字も許されるが、それには重要な違いがないことに注意してほしい。つまり、同じつづりで大文字・小文字の異なる二つの名前は同じ物として扱われるということである。

The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. ラベルは ARPANET のホスト名の規則にしたがわなければならない。ラベルは文字で始まり、文字または数字で終わり、間には文字・数字・ハイフンだけが含まれなければならない。ラベルの長さにも制約があり、63 文字以下でなければならない。

For example, the following strings identify hosts in the Internet: 例えば以下の文字列はインターネット上のホストを識別する:

A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA

3.6. Resource Records 3.6. リソースレコード

A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate resource records (RRs). The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS. ドメイン名はノードを識別する。各々のノードはリソース情報の集合(空でもよい)を持つ。ある特定の名前に対応するリソース情報の集合は、個別のリソースレコード(RR)から構成される。集合の中の RR の順序は重要ではなく、ネームサーバーやリゾルバやその他の DNS の要素がその順序を保存する必要はない。

When we talk about a specific RR, we assume it has the following: 私たちがある特定の RR に付いて述べるとき、それは以下の内容を持つと仮定する:

owner 所有者
which is the domain name where the RR is found. その RR を見つけられるドメイン名。
type タイプ
which is an encoded 16 bit value that specifies the type of the resource in this resource record. Types refer to abstract resources. エンコードされた 16 ビット値で、そのリソースレコード内のリソースの種類を表す。タイプは抽象リソースを表す。
This memo uses the following types: この文書では以下のタイプを使用する:
A
a host address ホストアドレス
CNAME
identifies the canonical name of an alias 別名の正式な名前を特定する
HINFO
identifies the CPU and OS used by a host ホストが使用する CPU と OS を特定する
MX
identifies a mail exchange for the domain. See [RFC-974 for details. そのドメインのメールエクスチェンジを特定する。詳細は [RFC-974] を参照してほしい。
NS
the authoritative name server for the domain そのドメインに対して権威を持つネームサーバー
PTR
a pointer to another part of the domain name space ドメイン名空間の別の部分へのポインタ
SOA
identifies the start of a zone of authority 権威を持つゾーンの開始を表す
class クラス
which is an encoded 16 bit value which identifies a protocol family or instance of a protocol. エンコードされた 16 ビット値で、プロトコルファミリーまたはプロトコルのインスタンスを表す。
This memo uses the following classes: この文書では以下のクラスを使用する:
IN
the Internet system インターネット
CH
the Chaos system カオスシステム
TTL
which is the time to live of the RR. This field is a 32 bit integer in units of seconds, an is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it should be discarded. RR の生存期間。このフィールドは秒単位の 32 ビット整数値で、主にリゾルバが RR をキャッシュする際に使用する。TTL は RR が破棄されるまでにどれだけの時間キャッシュされてよいかを記述したものである。
RDATA
which is the type and sometimes class dependent data which describes the resource: そのリソースを説明する情報である。タイプと、場合によってはクラスに依存する:
A
For the IN class, a 32 bit IP address IN クラスの場合、32 ビット IP アドレス
For the CH class, a domain name followed by a 16 bit octal Chaos address. CH クラスの場合、16 ビットの 8 進数カオスアドレスが続くドメイン名。
CNAME
a domain name. ドメイン名
MX
a 16 bit preference value (lower is better) followed by a host name willing to act as a mail exchange for the owner domain. 16 ビットの優先順位(小さい方が優先順位が高い)の後に、所有ドメインのメールエクスチェンジとして動作させようとするホスト名が続く。
NS
a host name. ホスト名
PTR
a domain name. ドメイン名
SOA
several fields. いくつかのフィールド

The owner name is often implicit, rather than forming an integral part of the RR. For example, many name servers internally form tree or hash structures for the name space, and chain RRs off nodes. The remaining RR parts are the fixed header (type, class, TTL) which is consistent for all RRs, and a variable part (RDATA) that fits the needs of the resource being described. 多くの場合、所有者名は RR の必須要素とされるのではなく、暗黙的である。例えば多くのネームサーバーは、名前空間のためのツリーとハッシュ構造とを内部的に形成し、ノードを鎖状に繋ぐ。RR の残りの要素は、すべての RR において変化しない固定ヘッダ(タイプ、クラス、TTL)と、リソースを説明するための可変部分(右辺値(RDATA))である。

The meaning of the TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in zones; it is also timed out, but by the refreshing policies for the zone. The TTL is assigned by the administrator for the zone where the data originates. While short TTLs can be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance suggest that these times should be on the order of days for the typical host. If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change. TTL フィールドは、RR をキャッシュに保持できる制限時間を表す。この制限時間は権威を持つゾーン内の情報には適用されない。権威を持つゾーン内の情報もタイムアウトはするが、それはそのゾーンのリフレッシュポリシーによるものである。TTL は、その情報の源であるゾーンの管理者によって割当てられる。キャッシュされる時間を短くするために短い TTL を使用してもよいし、キャッシュされるのを拒否するために TTL をゼロにしてもよい。しかしながら、現実のインターネットのパフォーマンスを考えると、一般的なホストでは日単位にするべきである。前もって変更を予期できる場合、その変更による不一致を最小化するために、変更前に TTL を減らし、変更後に前の値に戻すことができる。

The data in the RDATA section of RRs is carried as a combination of binary strings and domain names. The domain names are frequently used as "pointers" to other data in the DNS. RR の RDATA 部のデータは、バイナリ文字列とドメイン名との組合わせとして転送される。ドメイン名はしばしば DNS の別の情報への "ポインタ(pointers)" として使用される。

3.6.1. Textual expression of RRs 3.6.1. RR のテキスト表現

RRs are represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form when stored in a name server or resolver. In this memo, we adopt a style similar to that used in master files in order to show the contents of RRs. In this format, most RRs are shown on a single line, although continuation lines are possible using parentheses. RR は DNS プロトコルのパケット内ではバイナリ形式で表現され、ネームサーバーやリゾルバの内部に保存される場合には高度にエンコードされて表現されるのが通常である。この文書では RR の内容を表すために、マスターファイル内で使用されるスタイルに似た形式を採用する。括弧を使って行を続けることも可能だが、この形式では大抵の RR は単一行で表される。

The start of the line gives the owner of the RR. If a line begins with a blank, then the owner is assumed to be the same as that of the previous RR. Blank lines are often included for readability. 行の先頭には RR の所有者が示される。行が空白で始まる場合、その所有者は直前の RR の所有者と同じであると見なされる。可読性のために、しばしば空行が含められる。

Following the owner, we list the TTL, type, and class of the RR. Class and type use the mnemonics defined above, and TTL is an integer before the type field. In order to avoid ambiguity in parsing, type and class mnemonics are disjoint, TTLs are integers, and the type mnemonic is always last. The IN class and TTL values are often omitted from examples in the interests of clarity. 所有者に続けて、RR の TTL・タイプ・クラスが示される。クラスとタイプは前述のニーモニックを使用し、TTL はタイプフィールドの前に置かれる整数値である。解析の際のあいまいさを避けるために、タイプとクラスのニーモニックは分離される。TTL は整数であり、タイプのニーモニックは常に最後にくる。明快さのために、例ではしばしば IN クラスと TTL 値とを省略している。

The resource data or RDATA section of the RR are given using knowledge of the typical representation for the data. RR のリソース情報または RDATA 部は、その情報の一般的表現の知識を使用して与えられる。

For example, we might show the RRs carried in a message as: 例えば、メッセージ内で運ばれる RR を以下のように表す:

    ISI.EDU.        MX      10 VENERA.ISI.EDU.
                    MX      10 VAXA.ISI.EDU.
    VENERA.ISI.EDU. A       128.9.0.32
                    A       10.1.0.52
    VAXA.ISI.EDU.   A       10.2.0.27
                    A       128.9.0.33

The MX RRs have an RDATA section which consists of a 16 bit number followed by a domain name. The address RRs use a standard IP address format to contain a 32 bit internet address. MX RR の RDATA 部は、16 ビット値と、その後にドメイン名とが続く。アドレス RR は 32 ビットのインターネットアドレスを含むために、標準的 IP アドレスフォーマットを使用する。

This example shows six RRs, with two RRs at each of three domain names. 上の例は 6 つの RR を表しており、三つのドメインがそれぞれ二つの RR を持っている。

Similarly we might see: 同じような例:

    XX.LCS.MIT.EDU. IN      A       10.0.0.44
                    CH      A       MIT.EDU. 2420

This example shows two addresses for XX.LCS.MIT.EDU, each of a different class. この例は XX.LCS.MIT.EDU の二つのアドレスを表しており、それぞれクラスが異なる。

3.6.2. Aliases and canonical names 3.6.2. 別名と正規名

In existing systems, hosts and other resources often have several names that identify the same resource. For example, the names C.ISI.EDU and USC-ISIC.ARPA both identify the same host. Similarly, in the case of mailboxes, many organizations provide many names that actually go to the same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU, and PVM@ISI.EDU all go to the same mailbox (although the mechanism behind this is somewhat complicated). 既存の組織において、ホストやその他のリソースは、しばしば同じリソースを識別する複数の名前を持つ。例えば、C.ISI.EDU と USC-ISIC.ARPA とは同じホストを表す。同様にメールボックスの場合、多くの組織は実際には同じメールボックスに届く複数の名前を提供する。例えば、Mockapetris@C.ISI.EDU と Mockapetris@B.ISI.EDU、PVM@ISI.EDU とは、(たとえその背景のメカニズムが多少複雑であったとしても)同じメールボックスに届く。

Most of these systems have a notion that one of the equivalent set of names is the canonical or primary name and all others are aliases. このような組織の多くは、その同等な名前のなかのひとつが正統または主要な名前であり、他の名前はすべて別名であるという概念を持つ。

The domain system provides such a feature using the canonical name (CNAME) RR. A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types. そのような特徴を、ドメインシステムは正規名 (CNAME) RR によって提供する。CNAME RR はその所有者名を別名として識別し、対応する正規名を RR の RDATA 部に指定する。ノードに CNAME RR が与えられる場合、他の情報は現れるべきではない。これにより、正規名と別名との情報に差異がないことを保証できる。またこの規則は、他の RR タイプの権威サーバーに確認すること無く、キャッシュされた CNAME を使用できることを保証する。

CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted. CNAME RR は DNS ソフトウェアに特別な動作を起こさせる。ドメイン名に対応するリソース集合の中から目的の RR を見つけるのに失敗したネームサーバーは、そのリソース集合に同一クラスの CNAME レコードが含まれるかどうかを確認する。もし含まれるなら、ネームサーバーは応答にその CNAME レコードを含め、その CNAME レコードのデータフィールド内で特定されるドメイン名で問合せを再開する。この規則にはひとつの例外があり、CNAME タイプを検索する問合せの場合は再開しない。

For example, suppose a name server was processing a query with for USC- ISIC.ARPA, asking for type A information, and had the following resource records: 例えば、ネームサーバーが USC-ISIC.ARPA のタイプ A を求める問合せを処理しており、以下のリソースレコードを持っていると仮定する:

    USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU

    C.ISI.EDU       IN      A       10.0.0.52

Both of these RRs would be returned in the response to the type A query, while a type CNAME or * query should return just the CNAME. タイプ A の問合せへの応答には、これら両方の RR が返される。一方、タイプ CNAME または * の問合せには CNAME だけが返される。

Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information. For example, the address to name RR for the above host should be: 別の名前を指す RR 内のドメイン名は、別名ではなく常に主要な名前を指すべきである。これは情報にアクセスする際の余分な遠回りを避ける。例えば、上記のホストのための RR を指すアドレスは、USC-ISIC.ARPA ではなく、以下のようにするべきである:

    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

rather than pointing at USC-ISIC.ARPA. Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error. 当然ながら堅牢性の原則によって、ドメインソフトウェアは CNAME のチェーンやループに陥っても正常に機能するべきである。CNAME チェーンは処理が続けられ、CNAME ループはエラーとして通知されるべきである。

3.7. Queries 3.7. 問合せ

Queries are messages which may be sent to a name server to provoke a response. In the Internet, queries are carried in UDP datagrams or over TCP connections. The response by the name server either answers the question posed in the query, refers the requester to another set of name servers, or signals some error condition. 問合せは応答を引き出すためにネームサーバーに送られるメッセージである。インターネットにおいて、問合せは UDP データグラムまたは TCP 接続を通して伝えられる。ネームサーバーからの応答は、その問合せによってなされた質問に回答するか、リクエスタに別のネームサーバーの集合を参照させるか、何らかのエラー状態を知らせるか、何れかになる。

In general, the user does not generate queries directly, but instead makes a request to a resolver which in turn sends one or more queries to name servers and deals with the error conditions and referrals that may result. Of course, the possible questions which can be asked in a query does shape the kind of service a resolver can provide. 一般にユーザーは、直接問合せを生成するのではなく、代わりにリゾルバへのリクエストを生成する。リゾルバはネームサーバーにひとつ以上の問合せを送信し、結果として起こる参照やエラー状態を処理する。当然ながら、問合せできる質問がリゾルバの提供できるサービスの種類を決定する。

DNS queries and responses are carried in a standard message format. The message format has a header containing a number of fixed fields which are always present, and four sections which carry query parameters and RRs. DNS の問合せと応答は標準メッセージフォーマットで送られる。メッセージフォーマットは、必ず提示される多くの固定フィールドを持つヘッダと、問合せパラメータおよび RR を伝える 4 つのセクションとを持つ。

The most important field in the header is a four bit field called an opcode which separates different queries. Of the possible 16 values, one (standard query) is part of the official protocol, two (inverse query and status query) are options, one (completion) is obsolete, and the rest are unassigned. ヘッダ内でもっとも重要なフィールドは opcode と呼ばれる 4 ビットのフィールドで、種々の問合せを区別するものである。取り得る 16 の値のうち、ひとつ(標準問合せ)は公式なプロトコルの一部であり、二つ(逆問合せと状態問合せ)はオプション、ひとつ(補完(completion))は非推奨、その他は未割当てである。

The four sections are: 4 つのセクションは以下の通り:

Question(質問)
Carries the query name and other query parameters. 問合せる名前とその他の問合せパラメータとを伝える。
Answer(回答)
Carries RRs which directly answer the query. 問合せの直接の回答となる RR を伝える。
Authority(権威)
Carries RRs which describe other authoritative servers. May optionally carry the SOA RR for the authoritative data in the answer section. 別の権威サーバーを記述する RR を伝える。任意で Answer セクション内の権威情報の SOA RR を伝えることもできる。
Additional(追加)
Carries RRs which may be helpful in using the RRs in the other sections. 別セクション内の RR を使用する際に参考になる RR を伝える。

Note that the content, but not the format, of these sections varies with header opcode. ヘッダの opcode によって変化するのはこれらのセクションの内容であり、フォーマットではないことに注意してほしい。

3.7.1. Standard queries 3.7.1. 標準問合せ

A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match. This type of query makes up such a vast majority of DNS queries that we use the term "query" to mean standard query unless otherwise specified. The QTYPE and QCLASS fields are each 16 bits long, and are a superset of defined types and classes. 標準問合せは、目的のドメイン名(QNAME)・問合せタイプ(QTYPE)・問合せクラス(QCLASS)を指定し、それに一致する RR を求める。DNS の問合せの大多数はこの種類であるため、私たちは特に断らない限り "問合せ(query)" という用語をこの標準問合せを意味するものとして使用する。QTYPE フィールドおよび QCLASS フィールドは共に 16 ビット長で、定義済みのタイプおよびクラスの上位集合である。

The QTYPE field may contain: QTYPE フィールドは以下の内容を含むことができる:

<any type> <任意のタイプ>
matches just that type. (e.g., A, PTR). そのタイプ(例えば A、PTR)にのみ一致する。
AXFR
special zone transfer QTYPE. 特別なゾーン転送 QTYPE。
MAILB
matches all mail box related RRs (e.g. MB and MG). メールボックスに関連するすべての RR (例えば MB と MG)に一致する。
*
matches all RR types. すべての RR タイプに一致する。

The QCLASS field may contain: QCLASS フィールドは以下の内容を含むことができる:

<any class> <任意のクラス>
matches just that class (e.g., IN, CH). そのクラス(例えば IN、CH)にのみ一致する。
*
matches aLL RR classes. すべての RR クラスに一致する。

Using the query domain name, QTYPE, and QCLASS, the name server looks for matching RRs. In addition to relevant records, the name server may return RRs that point toward a name server that has the desired information or RRs that are expected to be useful in interpreting the relevant RRs. For example, a name server that doesn't have the requested information may know a name server that does; a name server that returns a domain name in a relevant RR may also return the RR that binds that domain name to an address. 問合せドメイン名と QTYPE と QCLASS とを使用して、ネームサーバーはそれらに一致する RR を探す。ネームサーバーは関連するレコードに加えて、目的の情報を持つネームサーバーを指し示す RR を返したり、関連する RR を解釈するのに役立つと思われる RR を返したりしてよい。例えば、要求された情報を持っていないネームサーバーがその情報を持っているネームサーバーを知っているかもしれないし、関連する RR としてドメイン名を返すネームサーバーが、そのドメイン名とアドレスとを関連付ける RR を返すかもしれない。

For example, a mailer tying to send mail to Mockapetris@ISI.EDU might ask the resolver for mail information about ISI.EDU, resulting in a query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer section would be: 例えば、Mockapetris@ISI.EDU 宛てにメールを送ろうとするメーラーは、ISI.EDU に関するメール情報をリゾルバに質問し、その結果として QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN の問合せが発生する。その応答の Answer セクションは以下のようになるだろう:

    ISI.EDU.        MX      10 VENERA.ISI.EDU.
                    MX      10 VAXA.ISI.EDU.

while the additional section might be: 一方、Additional セクションは以下のようになるだろう:

    VAXA.ISI.EDU.   A       10.2.0.27
                    A       128.9.0.33
    VENERA.ISI.EDU. A       10.1.0.52
                    A       128.9.0.32

Because the server assumes that if the requester wants mail exchange information, it will probably want the addresses of the mail exchanges soon afterward. なぜならサーバーは、リクエスタがメールエクスチェンジ情報を要求した場合、その後すぐにそのメールエクスチェンジのアドレスを要求するであろうと仮定するためである。

Note that the QCLASS=* construct requires special interpretation regarding authority. Since a particular name server may not know all of the classes available in the domain system, it can never know if it is authoritative for all classes. Hence responses to QCLASS=* queries can never be authoritative. QCLASS=* の構成は、権威に関連して特別な解釈を必要とすることに注意してほしい。ある特定のネームサーバーがそのドメイン組織内で有効なすべてのクラスを知っている必要はないため、サーバーは自身がすべてのクラスに対して権威を持つかどうかを決して知ることはない。したがって QCLASS=* への応答は、決して権威を持つことがない。

3.7.2. Inverse queries (Optional) 3.7.2. 逆問合せ(オプション)

Name servers may also support inverse queries that map a particular resource to a domain name or domain names that have that resource. For example, while a standard query might map a domain name to a SOA RR, the corresponding inverse query might map the SOA RR back to the domain name. ネームサーバーは、ある特定のリソースを、そのリソースを持つひとつまたは複数のドメイン名にマップする逆問合せをサポートすることもできる。例えば、標準問合せはドメイン名を SOA RR にマップする一方で、それに対応する逆問合せは、その SOA RR をそのドメイン名にマップする。

Implementation of this service is optional in a name server, but all name servers must at least be able to understand an inverse query message and return a not-implemented error response. ネームサーバーがこのサービスを実装するかどうかは任意だが、すべてのネームサーバーは、少なくとも逆問合せのメッセージを理解し、実装されていない旨のエラー応答を返すことが出来なければならない。

The domain system cannot guarantee the completeness or uniqueness of inverse queries because the domain system is organized by domain name rather than by host address or any other resource type. Inverse queries are primarily useful for debugging and database maintenance activities. ドメインシステムは逆問合せの完全性や一意性を保証できない。なぜなら、ドメインシステムはホストアドレスまたは他のリソースタイプではなく、ドメイン名によって組織化されるためである。逆問合せは、デバッグおよびデータベースのメンテナンス作業において特に有効である。

Inverse queries may not return the proper TTL, and do not indicate cases where the identified RR is one of a set (for example, one address for a host having multiple addresses). Therefore, the RRs returned in inverse queries should never be cached. 逆問合せは適切な TTL を返さなくてもよく、特定された RR が集合の中のひとつ(例えば、複数のアドレスを持つホストに対するひとつのアドレス)であるような場合には提示されることもない。したがって、逆問合せで返される RR は決してキャッシュされるべきではない。

Inverse queries are NOT an acceptable method for mapping host addresses to host names; use the IN-ADDR.ARPA domain instead. ホストアドレスをホスト名にマッピングする方法としては、逆問合せは受け入れられるものではない。代わりに IN-ADDR.ARPA ドメインを使用する。

A detailed discussion of inverse queries is contained in [RFC-1035]. 逆問合せに付いての詳細な議論は [RFC-1035] に含まれている。

3.8. Status queries (Experimental) 3.8. 状態問合せ(実験目的)

To be defined. 将来定義される。

3.9. Completion queries (Obsolete) 3.9. 補完問合せ(非推奨)

The optional completion services described in RFCs 882 and 883 have been deleted. Redesigned services may become available in the future, or the opcodes may be reclaimed for other use. RFC 882 および RFC 883 で説明されているオプションの補完サービスは削除された。将来、再設計されたサービスが利用可能になってもよいし、この opcode が別の用途のために再利用されてもよい。

4. NAME SERVERS 4. ネームサーバー

4.1. Introduction 4.1. 導入

Name servers are the repositories of information that make up the domain database. The database is divided up into sections called zones, which are distributed among the name servers. While name servers can have several optional functions and sources of data, the essential task of a name server is to answer queries using data in its zones. By design, name servers can answer queries in a simple manner; the response can always be generated using only local data, and either contains the answer to the question or a referral to other name servers "closer" to the desired information. ネームサーバーはドメインデータベースを形成する情報の保管場所である。データベースはゾーンと呼ばれる部分に分割され、ネームサーバー間に分散される。ネームサーバーはいくつかのオプションの機能とデータソースとを持つことができる一方、ネームサーバーの必須の仕事はそのゾーン内の情報を使用して問合せに答えることである。設計上、ネームサーバーは単純な法則にしたがって問合せに答えることができる。その応答は常にローカルの情報だけを使用して生成され、質問への答えか、目的の情報に "より近い(closer)" 他のネームサーバーへの参照かを返す。

A given zone will be available from several name servers to insure its availability in spite of host or communication link failure. By administrative fiat, we require every zone to be available on at least two servers, and many zones have more redundancy than that. ある特定のゾーンは、ホストや通信回線の故障時でも利用できることを保証するために、複数のネームサーバーから利用可能だろう。管理上の判断により、私たちは全てのゾーンが少なくとも二つのサーバー上で利用可能であること、大部分のゾーンはそれ以上の冗長性を持つことを要求する。

A given name server will typically support one or more zones, but this gives it authoritative information about only a small section of the domain tree. It may also have some cached non-authoritative data about other parts of the tree. The name server marks its responses to queries so that the requester can tell whether the response comes from authoritative data or not. ある特定のネームサーバーは一般にひとつ以上のゾーンをサポートするが、それはドメインツリーのある小さな部分のみに関する権威情報を提供するだけである。またサーバーは、ツリーの別の部分に関する権威を持たないキャッシュされた情報を持つことができる。ネームサーバーは、その応答が権威情報から来たものかどうかをリクエスタが答えられるように、問合せへの応答に印を付ける。

4.2. How the database is divided into zones 4.2. データベースをゾーンに分割する方法

The domain database is partitioned in two ways: by class, and by "cuts" made in the name space between nodes. ドメインデータベースは二つの方法で分割される: クラスによる方法と、ノード間の名前空間に "切れ目(cuts)" を作る方法である。

The class partition is simple. The database for any class is organized, delegated, and maintained separately from all other classes. Since, by convention, the name spaces are the same for all classes, the separate classes can be thought of as an array of parallel namespace trees. Note that the data attached to nodes will be different for these different parallel classes. The most common reasons for creating a new class are the necessity for a new data format for existing types or a desire for a separately managed version of the existing name space. クラス分割は単純である。どのクラスのデータベースも他のクラスとは独立にまとめられ、委任され、保守される。習慣的に名前空間はすべてのクラスに対して同等であるので、それぞれのクラスを並列する名前空間ツリーと考えることができる。ノードに関連付けられる情報は、これら異なるクラスに対して異なるであろう点に注意してほしい。新しいクラスを作り出すもっとも一般的な理由は、既存のタイプのための新しいデータフォーマットの必要性、または既存の名前空間の独立して管理されるバージョンの要求である。

Within a class, "cuts" in the name space can be made between any two adjacent nodes. After all cuts are made, each group of connected name space is a separate zone. The zone is said to be authoritative for all names in the connected region. Note that the "cuts" in the name space may be in different places for different classes, the name servers may be different, etc. クラス内では、その名前空間内の "切れ目(cuts)" を任意の隣接ノード間に作成することができる。すべての切れ目が作成された後、関連する名前空間の各グループは独立したゾーンとなる。そのゾーンは関連する範囲内のすべての名前に対して権威を持つと言われる。名前空間内の "切れ目(cuts)" は異なるクラスに対しては異なる場所にあってもよいこと、ネームサーバーが異なってもよいこと等に注意してほしい。

These rules mean that every zone has at least one node, and hence domain name, for which it is authoritative, and all of the nodes in a particular zone are connected. Given, the tree structure, every zone has a highest node which is closer to the root than any other node in the zone. The name of this node is often used to identify the zone. これらの規則は、各ゾーンが少なくともひとつのノードを持ち、したがって、権威を持つドメイン名と特定ゾーン内の全てのノードとが関連付けられることを意味する。ツリー構造が与えられるため、各ゾーンはそのゾーン内の他のノードよりもルートに近い最上位のノードを持つ。そのノードの名前は、しばしばそのゾーンを識別するために使用される。

It would be possible, though not particularly useful, to partition the name space so that each domain name was in a separate zone or so that all nodes were in a single zone. Instead, the database is partitioned at points where a particular organization wants to take over control of a subtree. Once an organization controls its own zone it can unilaterally change the data in the zone, grow new tree sections connected to the zone, delete existing nodes, or delegate new subzones under its zone. 各ドメイン名をそれぞれ別のゾーン内に含めたり、すべてのノードを単一のゾーンに含めたりするように名前空間を分割することも可能だが、特に役に立たないだろう。その代わりデータベースは、個々の組織がひとつのサブツリーを占有したいだろうという観点から分割される。ある組織が自身の所有するゾーンをいったん占有すると、その組織はそのゾーン内の情報を一方的に変更したり、そのゾーンに接続する新しいツリーを発展させたり、既存ノードを削除したり、そのゾーンの下に新しいゾーンを委譲したりすることができる。

If the organization has substructure, it may want to make further internal partitions to achieve nested delegations of name space control. In some cases, such divisions are made purely to make database maintenance more convenient. もし組織が下部構造を持っているなら、名前空間の制御のネストした委譲を実現するために、内部的にさらに分割したいと望むかもしれない。場合によっては、単純にデータベースのメンテナンスを行いやすくするために、そのような分割が行われる。

4.2.1. Technical considerations 4.2.1. 技術的考察

The data that describes a zone has four major parts: ゾーンを記述する情報は 4 つの主要な要素を持つ:

All of this data is expressed in the form of RRs, so a zone can be completely described in terms of a set of RRs. Whole zones can be transferred between name servers by transferring the RRs, either carried in a series of messages or by FTPing a master file which is a textual representation. これらすべての情報は RR 形式で表現される。したがって、ゾーンは RR の集合によって完全に記述することができる。すべてのゾーンは、一連のメッセージとして転送するか、テキスト形式のマスターファイルを FTP で送受信するか、どちらかの方法による RR の転送によってネームサーバー間を転送される。

The authoritative data for a zone is simply all of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone. あるゾーンのための権威情報は、単にそのゾーンのトップノードから、末端ノードまたはそのゾーンの下位断片(cuts)の上位ノードまでの、すべてのノードに結びつくすべての RR である。

Though logically part of the authoritative data, the RRs that describe the top node of the zone are especially important to the zone's management. These RRs are of two types: name server RRs that list, one per RR, all of the servers for the zone, and a single SOA RR that describes zone management parameters. 権威情報の論理部分ではあるが、ゾーンのトップノードを記述する RR はそのゾーンの管理のために特に重要である。これらの RR には二種類が存在する:ゾーンのすべてのサーバーを(RR ごとにひとつ)リストするネームサーバー RR と、ゾーン管理パラメータを記述するひとつの SOA RR である。

The RRs that describe cuts around the bottom of the zone are NS RRs that name the servers for the subzones. Since the cuts are between nodes, these RRs are NOT part of the authoritative data of the zone, and should be exactly the same as the corresponding RRs in the top node of the subzone. Since name servers are always associated with zone boundaries, NS RRs are only found at nodes which are the top node of some zone. In the data that makes up a zone, NS RRs are found at the top node of the zone (and are authoritative) and at cuts around the bottom of the zone (where they are not authoritative), but never in between. ゾーンの下位の断片(cuts)を記述する RR は、その下位ゾーンのためのサーバーを指名する NS RR である。断片(cuts)はノードの間にあるため、これらの RR はそのゾーンの権威情報の一部ではなく、その下位ゾーンのトップノード内の対応する RR と正確に一致するべきである。ネームサーバーは常にゾーン境界に対応するため、NS RR はゾーンのトップノードであるノードにおいてのみ見つけられる。ゾーンを構成する情報において、NS RR はそのゾーンのトップノード(それらは権威を持つ)とそのゾーンの下位の断片(cuts)(それらは権威を持たない)とに見つけられるが、その間に見つかることはない。

One of the goals of the zone structure is that any zone have all the data required to set up communications with the name servers for any subzones. That is, parent zones have all the information needed to access servers for their children zones. The NS RRs that name the servers for subzones are often not enough for this task since they name the servers, but do not give their addresses. In particular, if the name of the name server is itself in the subzone, we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn. To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response. ゾーン構造の目的のひとつは、すべてのゾーンが、そのすべての下位ゾーンのネームサーバーと通信するために必要とされるすべての情報を持つというものである。つまり親ゾーンが、その子ゾーンのサーバーにアクセスすために必要とされるすべての情報を持つということである。下位ゾーンのサーバーを指定する NS RR はこの目的に十分ではない。なぜなら、それはサーバーを指名するが、アドレスを提示しないためである。具体的に言うと、ネームサーバーの名前自体がそのサブゾーン内にある場合、NS RR からネームサーバーのアドレスを知るには、その知りたいアドレスを使ってサーバーとコンタクトをとらなければならないという状況が起こりうる。ゾーンはこの問題を解決するために、権威情報の一部ではなく、かつそのサーバーのためのアドレス RR である "グルー(glue)" RR を含む。これらの RR は、そのネームサーバーが断片(cut)の "下位(below)" にある場合にのみ必要とされ、参照応答の一部としてのみ使用される。

4.2.2. Administrative considerations 4.2.2. 管理上の考慮事項

When some organization wants to control its own domain, the first step is to identify the proper parent zone, and get the parent zone's owners to agree to the delegation of control. While there are no particular technical constraints dealing with where in the tree this can be done, there are some administrative groupings discussed in [RFC-1032] which deal with top level organization, and middle level zones are free to create their own rules. For example, one university might choose to use a single zone, while another might choose to organize by subzones dedicated to individual departments or schools. [RFC-1033] catalogs available DNS software an discusses administration procedures. ある組織が独自ドメインの管理を望む場合、その第一歩は、適切な親ゾーンを特定し、その親ゾーンの所有者から管理委譲の同意を得ることである。これを行うツリー内の位置を交渉するのに技術的な制限は無いが、トップレベルの編成には [RFC-1032] で議論されている管理上のグループ分けが存在し、中間レベルのゾーンは自由に独自の規則を作成できる。例えば、ある大学は単一のゾーンを使用することを選択し、一方で別の大学は個々の学部や学科のために設けられたサブゾーンによって組織化することを選択してもよい。[RFC-1033] は、利用可能な DNS ソフトウェアと管理手続きとを列記している。

Once the proper name for the new subzone is selected, the new owners should be required to demonstrate redundant name server support. Note that there is no requirement that the servers for a zone reside in a host which has a name in that domain. In many cases, a zone will be more accessible to the internet at large if its servers are widely distributed rather than being within the physical facilities controlled by the same organization that manages the zone. For example, in the current DNS, one of the name servers for the United Kingdom, or UK domain, is found in the US. This allows US hosts to get UK data without using limited transatlantic bandwidth. 新しいサブゾーンのための適切な名前が選択さた時点で、その新しい所有者は、冗長なネームサーバーのサポートを明らかにすることを要求されるべきである。あるゾーンのためのサーバーが、そのドメイン内に名前を持つホスト上に存在する必要はないことに注意してほしい。あるゾーンのサーバーがそのゾーンを管理する同じ組織によって管理される物理的な施設内にある場合よりも、広く分散された場合の方が、インターネットへのより広範囲のアクセス性を持つだろう。例えば今現在の DNS において、英国または UK ドメインのためのネームサーバーのひとつは、アメリカ合衆国内にある。これによりアメリカ合衆国のホストは、大西洋を横断する限られた帯域を使用することなく、UK ドメインの情報を取得することができる。

As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. 導入の最終段階として、委譲を有効にするために必要な委譲 NS RR とグルー RR とを親ゾーンに追加しなければならない。両ゾーンの管理者は、その断片(cut)の両サイドを記録する NS と グルー RR とが一貫性を持ち続けることを保証しなければならない。

4.3. Name server internals 4.3. ネームサーバー内部

4.3.1. Queries and responses 4.3.1. 問合せと応答

The principal activity of name servers is to answer standard queries. Both the query and its response are carried in a standard message format which is described in [RFC-1035]. The query contains a QTYPE, QCLASS, and QNAME, which describe the types and classes of desired information and the name of interest. ネームサーバーの主要な働きは、標準問合せに答えることである。問合せとその応答とは共に、[RFC-1035] で説明されている標準メッセージフォーマットで転送される。問合せは QTYPE・QCLASS・QNAME を含み、それぞれ目的とする情報のタイプ、クラス、関心を持っている名前を表す。

The way that the name server answers the query depends upon whether it is operating in recursive mode or not: ネームサーバーが問合せに答える方法は、それが再帰モードで動作しているかどうかに依存する:

Recursive service is helpful in several situations: 再帰サービスはさまざまな状況で役に立つ:

Non-recursive service is appropriate if the requester is capable of pursuing referrals and interested in information which will aid future requests. リクエスタが参照を追跡する能力を持ち、今後のリクエストの手助けとなる情報に関心がある場合、非再帰サービスが適切である。

The use of recursive mode is limited to cases where both the client and the name server agree to its use. The agreement is negotiated through the use of two bits in query and response messages: 再帰モードの使用は、クライアントとネームサーバーとが共に合意した場合に限られる。この合意は、問合せメッセージと応答メッセージとにおける二つのビットを通して交渉される:

The recursive mode occurs when a query with RD set arrives at a server which is willing to provide recursive service; the client can verify that recursive mode was used by checking that both RA and RD are set in the reply. Note that the name server should never perform recursive service unless asked via RD, since this interferes with trouble shooting of name servers and their databases. RD をセットされた問合せが再帰サービスを提供する意思のあるサーバーに到着したとき、再帰モードが発動する。クライアントは、応答の RA と RD とが両方セットされているのを確認することで、再帰モードが使用されたことを確認できる。RD によって問い合わせられない限り、ネームサーバーは再帰サービスを実行するべきではない。なぜなら、ネームサーバーとそのデータベースとのトラブルシューティングを妨げるためである。

If recursive service is requested and available, the recursive response to a query will be one of the following: 再帰サービスが要求され、かつ有効である場合、問合せに対する再帰応答は以下の何れかとなる:

If recursive service is not requested or is not available, the non- recursive response will be one of the following: 再帰サービスが要求されなかったか、有効でなかった場合、非再帰応答は以下の何れかとなる:

4.3.2. Algorithm 4.3.2. アルゴリズム

The actual algorithm used by the name server will depend on the local OS and data structures used to store RRs. The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache: ネームサーバーが実際に使用するアルゴリズムは、ローカル OS と RR を保存するために使用するデータ構造とに依存するだろう。以下のアルゴリズムは、RR がいくつかのツリー構造(ひとつは各ゾーンのため、もうひとつはキャッシュのため)で編成されていると仮定している:

4.3.3. Wildcards 4.3.3. ワイルドカード

In the previous algorithm, special treatment was given to RRs with owner names starting with the label "*". Such RRs are called wildcards. Wildcard RRs can be thought of as instructions for synthesizing RRs. When the appropriate conditions are met, the name server creates RRs with an owner name equal to the query name and contents taken from the wildcard RRs. 前述のアルゴリズムにおいて、ラベル "*" から始まる所有者名を持つ RR に対して特別な扱いをした。このような RR はワイルドカードと呼ばれる。ワイルドカード RR は、RR を合成する指示と考えることができる。適切な条件が満たされたとき、ネームサーバーは問合せ名に等しい所有者名と内容とをワイルドカード RR から取り出し、RR を生成する。

This facility is most often used to create a zone which will be used to forward mail from the Internet to some other mail system. The general idea is that any name in that zone which is presented to server in a query will be assumed to exist, with certain properties, unless explicit evidence exists to the contrary. Note that the use of the term zone here, instead of domain, is intentional; such defaults do not propagate across zone boundaries, although a subzone may choose to achieve that appearance by setting up similar defaults. この仕組みがもっともよく使用されるのは、インターネットからのメールを別のメールシステムに転送するためのゾーンを生成する場合である。その概念は、問合せにおいてサーバーに提示されたゾーン内の任意の名前は、明確な反証がない限り一定の属性を持って存在しているだろうということである。ここでドメインではなくゾーンという言葉を意図的に使用していることに注意してほしい。このような初期値がゾーン境界をまたがることはないが、サブゾーンが同じような初期値を設定することで同じことを実現する可能性がある。

The contents of the wildcard RRs follows the usual rules and formats for RRs. The wildcards in the zone have an owner name that controls the query names they will match. The owner name of the wildcard RRs is of the form "*.<anydomain>", where <anydomain> is any domain name. <anydomain> should not contain other * labels, and should be in the authoritative data of the zone. The wildcards potentially apply to descendants of <anydomain>, but not to <anydomain> itself. Another way to look at this is that the "*" label always matches at least one whole label and sometimes more, but always whole labels. ワイルドカード RR の内容は、RR のための通常の規則とフォーマットとにしたがう。ゾーン内のワイルドカードは、一致した問合せ名を制御する所有者名を持つ。ワイルドカード RR の所有者名は "*.<anydomain>" の形式である(<anydomain> は任意のドメイン名)。<anydomain> は別の * を含むべきではなく、そのゾーンの権威情報内に存在するべきである。ワイルドカードは潜在的に <anydomain> の子孫に適用されるが、<anydomain> 自身には適用されない。別の見方をすると、ラベル "*" は、常に少なくともひとつ以上の完全なラベルに一致するが、常にラベル群全体に一致するということである。

Wildcard RRs do not apply: 以下の場合、ワイルドカード RR は適用されない:

A * label appearing in a query name has no special effect, but can be used to test for wildcards in an authoritative zone; such a query is the only way to get a response containing RRs with an owner name with * in it. The result of such a query should not be cached. 問合せ名の中に現れるラベル * は特別な効果を持たないが、権威ゾーン内のワイルドカードをテストするために使用することができる。このような問合せは、所有者名に * を持つ RR を含む応答を取得する唯一の手段である。この種の問合せの結果はキャッシュされるべきではない。

Note that the contents of the wildcard RRs are not modified when used to synthesize RRs. RR の合成に使用されるとき、ワイルドカード RR の内容は修正されないことに注意してほしい。

To illustrate the use of wildcard RRs, suppose a large company with a large, non-IP/TCP, network wanted to create a mail gateway. If the company was called X.COM, and IP/TCP capable gateway machine was called A.X.COM, the following RRs might be entered into the COM zone: ワイルドカード RR の使用方法を説明するために、非 IP/TCP の大きいネットワークを持つ大企業がメールゲートウェイを作成したい場合を考える。その企業を X.COM とし、IP/TCP 能力のあるゲートウェイマシンを A.X.COM とすると、以下の RR が COM ゾーンに入れられるだろう:

    X.COM           MX      10      A.X.COM

    *.X.COM         MX      10      A.X.COM

    A.X.COM         A       1.2.3.4
    A.X.COM         MX      10      A.X.COM

    *.A.X.COM       MX      10      A.X.COM

This would cause any MX query for any domain name ending in X.COM to return an MX RR pointing at A.X.COM. Two wildcard RRs are required since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM subtree by the explicit data for A.X.COM. Note also that the explicit MX data at X.COM and A.X.COM is required, and that none of the RRs above would match a query name of XX.COM. これにより、X.COM で終わるすべてのドメイン名に対する MX 問合せに対し、A.X.COM を指す MX RR が返されることになる。A.X.COM のための明示的な情報があるため、*.X.COM のワイルドカードの効果はサブツリー A.X.COM に対しては抑制される。そのため、二つのワイルドカード RR が必要となる。X.COM と A.X.COM とにおける明示的な MX 情報が必要であること、上記の RR は問合せ名 XX.COM には一致しないことに注意してほしい。

4.3.4. Negative response caching (Optional) 4.3.4. 否定応答キャッシュ(オプション)

The DNS provides an optional service which allows name servers to distribute, and resolvers to cache, negative results with TTLs. For example, a name server can distribute a TTL along with a name error indication, and a resolver receiving such information is allowed to assume that the name does not exist during the TTL period without consulting authoritative data. Similarly, a resolver can make a query with a QTYPE which matches multiple types, and cache the fact that some of the types are not present. DNS はオプションで、TTL を持つ否定結果をネームサーバーが配布したりリゾルバがキャッシュしたりすることを許可するサービスを提供する。例えばネームサーバーは名前エラーと共に TTL を配布することが可能であり、そのような情報を受け取ったリゾルバは、その TTL の間は権威情報を確認することなくその名前が存在しないと仮定することが許される。同じように、リゾルバは複数のタイプに一致する QTYPE を持つ問合せを生成し、一部のタイプが存在しないという結果をキャッシュすることができる。

This feature can be particularly important in a system which implements naming shorthands that use search lists beacuse a popular shorthand, which happens to require a suffix toward the end of the search list, will generate multiple name errors whenever it is used. よく知られた省略形(たまたま検索リストの終わりに接尾辞を必要とする)は、使用されると常に複数のエラーを生成する。そのためこの機能は、検索リストを使用する省略形の命名を実装するシステムにおいて特に重要となり得る。

The method is that a name server may add an SOA RR to the additional section of a response when that response is authoritative. The SOA must be that of the zone which was the source of the authoritative data in the answer section, or name error if applicable. The MINIMUM field of the SOA controls the length of time that the negative result may be cached. この方法は、ネームサーバーが権威ある応答を返すとき、その応答の Authority セクションに SOA RR を追加することを許可するものである。SOA は Answer セクションの権威情報、またはネームエラーの発生源であったゾーンのものでなければならない。SOA の MINIMUM フィールドは、その否定結果をキャッシュしてよい期間を制御する。
(訳注:1 文目、原文では「Additional section」となっていますが、RFC 2181 にて「Authority section」と訂正されています。この翻訳ではその訂正を反映しています。)

Note that in some circumstances, the answer section may contain multiple owner names. In this case, the SOA mechanism should only be used for the data which matches QNAME, which is the only authoritative data in this section. 環境によっては Answer セクションに複数の所有者名が含まれる可能性があることに注意してほしい。その場合この SOA のメカニズムは、このセクションの中の唯一の権威情報である QNAME に一致する情報のためにのみ使用されるべきである。

Name servers and resolvers should never attempt to add SOAs to the additional section of a non-authoritative response, or attempt to infer results which are not directly stated in an authoritative response. There are several reasons for this, including: cached information isn't usually enough to match up RRs and their zone names, SOA RRs may be cached due to direct SOA queries, and name servers are not required to output the SOAs in the authority section. ネームサーバーとリゾルバとは、権威のない応答の Authority セクションに SOA を追加しようと試みたり、権威ある応答に直接示されていない結果を推測しようと試みたりするべきではない。これにはいくつかの理由がある:キャッシュされた情報は RR およびそのゾーン名と比較するのに十分ではないこと、SOA RR は直接の SOA 問合せによってキャッシュされる可能性があること、ネームサーバーは Authority セクションに SOA を出力することを要求されないこと。
(訳注:1 文目、原文では「Additional section」となっていますが、RFC 2181 にて「Authority section」と訂正されています。この翻訳ではその訂正を反映しています。)

This feature is optional, although a refined version is expected to become part of the standard protocol in the future. Name servers are not required to add the SOA RRs in all authoritative responses, nor are resolvers required to cache negative results. Both are recommended. All resolvers and recursive name servers are required to at least be able to ignore the SOA RR when it is present in a response. この機能はオプションだが、将来洗練されたバージョンが標準プロトコルの一部になることが期待される。ネームサーバーは権威応答に SOA RR を追加することを要求されないし、リゾルバは否定結果をキャッシュすることを要求されない。これらは共に推奨事項である。すべてのリゾルバと再帰ネームサーバーとは、応答内に SOA RR が現れたとき、少なくともそれらを無視できることを要求される。

Some experiments have also been proposed which will use this feature. The idea is that if cached data is known to come from a particular zone, and if an authoritative copy of the zone's SOA is obtained, and if the zone's SERIAL has not changed since the data was cached, then the TTL of the cached data can be reset to the zone MINIMUM value if it is smaller. This usage is mentioned for planning purposes only, and is not recommended as yet. また、この機能を使用するいくつかの実験が提案されている。その着想は、キャッシュされた情報が特定のゾーンから来たことが分かっており、かつそのゾーンの SOA の権威あるコピーを取得しており、さらにそのゾーンの SERIAL がキャッシュされてから変更されていない場合、そのキャッシュされた情報の TTL を(それがそのゾーンの MINIMUM の値より小さい場合に)そのゾーンの MINIMUM の値にリセットするというものである。この使用方法は予定として言及されているだけであり、今のところ推奨事項ではない。

4.3.5. Zone maintenance and transfers 4.3.5. ゾーンの保守と転送

Part of the job of a zone administrator is to maintain the zones at all of the name servers which are authoritative for the zone. When the inevitable changes are made, they must be distributed to all of the name servers. While this distribution can be accomplished using FTP or some other ad hoc procedure, the preferred method is the zone transfer part of the DNS protocol. ゾーン管理者の仕事の一部は、そのゾーンに権威を持つすべてのネームサーバーの保守である。避けられない変更が行われるとき、それはすべてのネームサーバーに配布されなければならない。この配布は FTP または他の任意の方法により実現できるが、DNS プロトコルのゾーン転送による方法が好ましい。

The general model of automatic zone transfer or refreshing is that one of the name servers is the master or primary for the zone. Changes are coordinated at the primary, typically by editing a master file for the zone. After editing, the administrator signals the master server to load the new zone. The other non-master or secondary servers for the zone periodically check for changes (at a selectable interval) and obtain new zone copies when changes have been made. ゾーンの自動転送または自動リフレッシュの一般的モデルは、ネームサーバーのひとつがゾーンのマスターまたはプライマリになるというものである。一般に変更とはそのゾーンのマスターファイルを編集することであり、プライマリサーバー上で行われる。編集後、管理者はマスターサーバーに新しいゾーンの読み込みを指示する。他の非マスターまたはセカンダリのサーバーは変更を定期的(間隔は指定可能)に確認し、変更が行われていれば新しいゾーンのコピーを取得する。

To detect changes, secondaries just check the SERIAL field of the SOA for the zone. In addition to whatever other changes are made, the SERIAL field in the SOA of the zone is always advanced whenever any change is made to the zone. The advancing can be a simple increment, or could be based on the write date and time of the master file, etc. The purpose is to make it possible to determine which of two copies of a zone is more recent by comparing serial numbers. Serial number advances and comparisons use sequence space arithmetic, so there is a theoretic limit on how fast a zone can be updated, basically that old copies must die out before the serial number covers half of its 32 bit range. In practice, the only concern is that the compare operation deals properly with comparisons around the boundary between the most positive and most negative 32 bit numbers. 変更を検出するために、セカンダリサーバーはそのゾーンの SOA の SERIAL フィールドのみを確認する。変更が加えられる場合、常に同時にそのゾーンの SOA の SERIAL フィールドの値が増やされる。この増加は、単純なインクリメントや、マスターファイルの書き込み日時に基づく方法で行うことができる。目的は、シリアル番号の比較によりゾーンの二つのコピーのどちらが新しいかを判断できるようにすることである。シリアル番号の増加と比較とにはシリアル番号演算が使用される。そのため、ゾーンを更新できる速さには論理的限界があり、基本的にシリアル値が 32 ビット範囲の半分を使い切る前に、古いコピーは消滅しなければならない。現実問題として唯一の懸念事項は、この比較演算が 32 ビット値の正の最大値と負の最大値との近辺の比較を適切に扱えるかどうかである。

The periodic polling of the secondary servers is controlled by parameters in the SOA RR for the zone, which set the minimum acceptable polling intervals. The parameters are called REFRESH, RETRY, and EXPIRE. Whenever a new zone is loaded in a secondary, the secondary waits REFRESH seconds before checking with the primary for a new serial. If this check cannot be completed, new checks are started every RETRY seconds. The check is a simple query to the primary for the SOA RR of the zone. If the serial field in the secondary's zone copy is equal to the serial returned by the primary, then no changes have occurred, and the REFRESH interval wait is restarted. If the secondary finds it impossible to perform a serial check for the EXPIRE interval, it must assume that its copy of the zone is obsolete an discard it. セカンダリサーバーによる定期的なポーリングは、そのゾーンの SOA RR 内のパラメータによって制御され、そのパラメータには受け入れられる最低のポーリング間隔がセットされる。そのパラメータは REFRESH、RETRY、EXPIRE と呼ばれるものである。セカンダリに新しいゾーンが読み込まれたときにはいつでも、プライマリの新しいシリアル値を確認する前に、セカンダリは REFRESH 秒だけ待機する。確認を完了できなかった場合、新しい確認は RETRY 秒ごとに開始される。この確認は、そのゾーンの SOA RR をプライマリに求める単純な問合せである。セカンダリの持つゾーンのコピーの SERIAL フィールドがプライマリによって返されたシリアル値と同じ場合、変更は行われていないということであり、REFRESH 秒間の待機が再び開始される。EXPIRE 秒のあいだシリアル値の確認を実行できないことを検出したセカンダリは、そのゾーンのコピーがもはや使用されていないものと判断し、破棄しなければならない。

When the poll shows that the zone has changed, then the secondary server must request a zone transfer via an AXFR request for the zone. The AXFR may cause an error, such as refused, but normally is answered by a sequence of response messages. The first and last messages must contain the data for the top authoritative node of the zone. Intermediate messages carry all of the other RRs from the zone, including both authoritative and non-authoritative RRs. The stream of messages allows the secondary to construct a copy of the zone. Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests. ポーリングによりそのゾーンが変更されていることが分かった場合、セカンダリサーバーはそのゾーンに対し AXFR リクエストによるゾーン転送を要求しなければならない。最初と最後のメッセージは、そのゾーンの権威ある最上位ノードのための情報を含まなければならない。そのあいだのメッセージで、そのゾーンの他の RR (権威 RR も非権威 RR も含めて)のすべてを伝える。その一連のメッセージにより、セカンダリサーバーはそのゾーンのコピーを作成することができる。正確さが必須であるため、AXFR リクエストには TCP または他の信頼できるプロトコルを使用しなければならない。

Each secondary server is required to perform the following operations against the master, but may also optionally perform these operations against other secondary servers. This strategy can improve the transfer process when the primary is unavailable due to host downtime or network problems, or when a secondary server has better network access to an "intermediate" secondary than to the primary. 各セカンダリサーバーはマスターサーバーに追随する動作を要求されるが、任意で他のセカンダリサーバーに対してこれらの操作を実行してもよい。この戦略は、ホストの故障またはネットワークの問題によりプライマリを利用できない場合や、セカンダリサーバーが "中間の(intermediate)" セカンダリに対してプライマリよりも優れたネットワークアクセス性を持っている場合に、転送プロセスを改善する。

5. RESOLVERS 5. リゾルバ

5.1. Introduction 5.1. 導入

Resolvers are programs that interface user programs to domain name servers. In the simplest case, a resolver receives a request from a user program (e.g., mail programs, TELNET, FTP) in the form of a subroutine call, system call etc., and returns the desired information in a form compatible with the local host's data formats. リゾルバは、ユーザープログラムをドメインネームサーバーにインターフェイスするプログラムである。もっとも単純な場合、リゾルバはユーザープログラム(例えばメールプログラム、TELNET、FTP)からサブルーチンコールやシステムコールなどの形でリクエストを受け取り、求められた情報をローカルホストのデータフォーマットと互換性のある形式で返す。

The resolver is located on the same machine as the program that requests the resolver's services, but it may need to consult name servers on other hosts. Because a resolver may need to consult several name servers, or may have the requested information in a local cache, the amount of time that a resolver will take to complete can vary quite a bit, from milliseconds to several seconds. リゾルバはサービスを要求するプログラムと同じマシン上に位置するが、他ホスト上のネームサーバーの参照を必要とする可能性がある。リゾルバは複数のネームサーバーの参照を必要としたり、要求された情報をローカルキャッシュに保持していたりする可能性があるため、リゾルバが処理を完了するのに要する時間は、数ミリ秒から数秒まで、相当に異なる可能性がある。

A very important goal of the resolver is to eliminate network delay and name server load from most requests by answering them from its cache of prior results. It follows that caches which are shared by multiple processes, users, machines, etc., are more efficient than non-shared caches. リゾルバの特に重要な目的は、大部分のリクエストに過去の結果のキャッシュから回答することで、ネットワークの遅延とネームサーバーの負荷とを削減することである。つまり、複数のプロセス・ユーザー・マシンなどにより共有されるキャッシュは、共有されないキャッシュよりも効率的ということである。

5.2. Client-resolver interface 5.2. クライアント-リゾルバ インターフェイス

5.2.1. Typical functions 5.2.1. 代表的な機能

The client interface to the resolver is influenced by the local host's conventions, but the typical resolver-client interface has three functions: リゾルバに対するクライアントインターフェイスはローカルホストの習慣に影響されるが、典型的なリゾルバ-クライアントインターフェイスは三つの機能を持つ:

When the resolver performs the indicated function, it usually has one of the following results to pass back to the client: 通常、リゾルバが指示された機能を実行したとき、クライアントに以下の結果のひとつが返される:

It is important to note that the functions for translating between host names and addresses may combine the "name error" and "data not found" error conditions into a single type of error return, but the general function should not. One reason for this is that applications may ask first for one type of information about a name followed by a second request to the same name for some other type of information; if the two errors are combined, then useless queries may slow the application. ホスト名とアドレスとの変換機能は、"名前エラー(name error)" と "情報なしエラー(data not found)" とを単独の種類のエラーにまとめて返してもよいが、汎用検索機能ではそうでないことに注意してほしい。その理由のひとつは、アプリケーションは名前に付いて最初にひとつの情報タイプを問合せ、続いて他の情報タイプを問い合わせる可能性があるためである。二つのエラーが併せて返された場合、無駄な問合せがアプリケーションの速度を低下させる可能性がある。

5.2.2. Aliases 5.2.2. エイリアス

While attempting to resolve a particular request, the resolver may find that the name in question is an alias. For example, the resolver might find that the name given for host name to address translation is an alias when it finds the CNAME RR. If possible, the alias condition should be signalled back from the resolver to the client. リゾルバは、リクエストを解決しようとしている間に、問題の名前がエイリアスであることを知る可能性がある。例えばリゾルバが CNAME RR を見つけたとき、ホスト名からアドレスへの変換に与えられた名前がエイリアスであることを知るかもしれない。可能なら、エイリアスであるということがリゾルバからクライアントに返されるべきである。

In most cases a resolver simply restarts the query at the new name when it encounters a CNAME. However, when performing the general function, the resolver should not pursue aliases when the CNAME RR matches the query type. This allows queries which ask whether an alias is present. For example, if the query type is CNAME, the user is interested in the CNAME RR itself, and not the RRs at the name it points to. リゾルバが CNAME に遭遇したとき、たいていは単純にその新しい名前で問合せを再開する。しかしながら汎用検索機能を実行している場合、CNAME RR が問合せタイプに一致するのであれば、リゾルバはエイリアスを追跡しないべきである。これにより、エイリアスが存在しているかどうかを尋ねる問合せが可能となる。例えば問合せタイプが CNAME の場合、ユーザーはその名前が指す RR ではなく、CNAME RR そのものに関心がある。

Several special conditions can occur with aliases. Multiple levels of aliases should be avoided due to their lack of efficiency, but should not be signalled as an error. Alias loops and aliases which point to non-existent names should be caught and an error condition passed back to the client. エイリアスにはいくつかの特殊な状況が発生し得る。多段階のエイリアスは非効率なため避けるべきだが、エラーとして報告されるべきではない。エイリアスのループや存在しない名前を指すエイリアスは検出され、クライアントにエラー状態として返されるべきである。

5.2.3. Temporary failures 5.2.3. 一時的障害

In a less than perfect world, all resolvers will occasionally be unable to resolve a particular request. This condition can be caused by a resolver which becomes separated from the rest of the network due to a link failure or gateway problem, or less often by coincident failure or unavailability of all servers for a particular domain. 世の中は完全ではないので、リゾルバが特定のリクエストを解決できない場合もある。そのような状況は、回線障害やゲートウェイの不具合のためにリゾルバが他のネットワークから孤立した場合や、可能性は低いものの、ある特定のドメインのためのすべてのサーバーが同時に故障または利用不能になった場合に起こり得る。

It is essential that this sort of condition should not be signalled as a name or data not present error to applications. This sort of behavior is annoying to humans, and can wreak havoc when mail systems use the DNS. この状態は、名前または情報が存在しないというエラーとしてアプリケーションに通知されるべきではない。そのような動作は人間を悩ませるうえ、メールシステムが DNS を使用している場合には大きな混乱をもたらす可能性がある。

While in some cases it is possible to deal with such a temporary problem by blocking the request indefinitely, this is usually not a good choice, particularly when the client is a server process that could move on to other tasks. The recommended solution is to always have temporary failure as one of the possible results of a resolver function, even though this may make emulation of existing HOSTS.TXT functions more difficult. リクエストを永久に遮断することでこの種の一時的な問題に対処することも場合によっては可能だが、あまりよい選択ではない。クライアントが他のタスクに繋がるサーバープロセスの場合は特にそうである。推奨される解決法は一時的障害をリゾルバ関数の結果のひとつとして持つことだが、これは既存の HOSTS.TXT の機能の模倣をより困難にする可能性がある。

5.3. Resolver internals 5.3. リゾルバ内部

Every resolver implementation uses slightly different algorithms, and typically spends much more logic dealing with errors of various sorts than typical occurances. This section outlines a recommended basic strategy for resolver operation, but leaves details to [RFC-1035]. すべてのリゾルバ実装は若干異なるアルゴリズムを使用し、一般に、典型的な状況よりも様々なエラーを扱うためにより多くのロジックを費やす。このセクションではリゾルバの運用に推奨される基本的な戦略の概要を説明するが、詳細は [RFC-1035] を参照してほしい。

5.3.1. Stub resolvers 5.3.1. スタブリゾルバ

One option for implementing a resolver is to move the resolution function out of the local machine and into a name server which supports recursive queries. This can provide an easy method of providing domain service in a PC which lacks the resources to perform the resolver function, or can centralize the cache for a whole local network or organization. リゾルバを実装する場合のひとつの選択肢は、解決機能をローカルマシンの外に出し、再帰問合せをサポートするネームサーバーの中に移すことである。これは、リゾルバ機能を実行するリソースを持たない PC にドメインサービスを提供する簡単な方法であり、また、ローカルネットワークまたは組織全体のキャッシュを中央に集中させることができる。

All that the remaining stub needs is a list of name server addresses that will perform the recursive requests. This type of resolver presumably needs the information in a configuration file, since it probably lacks the sophistication to locate it in the domain database. The user also needs to verify that the listed servers will perform the recursive service; a name server is free to refuse to perform recursive services for any or all clients. The user should consult the local system administrator to find name servers willing to perform the service. 他にスタブが必要とするものは、再帰リクエストを実行するネームサーバーの一覧だけである。おそらくこの種のリゾルバはドメインデータベース内でそれを探すための高度な機能を持たないため、構成ファイル内にその情報を必要とするだろう。ネームサーバーは任意の、またはすべてのクライアントに対して再帰サービスの実行を拒否することができるため、ユーザーはリストされたサーバーが再帰サービスを実行できるかどうかを確認する必要がある。ユーザーはサービスを実行する意思のあるネームサーバーを見つけるために、システム管理者に相談するべきである。

This type of service suffers from some drawbacks. Since the recursive requests may take an arbitrary amount of time to perform, the stub may have difficulty optimizing retransmission intervals to deal with both lost UDP packets and dead servers; the name server can be easily overloaded by too zealous a stub if it interprets retransmissions as new requests. Use of TCP may be an answer, but TCP may well place burdens on the host's capabilities which are similar to those of a real resolver. この種のサービスはいくつかの欠点に苦しむことになる。再帰リクエストの実行時間は不定であるため、UPD パケットの喪失とサーバー障害とを扱うための再送信間隔の最適化には困難が伴なう。熱心なスタブによる新しいリクエストに割り込まれることで、ネームサーバーは簡単に過負荷状態になる。TCP の使用がその解決策となるかもしれないが、TCP は本物のリゾルバと同等の負荷をそのホストにかけることになるだろう。

5.3.2. Resources 5.3.2. リソース

In addition to its own resources, the resolver may also have shared access to zones maintained by a local name server. This gives the resolver the advantage of more rapid access, but the resolver must be careful to never let cached information override zone data. In this discussion the term "local information" is meant to mean the union of the cache and such shared zones, with the understanding that authoritative data is always used in preference to cached data when both are present. リゾルバは自身のリソースに加え、ローカルのネームサーバーによって維持されるゾーンへのアクセスを共有してよい。これはより迅速なアクセスという利点をリゾルバに与えるが、リゾルバはキャッシュ情報がゾーン情報に優先しないよう注意しなければならない。この議論における "ローカル情報(local information)" という用語は、キャッシュ情報と権威情報とが共に存在する場合には権威情報が優先されるという了解のもと、キャッシュと共有されたゾーンとの集合を意味することを意図している。

The following resolver algorithm assumes that all functions have been converted to a general lookup function, and uses the following data structures to represent the state of a request in progress in the resolver: 以下のリゾルバアルゴリズムは、すべての機能が汎用検索機能に変換されたものと仮定しており、リゾルバ内で進行中のリクエストの状態を表すために以下のデータ構造を使用する:

SNAME
the domain name we are searching for. 探しているドメイン名
STYPE
the QTYPE of the search request. 検索リクエストの QTYPE。
SCLASS
the QCLASS of the search request. 検索リクエストの QCLASS。
SLIST
a structure which describes the name servers and the zone which the resolver is currently trying to query. This structure keeps track of the resolver's current best guess about which name servers hold the desired information; it is updated when arriving information changes the guess. This structure includes the equivalent of a zone name, the known name servers for the zone, the known addresses for the name servers, and history information which can be used to suggest which server is likely to be the best one to try next. The zone name equivalent is a match count of the number of labels from the root down which SNAME has in common with the zone being queried; this is used as a measure of how "close" the resolver is to SNAME. リゾルバが現在問合せを試みているネームサーバーとゾーンとを記述する構造体。この構造体は、どのネームサーバーが目的の情報を保持しているかに関して、リゾルバの現在の最善の予測を記録し、その予測を変更する情報が届くと更新される。この構造体は、ゾーン名一致数、そのゾーンのための既知のネームサーバー、そのネームサーバーのための既知のアドレス、そして、次に試みるのに最適と思われるサーバーを示すために使用できる履歴情報を含む。ゾーン名一致数は、問合せられたゾーンと SNAME とで共有するルートからのラベルの一致数である。これは、リゾルバが SNAME にどれだけ "近い(close)" かの尺度として使用される。
SBELT
a "safety belt" structure of the same form as SLIST, which is initialized from a configuration file, and lists servers which should be used when the resolver doesn't have any local information to guide name server selection. The match count will be -1 to indicate that no labels are known to match. SLIST と同じ形式の "安全ベルト(safety belt)" 構造体で、構成ファイルにより初期化される。これは、リゾルバがネームサーバーの選択を導くためのローカル情報を何も持たないときに使用するサーバーのリストである。SBELT の一致数は、一致したことの分かっているラベルがないことを表す -1 になるだろう。
CACHE
A structure which stores the results from previous responses. Since resolvers are responsible for discarding old RRs whose TTL has expired, most implementations convert the interval specified in arriving RRs to some sort of absolute time when the RR is stored in the cache. Instead of counting the TTLs down individually, the resolver just ignores or discards old RRs when it runs across them in the course of a search, or discards them during periodic sweeps to reclaim the memory consumed by old RRs. 直前の応答の結果を保持する構造体。リゾルバは TTL の切れた古い RR を破棄する責任を持つため、RR がキャッシュに保持されたとき、大部分の実装はその RR に指定されている間隔を何らかの絶対時刻に変換する。リゾルバは TTL を個別にカウントダウンする代わりに、検索の過程で古い RR を無視または破棄するか、古い RR により消費されたメモリを再要求するための定期的なメモリ解放の間に破棄すればよい。

5.3.3. Algorithm 5.3.3. アルゴリズム

The top level algorithm has four steps: 最上位レベルのアルゴリズムは 4 つのステップを持つ:

Step 1 searches the cache for the desired data. If the data is in the cache, it is assumed to be good enough for normal use. Some resolvers have an option at the user interface which will force the resolver to ignore the cached data and consult with an authoritative server. This is not recommended as the default. If the resolver has direct access to a name server's zones, it should check to see if the desired data is present in authoritative form, and if so, use the authoritative data in preference to cached data. ステップ 1 では目的の情報をキャッシュから検索する。キャッシュ内に情報が見つかった場合、それは通常の使用に十分であると見なされる。一部のリゾルバは、ユーザーがリゾルバにキャッシュ情報を無視させ、権威サーバーに尋ねることを強制するユーザーインターフェイスのオプションを持つ。これはデフォルトとしては推奨されない。リゾルバがネームサーバーのゾーンに直接アクセスできる場合、目的の情報が権威を持つ形で提供されているかどうかを確認し、もしそうであれば、キャッシュ情報に優先してその権威情報を使用するべきである。

Step 2 looks for a name server to ask for the required data. The general strategy is to look for locally-available name server RRs, starting at SNAME, then the parent domain name of SNAME, the grandparent, and so on toward the root. Thus if SNAME were Mockapetris.ISI.EDU, this step would look for NS RRs for Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root). These NS RRs list the names of hosts for a zone at or above SNAME. Copy the names into SLIST. Set up their addresses using local data. It may be the case that the addresses are not available. The resolver has many choices here; the best is to start parallel resolver processes looking for the addresses while continuing onward with the addresses which are available. Obviously, the design choices and options are complicated and a function of the local host's capabilities. The recommended priorities for the resolver designer are: ステップ 2 では要求された情報を尋ねるべきネームーサーバーを探す。一般的な戦略は、ローカルで利用可能なネームサーバー RR を、SNAME から始め、SNAME の親ドメイン、そのまた親のドメインと続け、ルートまで探すことである。したがって SNAME が Mockapetris.ISI.EDU であった場合、このステップはまず Mockapetris.ISI.EDU のための NS RR を探し、次に ISI.EDU、次に EDU、そして . (ルート)と探すことになる。これらの NS RR は、SNAME のゾーンかその上位ゾーンかのためのホスト名をリストする。それらの名前を SLIST にコピーする。ローカル情報を使用してそれらのアドレスを設定する。アドレスを利用できない可能性もある。その場合リゾルバには多くの選択肢がある。もっとも優れている選択は、利用可能なアドレスを使用して処理を進めながら、アドレスを探すリゾルバプロセスを並行して開始することである。明らかにこの設計の選択とオプションとは複雑であり、ローカルホストの役割である。リゾルバ設計者に推奨される優先順位は以下の通り:

If the search for NS RRs fails, then the resolver initializes SLIST from the safety belt SBELT. The basic idea is that when the resolver has no idea what servers to ask, it should use information from a configuration file that lists several servers which are expected to be helpful. Although there are special situations, the usual choice is two of the root servers and two of the servers for the host's domain. The reason for two of each is for redundancy. The root servers will provide eventual access to all of the domain space. The two local servers will allow the resolver to continue to resolve local names if the local network becomes isolated from the internet due to gateway or link failure. NS RR の検索に失敗すると、リゾルバは SLIST を安全ベルト SBELT で初期化する。基本的な思想は、リゾルバがどのサーバーに尋ねるべきかを知らない場合、手掛かりとなるであろうサーバー群をリストした設定ファイルの情報を使用するべきというものである。特殊な状況はあるものの、通常の選択は、二つのルートサーバーとそのホストのドメインのための 二つのサーバーとである。二つであるのは冗長性のためである。ルートサーバーは、結果として全ドメイン空間へのアクセスを提供する。ローカルサーバーが二つあることにより、ゲートウェイや回線障害によってローカルネットワークがインターネットから分離された場合でも、ローカルの名前解決を継続できるだろう。

In addition to the names and addresses of the servers, the SLIST data structure can be sorted to use the best servers first, and to insure that all addresses of all servers are used in a round-robin manner. The sorting can be a simple function of preferring addresses on the local network over others, or may involve statistics from past events, such as previous response times and batting averages. サーバーの名前とアドレスとに加え、最適なサーバーから先に使用するために、またすべてのサーバーのすべてのアドレスがラウンドロビン方式で使用されることを保証するために、SLIST 構造体をソートすることができる。このソートは、ローカルネットワーク上のアドレスを他に優先するような単純なものでもよいし、以前の応答時間や成功率など、過去のイベントからの統計を考慮してもよい。

Step 3 sends out queries until a response is received. The strategy is to cycle around all of the addresses for all of the servers with a timeout between each transmission. In practice it is important to use all addresses of a multihomed host, and too aggressive a retransmission policy actually slows response when used by multiple resolvers contending for the same name server and even occasionally for a single resolver. SLIST typically contains data values to control the timeouts and keep track of previous transmissions. ステップ 3 では応答を受け取るまで問合せを送信する。その戦略は、各送信ごとにタイムアウトさせながら、すべてのサーバーのすべてのアドレスを巡回するというものである。実際問題として、マルチホーム化されたホストのすべてのアドレスを使用することは重要であり、また積極的すぎる再送信ポリシーは、複数のリゾルバ(時には単一のリゾルバでも)が同じネームサーバーに対して競合した場合の応答を遅らせる。一般に SLIST はタイムアウトを制御し、以前の送信を追跡するためのデータ値を含む。

Step 4 involves analyzing responses. The resolver should be highly paranoid in its parsing of responses. It should also check that the response matches the query it sent using the ID field in the response. ステップ 4 は応答の解析を必要とする。リゾルバは応答の解析において非常に柔軟であるべきである。またリゾルバは、送信した問合せに対応する応答かどうかを、応答の ID フィールドを使用して確認する。

The ideal answer is one from a server authoritative for the query which either gives the required data or a name error. The data is passed back to the user and entered in the cache for future use if its TTL is greater than zero. 理想的な回答は、問い合わせに対して権威あるサーバーからの、目的の情報または名前エラーを表すものである。情報はユーザーに渡され、TTL がゼロより大きければ将来のためにキャッシュに入れられる。

If the response shows a delegation, the resolver should check to see that the delegation is "closer" to the answer than the servers in SLIST are. This can be done by comparing the match count in SLIST with that computed from SNAME and the NS RRs in the delegation. If not, the reply is bogus and should be ignored. If the delegation is valid the NS delegation RRs and any address RRs for the servers should be cached. The name servers are entered in the SLIST, and the search is restarted. 応答が委譲を示している場合、リゾルバは、その委譲が SLIST 内のサーバーより回答に "近い(closer)" かどうかを確認するべきである。これは SLIST 内の一致数を、委譲内の SNAME と NS RR とから計算されたものと比較することで実現できる。もし近くないのであればその応答は間違いであり、無視するべきである。委譲が有効な場合、そのサーバーのための NS 委譲 RR と任意のアドレス RR とはキャッシュされるべきである。ネームサーバーは SLIST に入れられ、検索が再開される。

If the response contains a CNAME, the search is restarted at the CNAME unless the response has the data for the canonical name or if the CNAME is the answer itself. 応答が CNAME を含む場合、その CNAME から検索が再開される。ただしその応答が正規名の情報を持っているか、CNAME が回答そのものである場合を除く。

Details and implementation hints can be found in [RFC-1035]. 詳細と実装との手引きは [RFC-1035] に見つけれらる。

6. A SCENARIO 6. シナリオ

In our sample domain space, suppose we wanted separate administrative control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might allocate name servers as follows: 私たちのサンプルドメイン空間では、ルート、MIL、EDU、MIT.EDU、ISI.EDU の各ゾーンに個別の運用管理を求めていると仮定する。私たちは以下のようにネームサーバーを割り当てるだろう:

                                   |(C.ISI.EDU,SRI-NIC.ARPA
                                   | A.ISI.EDU)
             +---------------------+------------------+
             |                     |                  |
            MIL                   EDU                ARPA
             |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
             | A.ISI.EDU           | C.ISI.EDU)       |
       +-----+-----+               |     +------+-----+-----+
       |     |     |               |     |      |           |
      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
                                   |
       +--------+------------------+---------------+--------+
       |        |                  |               |        |
      UCI      MIT                 |              UDEL     YALE
                |(XX.LCS.MIT.EDU, ISI
                |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
            +---+---+              | A.ISI.EDU)
            |       |              |
           LCS   ACHILLES +--+-----+-----+--------+
            |             |  |     |     |        |
            XX            A  C   VAXA  VENERA Mockapetris

In this example, the authoritative name server is shown in parentheses at the point in the domain tree at which is assumes control. この例において、権威ネームサーバーは制御を担うドメインツリーの位置に括弧で示されている。

Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers may have zones which are contiguous or disjoint. In this scenario, C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU has contiguous zones at the root and MIL domains, but also has a non- contiguous zone at ISI.EDU. したがってルートネームサーバーは C.ISI.EDU、SRI-NIC.ARPA、A.ISI.EDU 上にある。MIL ドメインは SRI-NIC.ARPA と A.ISI.EDU とによって提供される。EDU ドメインは SRI-NIC.ARPA と C.ISI.EDU とによって提供される。サーバーが保持するドメインのゾーンは隣接していても離れていてもよいことに注意してほしい。このシナリオでは、C.ISI.EDU はルートと EDU ドメインとに隣接するゾーンを持つ。A.ISI.EDU はルートと MIL ドメインとに隣接するゾーンを持つが、同時に ISI.EDU に隣接しないゾーンを持つ。

6.1. C.ISI.EDU name server 6.1. C.ISI.EDU ネームサーバー

C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN class, and would have zones for these domains. The zone data for the root domain might be: C.ISI.EDU は IN クラスのルート・MIL・EDU ドメインのネームサーバーであり、それらのドメインのゾーンを保持しているだろう。ルートのゾーン情報は次のようになるだろう:

    .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
                            870611          ;serial
                            1800            ;refresh every 30 min
                            300             ;retry every 5 min
                            604800          ;expire after a week
                            86400)          ;minimum of a day
                    NS      A.ISI.EDU.
                    NS      C.ISI.EDU.
                    NS      SRI-NIC.ARPA.

    MIL.    86400   NS      SRI-NIC.ARPA.
            86400   NS      A.ISI.EDU.

    EDU.    86400   NS      SRI-NIC.ARPA.
            86400   NS      C.ISI.EDU.

    SRI-NIC.ARPA.   A       26.0.0.73
                    A       10.0.0.51
                    MX      0 SRI-NIC.ARPA.
                    HINFO   DEC-2060 TOPS20

    ACC.ARPA.       A       26.6.0.65
                    HINFO   PDP-11/70 UNIX
                    MX      10 ACC.ARPA.

    USC-ISIC.ARPA.  CNAME   C.ISI.EDU.

    73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
    65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
    51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
    52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
    103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.

    A.ISI.EDU. 86400 A      26.3.0.103
    C.ISI.EDU. 86400 A      10.0.0.52

This data is represented as it would be in a master file. Most RRs are single line entries; the sole exception here is the SOA RR, which uses "(" to start a multi-line RR and ")" to show the end of a multi-line RR. Since the class of all RRs in a zone must be the same, only the first RR in a zone need specify the class. When a name server loads a zone, it forces the TTL of all authoritative RRs to be at least the MINIMUM field of the SOA, here 86400 seconds, or one day. The NS RRs marking delegation of the MIL and EDU domains, together with the glue RRs for the servers host addresses, are not part of the authoritative data in the zone, and hence have explicit TTLs. この情報はマスターファイルにあるであろう通りに示されている。大部分の RR は単一行のエントリである。唯一の例外は SOA RR で、複数行 RR の開始のために "(" を使用し、また複数行 RR の終了を表すために ")" を使用している。あるゾーン内のすべての RR は同じクラスでなければならないので、ゾーン内の最初の RR にだけクラスを指定する必要がある。ネームサーバーがゾーンを読み込むとき、すべての権威 RR の TTL を少なくとも SOA の MINIMUM フィールドの値、ここでは 86400 秒(1 日)に強制する。MIL ドメインおよび EDU ドメインの委譲をサーバーのホストアドレスのグルー RR と共に表している NS RR は、このゾーンの権威情報ではないため、明示的な TTL を持っている。

Four RRs are attached to the root node: the SOA which describes the root zone and the 3 NS RRs which list the name servers for the root. The data in the SOA RR describes the management of the zone. The zone data is maintained on host SRI-NIC.ARPA, and the responsible party for the zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400 second minimum TTL, which means that all authoritative data in the zone has at least that TTL, although higher values may be explicitly specified. 4 つの RR がルートノードに接続している。ルートゾーンを記述する SOA と、そのルートのためのネームサーバーをリストしている 3 つの NS RR である。SOA RR 内の情報はこのゾーンの取り扱いを記述する。ゾーン情報はホスト SRI-NIC.ARPA 上で保守され、ゾーンに責任を持つ関係者は HOSTMASTER@SRI-NIC.ARPA である。SOA 内の重要な項目は 86400 秒の最低 TTL であり、明示的にそれ以上の値を指定することはできるものの、ゾーン内のすべての権威情報が少なくともその TTL を持つことを意味している。

The NS RRs for the MIL and EDU domains mark the boundary between the root zone and the MIL and EDU zones. Note that in this example, the lower zones happen to be supported by name servers which also support the root zone. MIL ドメインおよび EDU ドメインのための NS RR は、ルートゾーンと MIL・EDU ゾーンとの間の境界を表している。この例では、ルートゾーンをサポートするネームサーバーが、たまたま下位ゾーンもサポートしていることに注意してほしい。

The master file for the EDU zone might be stated relative to the origin EDU. The zone data for the EDU domain might be: EDU ゾーンのためのマスターファイルは、基点である EDU に対する相対位置から開始することができる。EDU ドメインのゾーン情報は以下のようになるだろう:

    EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
                            870729 ;serial
                            1800 ;refresh every 30 minutes
                            300 ;retry every 5 minutes
                            604800 ;expire after a week
                            86400 ;minimum of a day
                            )
                    NS SRI-NIC.ARPA.
                    NS C.ISI.EDU.

    UCI 172800 NS ICS.UCI
                    172800 NS ROME.UCI
    ICS.UCI 172800 A 192.5.19.1
    ROME.UCI 172800 A 192.5.19.31
    ISI 172800 NS VAXA.ISI
                    172800 NS A.ISI
                    172800 NS VENERA.ISI.EDU.
    VAXA.ISI 172800 A 10.2.0.27
                    172800 A 128.9.0.33
    VENERA.ISI.EDU. 172800 A 10.1.0.52
                    172800 A 128.9.0.32
    A.ISI 172800 A 26.3.0.103

    UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
                    172800 NS UMN-REI-UC.ARPA.
    LOUIE.UDEL.EDU. 172800 A 10.0.0.96
                    172800 A 192.5.39.3

    YALE.EDU.  172800 NS YALE.ARPA.
    YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.

    MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
                      43200 NS ACHILLES.MIT.EDU.
    XX.LCS.MIT.EDU.  43200 A 10.0.0.44
    ACHILLES.MIT.EDU. 43200 A 18.72.0.8

Note the use of relative names here. The owner name for the ISI.EDU. is stated using a relative name, as are two of the name server RR contents. Relative and absolute domain names may be freely intermixed in a master ここでは相対名の使用法に注意してほしい。ISI.EDU. の所有者名の二つのネームサーバー RR が相対名を使用して記述されている。マスターファイル内では相対ドメイン名と絶対ドメイン名とを自由に混在させてよい。

6.2. Example standard queries 6.2. 標準問合せの例

The following queries and responses illustrate name server behavior. Unless otherwise noted, the queries do not have recursion desired (RD) in the header. Note that the answers to non-recursive queries do depend on the server being asked, but do not depend on the identity of the requester. 以下の問合せと応答は、ネームサーバーの振る舞いの説明である。特に記述のない限り、問合せは再帰要求(RD)を持たない。非再帰問合せへの回答は尋ねているサーバーに依存し、リクエスタには依存しないことに注意してほしい。

6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A

The query would look like: 問合せは以下のようになるだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY                                     |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

The response from C.ISI.EDU would be: C.ISI.EDU からの応答は以下のようになるだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
               |               86400 IN A 10.0.0.51                |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

The header of the response looks like the header of the query, except that the RESPONSE bit is set, indicating that this message is a response, not a query, and the Authoritative Answer (AA) bit is set indicating that the address RRs in the answer section are from authoritative data. The question section of the response matches the question section of the query. 応答のヘッダは問合せのヘッダと同じように見えるが、メッセージが応答であることを表すために RESPONSE ビットがセットされており、また Answer セクション内のアドレス RR が権威情報に由来することを表すために、Authoritative Answer (AA) がセットされている。応答の Question セクションは問合せの Question セクションに一致する。

If the same query was sent to some other server which was not authoritative for SRI-NIC.ARPA, the response might be: SRI-NIC.ARPA の権威ではない他のサーバーに同じ問合せが送られた場合、その応答は以下のようになるだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY,RESPONSE                            |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
               |               1777 IN A 26.0.0.73                 |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

This response is different from the previous one in two ways: the header does not have AA set, and the TTLs are different. The inference is that the data did not come from a zone, but from a cache. The difference between the authoritative TTL and the TTL here is due to aging of the data in a cache. The difference in ordering of the RRs in the answer section is not significant. この応答は二つの点で前のものと異なっている:ヘッダの AA がセットされておらず、TTL が異なる。推測では、この情報はゾーンからではなく、キャッシュから来ている。ここでの TTL と権威 TTL との違いは、キャッシュ内の情報の経過時間によるものである。Answer セクション内の RR の順序の違いは重要ではない。

6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*

A query similar to the previous one, but using a QTYPE of *, would receive the following response from C.ISI.EDU: 前の問合せと似ているが QTYPE に * を使用するこの問合せは、C.ISI.EDU から以下の応答を受け取るだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
               |                         A     10.0.0.51           |
               |                         MX    0 SRI-NIC.ARPA.     |
               |                         HINFO DEC-2060 TOPS20     |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

If a similar query was directed to two name servers which are not authoritative for SRI-NIC.ARPA, the responses might be: SRI-NIC.ARPA に権威を持たない二つのネームサーバーに同様の問合せが送られた場合、その応答は以下のようになるだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
               |                            A       10.0.0.51      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

and そして、

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

Neither of these answers have AA set, so neither response comes from authoritative data. The different contents and different TTLs suggest that the two servers cached data at different times, and that the first server cached the response to a QTYPE=A query and the second cached the response to a HINFO query. どちらの回答も AA がセットされておらず、したがって権威情報からの応答ではない。異なる内容と異なる TTL とは、二つのサーバーが異なる時刻に情報をキャッシュしたことを表しており、最初のサーバーは QTYPE=A への応答をキャッシュし、二番目のサーバーは HINFO 問合せへの応答をキャッシュしている。

6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX

This type of query might be result from a mailer trying to look up routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA. The response from C.ISI.EDU would be: この種類の問合せは、メールの宛先 HOSTMASTER@SRI-NIC.ARPA のためのルーティング情報を探そうとするメーラーによって生成される可能性がある。C.ISI.EDU からの応答は以下のようになるだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
               |                            A       10.0.0.51      |
               +---------------------------------------------------+

This response contains the MX RR in the answer section of the response. The additional section contains the address RRs because the name server at C.ISI.EDU guesses that the requester will need the addresses in order to properly use the information carried by the MX. この応答は Answer セクションに MX RR を含んでいる。Additional セクションにアドレス RR が含まれている。これは C.ISI.EDU のネームサーバーが、MX によって運ばれる情報を適切に使用するためにはリクエスタがそのアドレスを必要とするだろうと推測しているためである。

6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS

C.ISI.EDU would reply to this query with: この問合せに対し C.ISI.EDU は以下のように返すだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

The only difference between the response and the query is the AA and RESPONSE bits in the header. The interpretation of this response is that the server is authoritative for the name, and the name exists, but no RRs of type NS are present there. この応答と問合せとの違いは、ヘッダの AA ビットおよび RESPONSE ビットがセットされていることだけである。この応答は、そのサーバーがその名前の権威を持ち、その名前は存在するが、タイプ NS の RR は存在しないと解釈される。

6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A

If a user mistyped a host name, we might see this type of query. ユーザーがホスト名をミスタイプした場合に、この種の問合せに遭遇する可能性がある。

C.ISI.EDU would answer it with: これに対し C.ISI.EDU は以下のように答えるだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
               +---------------------------------------------------+
    Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
               |       870611 1800 300 604800 86400                |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

This response states that the name does not exist. This condition is signalled in the response code (RCODE) section of the header. この応答はその名前が存在しないことを示している。この状態はヘッダの応答コード(RCODE)で伝えられる。

The SOA RR in the authority section is the optional negative caching information which allows the resolver using this response to assume that the name will not exist for the SOA MINIMUM (86400) seconds. Authority セクションの SOA RR はオプションの否定キャッシュ情報である。これによりこの応答を使用するリゾルバは、その名前が SOA MINIMUM (86400) 秒間存在しなかったと推測できる。

6.2.6. QNAME=BRL.MIL, QTYPE=A

If this query is sent to C.ISI.EDU, the reply would be: この問合せが C.ISI.EDU に送られた場合、その応答は以下のようになるだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
               |                  86400    NS       A.ISI.EDU.     |
               +---------------------------------------------------+
    Additional | A.ISI.EDU.                A        26.3.0.103     |
               | SRI-NIC.ARPA.             A        26.0.0.73      |
               |                           A        10.0.0.51      |
               +---------------------------------------------------+

This response has an empty answer section, but is not authoritative, so it is a referral. The name server on C.ISI.EDU, realizing that it is not authoritative for the MIL domain, has referred the requester to servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative for the MIL domain. この応答は空の Answer セクションを持つが、権威を持たず、したがって参照である。C.ISI.EDU 上のネームサーバーは自身が MIL ドメインの権威ではないことを知っているため、MIL ドメインの権威であることを知っている A.ISI.EDU および SRI-NIC.ARPA 上のサーバーをリクエスタに参照させたということである。

6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A

The response to this query from A.ISI.EDU would be: この問合せに対する A.ISI.EDU からの応答は以下のようになるだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
               +---------------------------------------------------+
    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
               | C.ISI.EDU.     86400 IN A          10.0.0.52      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

Note that the AA bit in the header guarantees that the data matching QNAME is authoritative, but does not say anything about whether the data for C.ISI.EDU is authoritative. This complete reply is possible because A.ISI.EDU happens to be authoritative for both the ARPA domain where USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is found. ヘッダの AA ビットは、QNAME に一致する情報が権威を持つが、C.ISI.EDU のための情報が権威を持つかどうかに付いては何も述べていないことに注意してほしい。A.ISI.EDU が偶然にも、USC-ISIC.ARPA の見つかった ARPA ドメインと C.ISI.EDU の情報が見つかった ISI.EDU ドメインとの両方に権威を持つために、この完全な回答が可能となる。

If the same query was sent to C.ISI.EDU, its response might be the same as shown above if it had its own address in its cache, but might also be: 同じ問合せが C.ISI.EDU に送られた場合の応答は、キャッシュにそれ自身のアドレスを持っていれば上記と同じになるだろうが、おそらくは以下のようになるだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
               +---------------------------------------------------+
    Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
               +---------------------------------------------------+
    Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
               |                           NS      A.ISI.EDU.      |
               |                           NS      VENERA.ISI.EDU. |
               +---------------------------------------------------+
    Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
               |                 172800    A       128.9.0.33      |
               | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
               |                 172800    A       128.9.0.32      |
               | A.ISI.EDU.      172800    A       26.3.0.103      |
               +---------------------------------------------------+

This reply contains an authoritative reply for the alias USC-ISIC.ARPA, plus a referral to the name servers for ISI.EDU. This sort of reply isn't very likely given that the query is for the host name of the name server being asked, but would be common for other aliases. この回答はエイリアス USC-ISIC.ARPA のための権威ある回答と、加えて ISI.EDU のためのネームサーバーへの参照を含んでいる。この種類の回答は、尋ねられているネームサーバー自体のホスト名を問合せた場合にはありそうもないが、そうでないエイリアスの場合には一般的である。

6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME

If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would be: この問合せが A.ISI.EDU または C.ISI.EDU のどちらかに送られた場合、その回答は以下のようになるだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
               +---------------------------------------------------+
    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name server doesn't attempt to look up anything for C.ISI.EDU. (Except possibly for the additional section.) QTYPE=CNAME であるため、CNAME RR 自体が問合せの回答であり、ネームーサーバーは C.ISI.EDU に付いてそれ以上探そうとしない。(ただし Additional セクションのための例外はあるかもしれない。)

6.3. Example resolution 6.3. 解決の例

The following examples illustrate the operations a resolver must perform for its client. We assume that the resolver is starting without a cache, as might be the case after system boot. We further assume that the system is not one of the hosts in the data and that the host is located somewhere on net 26, and that its safety belt (SBELT) data structure has the following information: 以下の例は、リゾルバがクライアントのために実行しなければならない動作を表している。システムブートの後のように、リゾルバがキャッシュを持たない状態から始まると仮定する。さらに私たちは、そのシステムがその情報に含まれるホストのひとつではなく、そのホストがネット 26 上のどこかに存在し、安全ベルト(SBELT)情報構造体が以下の内容を持つと仮定する:

    Match count = -1
    SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
    A.ISI.EDU.      26.3.0.103

This information specifies servers to try, their addresses, and a match count of -1, which says that the servers aren't very close to the target. Note that the -1 isn't supposed to be an accurate closeness measure, just a value so that later stages of the algorithm will work. この情報は試みるべきサーバーのアドレスと一致数 -1 とを表しており、このサーバーが目標から非常に遠いことを示している。-1 は正しい距離を表しているものではなく、アルゴリズムの後続処理を正しく動作させるための値であることに注意してほしい。

The following examples illustrate the use of a cache, so each example assumes that previous requests have completed. 以下の例はキャッシュの使用法を表している。したがってそれぞれの例は前のリクエストが完了したと仮定している。

6.3.1. Resolve MX for ISI.EDU. 6.3.1. ISI.EDU の MX を解決する

Suppose the first request to the resolver comes from the local mailer, which has mail for PVM@ISI.EDU. The mailer might then ask for type MX RRs for the domain name ISI.EDU. リゾルバへの最初の問合せが、PVM@ISI.EDU 宛てのメールを持つローカルメーラーから来たと仮定する。メーラーは次に、ドメイン名 ISI.EDU のタイプ MX の RR を要求するだろう。

The resolver would look in its cache for MX RRs at ISI.EDU, but the empty cache wouldn't be helpful. The resolver would recognize that it needed to query foreign servers and try to determine the best servers to query. This search would look for NS RRs for the domains ISI.EDU, EDU, and the root. These searches of the cache would also fail. As a last resort, the resolver would use the information from the SBELT, copying it into its SLIST structure. リゾルバはキャッシュの中から ISI.EDU の MX RR を探そうとするが、キャッシュは空であるため役に立たない。リゾルバは、外部のサーバーに問合せ、問合せるべき最適なサーバーを決定する必要があることを認識するだろう。その検索ではドメイン ISI.EDU、EDU、ルートの NS RR を探すことになる。キャッシュからのそれらの検索は同じように失敗する。リゾルバは最後の手段として、SBELT の情報を SLIST 構造体にコピーして使用することになる。

At this point the resolver would need to pick one of the three available addresses to try. Given that the resolver is on net 26, it should choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would then send off a query of the form: この時点でリゾルバは、利用可能な三つのアドレスからひとつを選択する必要がある。リゾルバがネット 26 上にあることを考えると、最初の選択として 26.0.0.73 または 26.3.0.103 を選択するべきである。リゾルバは次に以下の形式の問合せを送信するだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY                                     |
               +---------------------------------------------------+
    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

The resolver would then wait for a response to its query or a timeout. If the timeout occurs, it would try different servers, then different addresses of the same servers, lastly retrying addresses already tried. It might eventually receive a reply from SRI-NIC.ARPA: 次にリゾルバは、問合せに対する応答またはタイムアウトまで待機する。タイムアウトした場合、リゾルバは別のサーバーを試し、次に同じサーバーの別のアドレスを試し、最後にはすでに試したアドレスを再試行する。最終的にリゾルバは SRI-NIC.ARPA から以下の回答を受け取るだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
               |                           NS       A.ISI.EDU.     |
               |                           NS       VENERA.ISI.EDU.|
               +---------------------------------------------------+
    Additional | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
               |                 172800    A        128.9.0.33     |
               | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
               |                 172800    A        128.9.0.32     |
               | A.ISI.EDU.      172800    A        26.3.0.103     |
               +---------------------------------------------------+

The resolver would notice that the information in the response gave a closer delegation to ISI.EDU than its existing SLIST (since it matches three labels). The resolver would then cache the information in this response and use it to set up a new SLIST: リゾルバは、この応答の情報が既知の SLIST よりも ISI.EDU に近い委譲を示していることに気付くだろう(三つのラベルが一致しているためである)。次にリゾルバは、この応答の情報をキャッシュし、それを使用して新しい SLIST を設定する:

    Match count = 3
    A.ISI.EDU.      26.3.0.103
    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
    VENERA.ISI.EDU. 10.1.0.52       128.9.0.32

A.ISI.EDU appears on this list as well as the previous one, but that is purely coincidental. The resolver would again start transmitting and waiting for responses. Eventually it would get an answer: このリスト上の A.ISI.EDU は前のリストにも現れていたが、これはまったくの偶然である。リゾルバは再び送信と応答の待機とを開始する。リゾルバは最終的に以下の回答を得るだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
               +---------------------------------------------------+
    Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
               |                         MX 20 VAXA.ISI.EDU.       |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
               |                 172800  A  128.9.0.33             |
               | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
               |                 172800  A  128.9.0.32             |
               +---------------------------------------------------+

The resolver would add this information to its cache, and return the MX RRs to its client. リゾルバはこの情報をキャッシュに追加し、クライアントにこの MX RR を返す。

6.3.2. Get the host name for address 26.6.0.65 6.3.2. アドレス 26.6.0.65 のホスト名を取得する

The resolver would translate this into a request for PTR RRs for 65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the resolver would look for foreign servers to ask. No servers would match, so it would use SBELT again. (Note that the servers for the ISI.EDU domain are in the cache, but ISI.EDU is not an ancestor of 65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.) リゾルバはこれを、65.0.6.26.IN-ADDR.ARPA の PTR RR を求めるリクエストに変換する。この情報がキャッシュに存在しないため、リゾルバは尋ねるべき外部のサーバーを探す。しかしサーバーが見つからないため、リゾルバは再び SBELT を使用することになる。(ISI.EDU ドメインのためのサーバーがキャッシュに存在するが、ISI.EDU は 65.0.6.26.IN-ADDR.ARPA の上位ではないため、SBELT が使用される。)

Since this request is within the authoritative data of both servers in SBELT, eventually one would return: このリクエストは SBELT の中の両サーバーの権威情報内にあるので、最終的にそのひとつが以下の応答を返すだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
               +---------------------------------------------------+
    Answer     | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

6.3.3. Get the host address of poneria.ISI.EDU 6.3.3. poneria.ISI.EDU のホストアドレスを取得する

This request would translate into a type A request for poneria.ISI.EDU. The resolver would not find any cached data for this name, but would find the NS RRs in the cache for ISI.EDU when it looks for foreign servers to ask. Using this data, it would construct a SLIST of the form: このリクエストは poneria.ISI.EDU のタイプ A のリクエストに変換される。リゾルバはキャッシュ情報にこの名前を見つけられない。しかし、尋ねるべき外部のサーバーを探すとき、キャッシュの中に ISI.EDU の NS RR を見つけるだろう。この情報を使用して、リゾルバは以下の形の SLIST を構築するだろう:

    Match count = 3

    A.ISI.EDU.      26.3.0.103
    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
    VENERA.ISI.EDU. 10.1.0.52

A.ISI.EDU is listed first on the assumption that the resolver orders its choices by preference, and A.ISI.EDU is on the same network. A.ISI.EDU はリゾルバの優先順位による順序付け条件の先頭にリストされており、かつ A.ISI.EDU は同じネットワーク上にある。

One of these servers would answer the query. これらのサーバーのひとつが問合せに回答するだろう。

7. REFERENCES and BIBLIOGRAPHY 7. 引用資料と参考資料

[Dyer 87]
Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical Plan - Name Service, April 1987, version 1.9.
Describes the fundamentals of the Hesiod name service. Hesiod ネームサービスの基礎を説明している。
[IEN-116]
J. Postel, "Internet Name Server", IEN-116, USC/Information Sciences Institute, August 1979.
A name service obsoleted by the Domain Name System, but still in use. ドメインネームシステムによって時代遅れとなったが、今もなお使用されているネームサービス。
[Quarterman 86]
Quarterman, J., and J. Hoskins, "Notable Computer Networks",Communications of the ACM, October 1986, volume 29, number 10.
[RFC-742]
K. Harrenstien, "NAME/FINGER", RFC-742, Network Information Center, SRI International, December 1977.
[RFC-768]
J. Postel, "User Datagram Protocol", RFC-768, USC/Information Sciences Institute, August 1980.
[RFC-793]
J. Postel, "Transmission Control Protocol", RFC-793, USC/Information Sciences Institute, September 1981.
[RFC-799]
D. Mills, "Internet Name Domains", RFC-799, COMSAT, September 1981.
Suggests introduction of a hierarchy in place of a flat name space for the Internet. インターネットのために、フラットな名前空間ではなく階層構造の導入を提案している。
[RFC-805]
J. Postel, "Computer Mail Meeting Notes", RFC-805, USC/Information Sciences Institute, February 1982.
[RFC-810]
E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet Host Table Specification", RFC-810, Network Information Center, SRI International, March 1982.
Obsolete. See RFC-952. 非推奨。RFC-952 参照。
[RFC-811]
K. Harrenstien, V. White, and E. Feinler, "Hostnames Server", RFC-811, Network Information Center, SRI International, March 1982.
Obsolete. See RFC-953. 非推奨。RFC-953 参照。
[RFC-812]
K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812, Network Information Center, SRI International, March 1982.
[RFC-819]
Z. Su, and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC-819, Network Information Center, SRI International, August 1982.
Early thoughts on the design of the domain system. Current implementation is completely different. 初期のドメインシステムの設計思想。現在の実装とはまったく異なる。
[RFC-821]
J. Postel, "Simple Mail Transfer Protocol", RFC-821, USC/Information Sciences Institute, August 1980.
[RFC-830]
Z. Su, "A Distributed System for Internet Name Service", RFC-830, Network Information Center, SRI International, October 1982.
Early thoughts on the design of the domain system. Current implementation is completely different. 初期のドメインシステムの設計思想。現在の実装とはまったく異なる。
[RFC-882]
P. Mockapetris, "Domain names - Concepts and Facilities," RFC-882, USC/Information Sciences Institute, November 1983.
Superceeded by this memo. この文書により廃止された。
[RFC-883]
P. Mockapetris, "Domain names - Implementation and Specification," RFC-883, USC/Information Sciences Institute, November 1983.
Superceeded by this memo. この文書により廃止された。
[RFC-920]
J. Postel and J. Reynolds, "Domain Requirements", RFC-920, USC/Information Sciences Institute October 1984.
Explains the naming scheme for top level domains. トップレベルドメインのための命名スキームを説明している。
[RFC-952]
K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host Table Specification", RFC-952, SRI, October 1985.
Specifies the format of HOSTS.TXT, the host/address table replaced by the DNS. DNS によって置き換えられたホスト/アドレスのテーブルである HOSTS.TXT のフォーマットを規定している。
[RFC-953]
K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server", RFC-953, SRI, October 1985.
This RFC contains the official specification of the hostname server protocol, which is obsoleted by the DNS. This TCP based protocol accesses information stored in the RFC-952 format, and is used to obtain copies of the host table. この RFC には、DNS によって時代遅れになったホスト名サーバープロトコルの公式な規定が含まれる。TCP ベースのこのプロトコルは、RFC-952 のフォーマットで保存されている情報にアクセスし、ホストテーブルのコピーを取得するために使用される。
[RFC-973]
P. Mockapetris, "Domain System Changes and Observations", RFC-973, USC/Information Sciences Institute, January 1986.
Describes changes to RFC-882 and RFC-883 and reasons for them. Now obsolete. RFC-882 および RFC-883 への変更点とその理由を説明している。現在では非推奨である。
[RFC-974]
C. Partridge, "Mail routing and the domain system", RFC-974, CSNET CIC BBN Labs, January 1986.
Describes the transition from HOSTS.TXT based mail addressing to the more powerful MX system used with the domain system. HOSTS.TXT ベースのメールアドレッシングから、ドメインシステによるより強力な MX システムへの移行を説明している。
[RFC-1001]
NetBIOS Working Group, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and Methods", RFC-1001, March 1987.
This RFC and RFC-1002 are a preliminary design for NETBIOS on top of TCP/IP which proposes to base NetBIOS name service on top of the DNS. この RFC と RFC-1002 とは TCP/IP 上の NETBIOS のための予備的設計であり、DNS 上で NetBIOS ネームサービスの基礎を成すよう提案されている。
[RFC-1002]
NetBIOS Working Group, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed Specifications", RFC-1002, March 1987.
[RFC-1010]
J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010, USC/Information Sciences Institute, May 1987
Contains socket numbers and mnemonics for host names, operating systems, etc. ソケット番号、ホスト名のためのニーモニック、オペレーティングシステムなどを含む。
[RFC-1031]
W. Lazear, "MILNET Name Domain Transition", RFC-1031, November 1987.
Describes a plan for converting the MILNET to the DNS. MILNET から DNS への変換予定を説明している。
[RFC-1032]
M. K. Stahl, "Establishing a Domain - Guidelines for Administrators", RFC-1032, November 1987.
Describes the registration policies used by the NIC to administer the top level domains and delegate subzones. トップレベルドメインと委譲サブゾーンとを管理するために NIC が使用する登録ポリシーを説明している。
[RFC-1033]
M. K. Lottor, "Domain Administrators Operations Guide", RFC-1033, November 1987.
A cookbook for domain administrators. ドメイン管理者のための説明書。
[Solomon 82]
M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name Server", Computer Networks, vol 6, nr 3, July 1982.
Describes a name service for CSNET which is independent from the DNS and DNS use in the CSNET. DNS から独立している CSNET のためのネームサービスと、CSNET における DNS の使用方法とを説明している。

Index 索引

          A   12
          Absolute names   8
          Aliases   14, 31
          Authority   6
          AXFR   17

          Case of characters   7
          CH   12
          CNAME   12, 13, 31
          Completion queries   18

          Domain name   6, 7

          Glue RRs   20

          HINFO   12

          IN   12
          Inverse queries   16
          Iterative   4

          Label   7

          Mailbox names   9
          MX   12

          Name error   27, 36
          Name servers   5, 17
          NE   30
          Negative caching   44
          NS   12

          Opcode   16

          PTR   12

          QCLASS   16
          QTYPE   16

          RDATA   13
          Recursive   4
          Recursive service   22
          Relative names   7
          Resolvers   6
          RR   12

          Safety belt   33
          Sections   16
          SOA   12
          Standard queries   22

          Status queries   18
          Stub resolvers   32

          TTL   12, 13

          Wildcards   25

          Zone transfers   28
          Zones   19
    A
    絶対名(Absolute name)
    エイリアス(Aliases) 2
    権威(Authority)
    AXFR

    大文字・小文字(Case of characters)
    CH
    CNAME 2 3
    補完問合せ(Completion queries)

    ドメイン名(Domain name)

    グルー RR(Glue RRs)

    HINFO

    IN
    逆問合せ(Inverse queries)
    反復(Iterative)

    ラベル(Label)

    メールボックス名(Mailbox names)
    MX

    名前エラー(Name error) 2
    ネームサーバー(Name servers)  2
    NE
    否定キャッシュ(Negative caching)
    NS

    Opcode

    PTR

    QCLASS
    QTYPE

    RDATA
    再帰(Recursive)
    再帰サービス(Recursive service)
    相対名(Relative names)
    リゾルバ(Resolvers)
    RR

    安全ベルト(Safety belt)
    セクション(Sections)
    SOA
    標準問合せ(Standard queries)

    状態問合せ(Status queries)
    スタブリゾルバ(Stub resolvers)

    TTL, 2

    ワイルドカード(Wildcards)

    ゾーン転送(Zone transfers)
    ゾーン(Zones)