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


Network Working Group                                   D. Eastlake, 3rd
Request for Comments: 2930                                      Motorola
Category: Standards Track                                 September 2000


               Secret Key Establishment for DNS (TKEY RR)
                DNSの秘密鍵の確立(TKEY資源レコード)


Status of this Memo
この文書の状態


   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.
   この文書はインターネット共同体のためのインターネット標準化作業中のプ
   ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
   態とこのプロトコル状態は「インターネット公式プロトコル標準」(STD
   1)の現在の版を参照してください。このメモの配布は無制限です。

Copyright Notice
著作権表示

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract
概要

   [RFC 2845] provides a means of authenticating Domain Name System
   (DNS) queries and responses using shared secret keys via the
   Transaction Signature (TSIG) resource record (RR).  However, it
   provides no mechanism for setting up such keys other than manual
   exchange. This document describes a Transaction Key (TKEY) RR that
   can be used in a number of different modes to establish shared secret
   keys between a DNS resolver and server.
   [RFC 2845]が処理署名(TSIG)資源レコード(RR)による共有秘密鍵を使っ
   てドメインネームシステム(DNS)の問合せと回答を認証する手段を供給
   します。しかし[RFC 2845]は手動設定以外に鍵を設定するメカニズムを供給
   しません。この文書はDNSリゾルバとサーバ間で秘密鍵を共有する多くの
   異なるモードで使える処理鍵(TKEY)資源レコードを記述します。

Acknowledgments
謝辞

   The comments and ideas of the following persons (listed in alphabetic
   order) have been incorporated herein and are gratefully acknowledged:
   次の人々(アルファベット順)のコメントと考えはここに収録され、感謝し
   てます:

         Olafur Gudmundsson (TIS)

         Stuart Kwan (Microsoft)

         Ed Lewis (TIS)

         Erik Nordmark (SUN)

         Brian Wellington (Nominum)


Table of Contents
目次

   1. Introduction
   1. はじめに
   href="#68">1.1 Overview of Contents
   1.1 中身の概要
   href="#69">2. The TKEY Resource Record
   2. 処理鍵資源レコード
   href="#70">2.1 The Name Field
   2.1 名前フィールド
   href="#71">2.2 The TTL Field
   2.2 TTLフィールド
   href="#72">2.3 The Algorithm Field
   2.3 アルゴリズムフィールド
   href="#73">2.4 The Inception and Expiration Fields
   2.4 開始時刻と有効期限
   href="#74">2.5 The Mode Field
   2.5 モードフィールド
   href="#75">2.6 The Error Field
   2.6 エラーフィールド
   href="#76">2.7 The Key Size and Data Fields
   2.7 鍵サイズとデータフィールド
   href="#77">2.8 The Other Size and Data Fields
   2.8 他サイズと他データフィールド
   href="#78">3. General TKEY Considerations
   3. 一般的処理鍵の考察
   href="#79">4. Exchange via Resolver Query
   4. リゾルバ問合せによる交換
   href="#80">4.1 Query for Diffie-Hellman Exchanged Keying
   4.1 Diffie-Hellman鍵交換の問合せ
   href="#81">4.2 Query for TKEY Deletion
   4.2 処理鍵 削除の問合せ
   href="#82">4.3 Query for GSS-API Establishment
   4.3 GSS-API成立のための問合せ
   href="#83">4.4 Query for Server Assigned Keying
   4.4 サーバ割り当て鍵の問合せ
   href="#84">4.5 Query for Resolver Assigned Keying
   4.5 リゾルバ割当て鍵の要求
   href="#85">5. Spontaneous Server Inclusion
   5. サーバの自発的算入
   href="#86">5.1 Spontaneous Server Key Deletion
   5.1 自発的なサーバー鍵削除
   href="#87">6. Methods of Encryption
   6. 暗号化の方法
   href="#88">7. IANA Considerations
   7. IANAの考慮
   href="#89">8. Security Considerations
   8. セキュリティの考慮
   href="#90">References
   参考文献
   href="#91">Author's Address
   著者のアドレス
   href="#92">Full Copyright Statement
   著作権表示全文

1. Introduction
1. はじめに

   The Domain Name System (DNS) is a hierarchical, distributed, highly
   available database used for bi-directional mapping between domain
   names and addresses, for email routing, and for other information
   [RFC 1034, 1035].  It has been extended to provide for public key
   security and dynamic update [RFC 2535, RFC 2136].  Familiarity with
   these RFCs is assumed.
   ドメインネームシステム(DNS)は階層的で分散で高度に利用可能なデー
   タベースで、名前とアドレスの双方向マッピングとEメールルーチングとそ
   の他の情報に使います[RFC 1034, 1035]。これは公開鍵セキュリティとダイ
   ナミックな更新を供給するために拡張されました[RFC 2535, RFC 2136]。読
   者がこれらのRFCに精通すると想定します。

   [RFC 2845] provides a means of efficiently authenticating DNS
   messages using shared secret keys via the TSIG resource record (RR)
   but provides no mechanism for setting up such keys other than manual
   exchange. This document specifies a TKEY RR that can be used in a
   number of different modes to establish and delete such shared secret
   keys between a DNS resolver and server.
   [RFC 2845]が処理署名資源レコード(RR)によって効率的に共有秘密鍵を
   使いDNSメッセージを本物と証明する手段を供給しますが、手動の交換以
   外に鍵を準備するメカニズムを供給しません。この文書はDNSリゾルバと
   サーバー間で共有秘密鍵を確立し、削除するために多くの異なるモードで使
   える処理鍵資源レコードを示します。

   Note that TKEY established keying material and TSIGs that use it are
   associated with DNS servers or resolvers.  They are not associated
   with zones.  They may be used to authenticate queries and responses
   but they do not provide zone based DNS data origin or denial
   authentication [RFC 2535].
   処理鍵に使う鍵材料と鍵を使う処理署名は、DNSサーバかリゾルバに結び
   つくことに注意してください。鍵はゾーンとは結び付きません。鍵は問合せ
   と回答を認証するために使われるかもしれませんが、ゾーンのDNSデータ
   の生成源や否定認証[RFC 2535]を供給しません。

   Certain modes of TKEY perform encryption which may affect their
   export or import status for some countries.  The affected modes
   specified in this document are the server assigned mode and the
   resolver assigned mode.
   処理鍵のある特定のモードはある国の輸出や輸入の問題があるかもしれない
   暗号を実行します。この文書で指定された問題のモードはサーバ割当とリゾ
   ルバ割当モードです。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].
   この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
   NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
   [RFC 2119]に記述されるように解釈します。

   In all cases herein, the term "resolver" includes that part of a
   server which may make full and incremental [RFC 1995] zone transfer
   queries, forwards recursive queries, etc.
   例外なくこの文書での用語「リゾルバ」は、完全ゾーン転送や逐次ゾーン転
   送[RFC1995]の要求や、再帰問合せをするサーバーのある部分を含みます。

