## page was renamed from DNS/1/RFC/1034/3 ## page was renamed from DNS/基礎知識/RFC/1034/3 ## page was renamed from DNS/RFC/1034/3 ## page was renamed from DNS/RFC1034/3 #pragma section-numbers off DNS/RFC1034/3 改行を適当に挟んで、読みやすくしてみよう。-- ToshinoriMaeno <> <> ---- <> == 3. ドメイン名空間と資源レコード DOMAIN NAME SPACE and RESOURCE RECORDS == <> === 3.1. 名前空間の定義と用語 Name space specifications and terminology === {{{ The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). The domain system makes no distinctions between the uses of the interior nodes and leaves, and this memo uses the term 'node' to refer to both. }}} ドメイン名空間は木構造をしている。 木の節点(node)と葉(末端、leaf)はそれぞれ資源集合(空も可)に対応する。 DNS では内部節点と葉との使い方は区別しない。そして、この文書では両者を指すのに用語「節点」を使う。 {{{ Each node has a label, which is zero to 63 octets in length. Brother nodes may not have the same label, although the same label can be used for nodes which are not brothers. One label is reserved, and that is the null (i.e., zero length) label used for the root. }}} 各節点はラベルを持ち、その長さは 0 から63 オクテットである。 兄弟節点は同じラベルを持てないが、兄弟ではない節点は同じラベルを持てる。 事前に予約されていラベルがひとつあり、それは空(つまり長さがゼロ)のラベルであって根(root)を表わすのに使われる。 {{{ The domain name of a node is the list of the labels on the path from the node to the root of the tree. By convention, the labels that compose a domain name are printed or read left to right, from the most specific (lowest, farthest from the root) to the least specific (highest, closest to the root). }}} 節点のドメイン名とは節点から根に到る経路上のラベルを並べたものである。 読みかきの約束として、ドメイン名を構成するラベルは 左から右へ、つまり最も細部(下位の、根から遠いもの）から より限定されない(上位の、根に近い）ものへと並べる。 {{{ Internally, programs that manipulate domain names should represent them as sequences of labels, where each label is a length octet followed by an octet string. Because all domain names end at the root, which has a null string for a label, these internal representations can use a length byte of zero to terminate a domain name. }}} ドメイン名を扱うプログラムなどは内部ではドメイン名をラベルの列として表現すべきである。 そして、各ラベルは長さを示すオクテットとそれに続くオクテット列とする。 すべてのドメイン名は根で終るので、そして根が持つラベルは空であるので、 内部表現としてはドメイン名の終端に長さバイト 0 を使うことができる。 {{{ By convention, domain names can be stored with arbitrary case, but domain name comparisons for all present domain functions are done in a case-insensitive manner, assuming an ASCII character set, and a high order zero bit. This means that you are free to create a node with label 'A' or a node with label 'a', but not both as brothers; you could refer to either using 'a' or 'A'. When you receive a domain name or label, you should preserve its case. The rationale for this choice is that we may someday need to add full binary domain names for new services; existing services would not be changed. }}} ドメイン名には大文字も小文字も使用できることになっているが、 現在のドメイン機能ではドメイン名の比較には ASCII文字であって、最上位ビットがゼロという仮定のもとで、 大文字小文字の区別をせずに比較している。 この事は'A'というラベルを持つ節点や'a'というラベルを持つ節点を作ってよいが、 これら両方を作って、兄弟としてはならない; これらはどちらも 'A'や'a'として参照してよい、ということを意味する。 ドメイン名やラベルを受け取る時には、大文字小文字の区別を守るべきである。 そうする理由は新サービスのために任意の文字が使えるドメイン名を加えることになるかもしれず、 それでも既存のサービスを変えずに済ませるためである。 {{{ When a user needs to type a domain name, the length of each label is omitted and the labels are separated by dots ('.'). Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot. We use this property to distinguish between: }}} 利用者はドメイン名を使うときには各ラベルの長さは書かないで、ラベルをドット('.')で区切る。 完全なドメイン名は根ラベルで終るので、ドットで終端された書式となる。 この特徴を使って以下のように区別される： {{{ - a character string which represents a complete domain name (often called 'absolute'). For example, 'poneria.ISI.EDU.' }}} - 完全なドメイン名を表す文字列(よく「絶対名」と呼ばれる）。 例えば、'poneria.ISI.EDU.' {{{ - a character string that represents the starting labels of a domain name which is incomplete, and should be completed by local software using knowledge of the local domain (often called 'relative'). For example, 'poneria' used in the ISI.EDU domain. }}} - ドメイン名の始まり部分のラベル列を表現する文字列、 ドメイン名としては不完全であり、ローカルドメインについての知識を使って ローカルソフトウェアが補完する必要がある(しばしば「相対名」と呼ばれる）。 例えば、ISI.EDUドメイン内で使われた'poneria' {{{ Relative names are either taken relative to a well known origin, or to a list of domains used as a search list. Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation, and in master files, where they are relative to a single origin domain name. The most common interpretation uses the root '.' as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing. }}} 相対名の基点としては、既知の起点もしくは検索リストに使われるドメインリストが採用される。 相対名はほとんどの場合ユーザインタフェースで現れ、解釈は実装ごとに異っている。 マスターファイルで使われる場合には起点ドメイン名相対となる。 最もよく使われる解釈ではルート('.')を唯一の基点として、 もしくは検索リストのメンバーにふくめて使うものである。 これにより、多段ラベルをもつ相対名は タイプの手間を省くために末尾のドットを省略されたものとなることがよくある。 {{{ To simplify implementations, the total number of octets that represent a domain name (i.e., the sum of all label octets and label lengths) is limited to 255. }}} 実装の単純化のために、ドメイン名を表すオクテットの総数 (すべてのラベルオクテットとラベル長の合計）は255に制限される。 {{{ A domain is identified by a domain name, and consists of that part of the domain name space that is at or below the domain name which specifies the domain. A domain is a subdomain of another domain if it is contained within that domain. This relationship can be tested by seeing if the subdomain's name ends with the containing domain's name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and ' '. }}} ドメインはドメイン名で識別される。 そして、ドメイン名空間のうち、ドメインを示すドメイン名の部分と その下の部分から成り立っている。 ドメインが他のドメインに含まれているとき、他のドメインのサブドメインで あるという。 この関係はサブドメインの名前の後部が「含む側のドメイン」の名前に一致するかを 調べればわかる。 例えば、A.B.C.DはB.C.DとC.DとDと " "のサブドメインである。 <> === 3.2. 利用上の管理ガイドライン Administrative guidelines on use === {{{ As a matter of policy, the DNS technical specifications do not mandate a particular tree structure or rules for selecting labels; its goal is to be as general as possible, so that it can be used to build arbitrary applications. In particular, the system was designed so that the name space did not have to be organized along the lines of network boundaries, name servers, etc. The rationale for this is not that the name space should have no implied semantics, but rather that the choice of implied semantics should be left open to be used for the problem at hand, and that different parts of the tree can have different implied semantics. For example, the IN-ADDR.ARPA domain is organized and distributed by network and host address because its role is to translate from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- 1002] are flat because that is appropriate for that application. }}} ポリシーの問題として、 DNS技術仕様書では特定の木構造や特定のラベル選択規 則を強要しない； その目的をできるだけ一般的にしておくことで、 任意のアプリケーションを構築するときに使えるようにするためである。 特に、名前空間がネットワーク境界やネームサーバなどに従属する構成を とる必要がないように DNS は設計された。 こうしたのは 名前空間はきまった意味を持つべきものではなく、 意味の選択は対象とする問題分野で自由に決められるようにしておくためであり、 木の異なる部分ごとに異なった意味をもてるようにするためでもある。 例えば、IN-ADDR.ARPAドメインはネットワークやホストアドレスにしたがって 組織化され分散される。なぜなら、ネットワークやホスト番号を 名前へ変換することがその役割だから; NetBIOSドメイン[RFC-1001, RFC- 1002]はアプリケーションにとって適切なので、 フラットな構造になっている。 {{{ However, there are some guidelines that apply to the 'normal' parts of the name space used for hosts, mailboxes, etc., that will make the name space more uniform, provide for growth, and minimize problems as software is converted from the older host table. The political decisions about the top levels of the tree originated in RFC-920. Current policy for the top levels is discussed in [RFC-1032]. MILNET conversion issues are covered in [RFC-1031]. }}} しかしながら、 ホストやメールボックス等に使われる名前空間の通常部分に適用される ガイドラインは存在しており、 名前空間をより一様にし、発展に備え、古いホストテーブルを使った ソフトウェアを変換する際の問題を最小にするようにしている。 木のトップレベルについての政治的決定はRFC920から始まる。 トップレベルに関するポリシーの現状は[RFC-1032]にある。 MILNET変換問題は[RFC-1031]で触れられている。 {{{ Lower domains which will eventually be broken into multiple zones should provide branching at the top of the domain so that the eventual decomposition can be done without renaming. Node labels which use special characters, leading digits, etc., are likely to break older software which depends on more restrictive choices. }}} 先々、複数のゾーンに分割されることが予想される下位ドメインは 分解されるときに名前を変更しなくてよいように トップのドメインで分けておくべきである。 特殊文字を使っていたり、数字で始まっていたりする節点ラベルは より制約のある条件に依存している古いソフトウェアでは動作しない可能性がある。 <> === 3.3. 利用上の技術的ガイドライン Technical guidelines on use === {{{ Before the DNS can be used to hold naming information for some kind of object, two needs must be met: }}} DNS になんらかのオブジェクトの名前情報を持たせる前に、 次の二つの条件を満たすべきである： {{{ - A convention for mapping between object names and domain names. This describes how information about an object is accessed. }}} - オブジェクト名とドメイン名の間の対応の便法。 これはオブジェクト情報にアクセスする方法を記述する。 {{{ - RR types and data formats for describing the object. }}} - RR タイプとオブジェクトを記述するデータ形式。 {{{ These rules can be quite simple or fairly complex. Very often, the designer must take into account existing formats and plan for upward compatibility for existing usage. Multiple mappings or levels of mapping may be required. }}} これらの規則は非常に単純であるか、あるいはかなり複雑である。 よくあることだが、設計者は既存の形式も考慮に入れて、 既存の使い方の上位互換性を計画しなければならい。 多数の変換や多段の変換が必要となるかもしれない。 {{{ For hosts, the mapping depends on the existing syntax for host names which is a subset of the usual text representation for domain names, together with RR formats for describing host addresses, etc. Because we need a reliable inverse mapping from address to host name, a special mapping for addresses into the IN-ADDR.ARPA domain is also defined. }}} ホストに関しては、 ドメイン名の通常のテキスト表現の部分集合である既存のホスト名の構文や ホストアドレスを表現する RR 形式などに依存した 変換となる。 アドレスからホスト名への信頼できる逆変換が必要なため、 アドレスをIN-ADDR.ARPAドメインに変換する特別な規則も定義した。 {{{ For mailboxes, the mapping is slightly more complex. The usual mail address @ is mapped into a domain name by converting into a single label (regardles of dots it contains), converting into a domain name using the usual text format for domain names (dots denote label breaks), and concatenating the two to form a single domain name. Thus the mailbox HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this design also must take into account the scheme for mail exchanges [RFC- 974]. }}} メールボックスのための変換はもう少し複雑である。 通常のメールアドレス @は 次のようにしてドメイン名に変換される。 を１つのラベルに変換し(ドットが含まれていてもよい）、 をドメイン名のために通常のテキスト形式を使った ドメイン名(ドットをラベルの区切りとするもの）に変換して、 これらをつないだものをドメイン名とする。 それで、メールボックス HOSTMASTER@SRI-NIC.ARPA はドメイン名では HOSTMASTER.SRI-NIC.ARPA. と表現される。 こう設計したことの背景にはメール交換 [RFC-974]のスキームを考慮したことがある。 {{{ The typical user is not concerned with defining these rules, but should understand that they usually are the result of numerous compromises between desires for upward compatibility with old usage, interactions between different object definitions, and the inevitable urge to add new features when defining the rules. The way the DNS is used to support some object is often more crucial than the restrictions inherent in the DNS. }}} 通常の利用者はこれらの規則の定義には関わっていないが、 これらは次のようなことについての多くの妥協の結果であることを理解してほしい。 古い使い方の上位互換性、オブジェクトの異なる定義の間の干渉、 新しい規則を定義する時に新しい機能を追加しようとする避けがたい衝動。 ある種のオブジェクトをサポートするために DNSを使う方法は DNS 固有の制限に よるよりもしばしばより困難である。 <> === 3.4. 例に使う名前空間 Example name space === {{{ The following figure shows a part of the current domain name space, and is used in many examples in this RFC. Note that the tree is a very small subset of the actual name space. }}} 次の図は現在のドメイン名空間の一部を示している。 そして、このRFCの多くの例で使われる。 木は現実の名前空間の非常に小さい部分であることに注意せよ。 {{{ | | +---------------------+------------------+ | | | MIL EDU ARPA | | | | | | +-----+-----+ | +------+-----+-----+ | | | | | | | BRL NOSC DARPA | IN-ADDR SRI-NIC ACC | +--------+------------------+---------------+--------+ | | | | | UCI MIT | UDEL YALE | ISI | | +---+---+ | | | | LCS ACHILLES +--+-----+-----+--------+ | | | | | | XX A C VAXA VENERA Mockapetris }}} {{{ In this example, the root domain has three immediate subdomains: MIL, EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named XX.LCS.MIT.EDU. All of the leaves are also domains. }}} この例では、ルートドメインは 3つの直下のサブドメインを持つ: MIL, EDU, ARPA である。 LCS.MIT.EDUドメインはXX.LCS.MIT.EDU という名前のただひとつの直接の サブドメインを持つ。全ての枝(リーフ)はドメインである。 <> === 3.5. 名前のよりよい構文 Preferred name syntax === {{{ The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. }}} DNS の仕様はドメイン名を構成する規則を可能な限り一般的にしようとしている。 存在するものならなんでもその名前をドメイン名として最小限の変更で 表現できるようにしようという考えである。 しかしながら、オブジェクトにドメイン名をつける時、 慎重なユーザーなら DNS の規則に従うと同時に オブジェクトに対しての既存のどんな規則にも従うような名前を 選ぶだろう。 それらの規則が公開されているものか、 既存プログラムにより意味づけされているものであるかにかかわらず。 {{{ For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. }}} 例えば、メールドメインに名前を付ける時、 このメモにある規則と RFC 822との両方を満たすようにすべきである。 新しいホスト名を作る時、HOST.TXTの古い規則も守るべきである。 これならドメイン名を使うように古いソフトウェアを書き直す時に 発生するトラブルを避けられる。 {{{ The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET). }}} 以下の構文なら、ドメイン名を使うアプリケーション(例えば、メール、TELNET） の多くで、問題発生が少なくなるだろう。 {{{ ::= | ' ' ::=