RFC 5395 ドメインネームシステム（ＤＮＳ）ＩＡＮＡの考察

この文書はRFC 5395の日本語訳（和訳）です。この文書の翻訳内容の正確さは保障できないため、正確な知識や情報を求める方は原文を参照してください。翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の配布は元のＲＦＣ同様に無制限です。

Network Working Group D. Eastlake 3rd
Request for Comments: 5395 Stellar Switches
BCP: 42 November 2008
Obsoletes: 2929
Updates: 1183, 3597
Category: Best Current Practice

Domain Name System (DNS) IANA Considerations
ドメインネームシステム（ＤＮＳ）ＩＡＮＡの考察

Status of This Memo
このメモの状態

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
この文書ははインターネット共同体びための現在の最良実践を示し、
改良のための議論と提案を求めます。この文書の配布は無制限です。

Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
ＩＥＴＦ信託と著者に示された人が著作権を持ちます。すべての権利を
保有しています。

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
事実上、この文書はＢＣＰ７８とこの文書の公表日に有効なＩＥＴＦ文書
へのＩＥＴＦ信託の法的な関係( http://trustee.ietf.org/license-info )
の影響を受けます。この文書の権利と制限について説明するとき、慎重に
これらの文書を再検討してください。

Abstract
要約

Internet Assigned Number Authority (IANA) parameter assignment
considerations are specified for the allocation of Domain Name System
(DNS) resource record types, CLASSes, operation codes, error codes,
DNS protocol message header bits, and AFSDB resource record subtypes.
インターネット番号割当権威(ＩＡＮＡ)パラメータの割当はドメイン名シス
テム（ＤＮＳ）の資源レコード種別、クラス、オペレーションコード、エラー
コード、ＤＮＳプロトコルメッセージヘッダビットとＡＦＳＤＢ資源レコー
ド副種別で指定されます。

Table of Contents
目次

1. Introduction
1. 序論
1.1. Terminology
1.1. 用語
2. DNS Query/Response Headers
2. ＤＮＳ問合せ/応答ヘッダ
2.1. One Spare Bit?
2.1. １つの予備ビット?
2.2. OpCode Assignment
2.2. オペレーションコード割当
2.3. RCODE Assignment
2.3. 応答コード割当
3. DNS Resource Records
3. ＤＮＳ資源レコード
3.1. RRTYPE IANA Considerations
3.1. 資源レコード種別のＩＡＮＡ割当の問題
3.1.1. DNS RRTYPE Allocation Policy
3.1.1. ＤＮＳ資源レコード種別割当ポリシ
3.1.2. DNS RRTYPE Expert Guidelines
3.1.2. ＤＮＳ資源レコード種別の専門家ガイドライン
3.1.3. Special Note on the OPT RR
3.1.3. ＯＰＴ資源レコードの特別な注意
3.1.4. The AFSDB RR Subtype Field
3.1.4. AFSDB資源レコード副種別フィールド
3.2. RR CLASS IANA Considerations
3.2. 資源レコードクラスのＩＡＮＡの考慮
3.3. Label Considerations
3.3. ラベル問題
3.3.1. Label Types
3.3.1. ラベル形式
3.3.2. Label Contents and Use
3.3.2. ラベル内容と使い方
4. Security Considerations
4. セキュリティの問題
5. IANA Considerations
5. ＩＡＮＡの考慮
Appendix A. RRTYPE Allocation Template
付録Ａ．資源レコード種別割当テンプレート
Normative References
基準的参考文献
Informative References
有益な参考文献

1. Introduction
1. 序論

The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases that store "resource records" (RRs) under
domain names. DNS data is structured into CLASSes and zones that can
be independently maintained. See [RFC1034], [RFC1035], [RFC2136],
[RFC2181], and [RFC4033], familiarity with which is assumed.
ドメインネームシステム(ＤＮＳ)はドメイン名下にある「資源レコード」
(RR)を保存する複製され分散された安全な階層型データベースを提供しま
す。ＤＮＳデータは独自に維持できるCLASSとゾーンで構造化されます。
[RFC1034]と[RFC1035]と[RFC2136]と[RFC2181]と[RFC4033]を見てください。

This document provides, either directly or by reference, the general
IANA parameter assignment considerations that apply across DNS query
and response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RRTYPE or
query/response OpCode. See the specific RFC defining that RRTYPE or
query/response OpCode for such considerations if they have been
defined, except for AFSDB RR considerations [RFC1183], which are
included herein. This RFC obsoletes [RFC2929].
この文書はＤＮＳ問合せと応答のヘッダと全ての資源レコードに適用される
一般的なＩＡＮＡパラメータ割当問題の考察を直接又は間接的に供給します。
これは特定の資源レコード種別や問合せ/応答オペレーションコードにだけ
に適用される追加のＩＡＮＡの考察があるかもしれません。考察については、
もし定義されているなら、これらの資源レコード種別や問合せ/応答オペレー
ションコードを定義する特定のRFCを見てください、AFSDB資源レコードの
問題[RFC1183]は例外でこの文書に含まれます。このＲＦＣは[RFC2929]を時
代遅れにします。

IANA currently maintains a web page of DNS parameters available from
http://www.iana.org.
ＩＡＮＡは現在、http://www.iana.org から利用可能なDNSパラメタのウェブ
ページを維持します。

1.1. Terminology
1.1. 用語

"IETF Standards Action", "IETF Review", "Specification Required", and
"Private Use" are as defined in [RFC5226].
「ＩＥＴＦ標準手順」「ＩＥＴＦレビュー」「標準化要求」「私的利用」は
[RFC5226]で定義される通りです。

2. DNS Query/Response Headers
2. ＤＮＳ問合せ/応答ヘッダ

The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC2136] and [RFC2929]:
ＤＮＳ問合せと応答のヘッダは[RFC2136]と[RFC2929]にある下図のフィールド
とビットを含んでいます:

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|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The ID field identifies the query and is echoed in the response so
they can be matched.
IDフィールドは問合せを識別し、問合せと応答を対応付けるために応答で
返送されます。