1.1 Overview of Contents
1.1 中身の概要

   Section 2 below specifies the TKEY RR and provides a description of
   and considerations for its constituent fields.
   下記2章が署名鍵資源レコードを指定し、署名鍵資源レコードの詳細を記述
   し、その構成要素フィールドにを考察します。

   Section 3 describes general principles of operations with TKEY.
   3章が処理鍵のオペレーションの一般原則を記述します。

   Section 4 discusses key agreement and deletion via DNS requests with
   the Query opcode for RR type TKEY.  This method is applicable to all
   currently defined TKEY modes, although in some cases it is not what
   would intuitively be called a "query".
   4章が処理鍵資源レコードタイプのための問合せオペコードのDNS要求に
   よる鍵合意と削除を論じます。この方法は、ある場合には直感的に「問合せ」
   と呼ばれるものではないが、すべての現在定義された処理鍵モードに適用で
   きます。

   Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
   servers which is currently used only for key deletion.
   5章が現在は鍵削除にだけ使われるサーバーの回答での処理鍵資源レコード
   自然発生的な包含を論じます。

   Section 6 describes encryption methods for transmitting secret key
   information. In this document these are used only for the server
   assigned mode and the resolver assigned mode.
   6章が秘密鍵情報を伝達するための暗号化方法を記述します。この文書でこ
   れらはサーバ割当てモードとリゾルバ割当てモードでのみ使われます。

   Section 7 covers IANA considerations in assignment of TKEY modes.
   7章が処理鍵モード割当てでのIANA考慮をカバーします。

   Finally, Section 8 provides the required security considerations
   section.
   最後に8章が必要なセキュリティ考察章を供給します。

2. The TKEY Resource Record
2. 処理鍵資源レコード

   The TKEY resource record (RR) has the structure given below.  Its RR
   type code is 249.
   処理鍵資源レコード(RR)は以下の構造を持ちます。資源レコードタイプ
   コードは249です。

      Field       Type         Comment
      フィールド  タイプ       コメント
      -----       ----         -------
      NAME         domain      see description below
      名前         ドメイン    下記参照
      TTYPE        u_int16_t   TKEY = 249
      タイプ       u_int16_t   TKEY = 249
      CLASS        u_int16_t   ignored, SHOULD be 255 (ANY)
      クラス       u_int16_t   無視、255(ANY)であるべき(SHOULD)
      TTL          u_int32_t   ignored, SHOULD be zero
      TTL       u_int16_t   無視、0であるべき(SHOULD)
      RDLEN        u_int16_t   size of RDATA
      資源データ長 u_int16_t   資源データサイズ
      RDATA:
      資源データ
       Algorithm:   domain
       アルゴリズム:ドメイン
       Inception:   u_int32_t
       開始時刻:   u_int32_t
       Expiration:  u_int32_t
       有効期限:   u_int32_t
       Mode:        u_int16_t
       モード:     u_int16_t
       Error:       u_int16_t
       エラー:     u_int16_t
       Key Size:    u_int16_t
       鍵サイズ:   u_int16_t
       Key Data:    octet-stream
       鍵データ:   オクテット列
       Other Size:  u_int16_t
       他サイズ:   u_int16_t
       Other Data:  octet-stream  undefined by this specification
       他データ:   オクテット列、この仕様書では規定しない

2.1 The Name Field
2.1 名前フィールド

   The Name field relates to naming keys.  Its meaning differs somewhat
   with mode and context as explained in subsequent sections.
   名前フィールドは鍵の命名に関係があります。その意味は、次章で説明する
   ように、モードと文脈で幾分異なります。

   At any DNS server or resolver only one octet string of keying
   material may be in place for any particular key name.  An attempt to
   establish another set of keying material at a server for an existing
   name returns a BADNAME error.
   DNSサーバーやリゾルバで、たった1つの鍵材料のオクテット列だけが、
   鍵名の特定の場所に設定されるかもしれません。既存の名前のサーバーにも
   う1つの鍵材料をセット作る試みが名前誤エラーを返します。

   For a TKEY with a non-root name appearing in a query, the TKEY RR
   name SHOULD be a domain locally unique at the resolver, less than 128
   octets long in wire encoding, and meaningful to the resolver to
   assist in distinguishing keys and/or key agreement sessions.   For
   TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
   be a globally unique server assigned domain.
   問合せでルート以外の名前の処理鍵について、処理鍵資源レコード名はリゾ
   ルバにユニークなローカルドメインであるべきで(SHOULD)、ワイヤコーディ
   ングで128オクテット以下で、鍵の区別や鍵合意セッションでリゾルバに
   有意であるべきです。問合せの解答に現れる処理鍵について、処理鍵資源レ
   コード名はグローバルにユニークなサーバドメイン名であるべきです(SHOULD)。

   A reasonable key naming strategy is as follows:
   合理的な鍵の命名戦略は以下の通りです:

      If the key is generated as the result of a query with root as its
      owner name, then the server SHOULD create a globally unique domain
      name, to be the key name, by suffixing a pseudo-random [RFC 1750]
      label with a domain name of the server.  For example
      89n3mDgX072pp.server1.example.com.  If generation of a new
      pseudo-random name in each case is an excessive computation load
      or entropy drain, a serial number prefix can be added to a fixed
      pseudo-random name generated an DNS server start time, such as
      1001.89n3mDgX072pp.server1.example.com.
      もし鍵が質問の結果として生成され所有者名がルートなら、サーバーは鍵
      名のために、サーバードメイン名に疑似ランダム[RFC 1750]ラベルを付け、
      グローバルにユニークなドメイン名を作るべきである(SHOULD)、例えば
      89n3mDgX072pp.server1.example.comです。もし各場合に新しい疑似ラン
      ダム名を生成するのが計算負荷やエントロピーの消耗なら、DNSサー
      バースタート時生成された固定した疑似ランダムな名前に通し番号プレ
      フィックスを加えて、1001.89n3mDgX072pp.server1.example.com.の様に、
      生成できます。

      If the key is generated as the result of a query with a non-root
      name, say 789.resolver.example.net, then use the concatenation of
      that with a name of the server.  For example
      789.resolver.example.net.server1.example.com.
      もし鍵がルート以外の名前の問合せの結果として生成されるなら、例えば
      789.resolver.example.netなら、サーバー名とそれを結合して使ってくだ
      さい。例えば789.resolver.example.net.server1.example.comです。

