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


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
              ドメインネームシステム(DNS)IANAの考察

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 Notice
著作権表示

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

   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.
   事実上、この文書はBCP78とこの文書の公表日に有効なIETF文書
   へのIETF信託の法的な関係( 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.
   インターネット番号割当権威(IANA)パラメータの割当はドメイン名シス
   テム(DNS)の資源レコード種別、クラス、オペレーションコード、エラー
   コード、DNSプロトコルメッセージヘッダビットとAFSDB資源レコー
   ド副種別で指定されます。


Table of Contents
目次

   1.  Introduction
   1.  序論
      1.1.  Terminology
      1.1.  用語
   2.  DNS Query/Response Headers
   2.  DNS問合せ/応答ヘッダ
      2.1.  One Spare Bit?
      2.1.  1つの予備ビット?
      2.2.  OpCode Assignment
      2.2.  オペレーションコード割当
      2.3.  RCODE Assignment
      2.3.  応答コード割当
   3.  DNS Resource Records
   3.  DNS資源レコード
      3.1.  RRTYPE IANA Considerations
      3.1.  資源レコード種別のIANA割当の問題
           3.1.1.  DNS RRTYPE Allocation Policy
           3.1.1.  DNS資源レコード種別割当ポリシ
           3.1.2.  DNS RRTYPE Expert Guidelines
           3.1.2.  DNS資源レコード種別の専門家ガイドライン
           3.1.3.  Special Note on the OPT RR
           3.1.3.  OPT資源レコードの特別な注意
           3.1.4.  The AFSDB RR Subtype Field
           3.1.4.  AFSDB資源レコード副種別フィールド
      3.2.  RR CLASS IANA Considerations
      3.2.  資源レコードクラスのIANAの考慮
      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.  IANAの考慮
   Appendix A.  RRTYPE Allocation Template
   付録A.資源レコード種別割当テンプレート
   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.
   ドメインネームシステム(DNS)はドメイン名下にある「資源レコード」
   (RR)を保存する複製され分散された安全な階層型データベースを提供しま
   す。DNSデータは独自に維持できる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].
   この文書はDNS問合せと応答のヘッダと全ての資源レコードに適用される
   一般的なIANAパラメータ割当問題の考察を直接又は間接的に供給します。
   これは特定の資源レコード種別や問合せ/応答オペレーションコードにだけ
   に適用される追加のIANAの考察があるかもしれません。考察については、
   もし定義されているなら、これらの資源レコード種別や問合せ/応答オペレー
   ションコードを定義する特定のRFCを見てください、AFSDB資源レコードの
   問題[RFC1183]は例外でこの文書に含まれます。このRFCは[RFC2929]を時
   代遅れにします。

   IANA currently maintains a web page of DNS parameters available from
   http://www.iana.org.
   IANAは現在、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].
   「IETF標準手順」「IETFレビュー」「標準化要求」「私的利用」は
   [RFC5226]で定義される通りです。

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

   The header for DNS queries and responses contains field/bits in the
   following diagram taken from [RFC2136] and [RFC2929]:
   DNS問合せと応答のヘッダは[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ビットは、ビットによって問合せか応答でだけ
   で意味を持ちます。しかしながら、いくつかのDNS実装は、ビットをクリ
   アせずに問合せのヘッダの応答の初期値として使用します。したがって、
   「問合せ」のビットを応答で異なる意味に使用したり、「応答」のビットに
   問合せでの意味を定義する試みは、既存の実装を考えると、危険です。この
   ような意味はIETF標準手順によってだけ割り当てできるかもしれません。

   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.  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.
   問合せでZビットが設定されている場合、これがゾーンの第1サーバからの
   応答だけが許容できることを意味していた古いDNS実装がありました。
   現在のDNS実装がこのビットを無視すると信じられています。

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

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

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

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

          0     Query                              [RFC1035]
                問合せ
          1     IQuery (Inverse Query, Obsolete)   [RFC3425]
                I問合せ(逆問合せ、時代遅れ)
          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]から変更になり、IETF標準手順を
   必要とします。

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.
   DNSヘッダからは、たった4ビットの応答コード(RCODE)、または応答/
   エラーコードだけが有効に見えるでしょう。しかしながら、応答コード
   RCODEはDNS応答の先頭に現れるだけではなく、OPT資源レコード
   [RFC2671]やTSIG資源レコード[RFC2845]やTKEY資源レコード
   [RFC2930]の中にも現れることができます。OPT資源レコードは12
   ビットの応答フィールドをもたらす8ビットの拡張を提供します、そして、
   TSIGとTKEY資源レコードには16ビットの応答フィールドがあり
   ます。

   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.
   DNSヘッダとこれらの3つのRRタイプで現れるエラーコードは、エラー
   コード16を唯一の例外として、すべて同じエラーコード空間を参照します、
   エラーコード16はOPT資源レコードで他の意味と異なる意味を持ちます。
   以下の表を見てください。

        RCODE   Name    Description                        Reference
        エラーコード 名前 意味                             参照
        Decimal
        10進数
          Hexadecimal
          16進数
         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]
                        OPTバージョン誤り
        16    BADSIG    TSIG Signature Failure             [RFC2845]
                        TSIG署名失敗
        17    BADKEY    Key not recognized                 [RFC2845]
                        認識できない鍵
        18    BADTIME   Signature out of time window       [RFC2845]
                        署名が時間外である。
        19    BADMODE   Bad TKEY Mode                      [RFC2930]
                        TKEYモード誤り
        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.
                        予約、IETF標準化行動によってのみ割り当て
                        できます。

   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の割当はIETFレビューを必要
   とします。

