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


Network Working Group                                    D. Eastlake 3rd
Request for Comments: 2931                                      Motorola
Updates: 2535                                             September 2000
Category: Standards Track


           DNS Request and Transaction Signatures ( SIG(0)s )
                     DNS問合せと処理署名(SIG(0))

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
概要

   Extensions to the Domain Name System (DNS) are described in [RFC
   2535] that can provide data origin and transaction integrity and
   authentication to security aware resolvers and applications through
   the use of cryptographic digital signatures.
   暗号のディジタル署名の使用でデータ源認証と処理完全性と認証をセキュリ
   ティの認識のあるリゾルバとアプリケーションに供給するドメインネームシ
   ステムの拡張が[RFC 2535]に記述されます。

   Implementation experience has indicated the need for minor but non-
   interoperable changes in Request and Transaction signature resource
   records ( SIG(0)s ).  These changes are documented herein.
   実装の経験により問合せと取引署名資源レコード(SIG(0))に細かなことだ
   が協同使用が可能でない変更の必要を示しました。これらの変更はここに文
   書化されます。

Acknowledgments
謝辞

   The contributions and suggestions of the following persons (in
   alphabetic order) to this memo are gratefully acknowledged:
   このメモへの次の人々(アルファベット順の秩序で)の貢献と示唆は感謝し
   て認められます:

         Olafur Gudmundsson

         Ed Lewis

         Erik Nordmark

         Brian Wellington

Table of Contents
目次


   1. Introduction
      はじめに
   2. SIG(0) Design Rationale
      SIG(0)デザイン原理
   2.1 Transaction Authentication
       処理認証
   2.2 Request Authentication
       問合せ認証
   2.3 Keying

   2.4 Differences Between TSIG and SIG(0)
       TSIGとSIG(0)の差
   3. The SIG(0) Resource Record
      SIG(0)資源レコード
   3.1 Calculating Request and Transaction SIGs
      要求と処理署名の計算
   3.2 Processing Responses and SIG(0) RRs
       回答処理とSIG(0)資源レコード
   3.3 SIG(0) Lifetime and Expiration
       SIG(0)寿命と期限
   4. Security Considerations
      セキュリティ考慮
   5. IANA Considerations
      IANA考慮
   References
   参考文献
   Author's Address
   著者のアドレス
   Appendix: SIG(0) Changes from RFC 2535
   付録:RFC 2535からのSIG(0)の変更点
   Full Copyright Statement
   著作権表示全文
   Acknowledgement
   謝辞

1. Introduction
1. はじめに

   This document makes minor but non-interoperable changes to part of
   [RFC 2535], familiarity with which is assumed, and includes
   additional explanatory text.  These changes concern SIG Resource
   Records (RRs) that are used to digitally sign DNS requests and
   transactions / responses.  Such a resource record, because it has a
   type covered field of zero, is frequently called a SIG(0). The
   changes are based on implementation and attempted implementation
   experience with TSIG [RFC 2845] and the [RFC 2535] specification for
   SIG(0).
   この文書は[RFC 2535]の一部に対する些細ではあるが協同使用可能でない変
   更をします、読者が[RFC 2535]に精通することを想定し、追加の説明的なテ
   キストがこの文書に含まれます。これらの変更は、DNS問合せと処理/回
   答のデジタル署名に使う署名資源レコードに関係します。このような資源レ
   コードは、タイプカバーフィールドがゼロなので、しばしばSIG(0)と呼ばれ
   ます。この変更はTSIG[RFC 2845]とSIG(0)の仕様書[RFC 2535]の実装と実装
   する試みの経験に基づきます。

   Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
   and 4.3.  No changes are made herein related to the KEY or NXT RRs or
   to the processing involved with data origin and denial authentication
   for DNS data.
   [RFC 2535]の更新した章は4.1.8.1全体と4.2と4.3の一部です。
   鍵とNXT資源レコードとデータ源処理とDNSデータの非存在処理に関する変
   更がここにはありません。

   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]に記述されるように解釈されるはずです。