2.2 The TTL Field
2.2 TTLフィールド

   The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
   be sure that older DNS implementations do not cache TKEY RRs.
   TTLフィールドは処理鍵資源レコードで無意味です。古いDNS実装が処理鍵
   資源レコードをキャッシュしないことを確実にするためゼロであるべきです
   (SHOULD)。

2.3 The Algorithm Field
2.3 アルゴリズムフィールド

   The algorithm name is in the form of a domain name with the same
   meaning as in [RFC 2845].  The algorithm determines how the secret
   keying material agreed to using the TKEY RR is actually used to
   derive the algorithm specific key.
   アルゴリズム名は[RFC 2845]と同じ意味でドメイン名形式です。アルゴリズ
   ムは処理鍵資源レコードで使うことに同意された秘密鍵材料が実際に使われ
   る特定のアルゴリズムを決定します。

2.4 The Inception and Expiration Fields
2.4 開始時刻と有効期限

   The inception time and expiration times are in number of seconds
   since the beginning of 1 January 1970 GMT ignoring leap seconds
   treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
   between a DNS resolver and a DNS server where these fields are
   meaningful, they are either the requested validity interval for the
   keying material asked for or specify the validity interval of keying
   material provided.
   開始時刻と有効期限が、グリニッジ標準時で1970年1月1日の最初から
   のうるう秒を無視した秒数で、2の32乗のリング算術[RFC 1982]を使いま
   す。DNSリゾルバとDNSサーバ間のメッセージでこれらのフィールドが
   有意義です、これは鍵材料を求める合法的期間か、鍵材料を供給した際の合
   法的期間のいずれかです。

   To avoid different interpretations of the inception and expiration
   times in TKEY RRs, resolvers and servers exchanging them must have
   the same idea of what time it is.  One way of doing this is with the
   NTP protocol [RFC 2030] but that or any other time synchronization
   used for this purpose MUST be done securely.
   処理鍵資源レコードで開始時刻と有効期限の異なる解釈を避けるために、リ
   ゾルバとサーバの時計が合っていなければなりません。これをする方法の1
   つがNTPプロトコル[RFC 2030]ですが、NTPか他の方法で時間を合わせ
   る際に安全に行わなければなりません(MUST)。

2.5 The Mode Field
2.5 モードフィールド

   The mode field specifies the general scheme for key agreement or the
   purpose of the TKEY DNS message.  Servers and resolvers supporting
   this specification MUST implement the Diffie-Hellman key agreement
   mode and the key deletion mode for queries.  All other modes are
   OPTIONAL.  A server supporting TKEY that receives a TKEY request with
   a mode it does not support returns the BADMODE error.  The following
   values of the Mode octet are defined, available, or reserved:
   モードフィールドは鍵合意か処理鍵DNSメッセージの目的のために一般的
   な案を指定します。この仕様をサポートするサーバーとリゾルバは
   Diffie-Hellman鍵協定モードと鍵削除モードを実行しなくてはなりません
   (MUST)。すべての他のモードは任意です(OPTIONAL)。処理鍵をサポートする
   サーバがサポートしないモードの処理鍵要求を受け取った場合、モードエラー
   を返します。次のモードオクテット値は利用可能か予約と定義されます:

         Value    Description
         値       説明
         -----    -----------
          0        - reserved, see section 7
                  予約、7章参照
          1       server assignment
                  サーバ割り当て
          2       Diffie-Hellman exchange
                  Diffie-Hellman交換
          3       GSS-API negotiation
                  GSS-API交渉
          4       resolver assignment
                  リゾルバ割り当て
          5       key deletion
                  鍵削除
         6-65534   - available, see section 7
                  利用可能、7章参照
         65535     - reserved, see section 7
                  予約、7章参照

2.6 The Error Field
2.6 エラーフィールド

   The error code field is an extended RCODE.  The following values are
   defined:
   エラーコードフィールドは拡張された応答コードです。次の値が定義されます:

         Value   Description
         値       説明
         -----   -----------
          0       - no error
                 エラーなし
          1-15   a non-extended RCODE
                 応答コード拡張なし
          16     BADSIG   (TSIG)
                 署名誤り(処理署名)
          17     BADKEY   (TSIG)
                 鍵誤り(処理署名)
          18     BADTIME  (TSIG)
                 時間誤り(処理署名)
          19     BADMODE
                 モード誤り
          20     BADNAME
                 名前誤り
          21     BADALG
                 アルゴリズム誤り

   When the TKEY Error Field is non-zero in a response to a TKEY query,
   the DNS header RCODE field indicates no error. However, it is
   possible if a TKEY is spontaneously included in a response the TKEY
   RR and DNS header error field could have unrelated non-zero error
   codes.
   処理鍵エラーフィールドが処理鍵問合せに対する回答でゼロ以外の場合、D
   NSヘッダー応答コードフィールドはエラーを示しません。しかし、もし処
   理鍵が自発的に回答に含められるなら、処理鍵資源レコードとDNSヘッダー
   エラーフィールドが無関係なエラーコードを持つことが可能です。

2.7 The Key Size and Data Fields
2.7 鍵サイズとデータフィールド

   The key data size field is an unsigned 16 bit integer in network
   order which specifies the size of the key exchange data field in
   octets. The meaning of this data depends on the mode.
   鍵データサイズフィールドは符号無し16ビット整数で、ネットワークオー
   ダーで、オクテット単位で鍵交換データフィールドの大きさを指定します。
   このデータの意味はモードに頼ります。

2.8 The Other Size and Data Fields
2.8 他サイズと他データフィールド

   The Other Size and Other Data fields are not used in this
   specification but may be used in future extensions.  The RDLEN field
   MUST equal the length of the RDATA section through the end of Other
   Data or the RR is to be considered malformed and rejected.
   他サイズと他データフィールドはこの仕様書で使われません、しかし未来の
   拡張で使われるかもしれません。資源データ長フィールドは他データの終わ
   りが資源データ部長に等しくなければならず(MUST)、そういでなければ資源
   データは誤っていると思われ拒絶されるはずです。

