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 オクテットの長さフィールドに続くオクテット列で表される。 すべてのドメイン名はルートを表わす空のラベルで終わるので、 ドメイン名は値が 0 である長さバイト(オクテット)で終わる。 長さオクテットの上位 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ビット値を含められるが、 ラベルはこのメモの他の場所で記述されているようなよりよい構文に従うことを 強く推奨する。その構文は既存のホストの命名法と両立するものである。 ネームサーバとリゾルバはラベルを比較するのに、 パリティビットが 0 の ASCII コードを想定して、 大文字小文字の違いを区別しない方法を使うこと(すなわち、A=a)。 アルファベットでない文字コードは正確におなじであること。
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 TYPE コードを含む 2オクテット
CLASS two octets containing one of the RR CLASS codes.
RR CLASSコードを含む 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で配布される。ゼロ値は非常に変化しやすいデータ
にも使える。
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.
資源を表現する可変長オクテット列。この
情報の形式は資源レコードの TYPE と CLASSにより決る。
3.2.2. タイプ値 TYPE values
TYPE fields are used in resource records. Note that these types are a subset of QTYPEs.
TYPE フィールドは資源レコード内で使われる。 ここのタイプは QTYPE の部分集合であることに注意せよ。
TYPE value and meaning
種別 値と意味
A 1 a host address
ホストアドレス
NS 2 an authoritative name server
正式なネームサーバ
MD 3 a mail destination (Obsolete - use MX)
メール宛先（時代遅れ、MXを使うこと）
MF 4 a mail forwarder (Obsolete - use MX)
メール転送ホスト（時代遅れ、MXを使うこと）
CNAME 5 the canonical name for an alias
別名に対する正規名
SOA 6 marks the start of a zone of authority
権威あるゾーンの開始
MB 7 a mailbox domain name (EXPERIMENTAL)
メールボックスドメイン名（実験的）
MG 8 a mail group member (EXPERIMENTAL)
メールグループメンバー（実験的）
MR 9 a mail rename domain name (EXPERIMENTAL)
メール改名ドメイン名（実験的）
NULL 10 a null RR (EXPERIMENTAL)
空資源レコード（実験的）
WKS 11 a well known service description
周知のサービス記述
PTR 12 a domain name pointer
ドメイン名ポインタ
HINFO 13 host information
ホスト情報
MINFO 14 mailbox or mail list information
メールボックスあるいはメールリスト情報
MX 15 mail exchange
メール交換ホスト
TXT 16 text strings
テキスト文字列
3.2.3. 問合せ種別 QTYPE values
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:
QTYPE フィールドは問合せの質問部分に現われる。 QTYPE は TYPE の上位集合なので、すべての TYPE は正しい QTYPE になる。 加えて、次の問合せ種別が定義される：
AXFR 252 A request for a transfer of an entire zone
全ゾーンの転送の要求
MAILB 253 A request for mailbox-related records (MB, MG or MR)
メールボックス関連のレコード（MBやMGやMR）の要求
MAILA 254 A request for mail agent RRs (Obsolete - see MX)
メール代理人資源レコードの要求（時代遅れ、MX参照）
* 255 A request for all records
すべてのレコードの要求
3.2.4. クラス値 CLASS valuesCLASS fields appear in resource records. The following CLASS mnemonics and values are defined:
CLASS フィールドは資源レコードに現われる。 次の CLASS 名称記号と値が定義される：
IN 1 the Internet
インターネット
CS 2 the CSNET class (Obsolete - used only for examples in
some obsolete RFCs)
CSNET クラス（時代遅れ−ある時代遅れのRFCで例にだけ使われた）
CH 3 the CHAOS class
カオスクラス
HS 4 Hesiod [Dyer 87]
ヘシオド[Dyer 87]
3.2.5. 問合せクラス値 QCLASS values
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:
QCLASS フィールドは問合せの質問部に現われる。 QCLASS値はCLASS の上位集合である; どの CLASS も正当な QCLASSである。 CLASS 値に加えて、次のQCLASS値が定義される:
* 255 any class
全てのクラス
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.
以下の RR 定義は、少なくとも可能性として、すべてのクラスに出現する ことが期待される。 特に、NS、SOA、CNAME、PTRはすべてのクラスで使われて、 すべてのクラスで同じ形式を持つ。 その RDATA 形式が知られていることからこれらの RRs の RDATA 節中の すべてドメイン名は圧縮してよい。<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
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CNAME A <domain-name> which specifies the canonical or primary
name for the owner. The owner name is an alias.
所有者の正規名を指定する"ドメイン名"、所有者名は別名である。
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.
CNAME RRs は付加節の処理をひきおこさない。 ネームサーバーは場合によっては正規名で問合せを再開してもよい。 詳しくは [RFC-1034]にあるネームサーバーのロジックの記述を見よ。3.3.2. ホスト情報資源レコード形式 HINFO RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CPU /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ OS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CPU A <character-string> which specifies the CPU type.
CPU 種別を示す"文字列"
OS A <character-string> which specifies the operating system type.
OS 種別を示す"文字列"
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のようなプロトコルで 同種のマシンや OS 間の通信に特別な手順を使えるようにすることである。3.3.3. メールボックス資源データ形式（実験的） MB RDATA format (EXPERIMENTAL)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MADNAME A <domain-name> which specifies a host which has the
specified mailbox.
指定されたメールボックスを持つホストを指定する"ドメイン名"
MB records cause additional section processing which looks up an A type RRs corresponding to MADNAME.
MBレコードは MADNAMEに対応した A タイプ RRs 検索という 付加節処理を引きおこす。3.3.4. MD資源データフォーマット（時代遅れ）MD RDATA format (Obsolete)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ 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.
このドメインにメールを配達できるエージェントを持つ
ホストを指定する"ドメイン名"
MD records cause additional section processing which looks up an A type record corresponding to MADNAME.
MD レコードは MADNAMEに対応した A タイプ RRs 検索という 付加節処理を引きおこす。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 RRs を扱うときに推奨される方針は それらを拒否するか、優先度 0 の MX RRsとして扱うかである。3.3.5. MF資源データフォーマット(時代遅れ) MF RDATA format (Obsolete)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ 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.
このドメインにメールを転送できるエージェントを持つホスト
を示す"ドメイン名"
MF records cause additional section processing which looks up an A type record corresponding to MADNAME.
MD レコードは MADNAMEに対応した A タイプ RRs 検索という 付加節処理を引きおこす。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.
MFは時代遅れである。 新しい案の詳細は MX の定義と[RFC-974]を見よ。 マスターファイルにあるMD RRs を扱うときに推奨される方針は それらを拒否するか、優先度 10 の MX RRsとして扱うかである。3.3.6. メールグループ資源データフォーマット（実験的） MG RDATA format (EXPERIMENTAL)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MGMNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MGMNAME A <domain-name> which specifies a mailbox which is a
member of the mail group specified by the domain name.
ドメイン名で指定されるメールグループのメンバー
のメールボックスを指定する"ドメイン名"
MG records cause no additional section processing.
MG レコードは付加節の処理をひきおこさない。3.3.7. メール情報資源レコードフォーマット(実験的) MINFO RDATA format (EXPERIMENTAL)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ 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.
メーリングリストあるいはメールボックスの責任者を指
定する"ドメイン名"
このドメイン名がルートを示すなら、
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 RR の所有者に指定されたメーリングリス
トやメールボックスに関するエラーメッセージを受け取るメー
ルボックスを指定する"ドメイン名"
（提案されている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)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ 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
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 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 ビット整数であり、同じ所有者の RR の中で
この RR に与えられた優先度を示す。小さい方が優先される。
EXCHANGE A <domain-name> which specifies a host willing to act as
a mail exchange for the owner 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 レコードは EXCHANGE により指定されたホストの タイプ A 付加節処理を 引きおこす。 MX RRsの使い方は [RFC-974]で詳細に説明される。3.3.10. 空資源データ形式（実験的） NULL RDATA format (EXPERIMENTAL)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ <anything> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Anything at all may be in the RDATA field so long as it is 65535 octets or less.
65536 オクテット以下であれば、RDATA フィールドになんでも書いてよい。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.
NULL レコードは付加節の処理を引き起こさない。 NULL RRs はマスターファイルには許されない。 NULL は DNS の実験的な拡張における場所確保として用いられる。3.3.11. ネームサーバ資源データ形式 NS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NSDNAME A <domain-name> which specifies a host which should be
authoritative for the specified class and domain.
指定されたクラスとドメインに権威があるホスト名を
示す"ドメイン名"
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.
NS レコードはタイプ A レコードを求める通常の付加節処理を引きおこす。 参照に使われるときには、さらに NS レコードの存在するゾーン内で、 グルー情報の特別の検索を引きおこす。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.
NS RR はそこで指定されたホストが指定クラスの所有者名で始まる ゾーンを持つものだということを述べる。 クラスは一般に強いヒントになるが、 ホストと通信に使われるべきプロトコルファミリーを示すものではないことに 注意せよ。 例えば、インターネット(IN)とヘシオド(HS)クラス情報のネームサーバである ホストは通常 IN クラスプロトコルを使って質問される。3.3.12. ポインタ資源データ形式 PTR RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ PTRDNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PTRDNAME A <domain-name> which points to some location in the
domain name space.
ドメイン名空間内のどこかを指し示す"ドメイン名"
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レコードは付加節の処理を引起さない。 この RRs はドメイン空間内のどこかの位置を指すための特別のドメイン内で 使われる。 これらのレコードは単純なデータであり、 別名に使われるCNAMEで行われる特別な処理のようなものは含まない。 例としてはIN-ADDR.ARPAドメインの記述を参照のこと。3.3.13. SOA資源データ SOA RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ 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.
ゾーンデータの起源の情報源であるネームサーバの<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.
ゾーンの RRs を送信するときに指定される最小の
生存時間を示す 符号なし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 のフィールドの大部分はネームサーバの保守運用だけに関係する。 しかし、MINIMUM はゾーンから RRs を検索する全ての問合せ操作で使われる。 問合せの返答として RRs が送られる時、TTLフィールドには TTL と SOA のMINIMUM フィールドのうち大きい方の値がセットされる。 つまり MINIMUM はゾーン内の全ての RRs の TTL フィールドの下限である。 この最小値の使用法は RRsが返答に使われる時に限られ、 ゾーンをマスターファイルやゾーン転送で読み込んだりするときには 使われないことに注意せよ。 こうしておく理由は 将来のダイナミック更新機能で SOA RR を変更できるようにするためである。3.3.14. テキスト資源データ形式 TXT RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ TXT-DATA /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
TXT-DATA One or more <character-string>s.
<character-string>
TXT RRs are used to hold descriptive text. The semantics of the text depends on the domain where it is found.
TXT RRs は説明用テキストを置くのに使われる。 テキストの意味は使われるドメインに依存する。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS A 32 bit Internet address.
32 ビットインターネットアドレス
Hosts that have multiple Internet addresses will have multiple A records.
複数のインターネットアドレスを持つホストは複数のＡレコードを持つ。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 レコードは付加節の処理を引起こさない。 マスターファイル内の A レコード行の RDATA 節は ドットで分割された 4つの10進数で表される インターネットアドレスである。途中に空白は含まないものとする。 （例、"10.2.0.52"や"192.0.5.6"）3.4.2. 仕事資源データ形式 WKS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS An 32 bit Internet address
32ビットインターネットアドレス
PROTOCOL An 8 bit IP protocol number
8ビットＩＰプロトコル番号
<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].
仕事レコードは特定のインターネットアドレス上で、特定のプロトコルをサポート する既知サービスを記述するために使われる。 PROTOCOL フィールドは IP プロトコル番号を指定する。 また、ビットマップは指定されたプロトコルのポート毎に 1ビットを持つ。 最初のビットはポート0に、２番目はポート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.
例えば、もし PROTOCOL=TCP (6) なら、26番目のビットは TCP ポート25 (SMTP)に対応する。 このビットが 1 なら、SMTPサーバが TCP ポート25 を待ちうけているはずである。 もし 0 なら 指定されたアドレス上では SMPT サービスはサポートされていない。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.
WKS RRs の目的は TCP と UDP 上のサーバの利用可能情報を提供することである。 サーバが TCP と UDP の両方をサポートし、複数のインターネットアドレスを 持つなら、複数の WKS RRs が使われる。WKS RRs cause no additional section processing.
WKS RRs は付加節の処理を引起さない。 In master files, both ports and protocols are expressed using mnemonics or decimal numbers. マスターファイル内ではポートとプロトコルとも名称か10進数で表現される。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進数文字列として表現される。 (ゼロであるオクテットが 0で表現されることを除き、頭のゼロは省略される)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 で検索できる。 逆順になっているのは読みづらいが、 アドレス空間のひとつのネットワークがゾーンとして委譲できる ようになる。 例えば、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ドメインの非終端ノードに対応する。 ネットワークノードは そのネットワーク内のゲートウェイのプライマリホスト名への ポインタを持たせるために使われる。 ゲートウェイとは定義からして複数のネットワークにまたがっているので、 通常、複数のネットワークノードがそれを指す。 ゲートウェイはその IP アドレスに対応した ホストレベルポインタも持つであろう。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.
ネットワークノードでのゲートウェイポインタと フルアドレスノードとしてのホストとの双方が 当該ホストのプライマリドメイン名を指す PTR RR を持つ。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 のゲートウェイを知りたいプログラムは QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA の問合せをする。 返答には 2つの RRsを受け取る：
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. のインターネットアドレスを知るには、 QTYPE=A, QCLASS=IN の問合せをする。 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 に対応するホスト名を 探したいリゾルバは QTYPE=PTR, QCLASS=IN, QNAME=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つの名前を持つが、 そのうちのひとつだけが本名でありえる。- 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 からの動的アベイラビリティ情報の 代替とはならない。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.
一般に、既存のオブジェクトについて新しい情報をデータベースに追加したり、 完全に新しいオブジェクトに対しての新しいデータ形式が必要だったりする 場合には新しいタイプが適当である。 設計者はタイプとその RDATA 形式を定義するときには すべてのクラスに一般的に適用できるようにすべきであり、 情報の重複を避けるようにすべきである。 新しいクラスが適当なのは、 クラス特有の新しいデータ形式が必要な 新しいプロトコルなどで 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.
TYPE と CLASS はそれぞれ QTYPE と QCLASS の真部分集合でなければならない。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.
現在のシステムはあるタイプについての複数の値を表現するのに ひとつの RR の RDATA 節に複数の値を置くよりも複数 の RRs を使用する。 これはほとんどのアプリケーションで効率が悪くなるが、RRs をより短かく保つ。 複数 RRs の仮定は動的更新法のある実験的な作業に取入れられている。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.
新しいタイプのデータを定義する際に、 項目間の順序をつけるためだったり、 等価な結合に対する異なる形式を表現する目的で 複数 RR タイプを使ってはならない。 かわりに、この情報は RR の本体中にひとつのタイプを使って運ばれるべきだ。 この方針は複数タイプをキャッシュすること 複数のタイプに適合する QTYPE を定義することについてのトラブルを避ける。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 つのRR タイプを使用していた。ひとつは「より近い」交換ホスト(MD)を表し、 もうひとつは「近くない」交換ホスト(MF)を表していた。 困ったことは、 キャッシュにひとつのRR タイプが存在しても、 他の RR についてはなんの情報もないことである。 なぜなら、キャッシュ情報を得た問合せは MF, MD, MAILA の QTYPE （両方に一致）のどれも使っているから。 設計しなおされたサービスは ひとつのタイプ (MX)を使い、 異なる RRs を順序づけできる優先順位値を RDATA 節に持つ。 しかしながら、キャッシュにひとつでも MX RRs があれば、 全ての MX RRs が キャッシュにあるはずだ。