2. SIG(0) Design Rationale
2. SIG(0)デザイン原理

   SIG(0) provides protection for DNS transactions and requests that is
   not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
   2535].  The authenticated data origin services of secure DNS either
   provide protected data resource records (RRs) or authenticatably deny
   their nonexistence.  These services provide no protection for glue
   records, DNS requests, no protection for message headers on requests
   or responses, and no protection of the overall integrity of a
   response.
   SIG(0) が[RFC 2535]で示される通常の署名と鍵とNXT資源レコードで供給さ
   れないDNS処理と問合せの保護を提供します。安全なDNSのデータ源認
   証サービスは資源レコードの保護と非存在の保証を提供します。これらのサー
   ビスは接着剤レコードとDNS問合せと問合せや回答のメッセージヘッダと
   回答全体の完全性の保護ではありません。

2.1 Transaction Authentication
2.1 処理認証

   Transaction authentication means that a requester can be sure it is
   at least getting the messages from the server it queried and that the
   received messages are in response to the query it sent.  This is
   accomplished by optionally adding either a TSIG RR [RFC 2845] or, as
   described herein, a SIG(0) resource record at the end of the response
   which digitally signs the concatenation of the server's response and
   the corresponding resolver query.
   取引認証は、要求者が受け取られたメッセージが要求者が送った問合せの回
   答あることを要求者が確認できる事を意味します。これは問合せの最後にオ
   プションのTSIG資源レコード[RFC 2845]かこの文書で記述するSIG(0)を加え
   て、サーバの回答と対応するリゾルバの問合せの対応をデジタル的に署名す
   る事で、達成できる。

2.2 Request Authentication
2.2 問合せ認証

   Requests can also be authenticated by including a TSIG or, as
   described herein, a special SIG(0) RR at the end of the request.
   Authenticating requests serves no function in DNS servers that
   predate the specification of dynamic update.  Requests with a non-
   empty additional information section produce error returns or may
   even be ignored by a few such older DNS servers. However, this syntax
   for signing requests is defined for authenticating dynamic update
   requests [RFC 2136], TKEY requests [RFC 2930], or future requests
   requiring authentication.
   問合せの最後にTSIGかこの文書で記述する特別SIG(0)資源レコードを加える
   ことで、問合せも認証できます。問合せ認証はダイナミック更新仕様の前の
   DNSサーバーは機能を果たしません。空でない追加情報セクションを持つ
   問合せは、エラー応答を作り出すか、少数の古いDNSサーバーに無視され
   るかもしれません。しかし、この問合せ署名の構文はダイナミック更新要求
   [RFC 2136]とTKEY要求[RFC 2930]や要求認証を必要とする将来の要求を認証
   することに対して定義されます。

2.3 Keying
2.3 鍵

   The private keys used in transaction security belong to the host
   composing the DNS response message, not to the zone involved.
   Request authentication may also involve the private key of the host
   or other entity composing the request or of a zone to be affected by
   the request or other private keys depending on the request authority
   it is sought to establish. The corresponding public key(s) are
   normally stored in and retrieved from the DNS for verification as KEY
   RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
   処理セキュリティで使う秘密鍵は、関連するゾーンではなくDNS回答メッ
   セージを書くホストに属します。要求認証は、ホストか他の要求を構成する
   者の秘密鍵か、要求によって変更されるゾーンの秘密鍵か、要求を作る権威
   者に依存する秘密鍵かを伴うかもしれません。対応する公開鍵は通常DNS
   に鍵資源レコードとして登録され、検証のためプロトコルバイトが
   3(DNSSEC)か255(ANY)で検索されます。

   Because requests and replies are highly variable, message
   authentication SIGs can not be pre-calculated.  Thus it will be
   necessary to keep the private key on-line, for example in software or
   in a directly connected piece of hardware.
   問合せと回答はいろいろあるので、メッセージ認証署名はは前もって計算す
   る事ができません。そのため、例えばソフトウェアか直接接続ハードウェア
   で、秘密鍵をオンラインに保持する必要があるでしょう。