3. General TKEY Considerations
3. 一般的処理鍵の考察

   TKEY is a meta-RR that is not stored or cached in the DNS and does
   not appear in zone files.  It supports a variety of modes for the
   establishment and deletion of shared secret keys information between
   DNS resolvers and servers.  The establishment of such a shared key
   requires that state be maintained at both ends and the allocation of
   the resources to maintain such state may require mutual agreement. In
   the absence of willingness to provide such state, servers MUST return
   errors such as NOTIMP or REFUSED for an attempt to use TKEY and
   resolvers are free to ignore any TKEY RRs they receive.
   処理鍵メタ資源レコードで、DNSで蓄積やキャッシュはせず、ゾーンファ
   イルにも現れません。これはDNSリゾルバとサーバ間で秘密鍵情報の共有
   と削除のため様々なモードをサポートします。このような共有鍵の作成は両
   者で状態管理が要求され、この状態を管理する資源の割当が相互の合意を必
   要とするかもしれません。このような状態を供給する自発的意志がない場合、
   サーバーが未実装か処理鍵使用を断わるエラーを返さなくてはなりません
   (MUST)、そしてリゾルバは受け取った処理鍵資源レコードを無視するのは自
   由です。

   The shared secret keying material developed by using TKEY is a plain
   octet sequence.  The means by which this shared secret keying
   material, exchanged via TKEY, is actually used in any particular TSIG
   algorithm is algorithm dependent and is defined in connection with
   that algorithm.  For example, see [RFC 2104] for how TKEY agreed
   shared secret keying material is used in the HMAC-MD5 algorithm or
   other HMAC algorithms.
   処理鍵を使うために開発された共有秘密鍵材料は単純なオクテット列です。
   処理鍵に交換による秘密鍵材料共有手段はどんな特定の処理署名アルゴリズ
   ムでも実際に使われ、アルゴリズム依存で、アルゴリズムに関連して定義さ
   れます。例えば、処理鍵共有秘密鍵材料がHMAC-MD5アルゴリズムや他のHMAC
   アルゴリズムで使う方法について[RFC 2104]を見てください。

   There MUST NOT be more than one TKEY RR in a DNS query or response.
   DNSの問合せや回答に2個以上の処理鍵資源レコードがあってはなりませ
   ん(MUST NOT)。

   Except for GSS-API mode, TKEY responses MUST always have DNS
   transaction authentication to protect the integrity of any keying
   data, error codes, etc.  This authentication MUST use a previously
   established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
   NOT use any key that the response to be verified is itself providing.
   GSS-APIモード以外、処理鍵回答で常に鍵データやエラーコードなどの完全性
   を守るためのDNS処理認証をしなければなりません(MUST)。この認証は前
   に確定した秘密鍵(TSIG)か公開鍵(SIG(0) [RFC 2931])を使わなければな
   りません(MUST)、そして回答で供給された検証される必要がある鍵を使って
   検証を行ってはなりません(MUST NOT)。

   TKEY queries MUST be authenticated for all modes except GSS-API and,
   under some circumstances, server assignment mode.  In particular, if
   the query for a server assigned key is for a key to assert some
   privilege, such as update authority, then the query must be
   authenticated to avoid spoofing.  However, if the key is just to be
   used for transaction security, then spoofing will lead at worst to
   denial of service.  Query authentication SHOULD use an established
   secret (TSIG) key authenticator if available.  Otherwise, it must use
   a public (SIG(0)) key signature.  It MUST NOT use any key that the
   query is itself providing.
   処理鍵の問合せが、GSS-APIモードとある状況のサーバ割当てモード以外で、
   認証が必要です(MUST)。特に、もしサーバ割当て鍵の問合せが、更新権限の
   ような特権を主張するなら、問合せはだましを避けるため認証されなくては
   なりません。しかしながら、もし鍵が処理認証に使われるなら、だましが最
   悪の場合サービス拒否に導くでしょう。問合せ認証が、もし利用可能である
   なら、確立した秘密鍵の認証を使うべきです(SHOULD)。さもなければ、公開
   (SIG(0))鍵署名を使わなければなりません。問合せ自身で供給している鍵を
   使ってはなりません(MUST NOT)。

   In the absence of required TKEY authentication, a NOTAUTH error MUST
   be returned.
   必要とされる処理鍵認証がない場合、未認証エラーを返さなければなりませ
   ん。

   To avoid replay attacks, it is necessary that a TKEY response or
   query not be valid if replayed on the order of 2**32 second (about
   136 years), or a multiple thereof, later.  To accomplish this, the
   keying material used in any TSIG or SIG(0) RR that authenticates a
   TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
   (about 68 years).  Thus, on attempted replay, the authenticating TSIG
   or SIG(0) RR will not be verifiable due to key expiration and the
   replay will fail.
   再生攻撃を避けるために、処理鍵回答あるいは質問が2の32乗秒後(およ
   そ136年後)やその倍数秒後に再生された場合正当とされない事が必要で
   す。これを達成するために、処理鍵メッセージを本物と証明する処理署名か
   SIG(0)資源レコードで使われた鍵材料は2^31−1秒(およそ68年)
   以上のライフタイムを持ってはなりません(MUST NOT)。それで、再生の試み
   は、認証している処理署名やSIG(0)資源レコードが鍵期限のために証明可
   能でなく、再生は失敗するでしょう。

4. Exchange via Resolver Query
4. リゾルバ問合せによる交換

   One method for a resolver and a server to agree about shared secret
   keying material for use in TSIG is through DNS requests from the
   resolver which are syntactically DNS queries for type TKEY.  Such
   queries MUST be accompanied by a TKEY RR in the additional
   information section to indicate the mode in use and accompanied by
   other information where required.
   リゾルバとサーバーが処理署名で使用するため共有秘密鍵材料の合意をする
   1つの方法が、文法的には処理鍵タイプのDNS問合せであるリゾルバから
   のDNS問合せのよる方法です。このような問合せは処理鍵資源レコードが、
   使用するモードを必要な他の情報と共に、追加情報セクションに必要です
   (MUST)。

   Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
   ignore the recursive header bit in TKEY queries they receive.
   処理鍵タイプの問合せ再帰マークをつけるべきではありません(SHOULD NOT)、
   そしてサーバーが受け取った処理鍵問合せでヘッダの再帰ビットを無視して
   もよいです(MAY)。

