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