2.4 Differences Between TSIG and SIG(0)
2.4 TSIGとSIG(0)の差

   There are significant differences between TSIG and SIG(0).
   TSIGとSIG(0)の間の重要な相違があります。

   Because TSIG involves secret keys installed at both the requester and
   server the presence of such a key implies that the other party
   understands TSIG and very likely has the same key installed.
   Furthermore, TSIG uses keyed hash authentication codes which are
   relatively inexpensive to compute.  Thus it is common to authenticate
   requests with TSIG and responses are authenticated with TSIG if the
   corresponding request is authenticated.
   TSIGがキーが要求者とサーバの両方にインストールした秘密鍵を伴い、他者
   が理解するTSIGような鍵の存在は他者に多分同じ鍵がインストールされてる
   ことを意味します。さらにTSIGが比較的計算が簡単な鍵付きハッシュ認証コー
   ドを使います。そのためTSIGで要求を認証するのが普通で、要求が認証され
   れば対応する回答もTSIGで認証されます。

   SIG(0) on the other hand, uses public key authentication, where the
   public keys are stored in DNS as KEY RRs and a private key is stored
   at the signer.  Existence of such a KEY RR does not necessarily imply
   implementation of SIG(0).  In addition, SIG(0) involves relatively
   expensive public key cryptographic operations that should be
   minimized and the verification of a SIG(0) involves obtaining and
   verifying the corresponding KEY which can be an expensive and lengthy
   operation.  Indeed, a policy of using SIG(0) on all requests and
   verifying it before responding would, for some configurations, lead
   to a deadly embrace with the attempt to obtain and verify the KEY
   needed to authenticate the request SIG(0) resulting in additional
   requests accompanied by a SIG(0) leading to further requests
   accompanied by a SIG(0), etc.  Furthermore, omitting SIG(0)s when not
   required on requests halves the number of public key operations
   required by the transaction.
   一方SIG(0)は公開鍵認証を使い、公開鍵は鍵資源レコードとしてDNSに登
   録され、秘密鍵が署名者が持ちます。このような鍵資源レコードの存在は
   SIG(0)の実装をの必要性を暗示しません。さらにSIG(0)は少なく見ても計算
   量の多い公開鍵暗号処理を伴い、SIG(0)の検証は対応する鍵を得て、計算量
   の多く時間のかかる検証を伴います。実際にある設定で、すべての要求に
   SIG(0)を使い回答する前にそれを検証するポリシーが、要求のSIG(0)を認証
   するために必要な鍵を得て検証する試みが、SIG(0)を伴う追加の要求を伴い、
   さらなる要求を導く命取りの結果になるでしょう。さらに、要求に必要ない
   時にSIG(0)を除くことは処理の必要な公開鍵処理の数を半減します。

   For these reasons, SIG(0)s SHOULD only be used on requests when
   necessary to authenticate that the requester has some required
   privilege or identity.  SIG(0)s on replies are defined in such a way
   as to not require a SIG(0) on the corresponding request and still
   provide transaction protection.  For other replies, whether they are
   authenticated by the server or required to be authenticated by the
   requester SHOULD be a local configuration option.
   これらの理由のために、要求特権か識別を持つ要求者が認証を必要とする場
   合にだけSIG(0)を要求に使うべきです(SHOULD)。回答のSIG(0)は定義上対応
   する要求のSIG(0)を必要とせず、処理保護を供給します。他の回答について、
   サーバーで認証するか、要求者が認証する要求があるかどうかはローカル設
   定で選択すべきです(SHOULD)。

