RFC 2931 - DNS Request and Transaction Signatures ( SIG(0)s ) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2931
タイトル : RFC 2931 - DNSリクエストとトランザクションの署名（SIG（0）s）
翻訳編集 : 自動生成

[要約] RFC 2931は、DNSリクエストとトランザクションの署名（SIG（0））に関する標準仕様です。その目的は、DNSトランザクションのセキュリティを向上させ、データの信頼性と機密性を確保することです。

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）s）

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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.

ドメイン名システム（DNS）への拡張は、[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
   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. 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]の一部にマイナーではあるが互換性のない変更を行い、想定されている親しみやすさ、および追加の説明テキストが含まれています。これらの変更は、DNSリクエストとトランザクション /応答にデジタル的に署名するために使用されるSIGリソースレコード（RRS）に関するものです。このようなリソースレコードは、ゼロのタイプカバーフィールドを備えているため、しばしばSIG（0）と呼ばれます。変更は、TSIG [RFC 2845]および[RFC 2535]の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 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].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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]で指定された通常のSIG、キー、およびNXT RRSによって提供されないDNSトランザクションとリクエストの保護を提供します。保護されたDNSの認証されたデータ起源サービスは、保護されたデータリソースレコード（RRS）を提供するか、認証可能ではないことを拒否します。これらのサービスは、接着剤レコード、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 [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）RRを含めることによって認証されることもできます。認証リクエストは、動的アップデートの仕様に先行する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応答メッセージを構成するホストに属します。リクエスト認証には、ホストまたは要求またはゾーンのプライベートキーが、要求またはその他のプライベートキーの影響を受けるゾーンの秘密鍵を含む場合があります。対応する公開キーは通常、3（DNSSEC）または255（任意の）のプロトコルバイトを持つキー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は事前に計算することはできません。したがって、たとえばソフトウェアや直接接続されたハードウェアで、秘密キーをオンラインで保持する必要があります。

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）は、公開キー認証を使用します。ここでは、パブリックキーがキーRRSとしてDNSに保存され、秘密鍵が署名者に保存されます。このような重要なRRの存在は、必ずしもSIG（0）の実装を意味するわけではありません。さらに、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）は要求に応じて使用する必要があります。応答上のSIG（0）sは、対応する要求にSIG（0）を必要とせず、トランザクション保護を提供するような方法で定義されます。他の返信の場合、サーバーによって認証されているか、要求者によって認証される必要があるかどうかは、ローカル構成オプションである必要があります。

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.

SIGリソースレコード（RRS）の構造とタイプ数は、[RFC 2535]セクション4.1に記載されています。ただし、SIG（0）に関連するセクション4.1.8.1およびセクション4.2および4.3の部分は、以下の資料に置き換えると見なす必要があります。[RFC 2535]とSIG（0）RRに関するこの文書との間の競合は、この文書を支持して解決する必要があります。

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）sの場合、署名者フィールドは発信元のホストの名前でなければならず、署名の計算に使用される秘密鍵に対応する公開キーを使用して、その名前にキーRRが必要です。（使用されるホストドメイン名は、関連するキーがそこに保存されている場合、ホストの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フィールドはゼロである必要があり、クラスフィールドは任意のものでなければなりません。スペースを節約するには、所有者名はルート（単一のゼロオクテット）でなければなりません。応答に関するSIG（0）認証が必要な場合、そのSIG RRは、応答に含めるための追加情報の最優先事項と見なされなければなりません。SIG（0）RRを追加できない場合は、メッセージを切り捨てなくても、サーバーは応答を変更して、SIG（0）を含めることができます。この回答は、質問とSIG（0）レコードのみで構成され、TCビットセットとRcode 0（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).

DNS要求は、クエリ追加情報セクションの最後に1つのSIG（0）sを含めることにより、オプションで署名することができます。このような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セクションの「データ」（[RFC 2535]、セクション4.1.8を参照）を使用して計算されます。DNSヘッダーは、UDP/IPヘッダーではなく、RRカウントが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）の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）クエリのDNSヘッダーを含むこの応答を生成したDNSクエリメッセージ全体を使用して計算されますが、UDP/IPヘッダーではありません。（3）UDP/IPヘッダーではなく、DNSヘッダーを含むDNS応答メッセージ全体、および応答の前に、RRカウントが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）の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

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は上記であり、以前のパケットはDNSヘッダーとSIG（0）を含む以前のDNSペイロードですが、TCP/IPヘッダーではありません。TCPのSIG（0）のサポートはオプションです。別の方法として、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または1つのSIG（0）を持つことができますが、TSIGと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 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は、メッセージ内のデータRRSを有効性に直接認証しません。ただし、クエリサーバーによって送信され、処理されていないことを認証しています。（ゾーンによって署名された適切なSIG（0）RRのみまたはその権限をゾーンまたは静的リゾルバー構成に追跡するキーは、リゾルバーポリシーに応じてデータRRを直接認証できます。）リゾルバーまたはサーバーがトランザクションを実装していない場合/またはsigsをリクエストするには、それらがオプションである場合のエラーなしでそれらを無視し、必要な場所で失敗したとして扱う必要があります。

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

[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 1982] Elz、R。およびR. Bush、「シリアル番号算術」、RFC 1982、1996年9月。

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

[RFC 2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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.

[RFC 2136] Vixie、P.、Thomson、S.、Rekhter、Y。およびJ. Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。

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

[RFC 2535] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。

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

[RFC 2845] Vixie、P.、Gudmundsson、O.、Eastlake、D.およびB. Wellington、「DNSのシークレットキートランザクション署名」、RFC 2845、2000年5月。

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

[RFC 2930] Eastlake、D。、「DNSの秘密の鍵設立（RR）」、RFC 2930、2000年9月。

Author's Address

著者の連絡先

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

ドナルドE.イーストレイク第3モトローラ140フォレストアベニューハドソン、マサチューセッツ州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

付録：sig（0）RFC 2535からの変更

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）RDATAを含むように署名自体以外のRDATAを含めて、署名の開始と有効期限を確保し、リプレイ攻撃に抵抗します。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）sが存在する可能性がありますが、両方ではないことを示します。

Reword some areas for clarity.

明確にするためにいくつかの領域を言い換えます。

Full Copyright Statement

完全な著作権声明

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