4.1 Query for Diffie-Hellman Exchanged Keying
4.1 Diffie-Hellman鍵交換の問合せ

   Diffie-Hellman (DH) key exchange is a means whereby two parties can
   derive some shared secret information without requiring any secrecy
   of the messages they exchange [Schneier].  Provisions have been made
   for the storage of DH public keys in the DNS [RFC 2539].
   Diffie-Hellman(DH)鍵交換は2者が交換するメッセージの秘密を必要と
   せずにある共有秘密情報を得る手段です[Schneier]。DNSにDH公開鍵の登
   録の準備がされました[RFC 2539]。

   A resolver sends a query for type TKEY accompanied by a TKEY RR in
   the additional information section specifying the Diffie-Hellman mode
   and accompanied by a KEY RR also in the additional information
   section specifying a resolver Diffie-Hellman key.  The TKEY RR
   algorithm field is set to the authentication algorithm the resolver
   plans to use. The "key data" provided in the TKEY is used as a random
   [RFC 1750] nonce to avoid always deriving the same keying material
   for the same pair of DH KEYs.
   リゾルバが処理鍵タイプのために問合せを送ります、問合せは追加情報セク
   ションの処理鍵資源レコードでDiffie-Hellmanモードを指定し、追加情報セ
   クションの処理鍵資源レコードでリゾルバのDiffie-Hellman鍵を指定します。
   処理鍵資源レコードアルゴリズムフィールドはリゾルバが使うことを計画す
   る認証アルゴリズムを設定します。処理鍵で供給された「鍵データ」は1対
   のDHの鍵で同じ鍵材料を使うのを避けるため乱数を使います[RFC 1750]。

   The server response contains a TKEY in its answer section with the
   Diffie-Hellman mode. The "key data" provided in this TKEY is used as
   an additional nonce to avoid always deriving the same keying material
   for the same pair of DH KEYs. If the TKEY error field is non-zero,
   the query failed for the reason given. FORMERR is given if the query
   included no DH KEY and BADKEY is given if the query included an
   incompatible DH KEY.
   サーバー回答はDiffie-Hellmanモードでその解答セクションに処理鍵を含ん
   でいます。処理鍵で供給された「鍵データ」は1対のDHの鍵で同じ鍵材料
   を使うのを避けるため追加データ使います。もし処理鍵エラーフィールドが
   ゼロ以外なら、問合せはその理由で失敗しました。もし問合せがDH鍵を含
   まなければフォーマットエラーが、もし問合せが互換性がないDH鍵を含ん
   でいるなら鍵誤りが与えられます。

   If the TKEY error field is zero, the resolver supplied Diffie-Hellman
   KEY RR SHOULD be echoed in the additional information section and a
   server Diffie-Hellman KEY RR will also be present in the answer
   section of the response.  Both parties can then calculate the same
   shared secret quantity from the pair of Diffie-Hellman (DH) keys used
   [Schneier] (provided these DH keys use the same generator and
   modulus) and the data in the TKEY RRs.  The TKEY RR data is mixed
   with the DH result as follows:
   もし処理鍵エラーフィールドがゼロなら、リゾルバが供給するDiffie-Hellman
   鍵資源レコードは追加情報セクションに再設定させるべきで(SHOULD)、サー
   バDiffie-Hellman鍵資源レコードが回答の解答セクションにあるでしょう。
   両者は使われたDiffie-Hellman(DH)鍵の対と処理鍵資源レコードを使っ
   て同じ共有秘密鍵を計算します[Schneier](これらのDHの鍵が同じ生成
   機とモジュラスを使うなら)。処理鍵資源レコードデータは次のようにDH
   結果で混ぜられます:

      keying material =
           XOR ( DH value, MD5 ( query data | DH value ) |
                           MD5 ( server data | DH value ) )

   Where XOR is an exclusive-OR operation and "|" is byte-stream
   concatenation.  The shorter of the two operands to XOR is byte-wise
   left justified and padded with zero-valued bytes to match the length
   of the other operand.  "DH value" is the Diffie-Hellman value derived
   from the KEY RRs. Query data and server data are the values sent in
   the TKEY RR data fields.  These "query data" and "server data" nonces
   are suffixed by the DH value, digested by MD5, the results
   concatenated, and then XORed with the DH value.
   XORが排他的OR演算で、"|"がバイト列結合です。XORの2つの被演算子の短い
   方は他の被演算子と長さを合わすため左揃えで空いた右にゼロ値バイトを詰
   めます。"DH value"が鍵資源レコードから得られるDiffie-Hellman値です。
   query dataとserver dataが処理鍵資源レコードデータフィールドで送られる
   値です。これらの"query data"と"server data"はDH値が付けられて、MD5
   で要約され、結果の値を連結して、DH値とXORをとります。

   The inception and expiry times in the query TKEY RR are those
   requested for the keying material.  The inception and expiry times in
   the response TKEY RR are the maximum period the server will consider
   the keying material valid.  Servers may pre-expire keys so this is
   not a guarantee.
   問合せ処理鍵資源レコードの開始時刻と有効期限は鍵材料の求められるもの
   です。応答の処理鍵資源レコードの開始時刻と有効期限はサーバーが正当な
   鍵材料と思うであろう最大期間です。サーバーが鍵を有効期限前に失効させ
   るかもしれないので、これは保証ではありません。

4.2 Query for TKEY Deletion
4.2 処理鍵 削除の問合せ

   Keys established via TKEY can be treated as soft state.  Since DNS
   transactions are originated by the resolver, the resolver can simply
   toss keys, although it may have to go through another key exchange if
   it later needs one.  Similarly, the server can discard keys although
   that will result in an error on receiving a query with a TSIG using
   the discarded key.
   処理鍵によって確立された鍵がソフト状態と扱うことができます。DNS処
   理がリゾルバによって生成され、リゾルバはもし後で必要なった場合に再度
   鍵交換が必要になりますが、いつでも鍵を捨てることができます。同様に、
   サーバーは処理鍵を捨た状態で鍵を使うと問合せを受け取った場合にエラー
   を生じるが、鍵を捨てることができます。

   To avoid attempted reliance in requests on keys no longer in effect,
   servers MUST implement key deletion whereby the server "discards" a
   key on receipt from a resolver of an authenticated delete request for
   a TKEY RR with the key's name.  If the server has no record of a key
   with that name, it returns BADNAME.
   実際無効な鍵での問合せを避けるため、サーバーはリゾルバから受取った認
   証された削除要求に含まれる処理鍵資源レコードの鍵名の鍵を捨てる鍵削除
   を実装しなければなりません(MUST)。もしサーバーがその名前で鍵のレコー
   ドを持っていないなら、名前誤りを返します。

   Key deletion TKEY queries MUST be authenticated.  This authentication
   MAY be a TSIG RR using the key to be deleted.
   鍵削除問合せの処理鍵が認証されなくてはなりません(MUST)。この認証は削
   除される鍵を使う処理署名資源レコードかもしれません(MAY)。

   For querier assigned and Diffie-Hellman keys, the server MUST truly
   "discard" all active state associated with the key.  For server
   assigned keys, the server MAY simply mark the key as no longer
   retained by the client and may re-send it in response to a future
   query for server assigned keying material.
   要求者割当てとDiffie-Hellman鍵に対して、サーバは鍵に関する全ての状態
   を本当に「捨てなくて」はなりません(MUST)。サーバーの割り当てた鍵に対
   して、サーバーはクライアントが持っていないとマークするだけかもしれな
   く、サーバーの割り当てた暗号鍵材料として将来の問合せでそれを再送して
   もよいです(MAY)。

