RFC2931 日本語訳

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

コメントを求めるワーキンググループのD.イーストレーク第3要求をネットワークでつないでください: 2931のモトローラアップデート: 2535 2000年9月のカテゴリ: 標準化過程

           DNS Request and Transaction Signatures ( SIG(0)s )

DNS要求とトランザクション署名(SIG(0)s)

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

Copyright(C)インターネット協会(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.

拡大は暗号のデジタル署名の使用でデータ発生源、トランザクション保全、および認証をセキュリティの意識しているレゾルバとアプリケーションに提供できる[RFC2535]にドメインネームシステム(DNS)に説明されます。

   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.

実装経験はRequestにおける小さい方の、しかし、非共同利用できる変化とTransaction署名リソース記録(SIG(0)s)の必要性を示しました。 これらの変化はここに記録されます。

Acknowledgments

承認

   The contributions and suggestions of the following persons (in
   alphabetic order) to this memo are gratefully acknowledged:

(アルファベット順に)このメモへの以下の人々の貢献と提案は感謝して承諾されます:

         Olafur Gudmundsson

Olafurグドムンソン

         Ed Lewis

Ed Lewis

         Erik Nordmark

エリックNordmark

         Brian Wellington

ブライアン・ウェリントン

Eastlake                    Standards Track                     [Page 1]

RFC 2931                       DNS SIG(0)                 September 2000

イーストレークStandardsはDNS2000年SIG(0)9月にRFC2931を追跡します[1ページ]。

Table of Contents

目次

   1. Introduction.................................................  2
   2. SIG(0) Design Rationale......................................  3
   2.1 Transaction Authentication..................................  3
   2.2 Request Authentication......................................  3
   2.3 Keying......................................................  3
   2.4 Differences Between TSIG and SIG(0).........................  4
   3. The SIG(0) Resource Record...................................  4
   3.1 Calculating Request and Transaction SIGs....................  5
   3.2 Processing Responses and SIG(0) RRs.........................  6
   3.3 SIG(0) Lifetime and Expiration..............................  7
   4. Security Considerations......................................  7
   5. IANA Considerations..........................................  7
   References......................................................  7
   Author's Address................................................  8
   Appendix: SIG(0) Changes from RFC 2535..........................  9
   Full Copyright Statement........................................ 10

1. 序論… 2 2. SIG(0)デザイン原理… 3 2.1 トランザクション認証… 3 2.2 認証を要求してください… 3 2.3 合わせます。 3 TSIGとSIG(0)の2.4の違い… 4 3. SIG(0)リソース記録… 4 3.1の計算の要求とトランザクションSIG… 5 3.2 処理応答とSIG(0)RRs… 6 3.3のSIG(0)生涯と満了… 7 4. セキュリティ問題… 7 5. IANA問題… 7つの参照箇所… 7作者のアドレス… 8付録: SIG(0)はRFC2535から変化します… 9 完全な著作権宣言文… 10

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).

どれが想定されて、追加説明しているテキストを含んでいるかでこのドキュメントは[RFC2535]の一部、親しみへの小さい方の、しかし、非共同利用できる変更を行います。 これらの変化はDNSが要求とトランザクション/応答であるとデジタルに署名するのに使用されるSIG Resource Records(RRs)に関係があります。 そのようなリソース記録でありSIG(0)と呼ばれて頻繁にゼロの分野はそれでタイプをカバーするからです。 変化は実装、TSIGの試みられた実装経験[RFC2845]、およびSIG(0)のための[RFC2535]仕様に基づいています。

   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.

アップデートされた[RFC2535]のセクションは4.2と4.3の4.1の.8の.1と部品のすべてです。 ここに変更を全くKEYかNXT RRsか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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

Eastlake                    Standards Track                     [Page 2]

RFC 2931                       DNS SIG(0)                 September 2000