The QR bit indicates whether the header is for a query or a response.
QRビットは、ヘッダが問合せ応答かを示します。

The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
some DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus, any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous, given existing
implementation. Such meanings may only be assigned by an IETF
Standards Action.
AAとTCとRDとRAとADとCDビットは、ビットによって問合せか応答でだけ
で意味を持ちます。しかしながら、いくつかのＤＮＳ実装は、ビットをクリ
アせずに問合せのヘッダの応答の初期値として使用します。したがって、
「問合せ」のビットを応答で異なる意味に使用したり、「応答」のビットに
問合せでの意味を定義する試みは、既存の実装を考えると、危険です。この
ような意味はＩＥＴＦ標準手順によってだけ割り当てできるかもしれません。

The unsigned integer fields query count (QDCOUNT), answer count
(ANCOUNT), authority count (NSCOUNT), and additional information
count (ARCOUNT) express the number of records in each section for all
OpCodes except Update [RFC2136]. These fields have the same
structure and data type for Update but are instead the counts for the
zone (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and
additional information (ARCOUNT) sections.
符号なし整数フィールドの問合せ個数(QDCOUNT)と回答個数(ANCOUNT)と権威
個数(NSCOUNT)と追加情報個数(ARCOUNT)は、更新[RFC2136]を除き、すべての
オペレーションコード(OpCode)で、各セクションのレコード数を表します。
これらのフィールドは更新でも同じ構造とデータ型を持ちますが、ゾーン
(ZOCOUNT)と前提条件(PRCOUNT)と更新(UPCOUNT)と追加情報(ARCOUNT)の個数
です。

2.1. One Spare Bit?
2.1. １つの予備ビット?

There have been ancient DNS implementations for which the Z bit being
on in a query meant that only a response from the primary server for
a zone is acceptable. It is believed that current DNS
implementations ignore this bit.
問合せでＺビットが設定されている場合、これがゾーンの第１サーバからの
応答だけが許容できることを意味していた古いＤＮＳ実装がありました。
現在のＤＮＳ実装がこのビットを無視すると信じられています。

Assigning a meaning to the Z bit requires an IETF Standards Action.
Ｚビットに意味を割り当てるのはＩＥＴＦ標準手順を必要とします。

2.2. OpCode Assignment
2.2. オペレーションコード割当

Currently DNS OpCodes are assigned as follows:
現在の、ＤＮＳオペレーションコードは以下の通り割り当てられています:

OpCode Name Reference
オペコード 名前 参照

0 Query [RFC1035]
問合せ
1 IQuery (Inverse Query, Obsolete) [RFC3425]
Ｉ問合せ(逆問合せ、時代遅れ)
2 Status [RFC1035]
状態
3 available for assignment
割当可能
4 Notify [RFC1996]
通知
5 Update [RFC2136]
更新
6-15 available for assignment
割当可能

New OpCode assignments require an IETF Standards Action as modified
by [RFC4020].
新しいオペコード割当は、[RFC4020]から変更になり、ＩＥＴＦ標準手順を
必要とします。

2.3. RCODE Assignment
2.3. 応答コード割当

It would appear from the DNS header above that only four bits of
RCODE, or response/error code, are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside
OPT RRs [RFC2671], TSIG RRs [RFC2845], and TKEY RRs [RFC2930]. The
OPT RR provides an 8-bit extension resulting in a 12-bit RCODE field,
and the TSIG and TKEY RRs have a 16-bit RCODE field.
ＤＮＳヘッダからは、たった４ビットの応答コード(RCODE)、または応答/
エラーコードだけが有効に見えるでしょう。しかしながら、応答コード
RCODEはＤＮＳ応答の先頭に現れるだけではなく、ＯＰＴ資源レコード
[RFC2671]やＴＳＩＧ資源レコード[RFC2845]やＴＫＥＹ資源レコード
[RFC2930]の中にも現れることができます。ＯＰＴ資源レコードは１２
ビットの応答フィールドをもたらす８ビットの拡張を提供します、そして、
ＴＳＩＧとＴＫＥＹ資源レコードには１６ビットの応答フィールドがあり
ます。

Error codes appearing in the DNS header and in these three RR types
all refer to the same error code space with the single exception of
error code 16, which has a different meaning in the OPT RR from its
meaning in other contexts. See table below.
ＤＮＳヘッダとこれらの３つのＲＲタイプで現れるエラーコードは、エラー
コード１６を唯一の例外として、すべて同じエラーコード空間を参照します、
エラーコード１６はＯＰＴ資源レコードで他の意味と異なる意味を持ちます。
以下の表を見てください。

RCODE Name Description Reference
エラーコード 名前 意味 参照
Decimal
１０進数
Hexadecimal
１６進数
0 NoError No Error [RFC1035]
エラーなし
1 FormErr Format Error [RFC1035]
フォーマットエラー
2 ServFail Server Failure [RFC1035]
サーバー故障
3 NXDomain Non-Existent Domain [RFC1035]
実在しないドメイン
4 NotImp Not Implemented [RFC1035]
実装していません
5 Refused Query Refused [RFC1035]
質問拒否
6 YXDomain Name Exists when it should not [RFC2136]
あるべきでない名前が存在します
7 YXRRSet RR Set Exists when it should not [RFC2136]
存在すべきでない資源レコードセットが存在します。
8 NXRRSet RR Set that should exist does not [RFC2136]
資源レコードセットが存在するべきですがありません。
9 NotAuth Server Not Authoritative for zone [RFC2136]
サーバはゾーンの権威でありません。
10 NotZone Name not contained in zone [RFC2136]
名前はゾーンに含まれていません。
11 - 15 Available for assignment
割当可能
16 BADVERS Bad OPT Version [RFC2671]
ＯＰＴバージョン誤り
16 BADSIG TSIG Signature Failure [RFC2845]
ＴＳＩＧ署名失敗
17 BADKEY Key not recognized [RFC2845]
認識できない鍵
18 BADTIME Signature out of time window [RFC2845]
署名が時間外である。
19 BADMODE Bad TKEY Mode [RFC2930]
ＴＫＥＹモード誤り
20 BADNAME Duplicate key name [RFC2930]
鍵名重複
21 BADALG Algorithm not supported [RFC2930]
アルゴリズム未サポート
22 BADTRUC Bad Truncation [RFC4635]
切詰め誤り
23 - 3,840
0x0017 - 0x0F00 Available for assignment
割当可能

3,841 - 4,095
0x0F01 - 0x0FFF Private Use
私的利用

4,096 - 65,534
0x1000 - 0xFFFE Available for assignment
割当可能

65,535
0xFFFF Reserved, can only be allocated by an IETF
Standards Action.
予約、ＩＥＴＦ標準化行動によってのみ割り当て
できます。

Since it is important that RCODEs be understood for interoperability,
assignment of new RCODE listed above as "available for assignment"
requires an IETF Review.
相互運用性のためにRCODEが理解されているのが重要であるので、上記で
「割当可能」とされている新しいRCODEの割当はＩＥＴＦレビューを必要
とします。

3. DNS Resource Records
3. ＤＮＳ資源レコード

All RRs have the same top-level format, shown in the figure below
taken from [RFC1035].
すべての資源レコードには、[RFC1035]から写した下図に示す、同じ先頭の
形式があります。

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 /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

NAME is an owner name, i.e., the name of the node to which this
resource record pertains. NAMEs are specific to a CLASS as described
in section 3.2. NAMEs consist of an ordered sequence of one or more
labels, each of which has a label type [RFC1035] [RFC2671].
名前(NAME)は所有者名で、この資源レコードが所属するノードの名前です。
名前は３．２章で説明されるようにクラス(CLASS)依存です。名前は１個
以上のラベルの順序付きの列から成ります、それぞれのラベルはラベル種
別を持ちます[RFC1035] [RFC2671]。

TYPE is a 2-octet unsigned integer containing one of the RRTYPE
codes. See section 3.1.
種別(TYPE)は資源レコード種別(RRTYPE)コードの１つを含む２オクテット
の符号なし整数です。３．１章を見てください。

CLASS is a 2-octet unsigned integer containing one of the RR CLASS
codes. See section 3.2.
クラス(CLASS)は資源レコードクラスコードの１つを含む２オクテット符号
なし整数です。３．２章を見てください。

TTL is a 4-octet (32-bit) unsigned integer that specifies, for data
TYPEs, the number of seconds that the resource record may be cached
before the source of the information should again be consulted. Zero
is interpreted to mean that the RR can only be used for the
transaction in progress.
寿命(TTL)は４オクテット(32ビット)符号なし整数です、データ種別に対し、
情報源が再び参照されるまで、資源レコードがキャッシュされるかもしれな
い秒数です。ゼロは、資源レコードを進行中の取引にだけ使用できることを
意味すると解釈されます。

RDLENGTH is an unsigned 16-bit integer that specifies the length in
octets of the RDATA field.
資源データ長(RDLENGTH)はオクテット単位で資源データ(RDATA)フィールドの
長さを指定する符号なし１６ビット整数です。

RDATA is a variable length string of octets that constitutes the
resource. The format of this information varies according to the
TYPE and, in some cases, the CLASS of the resource record.
資源データ(RDATA)は資源を構成する可変長オクテット列です。この情報の形
式は資源レコード種別毎に、しばしばクラス毎に、異なります。

3.1. RRTYPE IANA Considerations
3.1. 資源レコード種別のＩＡＮＡ割当の問題

There are three subcategories of RRTYPE numbers: data TYPEs, QTYPEs,
and Meta-TYPEs.
資源レコード種別番号は３つに分けられます:データ種別、問合せ種別、
メタ種別。

Data TYPEs are the means of storing data. QTYPES can only be used in
queries. Meta-TYPEs designate transient data associated with a
particular DNS message and, in some cases, can also be used in
queries. Thus far, data TYPEs have been assigned from 1 upward plus
the block from 100 through 103 and from 32,768 upward, while Q and
Meta-TYPEs have been assigned from 255 downward except for the OPT
Meta-RR, which is assigned TYPE 41. There have been DNS
implementations that made caching decisions based on the top bit of
the bottom byte of the RRTYPE.
データ種別はデータを保存する手段です。問合せ種別は問合せににみ使用で
きます。メタ種別は特定のＤＮＳメッセージに関連する一時的なデータを指
定し、また、いくつかの場合、問合せに使用できます。これまでのところ、
データ種別が１から昇順と、100から103のブロックと、32,768から昇順に
割り当てられ、OPTメタ資源レコードが種別41を割り当てられたのを例外と
し、Ｑ種別とメタ種別は、255から降順に割り当てられました。資源レコード
種別の下位バイトの最上位ビットに基づくいてキャッシュを決定するＤＮＳ
実装がありました。

There are currently three Meta-TYPEs assigned: OPT [RFC2671], TSIG
[RFC2845], and TKEY [RFC2930]. There are currently five QTYPEs
assigned: * (ALL), MAILA, MAILB, AXFR, and IXFR.
現在割当て済みのメタ種別は３つあります: OPT [RFC2671]、TSIG [RFC2845]、
TKEY [RFC2930]。現在割当て済みの問合せ種別は５つあります: * (ALL)、
MAILA、MAILB、AXFR、IXFR。

RRTYPEs have mnemonics that must be completely disjoint from the
mnemonics used for CLASSes and that must match the following regular
expression:
資源レコード種別は通称(ニーモニック)を持ち、通称はクラス内で他の通称
と完全に見分けできなければならず、以下の正規表現に一致しなければなり
ません:

[A-Z][A-Z0-9-]*

Considerations for the allocation of new RRTYPEs are as follows:
新しい資源レコード種別割当の考慮事項は以下の通りです:

Decimal (十進数)
Hexadecimal (十六進数)

0
0x0000 - RRTYPE zero is used as a special indicator for the SIG (0)
RR [RFC2931] and in other circumstances, and it must never be
allocated for ordinary use.
- SIG(0)資源レコード[RFC2931]やその他の事情を示す特別な表示と
して使用し、決して通常の使用のために割当ててはいけません。

1 - 127
0x0001 - 0x007F - Remaining RRTYPEs in this range are assigned for
data TYPEs by the DNS RRTYPE Allocation Policy as specified
in Section 3.1.1.
- この範囲の残りの資源レコード種別は、３．１．１章に指定される
ＤＮＳ資源レコード種別割当ポリシによって、データ種別に割り当
てられます。

128 - 255
0x0080 - 0x00FF - Remaining RRTYPEs in this range are assigned for Q
and Meta TYPEs by the DNS RRTYPE Allocation Policy as
specified in Section 3.1.1.
- この範囲の残りの資源レコード種別は、３．１．１章に指定される
ＤＮＳ資源レコード種別割当割当ポリシによって、ＱとメタTYPEに
割り当てられます。

256 - 61,439
0x0100 - 0xEFFF - Remaining RRTYPEs in this range are assigned for
data RRTYPEs by the DNS RRTYPE Allocation Policy as
specified in Section 3.1.1. (32,768 and 32,769 (0x8000 and
0x8001) have been assigned.)
- この範囲の残りの資源レコード種別は、３．１．１章に指定される
ＤＮＳ資源レコード種別割当割当ポリシによって、データTYPEに
割り当てられます。(32,768と32,769 (0x8000と0x8001)は割当済
みです。)

61,440 - 65,279
0xF000 - 0xFEFF - Reserved for future use. IETF Review required to
define use.
- 将来の使用のために、予約されます。使用方法の定義にはＩＥＴＦ
レビューが必要です。

65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
- 私用。

65,535
0xFFFF - Reserved; can only be assigned by an IETF Standards Action.
- 予約：ＩＥＴＦ標準手順でのみ割当できます。

3.1.1. DNS RRTYPE Allocation Policy
3.1.1. ＤＮＳ資源レコード種別割当ポリシ

Parameter values specified in Section 3.1 above, as assigned based on
DNS RRTYPE Allocation Policy, are allocated by Expert Review if they
meet the two requirements listed below. There will be a pool of a
small number of Experts appointed by the IESG. Each application will
be ruled on by an Expert selected by IANA. In any case where the
selected Expert is unavailable or states they have a conflict of
interest, IANA may select another Expert from the pool.
ＤＮＳ資源レコード種別割当ポリシで割り当てると３．１章で示されたパラ
メータ値は、以下にリストアップされた２つの必要条件を満たすなら、専門
家レビューにより割当てられます。ＩＥＳＧによって任命された少数の専門
家がいるでしょう。各アプリケーションはＩＡＮＡによって選択された専門
家によって判決を下されるでしょう。 選択された専門家の手があいていない
か、専門家が利害関係者であると述べる場合は、ＩＡＮＡは別の専門家を選
択するかもしれません。

Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs
that do not meet the requirements below may nonetheless be allocated
by IETF Standards Action as modified by [RFC4020].
３．１．２章は専門家のためのいくつかのガイドラインを与えます。
[RFC4020]で変更されたように。以下の条件を満たさない資源レコード種別が
はＩＥＴＦ標準手順で割り当てられるかもしれません。

1. A complete template as specified in Appendix A has been posted for
three weeks to the namedroppers@ops.ietf.org mailing list before
the Expert Review decision.
付録Ａで指定される完全なテンプレートが専門家レビュー決定の３週間前
にnamedroppers@ops.ietf.orgメーリングリストに掲示されます。

Note that partially completed or draft templates may be posted
directly by the applicant for comment and discussion, but the
formal posting to start the three week period is made by the
Expert.
部分的に完成したものや草稿のテンプレートがコメントと議論のために直
接掲示されるかもしれませんが、３週間の期間を始める正式な掲示が専門
家によってされます。

2. The RR for which an RRTYPE code is being requested is either (a) a
data TYPE that can be handled as an Unknown RR as described in
[RFC3597] or (b) a Meta-Type whose processing is optional, i.e.,
it is safe to simply discard RRs with that Meta-Type in queries or
responses.
資源レコード種別コードが要求されている資源レコードは、(a) [RFC3597]
で説明される未知資源レコードとして扱うことができるデータ種別か、(b)
その処理をするかどうかは任意であるメタ種別、すなわち問合せか応答で
単にそのメタ種別資源レコードを破棄するのが安全なメタ種別のどちらか
です。

Note that such RRs may include additional section processing,
provided such processing is optional.
このような資源レコードが追加セクションに含まれるかもしれませんが、
その処理が任意なことに注意してください。

No less than three weeks and no more than six weeks after a completed
template has been formally posted to namedroppers@ops.ietf.org, the
selected Expert shall post a message, explicitly accepting or
rejecting the application, to IANA, namedroppers@ops.ietf.org, and
the email address provided by the applicant. If the Expert does not
post such a message, the application shall be considered rejected but
may be re-submitted to IANA.
完成したテンプレートが正式に namedroppers@ops.ietf.orgに掲示された後、
少なくとも３週間、多くとも６週間後に、選択された専門家は、アプリケー
ションが受理されたか拒否されたかを明示するメッセージを、ＩＡＮＡと
namedroppers@ops.ietf.orgと応募者の示したＥメールアドレスに送るでしょ
う。専門家がそのようなメッセージを掲示しないなら、アプリケーションは、
拒絶されていると考えられますが、ＩＡＮＡに再提出されるかもしれません。

IANA shall maintain a public archive of approved templates.
ＩＡＮＡは承認されたテンプレートの公的アーカイブを維持するものとします。

3.1.2. DNS RRTYPE Expert Guidelines
3.1.2. ＤＮＳ資源レコード種別の専門家ガイドライン

The selected DNS RRTYPE Expert is required to monitor discussion of
the proposed RRTYPE, which may occur on the namedroppers@ops.ietf.org
mailing list, and may consult with other technical experts as
necessary. The Expert should normally reject any RRTYPE allocation
request that meets one or more of the following criterion:
選択されたＤＮＳ資源レコード種別専門家は、多分namedroppers@ops.ietf.org
メーリングリストで行われる、提案された資源レコード種別の議論を監視し、
必要に応じて他の専門家と相談するかもしれません通常、専門家は以下の評
価基準の１つ以上を満たす資源レコード種別の配布要求を拒絶するはずです:

1. Was documented in a manner that was not sufficiently clear to
evaluate or implement.
文書に評価や実装ができるほどの明確さがない場合。

2. The proposed RRTYPE or RRTYPEs affect DNS processing and do not
meet the criteria in point 2 of Section 3.1.1 above.
提案された資源レコード種別がＤＮＳ処理に影響し、上記３．１．１章の
ポイント２の評価基準を満たしません。

3. The documentation of the proposed RRTYPE or RRTYPEs is incomplete.
(Additional documentation can be provided during the public
comment period or by the Expert.)
提案された資源レコード種別の文書が不完全です。(パブリックコメント
の期間中か、専門家による、追加文書が提供できます。)

4. Application use as documented makes incorrect assumptions about
DNS protocol behavior, such as wild cards, CNAME, DNAME, etc.
文書化されるアプリケーションはＤＮＳプロトコルの、ワイルドカード・
別名・ＤＮＡＭＥなどの、振る舞いに不正確な仮定をします

5. An excessive number of RRTYPE values is being requested when the
purpose could be met with a smaller number or with Private Use
values.
より少ない個数か私的利用値で目的を満たすことができるのに、過度の
個数の資源レコード種別値が要求されています。

3.1.3. Special Note on the OPT RR
3.1.3. ＯＰＴ資源レコードの特別な注意

The OPT (OPTion) RR (RRTYPE 41) and its IANA Considerations are
specified in [RFC2671]. Its primary purpose is to extend the
effective field size of various DNS fields including RCODE, label
type, OpCode, flag bits, and RDATA size. In particular, for
resolvers and servers that recognize it, it extends the RCODE field
from 4 to 12 bits.
ＯＰＴ（オプション）資源レコード（資源レコード種別４１）とそのＩＡＮＡ
の考慮は[RFC2671]で指定されます。この資源レコードの主な目的は応答コー
ドやラベル種別やオペレーションコードやフラグビットや資源データサイズな
どの様々なＤＮＳフィールドの有効サイズを広げることです。特に、これを認
識するリゾルバとサーバで、応答フィールドを４ビットから１２ビットい拡張
します。

3.1.4. The AFSDB RR Subtype Field
3.1.4. AFSDB資源レコード副種別フィールド

The AFSDB RR [RFC1183] is a CLASS-insensitive RR that has the same
RDATA field structure as the MX RR, but the 16-bit unsigned integer
field at the beginning of the RDATA is interpreted as a subtype as
follows:
AFSDB資源レコード[RFC1183]は、ＭＸ資源レコードと同じ資源データフィー
ルド構造をもつ、クラス非依存の資源レコードですが、資源データの始めの
１６ビットの符号なし整数フィールドが以下の副種別と解釈されます:

Decimal (十進数)
Hexadecimal (十六進数)

0
0x0000 - Reserved; allocation requires IETF Standards Action.
予約；配布はＩＥＴＦ標準手順を必要とします。

1
0x0001 - Andrews File Service v3.0 Location Service [RFC1183].
アンドリュースファイルサービスv3.0位置サービス[RFC1183]

2
0x0002 - DCE/NCA root cell directory node [RFC1183].
DCE/NCAはルートセルディレクトリノード[RFC1183]

3 - 65,279
0x0003 - 0xFEFF - Allocation by IETF Review.
ＩＥＴＦレビューによる割当。

65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
私用

65,535
0xFFFF - Reserved; allocation requires IETF Standards Action.
予約；配布はＩＥＴＦ標準手順を必要とします。

3.2. RR CLASS IANA Considerations
3.2. 資源レコードクラスのＩＡＮＡの考慮

There are currently two subcategories of DNS CLASSes: normal,
data-containing classes and QCLASSes that are only meaningful in
queries or updates.
現在、ＤＮＳクラスには２つに分けられます: 正常なデータを含むクラス
と、問合せか更新でだけ意味を持つＱクラス。

DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the name space or root servers for one data
CLASS and those for another data CLASS. The same DNS NAME can have
completely different meanings in different CLASSes. The label types
are the same, and the null label is usable only as root in every
CLASS. As global networking and DNS have evolved, the IN, or
Internet, CLASS has dominated DNS use.
ＤＮＳクラスはほとんど使用されていませんが、別次元のＤＮＳ分散データ
ベースを構成します。特に、１つのデータクラスの名前空間とルートサーバ
は、別データクラスのとどんな関係も必要ありません。同じＤＮＳ名がクラ
スが異なると完全に異なる意味を持つことができます。ラベル形式も同じで、
そして、ヌルラベルは単にルートとしてあらゆるクラスで使用可能です。グ
ローバルネットワークとＤＮＳの歴史により、ＩＮクラス、またはインター
ネットクラス、がＤＮＳの主要になりました。

As yet there has not be a requirement for "meta-CLASSes". That would
be a CLASS to designate transient data associated with a particular
DNS message, which might be usable in queries. However, it is
possible that there might be a future requirement for one or more
"meta-CLASSes".
まだ、「メタクラス」の要件はありません。これは、問合せで使用可能かも
しれない特定のＤＮＳメッセージに関連している一時的なデータを指定する
ためでしょう。しかしながら、将来の「メタクラス」で要件が発生するかも
しれません。

CLASSes have mnemonics that must be completely disjoint from the
mnemonics used for RRTYPEs and that must match the following regular
expression:
クラスは通称(ニーモニック)を持ち、これは資源種別の通称と完全に異なっ
ていなければならず、以下の正規表現に一致しなければなりません:

[A-Z][A-Z0-9-]*

The current CLASS assignments and considerations for future
assignments are as follows:
現在のクラスの割当と、将来の割当の考慮事項は以下の通りです:

Decimal (十進数)
Hexadecimal (十六進数)

0
0x0000 - Reserved; assignment requires an IETF Standards Action.
予約；割当はＩＥＴＦ標準手順を必要とします。

1
0x0001 - Internet (IN).
インターネット(IN)。

2
0x0002 - Available for assignment by IETF Review as a data CLASS.
ＩＥＴＦレビューにより、データクラスとして割当可能です。

3
0x0003 - Chaos (CH) [Moon1981].
カオス(CH)

4
0x0004 - Hesiod (HS) [Dyer1987].
ヘシオドス(HS)

5 - 127
0x0005 - 0x007F - Available for assignment by IETF Review for data
CLASSes only.
ＩＥＴＦレビューにより、データクラスにのみ割当可能です。

128 - 253
0x0080 - 0x00FD - Available for assignment by IETF Review for
QCLASSes and meta-CLASSes only.
ＩＥＴＦレビューにより、Ｑクラスとメタクラスに割当可能です。

254
0x00FE - QCLASS NONE [RFC2136].
Ｑクラス ＮＯＮＥ

255
0x00FF - QCLASS * (ANY) [RFC1035].
Ｑクラス ＊（ＡＮＹ）

256 - 32,767
0x0100 - 0x7FFF - Assigned by IETF Review.
ＩＥＴＦレビューにより割当可能です。

32,768 - 57,343
0x8000 - 0xDFFF - Assigned for data CLASSes only, based on
Specification Required as defined in [RFC5226].
[RFC5226]で定義される特別要請に基づき、データクラ
スに割当て済みです。

57,344 - 65,279
0xE000 - 0xFEFF - Assigned for QCLASSes and meta-CLASSes only, based
on Specification Required as defined in [RFC5226].
[RFC5226]で定義される特別要請に基づき、Ｑクラスと
メタクラスに割当て済みです。

65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
私用

65,535
0xFFFF - Reserved; can only be assigned by an IETF Standards Action.
予約；割当はＩＥＴＦ標準手順を必要とします。

3.3. Label Considerations
3.3. ラベル問題

DNS NAMEs are sequences of labels [RFC1035].
ＤＮＳ名ははラベルの列です[RFC1035]。

3.3.1. Label Types
3.3.1. ラベル形式

At the present time, there are two categories of label types: data
labels and compression labels. Compression labels are pointers to
data labels elsewhere within an RR or DNS message and are intended to
shorten the wire encoding of NAMEs.
現在に、ラベル形式に２つの種類があります：データラベルと圧縮ラベル。
圧縮ラベルは、資源レコードやＤＮＳメッセージ中のデータラベルへのポ
インタで、名前のバイト長を短くすることを意図します。

The two existing data label types are sometimes referred to as Text
and Binary. Text labels can, in fact, include any octet value
including zero-value octets, but many current uses involve only
[US-ASCII]. For retrieval, Text labels are defined to treat ASCII
upper and lower case letter codes as matching [RFC4343]. Binary
labels are bit sequences [RFC2673]. The Binary label type is
Experimental [RFC3363].
２つの既存のデータラベル形式は、時々、テキストとバイナリと呼ばれま
す。事実上、テキストラベルはゼロ値を含む全てのオクテット値を含むこ
とができますが、現在の多くの使用実態は[US-ASCII]だけを含みます。検
索において、テキストラベルは、アスキーの大文字コードと小文字コード
を同一に扱うと定義されています[RFC4343]。バイナリラベル種別は実験的
です[RFC3363]。

IANA considerations for label types are given in [RFC2671].
ラベル形式のＩＡＮＡ割当の考慮事項は[RFC2671]で与えられます。

3.3.2. Label Contents and Use
3.3.2. ラベル内容と使い方

The last label in each NAME is "ROOT", which is the zero-length
label. By definition, the null or ROOT label cannot be used for any
other NAME purpose.
各名前の最後のラベルは「ルート」で、長さがゼロのラベルです。定義上、
ヌル又はルートラベルは、他の名前で使用できません。

NAMEs are local to a CLASS. The Hesiod [Dyer1987] and Chaos
[Moon1981] CLASSes are for essentially local use. The IN, or
Internet, CLASS is thus the only DNS CLASS in global use on the
Internet at this time.
名前はクラス固有です。ヘシオドス[Dyer1987]とカオス[Moon1981]クラスは
本質的にローカルな使用のためのものです。現時点でＩＮまたはインターネッ
トクラスがインターネットにおけるグローバルに使用できる唯一のＤＮＳク
ラスです。

A somewhat out-of-date description of name allocation in the IN Class
is given in [RFC1591]. Some information on reserved top-level domain
names is in BCP 32 [RFC2606].
[RFC1591]でＩＮクラスの名前割当のいくらか時代遅れな記述があります。
予約された最上位ドメイン名のいくつかの情報がＢＣＰ３２[RFC2606]にあり
ます。

4. Security Considerations
4. セキュリティの問題

This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC4033], [RFC4034], and
[RFC4035] for secure DNS considerations.
この文書は一般的なＤＮＳパラメータの割当のＩＡＮＡの考慮を扱い、セキュ
リティを扱いません。安全なＤＮＳの問題に関しては[RFC4033]と[RFC4034]
と[RFC4035]を見てください。