3. The SIG(0) Resource Record
3. SIG(0)資源レコード

   The structure of and type number of SIG resource records (RRs) is
   given in [RFC 2535] Section 4.1.  However all of Section 4.1.8.1 and
   the parts of Sections 4.2 and 4.3 related to SIG(0) should be
   considered replaced by the material below.  Any conflict between [RFC
   2535] and this document concerning SIG(0) RRs should be resolved in
   favor of this document.
   署名資源レコードの構造とタイプ番号は[RFC 2535]の4.1章で与えられます。
   しかし、4.1.8.1章と、4.2章と4.3章のSIG(0)に関係がある部分は以
   下の内容で置き換えると考えるべきです。[RFC 2535]とこの文書にSIG(0)資
   源レコードに関して矛盾がある場合この文書が正しいと考えるべきです。

   For all transaction SIG(0)s, the signer field MUST be a name of the
   originating host and there MUST be a KEY RR at that name with the
   public key corresponding to the private key used to calculate the
   signature.  (The host domain name used may be the inverse IP address
   mapping name for an IP address of the host if the relevant KEY is
   stored there.)
   すべての処理SIG(0)で、署名者フィールドは出発点のホストの名前に違いあ
   りません(MUST)、そして署名を計算した秘密鍵に対応した公開鍵の名前がホ
   スト名に違いありません(MUST)。(使われたホストドメイン名は、ホストの
   IPアドレスからの逆変換によるホスト名かもしれません、もし適切な鍵が
   そこに設定されるなら)。

   For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
   meaningless.  The TTL fields SHOULD be zero and the CLASS field
   SHOULD be ANY.  To conserve space, the owner name SHOULD be root (a
   single zero octet).  When SIG(0) authentication on a response is
   desired, that SIG RR MUST be considered the highest priority of any
   additional information for inclusion in the response. If the SIG(0)
   RR cannot be added without causing the message to be truncated, the
   server MUST alter the response so that a SIG(0) can be included.
   This response consists of only the question and a SIG(0) record, and
   has the TC bit set and RCODE 0 (NOERROR).  The client should at this
   point retry the request using TCP.
   すべてのSIG(0)資源レコードで、所有者名とクラスとTTLとオリジナルTTLは
   無意味です。TTLフィールドはゼロであるべきで(SHOULD)、クラスフィールド
   はANYであるべきです(SHOULD)。スペースを節約するため、所有者名はルート
   (ひとつのゼロ値のオクテット)であるべきです(SHOULD)。回答のSIG(0)認
   証が要望される時、署名資源レコードは回答に含まれるどの追加情報よりも
   高い優先度と思わなくてはなりません(MUST)。もしSIG(0)資源レコードがメッ
   セージを切落とさないと追加できないなら、サーバーはSIG(0)を含める事が
   できるように回答を変えなくてはなりません(MUST)。この回答は質問とSIG(0)
   レコードだけから成り立ち、TCビットを設定し応答コードは0(エラーなし)
   です。クライアントはこの時点でTCPを使って要求を再度行うべきです。