イーストレークStandardsはDNS2000年SIG(0)9月にRFC2931を追跡します[2ページ]。

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)はDNSトランザクションと要求のための[RFC2535]で指定された通常のSIG、KEY、およびNXT RRsによって提供されない保護を提供します。 安全なDNSの認証されたデータ発生源サービスは、保護されたデータリソース記録(RRs)を提供するか、またはauthenticatablyに彼らの非実在を否定します。 これらのサービスは要求か応答でのメッセージヘッダー、および応答の総合的な保全のノー・プロテクションに接着剤記録、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 RR[RFC2845]かここに説明されるときの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)RRを含んでいることによって、要求を認証できます。 要求を認証するのはダイナミックなアップデートの仕様より前に起こるDNSサーバでの機能を全く果たしません。 非空の追加情報部による要求は、誤りリターンを起こすか、またはそのようないくつかの、より古いDNSサーバによって無視さえされるかもしれません。 しかしながら、署名要求のためのこの構文は、ダイナミックな更新要求[RFC2136]、TKEY要求[RFC2930]、または認証を必要とする今後の要求を認証するために定義されます。

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応答メッセージを構成するホストに属します。 また、要求を構成するホストか他の実体の秘密鍵にかかわるか、または認証が証明するために要求権威によって、要求か他の秘密鍵で影響を受けて、それが探されるということであるゾーンについてそうするかもしれないよう要求してください。 対応する公開鍵は(DNSSEC)か255(少しも)を、通常、保存されて、3のプロトコルバイトがあるKEY RRsとしての検証のためのDNSから検索されます。

   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.

要求と回答が非常に可変であるので、通報認証SIGはあらかじめ計算されているはずがありません。 したがって、秘密鍵をオンラインに保つのが例えば、ソフトウェアか直接接続されたハードウェアで必要でしょう。

Eastlake                    Standards Track                     [Page 3]

RFC 2931                       DNS SIG(0)                 September 2000

イーストレークStandardsはDNS2000年SIG(0)9月にRFC2931を追跡します[3ページ]。

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) 他方では、用途公開鍵認証、公開鍵がKEY RRsとしてDNSにどこに保存されるか、そして、および秘密鍵は署名者に保存されます。 そのようなKEY RRの存在は必ずSIG(0)の実装を含意するというわけではありません。 SIG(0)の検証は、さらに、SIG(0)は最小にされるべきである比較的高価な公開鍵暗号の操作を伴って、高価で長い操作であるかもしれない対応するKEYについて得て、確かめることを伴います。 本当に、いくつかの構成のために、すべての要求のときにSIG(0)を使用して、応じる前にそれについて確かめる方針はSIG(0)などによって伴われたさらなる要求に通じながら、SIG(0)によって伴われた追加要求をもたらしながら要求SIG(0)を認証するのが必要であるKEYについて得て、確かめる試みによる致命的な抱擁につながるでしょう。 その上、要求のときに必要でないとSIG(0)sを省略すると、トランザクションによって必要とされた公開鍵操作の数は半分にされます。

   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)s SHOULD。認証するのにリクエスタには何らかの必要な特権かアイデンティティがあるのが必要であるときには要求のときに単に使用されてください。 回答でのSIG(0)sは対応する要求のときに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.

構造、[RFC2535]セクション4.1でSIGリソース記録(RRs)の形式数を与えます。 しかしながら、以下で材料に取り替えて、セクション4.2と4.3の.1と部分がSIG(0)に関係づけたセクション4.1.8のすべてが考えられるべきです。 [RFC2535]とSIG(0)RRsに関するこのドキュメントとのどんな闘争もこのドキュメントを支持して解決されるべきです。

   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

すべてのトランザクションSIG(0)sのために、署名者分野は送信元ホストの名前でなければなりません、そして、計算するのに使用される秘密鍵に対応する公開鍵のその名前にはKEY RRがあるに違いありません。

Eastlake                    Standards Track                     [Page 4]

RFC 2931                       DNS SIG(0)                 September 2000

イーストレークStandardsはDNS2000年SIG(0)9月にRFC2931を追跡します[4ページ]。

   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.)