3.  DNS Resource Records
3.  DNS資源レコード

   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)は所有者名で、この資源レコードが所属するノードの名前です。
   名前は3.2章で説明されるようにクラス(CLASS)依存です。名前は1個
   以上のラベルの順序付きの列から成ります、それぞれのラベルはラベル種
   別を持ちます[RFC1035] [RFC2671]。

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

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

   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)は4オクテット(32ビット)符号なし整数です、データ種別に対し、
   情報源が再び参照されるまで、資源レコードがキャッシュされるかもしれな
   い秒数です。ゼロは、資源レコードを進行中の取引にだけ使用できることを
   意味すると解釈されます。

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

   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.  資源レコード種別のIANA割当の問題

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

   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.
   データ種別はデータを保存する手段です。問合せ種別は問合せににみ使用で
   きます。メタ種別は特定のDNSメッセージに関連する一時的なデータを指
   定し、また、いくつかの場合、問合せに使用できます。これまでのところ、
   データ種別が1から昇順と、100から103のブロックと、32,768から昇順に
   割り当てられ、OPTメタ資源レコードが種別41を割り当てられたのを例外と
   し、Q種別とメタ種別は、255から降順に割り当てられました。資源レコード
   種別の下位バイトの最上位ビットに基づくいてキャッシュを決定するDNS
   実装がありました。

   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.
   現在割当て済みのメタ種別は3つあります: OPT [RFC2671]、TSIG [RFC2845]、
   TKEY [RFC2930]。現在割当て済みの問合せ種別は5つあります: * (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.
          - この範囲の残りの資源レコード種別は、3.1.1章に指定される
            DNS資源レコード種別割当ポリシによって、データ種別に割り当
            てられます。

      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.
          - この範囲の残りの資源レコード種別は、3.1.1章に指定される
            DNS資源レコード種別割当割当ポリシによって、Qとメタ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.)
          - この範囲の残りの資源レコード種別は、3.1.1章に指定される
            DNS資源レコード種別割当割当ポリシによって、データTYPEに
            割り当てられます。(32,768と32,769 (0x8000と0x8001)は割当済
            みです。)

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

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

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

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

   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.
   DNS資源レコード種別割当ポリシで割り当てると3.1章で示されたパラ
   メータ値は、以下にリストアップされた2つの必要条件を満たすなら、専門
   家レビューにより割当てられます。IESGによって任命された少数の専門
   家がいるでしょう。各アプリケーションはIANAによって選択された専門
   家によって判決を下されるでしょう。 選択された専門家の手があいていない
   か、専門家が利害関係者であると述べる場合は、IANAは別の専門家を選
   択するかもしれません。

   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].
   3.1.2章は専門家のためのいくつかのガイドラインを与えます。
   [RFC4020]で変更されたように。以下の条件を満たさない資源レコード種別が
   はIETF標準手順で割り当てられるかもしれません。

   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.
      付録Aで指定される完全なテンプレートが専門家レビュー決定の3週間前
      に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.
      部分的に完成したものや草稿のテンプレートがコメントと議論のために直
      接掲示されるかもしれませんが、3週間の期間を始める正式な掲示が専門
      家によってされます。

   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に掲示された後、
   少なくとも3週間、多くとも6週間後に、選択された専門家は、アプリケー
   ションが受理されたか拒否されたかを明示するメッセージを、IANAと  
   namedroppers@ops.ietf.orgと応募者の示したEメールアドレスに送るでしょ
   う。専門家がそのようなメッセージを掲示しないなら、アプリケーションは、
   拒絶されていると考えられますが、IANAに再提出されるかもしれません。

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

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

   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:
   選択されたDNS資源レコード種別専門家は、多分namedroppers@ops.ietf.org
   メーリングリストで行われる、提案された資源レコード種別の議論を監視し、
   必要に応じて他の専門家と相談するかもしれません通常、専門家は以下の評
   価基準の1つ以上を満たす資源レコード種別の配布要求を拒絶するはずです:

   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.
      提案された資源レコード種別がDNS処理に影響し、上記3.1.1章の
      ポイント2の評価基準を満たしません。

   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.
      文書化されるアプリケーションはDNSプロトコルの、ワイルドカード・
      別名・DNAMEなどの、振る舞いに不正確な仮定をします

   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.  OPT資源レコードの特別な注意

   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.
   OPT(オプション)資源レコード(資源レコード種別41)とそのIANA
   の考慮は[RFC2671]で指定されます。この資源レコードの主な目的は応答コー
   ドやラベル種別やオペレーションコードやフラグビットや資源データサイズな
   どの様々なDNSフィールドの有効サイズを広げることです。特に、これを認
   識するリゾルバとサーバで、応答フィールドを4ビットから12ビットい拡張
   します。

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]は、MX資源レコードと同じ資源データフィー
   ルド構造をもつ、クラス非依存の資源レコードですが、資源データの始めの
   16ビットの符号なし整数フィールドが以下の副種別と解釈されます:

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

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

        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.
            IETFレビューによる割当。

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

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

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

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

   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.
   DNSクラスはほとんど使用されていませんが、別次元のDNS分散データ
   ベースを構成します。特に、1つのデータクラスの名前空間とルートサーバ
   は、別データクラスのとどんな関係も必要ありません。同じDNS名がクラ
   スが異なると完全に異なる意味を持つことができます。ラベル形式も同じで、
   そして、ヌルラベルは単にルートとしてあらゆるクラスで使用可能です。グ
   ローバルネットワークとDNSの歴史により、INクラス、またはインター
   ネットクラス、がDNSの主要になりました。

   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".
   まだ、「メタクラス」の要件はありません。これは、問合せで使用可能かも
   しれない特定のDNSメッセージに関連している一時的なデータを指定する
   ためでしょう。しかしながら、将来の「メタクラス」で要件が発生するかも
   しれません。

   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.
            予約;割当はIETF標準手順を必要とします。

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

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

        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.
                    IETFレビューにより、データクラスにのみ割当可能です。

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

      254
   0x00FE - QCLASS NONE [RFC2136].
            Qクラス NONE

      255
   0x00FF - QCLASS * (ANY) [RFC1035].
            Qクラス *(ANY)

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

   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]で定義される特別要請に基づき、Qクラスと
                     メタクラスに割当て済みです。

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

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