4.3 Query for GSS-API Establishment
4.3 GSS-API成立のための問合せ

   This mode is described in a separate document under preparation which
   should be seen for the full description.  Basically the resolver and
   server can exchange queries and responses for type TKEY with a TKEY
   RR specifying the GSS-API mode in the additional information section
   and a GSS-API token in the key data portion of the TKEY RR.
   このモードは下記の別の文書で完全な記述がされます。基本的にリゾルバと
   サーバーは処理鍵資源レコードを追加情報セクションに持つ処理鍵タイプの
   問合せと回答の交換ができ、処理鍵資源レコードがGSS-APIモードを指定し
   GSS-APIトークンが処理鍵資源レコードの鍵データ部に設定します。

   Any issues of possible encryption of parts the GSS-API token data
   being transmitted are handled by the GSS-API level.  In addition, the
   GSS-API level provides its own authentication so that this mode of
   TKEY query and response MAY be, but do not need to be, authenticated
   with TSIG RR or SIG(0) RR [RFC 2931].
   GSS-APIトークンデータの部分を転送する際の暗号化問題はGSS-APIレベルで
   処理されます。さらにGSS-APIレベルは自分自身の認証をし、処理鍵問合せと
   応答はこのモードで処理署名やSIG(0)で認証する必要がありません、しても
   よい[RFC2931](MAY)。

   The inception and expiry times in a GSS-API mode TKEY RR are ignored.
   開始時刻と有効期限はGSS-APIモードの処理鍵資源レコードでは無視されます。

4.4 Query for Server Assigned Keying
4.4 サーバ割り当て鍵の問合せ

   Optionally, the server can assign keying for the resolver.  It is
   sent to the resolver encrypted under a resolver public key.  See
   section 6 for description of encryption methods.
   オプションで、サーバーはリゾルバのために鍵を割り当てることができます。
   それはリゾルバ公開鍵で暗号化されてリゾルバに送られます。暗号化方法の
   記述は6章を見てください。

   A resolver sends a query for type TKEY accompanied by a TKEY RR
   specifying the "server assignment" mode and a resolver KEY RR to be
   used in encrypting the response, both in the additional information
   section. The TKEY algorithm field is set to the authentication
   algorithm the resolver plans to use.  It is RECOMMENDED that any "key
   data" provided in the query TKEY RR by the resolver be strongly mixed
   by the server with server generated randomness [RFC 1750] to derive
   the keying material to be used.  The KEY RR that appears in the query
   need not be accompanied by a SIG(KEY) RR.  If the query is
   authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
   and that authentication is verified, then any SIG(KEY) provided in
   the query SHOULD be ignored.  The KEY RR in such a query SHOULD have
   a name that corresponds to the resolver but it is only essential that
   it be a public key for which the resolver has the corresponding
   private key so it can decrypt the response data.
   リゾルバは処理鍵タイプの問合せを、「サーバー割当て」モードの処理鍵資
   源レコードと、回答の暗号化に使う鍵資源レコードを、共に追加の情報セク
   ションに設定し、送ります。処理鍵アルゴリズムフィールドはリゾルバが使
   うことを計画する認証アルゴリズムに設定されます。リゾルバの問合せ処理
   鍵資源レコードで供給された「鍵データ」は、鍵材料得るためにサーバの生
   成した乱数[RFC 1750]で強く混ぜらることが勧められます(RECOMMENDED)。質
   問に現われる鍵資源レコードは署名(鍵)資源レコードを伴う必要がありま
   せん。もし問合せが処理署名資源レコード[RFC2845]やSIG(0)資源レコード
   でリゾルバによって認証され、その認証が確かめられるなら、問合せの署名
   (鍵)は無視されるべきです(SHOULD)。このような問合せでの鍵資源レコー
   ドはリゾルバに対応する名前を持つべきです(SHOULD)、しかしリゾルバが回
   答データを解読できるように公開鍵に対応する秘密鍵を持つ事だけが不可欠
   です。

   The server response contains a TKEY RR in its answer section with the
   server assigned mode and echoes the KEY RR provided in the query in
   its additional information section.
   サーバー回答は、サーバ割当てモードの処理鍵資源レコードを解答セクショ
   ンに含み、追加情報セクションで問合せの鍵資源レコードのコピーを含みま
   す。

   If the response TKEY error field is zero, the key data portion of the
   response TKEY RR will be the server assigned keying data encrypted
   under the public key in the resolver provided KEY RR.  In this case,
   the owner name of the answer TKEY RR will be the server assigned name
   of the key.
   もし回答の処理鍵のエラーフィールドがゼロなら、回答の処理鍵資源レコー
   ドの鍵データ部は、リゾルバが鍵資源レコードで用意した公開鍵で暗号化さ
   れた鍵データであるでしょう。この場合、解答の処理鍵資源レコードの所有
   者名はサーバーが鍵に割り当てた名前でしょう。

   If the error field of the response TKEY is non-zero, the query failed
   for the reason given.  FORMERR is given if the query specified no
   encryption key.
   もし回答の処理鍵のエラーフィールドがゼロ以外なら、要求はその理由で失
   敗しました。フォーマットエラーは、もし問合せが暗号化の鍵を指定しなかっ
   た場合に与えられます。

   The inception and expiry times in the query TKEY RR are those
   requested for the keying material.  The inception and expiry times in
   the response TKEY are the maximum period the server will consider the
   keying material valid.  Servers may pre-expire keys so this is not a
   guarantee.
   質問の処理鍵資源レコードの開始時刻と有効期限は鍵材料に求められる期間
   です。回答の処理鍵の開始時刻と有効期限はサーバーが鍵材料が正当と思う
   最大期間です。サーバーが鍵を有効期限前に破棄するかもしれないのでこれ
   は保証ではありません。

   The resolver KEY RR MUST be authenticated, through the authentication
   of this query with a TSIG or SIG(0) or the signing of the resolver
   KEY with a SIG(KEY).  Otherwise, an attacker can forge a resolver KEY
   for which they know the private key, and thereby the attacker could
   obtain a valid shared secret key from the server.
   処理署名かSIG(0)か署名(鍵)で署名されたリゾルバ鍵で問合せを認証する
   事により、リゾルバの鍵資源レコードは認証しなければなりません(MUST)。
   さもなければ、攻撃者のプライベート鍵で、攻撃者がリゾルバ鍵を生成でき、
   攻撃者がサーバから共有秘密鍵を得ることができます。