署名。 (関連KEYがそこに保存されるなら、使用というホスト・ドメイン名はホストのIPアドレスのための逆さの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)RRs、クラスというすべての所有者名において、TTL、およびオリジナルのTTLは無意味です。 TTLはゼロとCLASSが分野SHOULDであったならSHOULDをさばきます。いずれになってくださいも。 スペースを保存するために、存在という所有者名のSHOULDは根づきます(シングルは八重奏のゼロに合っています)。 SIG(0)であるときに、応答の認証は望まれていて、SIG RR MUSTは応答での包含のためのどんな追加情報の最優先であるとも考えられます。 先端を切るべきメッセージを引き起こさないでSIG(0)RRを加えることができないなら、サーバは、SIG(0)を含むことができるように応答を変更しなければなりません。 この応答は、質問とSIG(0)記録だけから成って、TCビットセットとRCODE0(NOERROR)を持っています。 クライアントは、ここにTCPを使用することで要求を再試行するべきです。

3.1 Calculating Request and Transaction SIGs

3.1 計算の要求とトランザクションSIG

   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).

質問追加情報部の端の1つSIG(0)sを含んでいることによって、DNS要求は任意に署名されるかもしれません。 そのようなSIGは、ゼロの「カバーされたタイプ」分野を持っていることによって、特定されます。 それは、前のDNSがDNSヘッダーを含んでいますが、UDP/IPヘッダーを含まない要求メッセージであると署名します、そして、以前、要求RRカウントは要求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

(1) SIGのRDATA部の「データ」([RFC2535]、セクション4.1.8を見る)を完全に使用することによって、(まさしくゼロでない)を省略しながら、(2) 署名部分体自体、DNSがUDP/IPヘッダーではなく、DNSヘッダーを含むメッセージについて質問して、回答RRカウントの前にSIG(0)の包含のために調整されたと見込まれます。 すなわち

      data = RDATA | request - SIG(0)

データはRDATAと等しいです。| 要求--SIG(0)

   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
   calculated less the signature itself.

「どこ」|「(0) それほど計算されていなくて、連結とRDATAがSIGのRDATAであるということである、署名自体、」

   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) 署名自体を省略するSIGのRDATA部と(2) UDP/IPヘッダーではなく、質問のDNSヘッダーを含むこの応答を起こした全体のDNS質問メッセージと(3) UDP/IPヘッダーではなく、DNSヘッダーを含む全体のDNS応答メッセージの「データ」を使用することによって計算されて、応答RRカウントの前にSIG(0)の包含のために調整されました。

Eastlake                    Standards Track                     [Page 5]

RFC 2931                       DNS SIG(0)                 September 2000

イーストレークStandardsはDNS2000年SIG(0)9月にRFC2931を追跡します[5ページ]。

   That is

すなわち

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

データはRDATAと等しいです。| 完全な質問| 応答--SIG(0)

   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
   calculated less the signature itself.

「どこ」|「(0) それほど計算されていなくて、連結とRDATAがSIGのRDATAであるということである、署名自体、」

   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

データはRDATAと等しいです。| DNSペイロード--SIG(0)| 前のパケット

   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が同じくらい上にあって、前のパケットがTCP/IPヘッダーではなく、DNSヘッダーとSIG(0)を含む前のDNSペイロードであるということです」 TCPのためのSIG(0)のサポートはOPTIONALです。 代替手段として、必要なら、TKEY[RFC2930]と共にキーをセットアップした後に、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)の両方ではなく、独身のTSIGか1つのSIG(0)を持つことができます。

3.2 Processing Responses and SIG(0) RRs

3.2 処理応答とSIG(0)RRs

   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.

SIG RRが応答の追加情報部の端にあって、ゼロについてタイプをカバーさせるなら、応答を起こしたのは、応答と質問を含んでいるトランザクション署名です。 TKEY応答がないかどうか、それをチェックしなければなりませんでした、そして、そうでなくない場合チェックが失敗するなら拒絶されたメッセージは使用中のTKEYモードに指定しました。 他のすべての応答がないかどうか、それはチェックされるかもしれません、そして、チェックであるなら拒絶されたメッセージは失敗します。

   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