5. IANA Considerations
5. ＩＡＮＡの考慮

This document consists entirely of DNS IANA Considerations and
includes the following changes from its predecessor [RFC2929]. It
affects the DNS Parameters registry and its subregistries, which are
available from http://www.iana.org.
この文書は、もっぱらＤＮＳのＩＡＮＡの考慮からなり、前の[RFC2929]から
以下の変更があります。これはＤＮＳパラメータの登録とその副登録に影響
し、これはhttp://www.iana.orgから利用可能です。

1. In the Domain Name System "Resource record (RR) TYPES and QTYPEs"
registry, it changes most "IETF Consensus" and all "Specification
Required" allocation policies for RRTYPEs to be "DNS TYPE
Allocation Policy" and changes the policy for RRTYPE 0xFFFF to be
"IETF Standards Action". Remaining instances of "IETF Consensus"
are changed to "IETF Review", per [RFC5226]. It also specifies
the "DNS TYPE Allocation Policy", which is based on Expert Review
with additional provisions and restrictions, including the
submittal of a completed copy of the template in Appendix A to
dns-rrtype-applications@ietf.org, in most cases, and requires
"IETF Standards Action" as modified by [RFC4020] in other cases.
ドメイン名システムの「資源レコード(RR)種別とＱ種別」登記所で、ほと
んどの「ＩＥＴＦ合意」と全ての「仕様化が必要」な、資源レコード種別
の割当方針は、「ＤＮＳ種別割当方針」に変更され、資源レコード種別
0xFFFFの方針は「ＩＥＴＦ標準手順」に変更されました。残りの「ＩＥＴ
Ｆ合意」の物は[RFC5226]の「ＩＥＴＦレビュー」に変更されます。また、
これは「ＤＮＳ種別割当方針」を指定します、これは追加の条件と制限の
基づく専門家レビューに基づき、付録Ａのテンプレートの完成版の
dns-rrtype-applications@ietf.orgへの提出を含み、多くの場合、
[RFC4020]を他で修正した「ＩＥＴＦ標準手順」を必要とします