4.5 Query for Resolver Assigned Keying
4.5 リゾルバ割当て鍵の要求

   Optionally, a server can accept resolver assigned keys.  The keying
   material MUST be encrypted under a server key for protection in
   transmission as described in Section 6.
   オプションとして、サーバーがリゾルバが割り当てた鍵を受け入れることが
   できます。鍵材料は6章で記述されるように、送信保護のためにサーバー鍵
   で暗号化されなくてはなりません(MUST)。

   The resolver sends a TKEY query with a TKEY RR that specifies the
   encrypted keying material and a KEY RR specifying the server public
   key used to encrypt the data, both in the additional information
   section.  The name of the key and the keying data are completely
   controlled by the sending resolver so a globally unique key name
   SHOULD be used.  The KEY RR used MUST be one for which the server has
   the corresponding private key, or it will not be able to decrypt the
   keying material and will return a FORMERR. It is also important that
   no untrusted party (preferably no other party than the server) has
   the private key corresponding to the KEY RR because, if they do, they
   can capture the messages to the server, learn the shared secret, and
   spoof valid TSIGs.
   リゾルバは、暗号化された鍵材料を指定している処理鍵資源レコードとサー
   バー公開鍵を指定している鍵資源レコードを共に追加情報セクションにもつ
   処理鍵問合せを送ります。鍵の名前と鍵データは完全に送信しているリゾル
   バによってコントロールされます、それで世界的規模でユニークな鍵名が使
   われるべきです(SHOULD)。鍵資源レコードはサーバーが対応する秘密鍵を持っ
   ているもので(MUST)、そうでなければ鍵材料を解読できずフォーマットエラー
   を返すでしょう。信頼できない者(多分サーバ以外全員)が鍵資源レコード
   に対応した秘密鍵を持っていないことが重要です、でないと信頼できない者
   がサーバへのメッセージを読み込んで、秘密鍵を学び、正しい処理署名だま
   すことができるからです。

   The query TKEY RR inception and expiry give the time period the
   querier intends to consider the keying material valid.  The server
   can return a lesser time interval to advise that it will not maintain
   state for that long and can pre-expire keys in any case.
   要求の処理鍵資源レコードの開始時刻と有効期間は要求者が鍵材料に効力が
   あると意図する期間を与えます。サーバーは長期間保持しないことを示すた
   めにそれより短い期間を返すことが出来、有効期限前に任意の理由で消すこ
   とができます。

   This mode of query MUST be authenticated with a TSIG or SIG(0).
   Otherwise, an attacker can forge a resolver assigned TKEY query, and
   thereby the attacker could specify a shared secret key that would be
   accepted, used, and honored by the server.
   この問合せのモードは処理署名かSIG(0)で認証されなくてはなりません
   (MUST)。さもなければ、攻撃者がリゾルバが割り当てた処理鍵要求を作り出
   すことができ、それによって攻撃者はサーバーが受け容れる使用し、信用す
   る秘密鍵を生成できてしまいます。

5. Spontaneous Server Inclusion
5. サーバの自発的算入

   A DNS server may include a TKEY RR spontaneously as additional
   information in responses.  This SHOULD only be done if the server
   knows the querier understands TKEY and has this option implemented.
   This technique can be used to delete a key and may be specified for
   modes defined in the future.  A disadvantage of this technique is
   that there is no way for the server to get any error or success
   indication back and, in the case of UDP, no way to even know if the
   DNS response reached the resolver.
   DNSサーバーが自発的に追加情報として回答に処理鍵資源レコードを含め
   てもよいです。これは、サーバーが要求者が処理鍵を理解することを知って、
   このオプションが実装された場合にだけ行うべきです(SHOULD)。このテクニッ
   クは鍵を削除するために使うことができ、将来定義されたモードに指定され
   るかもしれません。このテクニックの欠点はサーバーがエラーか成功か知る
   方法がなく、UDPの場合DNS回答がリゾルバに達したかどうか知る方法
   がないということです。

5.1 Spontaneous Server Key Deletion
5.1 自発的なサーバー鍵削除

   A server can optionally tell a client that it has deleted a secret
   key by spontaneously including a TKEY RR in the additional
   information section of a response with the key's name and specifying
   the key deletion mode.  Such a response SHOULD be authenticated.  If
   authenticated, it "deletes" the key with the given name.  The
   inception and expiry times of the delete TKEY RR are ignored. Failure
   by a client to receive or properly process such additional
   information in a response would mean that the client might use a key
   that the server had discarded and would then get an error indication.
   サーバーが自発的に処理鍵資源レコードを回答に含めてクライアントに鍵の
   削除を通知できます、処理鍵は回答の追加情報セクションにあり、鍵名と鍵
   削除モードが指定されます。このような回答は認証されるべきです(SHOULD)。
   もし認証されるなら、その名前の鍵を「削除」します。削除処理鍵資源レコー
   ドの開始時刻と有効期間は無視されます。クライアントの受信失敗かこのよ
   うな追加情報の処理が、クライアントがサーバの捨てた鍵を使うかもしれな
   く、エラーになるだろう事を意味するでしょう。

   For server assigned and Diffie-Hellman keys, the client MUST
   "discard" active state associated with the key.  For querier assigned
   keys, the querier MAY simply mark the key as no longer retained by
   the server and may re-send it in a future query specifying querier
   assigned keying material.
   サーバ割当とDiffie-Hellman鍵で、クライアントは鍵に関連したものを「捨
   て」なければなりません(MUST)。要求者割り当て鍵について、要求者は鍵に
   サーバが維持していないとのマークをつけるだけで、将来の要求で同じ鍵の
   鍵材料を再び送ってもかまいません(MAY)。

