1. DNS/RFC1034/3.6
Contents
2. 3.6. 資源レコード Resource Records
A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate resource records (RRs). The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS.
ドメイン名は(ドメイン木の)節点を特定する。 各節点は資源情報集合をもっている。それは空でもよい。 ある名前に対応する資源情報の集合は別々の資源レコード(RRs)から構成される。 集合中での RRs の順序は問題ではなく、 ネームサーバ、リゾルバ、DNSの他の部分などでは保持する必要はない。
When we talk about a specific RR, we assume it has the following:
特定の RR の話をする時には、次の項目を持つことを仮定する：
owner which is the domain name where the RR is found.
RR のラベル (定義されるドメイン名)
type which is an encoded 16 bit value that specifies the type
of the resource in this resource record. Types refer to
abstract resources.
RR の種類を示す16ビットの値。タイプは抽象
的な資源を参照する。
This memo uses the following types:
この文書では以下のタイプを使う：
A a host address
ホストアドレス
CNAME identifies the canonical name of an alias
別名に対する正規名
HINFO identifies the CPU and OS used by a host
ホストで使われるCPU と OS の情報
MX identifies a mail exchange for the
domain. See [RFC-974 for details.
ドメインのメール交換ホスト情報
詳細は [RFC-974] を参照。
NS the authoritative name server for the domain
ドメインの権威(正式）ネームサーバ
PTR a pointer to another part of the domain name space
ドメイン空間の他の部分へのポインタ
SOA identifies the start of a zone of authority
権威あるゾーンの開始をしめす
class which is an encoded 16 bit value which identifies a
protocol family or instance of a protocol.
16ビット値であり、プロトコルファミリーあるいはプロトコルの
インスタンスを識別する。
This memo uses the following classes:
この文書では以下のクラスが使われる
IN the Internet system
インターネットシステム
CH the Chaos system
カオスシステム
TTL which is the time to live of the RR. This field is a 32
bit integer in units of seconds, and is primarily used by
resolvers when they cache RRs. The TTL describes how
long a RR can be cached before it should be discarded.
RR の有効時間。このフィールドは秒単位の 32ビッの整数である、
主にリゾルバが RRsをキャッシュする時に使われる。
TTL は RR がキャッシュから捨てられる前に、
どれだけ長く RR をキャッシュしておいてよいかを記述する。
RDATA which is the type and sometimes class dependent data
which describes the resource:
タイプや時にはクラスに依存する資源を記述するデータ：
A For the IN class, a 32 bit IP address
IN クラスでは 32ビットの IPアドレス
For the CH class, a domain name followed
by a 16 bit octal Chaos address.
CH クラスではドメイン名とそれに続く16ビット
の8進数カオスアドレス
CNAME a domain name.
ドメイン名
MX a 16 bit preference value (lower is
better) followed by a host name willing
to act as a mail exchange for the owner
domain.
16ビットの優先値(小さいほど優先）と、
ドメインのメール交換ホスト名
NS a host name.
ホスト名
PTR a domain name.
ドメイン名
SOA several fields.
いくつかのフィールドThe owner name is often implicit, rather than forming an integral part of the RR. For example, many name servers internally form tree or hash structures for the name space, and chain RRs off nodes. The remaining RR parts are the fixed header (type, class, TTL) which is consistent for all RRs, and a variable part (RDATA) that fits the needs of the resource being described.
ラベルは RR の中心的部分をなすというよりも暗黙指定されていることが多い。 例えば、多くのネームサーバは内部的には 名前空間を木やハッシュ構造で表現している。 そして、RRs をノードから解き離す。 残る RR 部分はすべての RR に共通の固定ヘッダ(タイプ、クラス、TTL）と 記述されるリソース毎の要求に適した可変部(RDATA）から成る。
The meaning of the TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in zones; it is also timed out, but by the refreshing policies for the zone. The TTL is assigned by the administrator for the zone where the data originates. While short TTLs can be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance suggest that these times should be on the order of days for the typical host. If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change.
TTL フィールドは RRをキャッシュに保持してよい期間を意味する。 この制限はゾーン内の権威あるデータには適用されない; 権威あるデータにも期限はあるが、それはゾーンの更新ポリシーに従う。 TTL はゾーンのデータを作成する管理者がきめるものである。 短い TTL だとキャッシュされる期間を小さくし、 ゼロ TTL はキャッシュを禁止するが、 インターネットの性能を考慮すべき現実では 通常ホストの場合、これらの値は数「日」程度にすべきことを示唆している。 変更が予定されているなら、変更にさきだって、TTL を小さくしてよい。 変更が行われている間の食違いを少なくするためである。 変更後には元の値に戻していくのである。
The data in the RDATA section of RRs is carried as a combination of binary strings and domain names. The domain names are frequently used as 'pointers' to other data in the DNS.
RRsの RDATA節にあるデータはバイナリ列とドメイン名の組み合わせとして 運ばれる。 ドメイン名はしばしばDNS 中の他のデータへの「ポインタ」として 使われる。
2.1. 3.6.1. 資源レコードのテキスト表現 Textual expression of RRs
RRs are represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form when stored in a name server or resolver. In this memo, we adopt a style similar to that used in master files in order to show the contents of RRs. In this format, most RRs are shown on a single line, although continuation lines are possible using parentheses.
RRs は DNSプロトコルのパケット中ではバイナリ形式で表わされる。 そしてネームサーバやリゾルバ中に保持される時には 通常は高度にコード化された形で表現される。 このメモでは、RRs の内容を表わすのにマスターファイルで使われる形式に 似た表現を使う。 この形式ではほとんどの RRs は 1行で表現される。 ただし、カッコを使えば、継続行も可能になる。
The start of the line gives the owner of the RR. If a line begins with a blank, then the owner is assumed to be the same as that of the previous RR. Blank lines are often included for readability.
行の最初に RR のラベル(持主)を置く。空白で始まっている場合、 直前の RR と同じとなる。読みやすさのために空白行を使える。
Following the owner, we list the TTL, type, and class of the RR. Class and type use the mnemonics defined above, and TTL is an integer before the type field. In order to avoid ambiguity in parsing, type and class mnemonics are disjoint, TTLs are integers, and the type mnemonic is always last. The IN class and TTL values are often omitted from examples in the interests of clarity.
ラベルの次には RR の TTL,タイプ,クラスがくる。 クラスとタイプには上に定義された名称を用いる。 そして、TTL はタイプ欄の前にある整数である。 構文解析するときのあいまい性を避けるために、 タイプとクラスの名称が重なることはない。 さらに TTLは整数で、タイプ名は常に最後に置く。 例題中では、論点を明かにするために、IN クラスとTTL値はしばしば省略される。
The resource data or RDATA section of the RR are given using knowledge of the typical representation for the data.
リソースデータや RR の RDATA節はデータの典型的表現 の知識を使って、記述される。
For example, we might show the RRs carried in a message as:
例えば、メッセージ中の RRs を次のように表現することがある：
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A 128.9.0.32
A 10.1.0.52
VAXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33The MX RRs have an RDATA section which consists of a 16 bit number followed by a domain name. The address RRs use a standard IP address format to contain a 32 bit internet address.
MX RRs は 16ビット数とそれに続くドメイン名から成る RDATA 節を持つ。 アドレス RRs は32ビットインターネットアドレスを示す 標準的 IP アドレス形式を使う。
This example shows six RRs, with two RRs at each of three domain names.
上の例では三つのドメイン名に対してそれぞれ 2 つのRR があり、 計 6 つの RRs が使われている
Similarly we might see:
同様にこういうのもある：
XX.LCS.MIT.EDU. IN A 10.0.0.44
CH A MIT.EDU. 2420This example shows two addresses for XX.LCS.MIT.EDU, each of a different class.
この例は XX.LCS.MIT.EDU の 2つの異なるクラスのアドレスを表わしている。
2.2. 3.6.2. 別名と正規名 Aliases and canonical names
In existing systems, hosts and other resources often have several names that identify the same resource. For example, the names C.ISI.EDU and USC-ISIC.ARPA both identify the same host. Similarly, in the case of mailboxes, many organizations provide many names that actually go to the same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU, and PVM@ISI.EDU all go to the same mailbox (although the mechanism behind this is somewhat complicated).
既存のシステムにおいては、ホストやその他の資源は 同じ資源を指すいくつかの名前を持つことがよくある。 例えば、C.ISI.EDU と USC-ISIC.ARPA という名前は共に同じホストを 指している。 同様に、メールボックスの場合には多くの組織で 結果として同じメールボックスに転送されることになる多くの名前を使っている; 例えば、Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU, PVM@ISI.EDU はどれも同じメイルボックスを指す。(そのための機構はだいぶ複雑だが）
Most of these systems have a notion that one of the equivalent set of names is the canonical or primary name and all others are aliases.
多くのシステムには等価な名前の集合のうちのひとつが正規名 あるいは本名であり、その他は別名であるという考えがある。
The domain system provides such a feature using the canonical name (CNAME) RR. A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.
DNS は正規名(CNAME) RRを使ってこういう機能を実現する。 CNAME RR はラベルが別名であることを示し、 RR の RDATA 節にある正規名が本名であることを指定している。 CNAME RR が存在する節点中には、他のデータは存在させられない; これにより、正規名と別名に対するデータに違いがでないことが保証される。 また、この規則により、キャッシュされた CNAMEを 権威あるサーバへ他のRRタイプについて問合わせることなく、 使えることを保証する。
CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted.
CNAME RRsは DNSソフトウェアにおいて特別な振舞いをおこさせる。
ドメイン名に付属する RR の中に希望するRRを見つけられなかった時、 ネームサーバは同じクラスの CNAME レコード であるかをチェックする。 もし、CNAME レコードだった場合には、 返答に CNAME レコードを含めるとともに、 CNAMEレコードのデータ欄で指定されたドメイン名を使って、再度問合せを行う。 ただし、このルールにはひとつ例外があって、 CNAME タイプが問合せられたときには問合せは再開されない。
For example, suppose a name server was processing a query with for USC- ISIC.ARPA, asking for type A information, and had the following resource records:
例えば、USC-ISIC.ARPAのタイプ A 情報の問合せを処理しているときに、 次の資源レコードがあったとせよ：
USC-ISIC.ARPA IN CNAME C.ISI.EDU
C.ISI.EDU IN A 10.0.0.52Both of these RRs would be returned in the response to the type A query, while a type CNAME or * query should return just the CNAME.
タイプ A の問合せには両方の RRが返答として返されるが、 CNAME や * 問合せでは CNAME だけが返されるはずだ。
Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information. For example, the address to name RR for the above host should be:
他の名前を指す RRs 中のドメイン名は別名ではなく、常に正規名を 指さねばならない。 これにより情報アクセスにおいて、余分の間接参照を回避できる。 例えば、上記のホストのアドレスを名前に変換する RR は 以下のようにするべきであり:
52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU
rather than pointing at USC-ISIC.ARPA. Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error.
USC-ISIC.ARPA.を指すべきではない。 もちろん、頑健性原理によって、 ドメインソフトウェアは CNAME 連鎖やループにであっても、 動作しつづけるべきである; CNAME 連鎖はたどられ、CNAMEループはエラー報告すべきである。
3. 3.7. 問合せ Queries
Queries are messages which may be sent to a name server to provoke a response. In the Internet, queries are carried in UDP datagrams or over TCP connections. The response by the name server either answers the question posed in the query, refers the requester to another set of name servers, or signals some error condition.
問合せとは返事を得るためにネームサーバに送られるメッセージである。 インターネットでは問合せには UDPデータグラムか、TCP接続が使われる。 ネームサーバからの返答は問合せられた質問にたいする返答であるか、 別のネームサーバ群への参照であるか、エラー発生の通知のどれかである。
In general, the user does not generate queries directly, but instead makes a request to a resolver which in turn sends one or more queries to name servers and deals with the error conditions and referrals that may result. Of course, the possible questions which can be asked in a query does shape the kind of service a resolver can provide.
一般に、利用者は問合せを直接生成せず、代わりにリゾルバに問い合わせる。 リゾルバがネームサーバーに問合せて、発生したエラーや参照を処理する。 もちろん、問合せとして出来る質問の範囲によって、 リゾルバのサービスする種類がきまる。
DNS queries and responses are carried in a standard message format. The message format has a header containing a number of fixed fields which are always present, and four sections which carry query parameters and RRs.
DNSの問合せと返答は標準的なメッセージ形式をしている。 メッセージ形式はヘッダ(常に存在している複数の固定フィールドをもつ)と 問合せパラメータと RR のための 4つの節(section)を持つ。
The most important field in the header is a four bit field called an opcode which separates different queries. Of the possible 16 values, one (standard query) is part of the official protocol, two (inverse query and status query) are options, one (completion) is obsolete, and the rest are unassigned.
ヘッダのうち最も重要なフィールドは問合せを分離するための opcode と呼 ばれる 4 ビットのフィールドである。 16 の可能な値のうち、ひとつ(標準的問合せ)は公式プロトコルの一部であり、 ふたつ (逆問合せと状態問合せ）は任意実装であり、 また、別のひとつ(補完）は廃止されており、残りは割り当てられていない。
The four sections are:
よっつの節とは
Question Carries the query name and other query parameters.
質問 問合せ名と問合せパラメータ
Answer Carries RRs which directly answer the query.
返答 問合せの直接の答えであるRR
Authority Carries RRs which describe other authoritative servers.
May optionally carry the SOA RR for the authoritative
data in the answer section.
権威 他の権威あるサーバについて記述する RR
返答節にある権威あるデータの SOA RRを含めてもよい。
Additional Carries RRs which may be helpful in using the RRs in the
other sections.
付加 他の節のRR を使うことを補助するRRNote that the content, but not the format, of these sections varies with header opcode.
これらの節の内容(形式ではなく）はヘッダの opcode により変わることに注意せよ。
<<Anchor(05)>>
=== 3.7.1. 標準問合せ Standard queries ===
{{{
A standard query specifies a target domain name (QNAME), query type
(QTYPE), and query class (QCLASS) and asks for RRs which match. This
type of query makes up such a vast majority of DNS queries that we use
the term 'query' to mean standard query unless otherwise specified.
The QTYPE and QCLASS fields are each 16 bits long, and are a superset of
defined types and classes.標準的な問合せは目標ドメイン名(QNAME)、問合せタイプ(QTYPE)、問合せク ラス(QCLASS)を指定して一致する RR を求る。 この種の問合せが DNS 問合せの大部分であるので、 特に断わりなく単に「問合せ」と言った場合、標準の問合せを意味する。 QTYPEとQCLASSフィールドは長さ 16ビットで、 定義されているタイプとクラスの上位集合である。
The QTYPE field may contain:
QTYPEフィールドに表われてよいもの：
<any type> matches just that type. (e.g., A, PTR).
指定されたタイプそのものに一致する(AやPTRなど）
AXFR special zone transfer QTYPE.
特別なゾーン転送 QTYPE
MAILB matches all mail box related RRs (e.g. MB and MG).
全てのメールボックス関係のRR(MBやMGなど）
* matches all RR types.
全てのRRタイプに一致The QCLASS field may contain:
QCLASSフィールドに表われてよいもの:
<any class> matches just that class (e.g., IN, CH).
指定されたクラスそのものに一致(INやCHなど）
* matches aLL RR classes.
全てのRRクラスに一致Using the query domain name, QTYPE, and QCLASS, the name server looks for matching RRs. In addition to relevant records, the name server may return RRs that point toward a name server that has the desired information or RRs that are expected to be useful in interpreting the relevant RRs. For example, a name server that doesn't have the requested information may know a name server that does; a name server that returns a domain name in a relevant RR may also return the RR that binds that domain name to an address.
問合せドメイン名、QTYPEとQCLASSを使って、 ネームサーバーは該当する RRs を探す。
ネームサーバは返答としてのレコードのほかに、 期待される情報を持つネームサーバをポイントするRRや、 RRを解釈するのに有用と思われる RR を返すことがある。 例えば、求められた情報を持たないネームサーバでも、 持っているネームサーバは知っているかもしれない;
RR中にドメイン名を返すネームサーバは ドメイン名をアドレスに結合する RR を一緒に返す ことがある。
For example, a mailer tying to send mail to Mockapetris@ISI.EDU might ask the resolver for mail information about ISI.EDU, resulting in a query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer section would be:
例えば、Mockapetris@ISI.EDUにメールを送ろうとしているメイラは リゾルバに ISI.EDU のメール情報を問い合わせる。 その結果、QNAME=ISI.EDU, QTYPE=MX, QCLASS=INの問合せが発生する。 返事の返答節はこうなる：
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.while the additional section might be:
一方、付加節はこうだろう：
VAXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33
VENERA.ISI.EDU. A 10.1.0.52
A 128.9.0.32Because the server assumes that if the requester wants mail exchange information, it will probably want the addresses of the mail exchanges soon afterward.
要求者がメール交換ホスト情報を必要とするなら、すぐにメール交換ホストの アドレスも必要になるものとネームサーバは想定するからだ。
Note that the QCLASS=* construct requires special interpretation regarding authority. Since a particular name server may not know all of the classes available in the domain system, it can never know if it is authoritative for all classes. Hence responses to QCLASS=* queries can never be authoritative.
QCLASS=* 構成は権威に関して特別な解釈を要することに注意せよ。 ネームサーバは DNS で利用可能なクラスのすべてを知っているとは限らないので、 すべてのクラスに対して権威があるかどうかは知るはずもない。 そのため、QCLASS=* の質問に対する返答は決して権威あるものにはならない。
3.1. 3.7.2. 逆問合せ(任意）Inverse queries (Optional)
Name servers may also support inverse queries that map a particular resource to a domain name or domain names that have that resource. For example, while a standard query might map a domain name to a SOA RR, the corresponding inverse query might map the SOA RR back to the domain name.
ネームサーバは資源から資源もつドメイン名(複数可)へ変換するような 逆問合せをサポートするかもしれない。 例えば、標準的問合せでドメイン名をSOA RRに変換するものがあるが、 対応する逆問合せは SOA RR をドメイン名に戻す。
Implementation of this service is optional in a name server, but all name servers must at least be able to understand an inverse query message and return a not-implemented error response.
このサービスの実装はネームサーバには任意であるが、 ネームサーバは少なくとも逆問合せメッセージを理解して、 「実装していない」エラー返答を返す必要がある。
The domain system cannot guarantee the completeness or uniqueness of inverse queries because the domain system is organized by domain name rather than by host address or any other resource type. Inverse queries are primarily useful for debugging and database maintenance activities.
DNS はドメイン名をもとに構成されており、 ホストアドレスやほかの資源タイプをもとにしていないので、 逆問合せの完全性やユニーク性を保証できない。 逆問合せは主としてデバッグやデータベース管理作業に有用である。
Inverse queries may not return the proper TTL, and do not indicate cases where the identified RR is one of a set (for example, one address for a host having multiple addresses). Therefore, the RRs returned in inverse queries should never be cached.
逆問い合わせは適切なTTLを返さないかもしれず、 識別された RR が集合のうちのひとつである場合、 そのことを示さない。 (例えば、複数アドレスをもつホストのアドレスのうちの１つ）。 そのため逆問い合わせに対して返された RRs は決してキャッシュすべきではない。
Inverse queries are NOT an acceptable method for mapping host addresses to host names; use the IN-ADDR.ARPA domain instead.
逆問合せはホストアドレスをホスト名に変換する方法としては 受入れられる方法ではない; 代わりにIN-ADDR.ARPAドメインを使うべきだ。
A detailed discussion of inverse queries is contained in [RFC-1035].
逆問い合わせの詳細な論議は[RFC-1035]にある。
4. 3.8. 状態問合せ(実験的） Status queries (Experimental)
To be defined.
まだ定義されていない。
5. 3.9. 補完の質問(廃止) Completion queries (Obsolete)
The optional completion services described in RFCs 882 and 883 have been deleted. Redesigned services may become available in the future, or the opcodes may be reclaimed for other use.
RFC882とRFC883にあった実装任意の補完サービスは削除された。 将来、設計しなおされたサービスが利用可能になったり、 opcodesが他の目的のために回収される可能性がある。
2002-08-08 訳 前野年紀