1. DNS/RFC1034/3.6


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.33

The MX RRs have an RDATA section which consists of a 16 bit number
followed by a domain name.  The address RRs use a standard IP address
format to contain a 32 bit internet address.

MX 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. 2420

This 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.52

Both of these RRs would be returned in the response to the type A query,
while a type CNAME or * query should return just the CNAME.

タイプ A の問合せには両方の RRが返答として返されるが、 CNAME や * 問合せでは CNAME だけが返されるはずだ。

Domain names in RRs which point at another name should always point at
the primary name and not the alias.  This avoids extra indirections in
accessing information.  For example, the address to name RR for the
above host should be:

他の名前を指す 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 を使うことを補助するRR

Note 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.32

Because the server assumes that if the requester wants mail exchange
information, it will probably want the addresses of the mail exchanges
soon afterward.

要求者がメール交換ホスト情報を必要とするなら、すぐにメール交換ホストの アドレスも必要になるものとネームサーバは想定するからだ。

Note that the QCLASS=* construct requires special interpretation
regarding authority.  Since a particular name server may not know all of
the classes available in the domain system, it can never know if it is
authoritative for all classes.  Hence responses to QCLASS=* queries can
never be authoritative.

QCLASS=* 構成は権威に関して特別な解釈を要することに注意せよ。 ネームサーバは 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 が集合のうちのひとつである場合、 そのことを示さない。 (例えば、複数アドレスをもつホストのアドレスのうちの1つ)。 そのため逆問い合わせに対して返された 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 訳 前野年紀