IANA shall establish a process for accepting such templates,
selecting an Expert from those appointed to review such template
form applications, archiving, and making available all approved
RRTYPE allocation templates. It is the duty of the selected
Expert to post the formal application template to the
namedroppers@ops.ietf.org mailing list. See Section 3.1 and
Appendix A for more details.
ＩＡＮＡはこのようなテンプレートを受け入れるために手順を作るとしま
す、そのようなテンプレート形式アプリケーションを評価するために任命
された専門家を選択し、すべての承認された資源種別割当テンプレートを
利用可能に格納し利用可能にします。正式なアプリケーションテンプレー
トを namedroppers@ops.ietf.org メーリングリストに掲示するのは、選択
された専門家の義務です。その他の詳細に関しては３．１章と付録Ａを見
てください。

2. For OpCodes (see Section 2.2), it changes "IETF Standards Action"
allocation requirements to add "as modified by [RFC4020]".
オペコード(２．２章参照)に関して、「ＩＥＴＦ標準手順」の割当要件に
「[RFC4020]で変更された」を加える変更をします。

3. It changes the allocation status of RCODE 0xFFFF to be "IETF
Standards Action required". See Section 2.3.
この文書は、応答コード0xFFFFを「ＩＥＴＦ標準手順が必要」に割当状態
を変更します。２．３章を参照してください。