3.1 Calculating Request and Transaction SIGs
3.1 要求と処理署名の計算

   A DNS request may be optionally signed by including one SIG(0)s at
   the end of the query additional information section.  Such a SIG is
   identified by having a "type covered" field of zero. It signs the
   preceding DNS request message including DNS header but not including
   the UDP/IP header and before the request RR counts have been adjusted
   for the inclusions of the request SIG(0).
   DNS要求がオプションで問合せ追加情報セクションの終わりに1つのSIG(0)
   を含める事で署名されるかもしれません。この様な署名はゼロ値の「カバー
   タイプ」フィールドで識別できます。この署名は署名の前のDNSヘッダー
   を含むDNS要求メッセージを署名します、しかしUDP/IPヘッダーを
   含まず、SIG(0)を含めるため資源レコード数を変更する前の状態で署名され
   ます。

   It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
   (1) the SIG's RDATA section entirely omitting (not just zeroing) the
   signature subfield itself, (2) the DNS query messages, including DNS
   header, but not the UDP/IP header and before the reply RR counts have
   been adjusted for the inclusion of the SIG(0).  That is
   署名はデータ([RFC 2535]の4.1.8章を参照)を使って計算される、(1)デー
   タは署名の資源データセクションは除く(ゼロを設定するのではない)が署
   名サブフィールド自体は含み、(2)データはDNSヘッダを含むDNS問合せ
   メッセージを含みUDP/IPヘッダを含まず、SIG(0)を含めるため資源レ
   コード数を変更する前の状態で署名は計算されます。つまり、

      data = RDATA | request - SIG(0)

   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
   calculated less the signature itself.
   ここで"|"が結合で、RDATAがSIG(0)の資源データで署名自身を除いて計算さ
   れます。

   Similarly, a SIG(0) can be used to secure a response and the request
   that produced it.  Such transaction signatures are calculated by
   using a "data" of (1) the SIG's RDATA section omitting the signature
   itself, (2) the entire DNS query message that produced this response,
   including the query's DNS header but not its UDP/IP header, and (3)
   the entire DNS response message, including DNS header but not the
   UDP/IP header and before the response RR counts have been adjusted
   for the inclusion of the SIG(0).
   同様にSIG(0)が回答と回答の元になった要求を確認するために使うことがで
   きます。このような処理署名は「データ」を使って計算できます、(1)データ
   は署名自身を除く署名資源データセクションを含みます、(2)データは問合せ
   の元になった全DNS問合せメッセージを含みます、これはDNSヘッダを
   含みますがUDP/IPヘッダを含みません、(3)データは全部のDNS回答
   メッセージを含みます、これはDNSヘッダを含みますがUDP/IPヘッ
   ダを含ず、SIG(0)を含めるため資源レコード数を変更する前の状態で署名は
   計算されます。

   That is
   つまり、

      data = RDATA | full query | response - SIG(0)

   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
   calculated less the signature itself.
   ここで"|"が結合で、RDATAがSIG(0)の資源データで署名自身を除いて計算さ
   れます。

   Verification of a response SIG(0) (which is signed by the server host
   key, not the zone key) by the requesting resolver shows that the
   query and response were not tampered with in transit, that the
   response corresponds to the intended query, and that the response
   comes from the queried server.
   回答のSIG(0)(これはゾーン鍵ではなく、サーバーホストの鍵で署名される)
   を検証すると、要求したリゾルバに、問合せと回答が途中で変更されていな
   い事と、回答が問合せに対応してる事と、回答が問い合わせたサーバーから
   来た事を、示します。

   In the case of a DNS message via TCP, a SIG(0) on the first data
   packet is calculated with "data" as above and for each subsequent
   packet, it is calculated as follows:
   TCPで送られるDNSメッセージの場合、最初のデータパケットの上の
   SIG(0)が上記の「データ」で計算され、続くパケットが以下の様に計算され
   ています:

      data = RDATA | DNS payload - SIG(0) | previous packet

   where "|" is concatenations, RDATA is as above, and previous packet
   is the previous DNS payload including DNS header and the SIG(0) but
   not the TCP/IP header.  Support of SIG(0) for TCP is OPTIONAL.  As an
   alternative, TSIG may be used after, if necessary, setting up a key
   with TKEY [RFC 2930].
   "|"が結合です、RDATAが上記と同じです、previous packetが以前のDNSペ
   イロードです、DNSペイロードはDNSヘッダとSIG(0)を含み、TCP/
   IPヘッダを含みません。TCPに対するSIG(0)のサポートは任意です
   (OPTIONAL)。代案として、もし必要であるならTKEY [RFC 2930]で鍵を設定し
   た後にTSIGが使われるかもしれません。

   Except where needed to authenticate an update, TKEY, or similar
   privileged request, servers are not required to check a request
   SIG(0).
   更新やTKEYや類似の特権要求の認証で必要な場合以外、サーバーが要求の
   SIG(0)を検査するように要求されません。

   Note: requests and responses can either have a single TSIG or one
   SIG(0) but not both a TSIG and a SIG(0).
   メモ:要請と回答でTSIGがSIG(0)のどちらかを設定できますが、両方は設定
   できません。

