DNS/RFC/1035/4
Contents
4. メッセージ MESSAGES
4.1. 形式 Format
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:
DNS プロトコルでのすべての通信はメッセージと呼ばれるたったひとつの 形式を使って行われる。 メッセージのトップレベルの形式は以下のように５つの部分に分けられる。 (一部は空のこともある)：
+---------------------+
| 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.
ヘッダ(Header)節は常に存在する。ヘッダには他のどの部分が存在するか、 メッセージが問合せであるか、返答であるか、 標準的な問合せか、他の処理であるか、などを示すフィールドがある。
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.
ヘッダに続く部分の名前は標準的な質問での使い方に由来する。 質問節(Question)はネームサーバへの質問を記述するフィールド群を含む。 これらのフィールドとは問合せ種別(QTYPE)、問合せクラス(QCLASS)と 問合せドメイン名(QNAME)である。
残る３つの節は同じ形式であり、資源レコード(RRs)の列(空も可)である;
- 回答節は問合せに答える RRs を含む；
- 権威節は権威を持つネームサーバに近づくためのRRsを含む;
- 付加レコード節は問合せに関連はしているが、問合せの直接の答ではない RRsを含む。
4.1.1. ヘッダ節形式 Header section format
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)か返答(0)かを示す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)
標準的質問(質問)
1 an inverse query (IQUERY)
逆問合せ(逆質問)
2 a server status request (STATUS)
サーバの状態を要求(状態)
3-15 reserved for future use
将来の使用のために予約
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.
権威のある返答－このビットは返答で有効、返答したネーム
サーバが質問節のドメイン名の権威あるネームサーバであることを
示す。
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.
切り詰め－伝送チャンネル上で、メッセージが最大長を
越えたため切り詰められたことを示す。
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.
再帰要請－問合せで設定され、返答にコピーされる。
再帰要請が 1 ならネームサーバに再帰問合せを要請する。
再帰問合わせはサポートは任意である。
RA Recursion Available - this be is set or cleared in a
response, and denotes whether recursive query support is
available in the name server.
再帰可能－これは返答で設定される。
ネームサーバが再帰的問合せをサポートするかどうかを示す。
Z Reserved for future use. Must be zero in all queries and responses.
将来のために予約されている。すべての質問と返答でゼロでなければならない。
RCODE Response code - this 4 bit field is set as part of
responses. The values have the following interpretation:
返答コード－この4 ビットフィールドは返答の一部として設定される。
値の解釈は次の通り：
0 No error condition
エラーはない。
1 Format error - The name server was
unable to interpret the query.
形式不備エラー－。ネームサーバは問合せを解釈できなかった。
2 Server failure - The name server was
unable to process this query due to a
problem with the name server.
サーバ失敗－ネームサーバに問題があって、
この問合せを処理することができなかった。
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.
名前エラー－権威あるネームサーバからの返答のときにだけ
意味がある。このコードは問合せで参照されたドメイン名が
存在しないことを示す。
4 Not Implemented - The name server does
not support the requested kind of query.
実装されていない－ネームサーバは求められ
た種類の問合せをサポートしていない。
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.
拒否－ネームサーバはポリシー的な理由で指定されたオペレーションの実行を拒否した。
例えば、ネームサーバは特定の問合せ者への情報提供を望まなかったり、
特定のデータの特定のオペレーション(例えばゾーン転送)を望まないなど。
6-15 Reserved for future use.
将来ために予約
QDCOUNT an unsigned 16 bit integer specifying the number of
entries in the question section.
質問節の項目数を示す符号なし16 ビット数
ANCOUNT an unsigned 16 bit integer specifying the number of
resource records in the answer section.
返答節の項目数を示す符号なし16ビット数
NSCOUNT an unsigned 16 bit integer specifying the number of name
server resource records in the authority records section.
権威レコード節のネームサーバ資源レコードの数を示す符号なし16ビット数
ARCOUNT an unsigned 16 bit integer specifying the number of
resource records in the additional records section.
付加節の項目数を示す符号なし16ビット数4.1.2. 質問節の形式 Question section format
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
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.
ラベル列で表現されたドメイン名。
各ラベルは長さを示すオクテットとその長さのオクテット列から成る。
ドメイン名はルートを意味する空ラベル(長さ 0 のオクテット)で
終端される。このフィールドは奇数個のオクテットでもよいことに注意せよ;
位置あわせ用詰めものは使われない。
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オクテットのコード。このフィールドの
値は TYPE フィールドに許されるすべてのコードを含む。
さらに、複数のタイプの RR に適合するより一般的な値も含む。
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
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.
RR 種別を示す 2オクテット。このフィールドは
RDATAフィールドのデータの意味を指定します。
CLASS two octets which specify the class of the data in the RDATA field.
RDATA フィールドのデータのクラスを指定する 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.
RR をキャッシュに保存してよい時間(秒単位)を示す符号なし32ビット数。
ゼロは RR が進行中の処理でのみ使えて、キャッシュしてはならないことを意味する。
RDLENGTH an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDATAフィールドのオクテット単位の長さを指定する符号なし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.
資源を記述する可変長オクテット列。この情報の
フォーマットは資源レコードの TYPE と CLASS により異なる。
例えば、TYPE が A で CLASS が IN なら RDATA フィールドは
4オクテットのARPAインターネットアドレスである。4.1.4. メッセージの圧縮 Message compression
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.
メッセージを小さくするために、DNS はメッセージ中のドメイン名の反復を 取り除くような圧縮案を採用する。 この方法では、ドメイン名全体やドメイン名の末尾のラベル列は 既出の同じ名前へのポインタで置き換えられる。
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です。 これによりラベルとポインタが区別できる。 ラベルはふたつの 0 のビットから始まるからで、 ラベルが63オクテット以下に制限されているからである。 (10 と 01 の組合せは将来の使用のために予約されている。) OFFSET フィールドはメッセージの開始位置 (ドメインヘッダの ID フィールドの最初のオクテット)からのオフセットを示す。 ゼロオフセットは ID フィールドの最初のバイトを指す。
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.
ポインタはクラス特有でない形式のドメイン名においてだけ使える。 そうでないと、ネームサーバやリゾルバは扱うすべての RR の形式を 知る必要がある。 現在のところ、このようなケースは存在しないが、 しかし将来、RDATAで起こるかもしれない。
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.
もしドメイン名が(RR の RDATA 節のような)メッセージの一部で 長さフィールドに支配されている部分に含まれていて、圧縮が使われるときには、 長さ計算では展開された名前の長さではなく、圧縮された名前の長さが使われる。
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 の位置にある; その定義は FOO ラベルのあとに連結するときに前に定義された F.ISI.ARPA への ポインタを使っている。 ドメイン名 ARPA はオフセット64 の位置で定義され、 名前 F.ISI.ARPA の要素である ARPA へのポインタを使う; ARPAに関するこのポインタは ARPA が 20 の位置にある文字列の最後のラベルで ある事に依存していることに注意せよ。 ルートドメイン名は 1 オクテットのゾーンとして、オフセット92 の位置で定義される ; ルートドメイン名はラベルを持たない。
4.2. 通信手段 Transport
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 使用法 UDP usage
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ビットが設定される。
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.
サーバの選択と再送方針に関しての提案はこのメモのリゾルバの章にもある。
4.2.2. TCP 使用法 TCP usage
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 分間の間接続がアイドルであることを確認すべきである。 特に、サーバは(更新作業を始める)SOAとAXFRの要求列は一回の接続中に許すべきである。 サーバは問合せに答えることが不可能になっているだろうから、 丁寧に終了するのではなく、一方的な終了やリセットを使ってもよい。
2002-07-26 訳 前野年紀