4. It adds an IANA allocation policy for the AFSDB RR Subtype field,
which requires the creation of a new registry. See Section 3.1.4.
この文書はAFSDB資源レコード副種別フィールドのＩＡＮＡ割当方針を追
加します、これは新しい登記所の作成を必要とします。３．１．４章を参
照してください。

5. It splits Specification Required CLASSes into data CLASSes and
query or meta CLASSes. See Section 3.2.
この文書は標準化が必用なクラスをデータクラスと、質問とメタクラスに
分割します。３．２章を参照してください。

Appendix A. RRTYPE Allocation Template
付録Ａ．資源レコード種別割当テンプレート

DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
ＤＮＳ資源レコード種別パラメタ割当テンプレート

When ready for formal consideration, this template is to be submitted
to IANA for processing by emailing the template to
dns-rrtype-applications@ietf.org.
正式な考慮事項の準備ができているとき、ＩＡＮＡが処理をはじめるため、
このテンプレートをdns-rrtype-applications@ietf.orgにメールして、
ＩＡＮＡに提出することになっています。

A. Submission Date:
提案日付:

B. Submission Type:
提案種別:
[ ] New RRTYPE
新資源レコード種別
[ ] Modification to existing RRTYPE
既存資源レコードの変更

C. Contact Information for submitter:
提案者の連絡情報
Name:
名前：
Email Address:
Ｅメールアドレス：
International telephone number:
国際電話番号：
Other contact handles:
他の連絡手法：