6. Methods of Encryption
6. 暗号化の方法

   For the server assigned and resolver assigned key agreement modes,
   the keying material is sent within the key data field of a TKEY RR
   encrypted under the public key in an accompanying KEY RR [RFC 2535].
   This KEY RR MUST be for a public key algorithm where the public and
   private keys can be used for encryption and the corresponding
   decryption which recovers the originally encrypted data.  The KEY RR
   SHOULD correspond to a name for the decrypting resolver/server such
   that the decrypting process has access to the corresponding private
   key to decrypt the data.  The secret keying material being sent will
   generally be fairly short, usually less than 256 bits, because that
   is adequate for very strong protection with modern keyed hash or
   symmetric algorithms.
   サーバ割当とリゾルバ割り当て鍵合意モードで、鍵材料が添付した鍵資源レ
   コードの公開鍵で暗号化され、処理鍵資源レコードの鍵データフィールドで
   送られます。この鍵資源レコードは、公開鍵とプライベート鍵が暗号化に使
   われる公開鍵アルゴリズムが設定されなければならず(MUST)、対応する解読
   が元のデータに戻します。鍵資源レコードは解読することリゾルバ/サーバー
   のために名前に対応するべきで、解読プロセスがデータを解読するために対
   応する秘密鍵にアクセスできるようにするべきです(SHOULD)。送られている
   秘密鍵材料は一般にかなり短く、通常256ビット以下であるでしょう、な
   ぜならそれで最新の鍵付きハッシュや対称的アルゴリズムで非常に強い保護
   ができるからです。

   If the KEY RR specifies the RSA algorithm, then the keying material
   is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
   PKCS#1 [RFC 2437].  (Note, the secret keying material being sent is
   directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
   some other symmetric algorithm.)  In the unlikely event that the
   keying material will not fit within one RSA modulus of the chosen
   public key, additional RSA encryption blocks are included.  The
   length of each block is clear from the public RSA key specified and
   the RSAES-PKCS1-v1_5 padding makes it clear what part of the
   encrypted data is actually keying material and what part is
   formatting or the required at least eight bytes of random [RFC 1750]
   padding.
   もし鍵資源レコードがRSAアルゴリズムを指定するなら、鍵材料はPKCS#1
   [RFC 2437]でRSAES-PKCS1-v1_5暗号化の記述に従って暗号化されます。(注
   意、秘密鍵材料は直接PKCS#1フォーマットのRSAで暗号化し送ったという
   ことです。これは何か他の対称的なアルゴリズムで「包まれ」ません。)選
   ばれた公開鍵の1つのRSAモジュール内に鍵材料が入らない、あまりなさ
   そうな場合の時は、追加のRSA暗号化ブロックが含まれます。それぞれの
   ブロックの長さは指定された公開RSA鍵から明確で、RSAES-PKCS1-v1_5パ
   ディングは暗号化データのどの部分が実際に鍵材料であるか、どの部分が少
   なくとも8バイトフォーマット化か必要なランダム[RFC 1750]なパディング
   か明確にします。

7. IANA Considerations
7. IANAの考慮

   This section is to be interpreted as provided in [RFC 2434].
   この章は[RFC 2434]で示されるように解釈します。

   Mode field values 0x0000 and 0xFFFF are reserved.
   モードフィールドの0x0000と0xFFFFは予約です。

   Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
   can only be assigned by an IETF Standards Action.
   モードフィールド値0x0001から0x00FFと0XFF00から0XFFFEがIETF標準行
   動によって割り当てられることができるだけです。

   Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
   are allocated by IESG approval or IETF consensus.
   モードフィールド値0x0100から0x0FFFと0xF0000から0xFEFFがIESGの賛成
   かIETF意見一致によって割り当てられます。

   Mode field values 0x1000 through 0xEFFF are allocated based on
   Specification Required as defined in [RFC 2434].
   モードフィールド値0x1000から0xEFFFは[RFC 2434]で定義されるように、仕
   様要求に基づいて割り当てられる。

   Mode values should not be changed when the status of their use
   changes.  For example, a mode value assigned based just on providing
   a specification should not be changed later just because that use's
   status is changed to standards track.
   モード値が、その使用状態が変わっても、変えられるべきではありません。
   例えば、仕様書の供給に基づいて行なわれて割り当てたモードが、その使用
   状態が標準化状態に変わってもモード値を変えるべきではありません。

   The following assignments are documented herein:
   次の割当てはここに文書化されます:

      RR Type 249 for TKEY.
      処理鍵のための資源レコードタイプ249

      TKEY Modes 1 through 5 as listed in section 2.5.
      処理鍵モード1から5は2.5章で記載してます。

      Extended RCODE Error values of 19, 20, and 21 as listed in section
      2.6.
      拡張応答コード値19と20と21は2.6章で記載しています。

8. Security Considerations
8. セキュリティの考慮

   The entirety of this specification is concerned with the secure
   establishment of a shared secret between DNS clients and servers in
   support of TSIG [RFC 2845].
   この仕様書の処理署名[RFC 2845]をサポートするDNSクライアントとサー
   バー間の共有秘密鍵のセキュリティ設定に関係しています。

   Protection against denial of service via the use of TKEY is not
   provided.
   処理鍵の使用はサービス拒否に対sる保護が供給されません。

References
参考文献

   [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
              Algorithms, and Source Code in C", 1996, John Wiley and
              Sons

   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, November 1987.

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
              Specifications", STD 13, RFC 1035, November 1987.

   [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
              Recommendations for Security", RFC 1750, December 1994.

   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              September 1996.

   [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              August 1996.

   [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
              for IPv4, IPv6 and OSI", RFC 2030, October 1996.

   [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
              Specifications Version 2.0", RFC 2437, October 1998.

   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
              Domain Name System (DNS)", RFC 2539, March 1999.

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

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

Author's Address
著者のアドレス

   Donald E. Eastlake 3rd
   Motorola
   140 Forest Avenue
   Hudson, MA 01749 USA

   Phone: +1 978-562-2827 (h)
          +1 508-261-5434 (w)
   Fax:   +1 508-261-4447 (w)
   EMail: Donald.Eastlake@motorola.com

Full Copyright Statement
著作権表示全文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.
   著作権(C)インターネット学会(2000)。すべての権利は保留される。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
   この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
   を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
   版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
   ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
   や他のインターネット組織は著作権表示や参照を削除されるような変更がで
   きません、インターネット標準を開発する場合はインターネット標準化プロ
   セスで定義された著作権の手順に従われます。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   上に与えられた限定された許可は永久で、インターネット学会やその後継者
   や譲渡者によって無効にされません。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So