応答のSIG(0)チェックが成功するなら、そのようなトランザクション認証SIGはメッセージで直接正当性いずれもデータ-RRsを認証しません。 しかしながら、それはそれを認証します。それらは、質問されたサーバによって送られて、だまされていません。 (適切なSIG(0)RRだけがゾーン、または、静的なレゾルバ構成への権威が直接認証できるゾーンか主要なたどることで署名しました。

Eastlake                    Standards Track                     [Page 6]

RFC 2931                       DNS SIG(0)                 September 2000

イーストレークStandardsはDNS2000年SIG(0)9月にRFC2931を追跡します[6ページ]。

   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.

データ-RRsレゾルバ方針によって、 レゾルバかサーバがトランザクションを実装する、そして/または、SIGを要求しないなら、それは、それらが任意であるところで誤りなしでそれらを無視して、それらが必要であるところで失敗するとしてそれらを扱わなければなりません。

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)sの始まりと満了時間は反射攻撃に抵抗する目的のためのものです。 彼らがそのブラケットの外のメッセージを無視できるように時間ブラケットを形成するように設定されるべきです。 IPネットワークでは、通常、この時間ブラケットは過去の5分前と未来の5分前より遠くに広がるはずがありません。

4. Security Considerations

4. セキュリティ問題

   No additional considerations beyond those in [RFC 2535].

[RFC2535]のそれらを超えた追加問題がありません。

   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.

[RFC1982] ElzとR.とR.ブッシュ、「通し番号演算」、RFC1982、1996年9月。

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[RFC2136] VixieとP.とトムソンとS.、RekhterとY.とJ.バウンド、「ドメインネームシステム(DNSアップデート)におけるダイナミックなアップデート」RFC2136(1997年4月)。

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

[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。

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

[RFC2845] Vixie、P.、グドムンソン、O.、イーストレーク、D.、およびB.ウェリントン(「DNS(TSIG)のための秘密鍵トランザクション署名」、RFC2845)は2000がそうするかもしれません。

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

[RFC2930] イーストレーク、D.、「DNS(RR)のための秘密鍵設立」、RFC2930、2000年9月。

Eastlake                    Standards Track                     [Page 7]

RFC 2931                       DNS SIG(0)                 September 2000

イーストレークStandardsはDNS2000年SIG(0)9月にRFC2931を追跡します[7ページ]。

Author's Address

作者のアドレス

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

ドナルドE.イーストレーク第3モトローラ140の森林Avenue MA01749ハドソン(米国)

   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

以下に電話をしてください。 +1-978-562-2827 (h)+1-508-261-5434(w)Fax: +1 978-567-7941 (h) +1-508-261-4447 (w) メールしてください: Donald.Eastlake@motorola.com

Eastlake                    Standards Track                     [Page 8]

RFC 2931                       DNS SIG(0)                 September 2000

イーストレークStandardsはDNS2000年SIG(0)9月にRFC2931を追跡します[8ページ]。

Appendix: SIG(0) Changes from RFC 2535

付録: RFC2535からの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)が署名始まりと満了が回であると機密保護するために(0) 署名自体以外のSIG RDATAを含んで、反射攻撃に抵抗するために計算されるデータを変えてください。 SIG(0)をTCPに指定してください。

   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)sが存在しているかもしれないのを示すために言葉遣いを加えますが、ともに加えるというわけではなくなってください。

   Reword some areas for clarity.

明快ためにいくつかの領域を言い換えてください。

Eastlake                    Standards Track                     [Page 9]

RFC 2931                       DNS SIG(0)                 September 2000

イーストレークStandardsはDNS2000年SIG(0)9月にRFC2931を追跡します[9ページ]。

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(2000)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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 Editor機能のための基金は現在、インターネット協会によって提供されます。

Eastlake                    Standards Track                    [Page 10]

イーストレーク標準化過程[10ページ]