(Note: This information will be publicly posted.)
(注意: この情報は公に掲示されるでしょう。)

D. Motivation for the new RRTYPE application?
新しい資源レコードアプリケーションの動機は？
Please keep this part at a high level to inform the Expert and
reviewers about uses of the RRTYPE. Remember most reviewers
will be DNS experts that may have limited knowledge of your
application space.
この部分はこの資源レコードの使い方を専門家や評論家に知らせるた
めに、高いレベルに保って下さい。ほとんどの評論家がＤＮＳ専門家
で、あなたアプリケーションに関する知識が少ないかも知れないこと
を覚えていてください。

E. Description of the proposed RR type.
提案された資源レコード種別の記述。
This description can be provided in-line in the template, as an
attachment, or with a publicly available URL:
この記述はテンプレート内に書くことも、添付や、公的に利用可能な
URLでも提供できます:

F. What existing RRTYPE or RRTYPEs come closest to filling that
need and why are they unsatisfactory?
既存の資源レコード種別が必要性を満たせそうですか、そして、それら
はなぜ不十分ですか?

G. What mnemonic is requested for the new RRTYPE (optional)?
どんな通称が新しい資源レコード種別に必用ですか(任意)？
Note: This can be left blank and the mnemonic decided after the
template is accepted.
注意：これを空白のままとし、テンプレート受理後に通称を決める事が
出来ます。