3.2 Processing Responses and SIG(0) RRs
3.2 回答処理とSIG(0)資源レコード

   If a SIG RR is at the end of the additional information section of a
   response and has a type covered of zero, it is a transaction
   signature covering the response and the query that produced the
   response.  For TKEY responses, it MUST be checked and the message
   rejected if the checks fail unless otherwise specified for the TKEY
   mode in use.  For all other responses, it MAY be checked and the
   message rejected if the checks fail.
   もし署名資源レコードが回答の追加の情報セクションの終わりにあり、カバー
   タイプがゼロなら、これは回答と回答を作り出した質問をカバーする処理署
   名です。TKEY回答では、署名を検査しなければなりません(MUST)、そして使
   用しているTKEYモードで指定されない限り、もし検査に失敗したら、メッセー
   ジを拒絶します。すべての他の回答でも署名を検査するかもしれません、そ
   してもし検査に失敗するならメッセージを拒絶します(MAY)。

   If a response's SIG(0) check succeed, such a transaction
   authentication SIG does NOT directly authenticate the validity any
   data-RRs in the message.  However, it authenticates that they were
   sent by the queried server and have not been diddled.  (Only a proper
   SIG(0) RR signed by the zone or a key tracing its authority to the
   zone or to static resolver configuration can directly authenticate
   data-RRs, depending on resolver policy.) If a resolver or server does
   not implement transaction and/or request SIGs, it MUST ignore them
   without error where they are optional and treat them as failing where
   they are required.
   もし回答のSIG(0)検査に成功しても、処理認証署名がメッセージ内のデータ
   資源レコードの正しさを直接認証しません。しかし、回答が問合せらたサー
   バーから送られて、だまされてないことを認証します(リゾルバのポリシー
   に依存して、ゾーンに署名されたか、権威からゾーンへ追跡した鍵で署名さ
   れたか、リゾルバの静的に設定した鍵で署名されたか、適切なSIG(0)だけが
   直接データ資源レコードを認証します)。もしリゾルバあるいはサーバーが
   処理署名か要求署名を実装しないなら、それをオプションならエラーなしで
   無視し、必須なら失敗したとあるかいます(MUST)。

3.3 SIG(0) Lifetime and Expiration
3.3 SIG(0)寿命と期限

   The inception and expiration times in SIG(0)s are for the purpose of
   resisting replay attacks.  They should be set to form a time bracket
   such that messages outside that bracket can be ignored.  In IP
   networks, this time bracket should not normally extend further than 5
   minutes into the past and 5 minutes into the future.
   SIG(0)の発行時刻と期限は再生攻撃に抵抗するためです。これはメッセージ
   発送時に他の時間には無視されるように、時間を限定すべきです。IPネッ
   トワークで、この時刻は過去5分、未来5分より広くすべきでありません。

4. Security Considerations
4. セキュリティ考慮

   No additional considerations beyond those in [RFC 2535].
   [RFC 2535]に追加する考慮はありません。

   The inclusion of the SIG(0) inception and expiration time under the
   signature improves resistance to replay attacks.
   SIG(0)発行時刻と期限を含めることは再生攻撃に対する抵抗を改善します。

5. IANA Considerations
5. IANA考慮

   No new parameters are created or parameter values assigned by this
   document.
   この文書で新しいパラメータが作られずや新しいパラメータ値が割り当てら
   れません。

References
参考文献

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

   [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 2535] Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

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

   [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
              2930, 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 978-567-7941(h)
          +1-508-261-4447(w)
   EMail: Donald.Eastlake@motorola.com

Appendix: SIG(0) Changes from RFC 2535
付録:RFC 2535からのSIG(0)の変更点

   Add explanatory text concerning the differences between TSIG and
   SIG(0).
   TSIGとSIG(0)の間の相違に関して説明文を追加。

   Change the data over which SIG(0) is calculated to include the SIG(0)
   RDATA other than the signature itself so as to secure the signature
   inception and expiration times and resist replay attacks.  Specify
   SIG(0) for TCP.
   SIG(0)を計算するデータに署名自身を除くSIG(0)資源データを含めるように
   変更しました、これは再生攻撃に抵抗するため署名発行時刻と期限を守るた
   めです。TCPのためのSIG(0)を指定しました。

   Add discussion of appropriate inception and expiration times for
   SIG(0).
   SIG(0)の適切な発行時刻と期限の論議を追加しました。

   Add wording to indicate that either a TSIG or one or more SIG(0)s may
   be present but not both.
   TSIGか1つ以上のSIG(0)があってもよいが両方は含まないとの言葉を追加し
   ました。

   Reword some areas for clarity.
   いくつかの部分を明確になつように言い直しました。

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