3.3.  Label Considerations
3.3.  ラベル問題

   DNS NAMEs are sequences of labels [RFC1035].
   DNS名ははラベルの列です[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.
   現在に、ラベル形式に2つの種類があります:データラベルと圧縮ラベル。
   圧縮ラベルは、資源レコードやDNSメッセージ中のデータラベルへのポ
   インタで、名前のバイト長を短くすることを意図します。

   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].
   2つの既存のデータラベル形式は、時々、テキストとバイナリと呼ばれま
   す。事実上、テキストラベルはゼロ値を含む全てのオクテット値を含むこ
   とができますが、現在の多くの使用実態は[US-ASCII]だけを含みます。検
   索において、テキストラベルは、アスキーの大文字コードと小文字コード
   を同一に扱うと定義されています[RFC4343]。バイナリラベル種別は実験的
   です[RFC3363]。

   IANA considerations for label types are given in [RFC2671].
   ラベル形式のIANA割当の考慮事項は[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]クラスは
   本質的にローカルな使用のためのものです。現時点でINまたはインターネッ
   トクラスがインターネットにおけるグローバルに使用できる唯一のDNSク
   ラスです。

   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]でINクラスの名前割当のいくらか時代遅れな記述があります。
   予約された最上位ドメイン名のいくつかの情報がBCP32[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.
   この文書は一般的なDNSパラメータの割当のIANAの考慮を扱い、セキュ
   リティを扱いません。安全なDNSの問題に関しては[RFC4033]と[RFC4034]
   と[RFC4035]を見てください。

5.  IANA Considerations
5.  IANAの考慮

   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.
   この文書は、もっぱらDNSのIANAの考慮からなり、前の[RFC2929]から
   以下の変更があります。これはDNSパラメータの登録とその副登録に影響
   し、これは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)種別とQ種別」登記所で、ほと
      んどの「IETF合意」と全ての「仕様化が必要」な、資源レコード種別
      の割当方針は、「DNS種別割当方針」に変更され、資源レコード種別
      0xFFFFの方針は「IETF標準手順」に変更されました。残りの「IET
      F合意」の物は[RFC5226]の「IETFレビュー」に変更されます。また、
      これは「DNS種別割当方針」を指定します、これは追加の条件と制限の
      基づく専門家レビューに基づき、付録Aのテンプレートの完成版の
      dns-rrtype-applications@ietf.orgへの提出を含み、多くの場合、
      [RFC4020]を他で修正した「IETF標準手順」を必要とします

      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.
      IANAはこのようなテンプレートを受け入れるために手順を作るとしま
      す、そのようなテンプレート形式アプリケーションを評価するために任命
      された専門家を選択し、すべての承認された資源種別割当テンプレートを
      利用可能に格納し利用可能にします。正式なアプリケーションテンプレー
      トを namedroppers@ops.ietf.org メーリングリストに掲示するのは、選択
      された専門家の義務です。その他の詳細に関しては3.1章と付録Aを見
      てください。

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

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

   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資源レコード副種別フィールドのIANA割当方針を追
      加します、これは新しい登記所の作成を必要とします。3.1.4章を参
      照してください。

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

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

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

   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.
   正式な考慮事項の準備ができているとき、IANAが処理をはじめるため、
   このテンプレートをdns-rrtype-applications@ietf.orgにメールして、
   IANAに提出することになっています。

   A.    Submission Date:
         提案日付:

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

   C.    Contact Information for submitter:
         提案者の連絡情報
            Name:
            名前:
            Email Address:
            Eメールアドレス:
            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.
         この部分はこの資源レコードの使い方を専門家や評論家に知らせるた
         めに、高いレベルに保って下さい。ほとんどの評論家がDNS専門家
         で、あなたアプリケーションに関する知識が少ないかも知れないこと
         を覚えていてください。

   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?
         要求された資源レコード種別は何か既存のIANA登記所を利用します
         か、あるいはDNSパラメータに新しいIANA登記所の作成を必要と
         しますか?
         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])?
         提案は、新しい種別が未知の資源レコード種別として処理されるのを防
         ぐために、DNSサーバ/リゾルバにおける変更を必要/予想しますか?
         ([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