H. Does the requested RRTYPE make use of any existing IANA
Registry or require the creation of a new IANA sub-registry in
DNS Parameters?
要求された資源レコード種別は何か既存のＩＡＮＡ登記所を利用します
か、あるいはＤＮＳパラメータに新しいＩＡＮＡ登記所の作成を必要と
しますか？
If so, please indicate which registry is to be used or created.
If a new sub-registry is needed, specify the allocation policy
for it and its initial contents. Also include what the
modification procedures will be.
もしそうだとすれば、どの登記所が使用されたらよいか、または作成さ
れたらよいかを示してください。新しい副登記所が必要であるなら、そ
の割当方針と初期内容を指定してください。また、変更手順がどうなる
かを含めてください。

I. Does the proposal require/expect any changes in DNS
servers/resolvers that prevent the new type from being
processed as an unknown RRTYPE (see [RFC3597])?
提案は、新しい種別が未知の資源レコード種別として処理されるのを防
ぐために、ＤＮＳサーバ/リゾルバにおける変更を必要/予想しますか？
（[RFC3597]参照）

J. Comments:
コメント:

Normative References
基準的参考文献

[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.

[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.

[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
2002.

[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.

[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February
2005.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.

[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message
Authentication Code, Secure Hash Algorithm) TSIG
Algorithm Identifiers", RFC 4635, August 2006.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.

[US-ASCII] ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York,
1968.

Informative References
有益な参考文献

[Dyer1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987.

[Moon1981] Moon, D., "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence
Laboratory, June 1981.

[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183, October
1990.

[RFC1591] Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.

[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.

[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.

[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42,
RFC 2929, September 2000.

[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, September 2000.

[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002.

[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
Insensitivity Clarification", RFC 4343, January 2006.

Author's Address
著者のアドレス

Donald E. Eastlake 3rd
Stellar Switches
155 Beaver Street
Milford, MA 01757 USA

Phone: +1-508-634-2066 (h)
EMail: d3e3e3@gmail.com

Japanese translation by Ishida So