[要約] RFC 2930は、DNSの秘密鍵の確立に関する仕様であり、TKEY RRと呼ばれる新しいリソースレコードを導入します。目的は、DNSセキュリティの向上と、鍵の交換や更新の効率化です。
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 RR）
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.
Copyright（C）The Internet Society（2000）。全著作権所有。
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）クエリと応答を認証する手段を提供します。ただし、手動交換以外に、このようなキーを設定するメカニズムは提供されません。このドキュメントでは、DNSリゾルバとサーバー間で共有秘密キーを確立するために、さまざまなモードで使用できるトランザクションキー（TKEY）RRについて説明します。
Acknowledgments
謝辞
The comments and ideas of the following persons (listed in alphabetic order) have been incorporated herein and are gratefully acknowledged:
以下の人物のコメントとアイデア（アルファベット順）がここに組み込まれ、感謝されます。
Olafur Gudmundsson (TIS)
オラファー・グドムンドソン（TIS）
Stuart Kwan (Microsoft)
スチュアートクワン（Microsoft）
Ed Lewis (TIS)
エドリーバイス（TIS）
Erik Nordmark (SUN)
エリック・ノードマーク（SUN）
Brian Wellington (Nominum)
ブライアンウェリントン（名前）
Table of Contents
目次
1. Introduction............................................... 2
1.1 Overview of Contents...................................... 3
2. The TKEY Resource Record................................... 4
2.1 The Name Field............................................ 4
2.2 The TTL Field............................................. 5
2.3 The Algorithm Field....................................... 5
2.4 The Inception and Expiration Fields....................... 5
2.5 The Mode Field............................................ 5
2.6 The Error Field........................................... 6
2.7 The Key Size and Data Fields.............................. 6
2.8 The Other Size and Data Fields............................ 6
3. General TKEY Considerations................................ 7
4. Exchange via Resolver Query................................ 8
4.1 Query for Diffie-Hellman Exchanged Keying................. 8
4.2 Query for TKEY Deletion................................... 9
4.3 Query for GSS-API Establishment........................... 10
4.4 Query for Server Assigned Keying.......................... 10
4.5 Query for Resolver Assigned Keying........................ 11
5. Spontaneous Server Inclusion............................... 12
5.1 Spontaneous Server Key Deletion........................... 12
6. Methods of Encryption...................................... 12
7. IANA Considerations........................................ 13
8. Security Considerations.................................... 13
References.................................................... 14
Author's Address.............................................. 15
Full Copyright Statement...................................... 16
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）は、ドメイン名とアドレス間の双方向マッピング、電子メールルーティング、およびその他の情報[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]は、TSIGリソースレコード（RR）を介して共有秘密鍵を使用してDNSメッセージを効率的に認証する手段を提供しますが、手動交換以外にそのような鍵を設定するメカニズムを提供しません。このドキュメントでは、DNSリゾルバーとサーバー間でこのような共有秘密キーを確立および削除するために、さまざまなモードで使用できるTKEY RRを指定しています。
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].
TKEYが確立したキー情報とそれを使用するTSIGは、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.
TKEYの特定のモードは暗号化を実行し、一部の国ではそのエクスポートまたはインポートのステータスに影響を与える可能性があります。このドキュメントで指定されている影響を受けるモードは、サーバー割り当てモードとリゾルバー割り当てモードです。
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.
ここでのすべての場合において、「リゾルバ」という用語は、完全かつ増分的な[RFC 1995]ゾーン転送クエリを作成し、再帰クエリを転送するなど、サーバのその部分を含みます。
Section 2 below specifies the TKEY RR and provides a description of and considerations for its constituent fields.
以下のセクション2では、TKEY RRを指定し、その構成フィールドの説明と考慮事項を示します。
Section 3 describes general principles of operations with TKEY.
セクション3では、TKEYを使用した操作の一般原則について説明します。
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では、RRタイプTKEYのクエリオペコードを使用したDNS要求を介した鍵の一致と削除について説明します。このメソッドは、現在定義されているすべてのTKEYモードに適用できますが、直感的に「クエリ」と呼ばれるものではない場合もあります。
Section 5 discusses spontaneous inclusion of TKEY RRs in responses by servers which is currently used only for key deletion.
セクション5では、サーバーによる応答にTKEY RRが自発的に含まれることについて説明します。これは、現在キーの削除にのみ使用されています。
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では、TKEYモードの割り当てにおけるIANAの考慮事項について説明します。
Finally, Section 8 provides the required security considerations section.
最後に、セクション8では、必要なセキュリティの考慮事項セクションを示します。
The TKEY resource record (RR) has the structure given below. Its RR type code is 249.
TKEYリソースレコード（RR）の構造は次のとおりです。そのRRタイプコードは249です。
Field Type Comment
----- ---- -------
NAME domain see description below TTYPE u_int16_t TKEY = 249 CLASS u_int16_t ignored, SHOULD be 255 (ANY) TTL u_int32_t ignored, SHOULD be zero RDLEN u_int16_t size of RDATA RDATA: Algorithm: domain Inception: u_int32_t Expiration: u_int32_t Mode: u_int16_t Error: u_int16_t Key Size: u_int16_t Key Data: octet-stream Other Size: u_int16_t Other Data: octet-stream undefined by this specification
NAMEドメインは以下の説明を参照TTYPE u_int16_t TKEY = 249 CLASS u_int16_t無視、SHOULD 255（任意）TTL u_int32_t無視、SHOULD 0サイズ：u_int16_tキーデータ：オクテットストリームその他のサイズ：u_int16_tその他のデータ：この仕様では未定義のオクテットストリーム
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つのオクテット文字列のキー情報のみを配置できます。サーバーで既存の名前の別のキー情報セットを確立しようとすると、BADNAMEエラーが返されます。
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.
クエリに表示される非ルート名を持つTKEYの場合、TKEY RR名は、リゾルバーでローカルに一意であるドメインである必要があり、ワイヤーエンコーディングで128オクテット未満であり、キーの区別を支援するためにリゾルバーにとって意味があります。重要な合意セッション。クエリへの応答に表示されるTKEYの場合、TKEY RR名は、グローバルに一意のサーバー割り当てドメインにする必要があります（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.
所有者名としてrootを使用したクエリの結果としてキーが生成された場合、サーバーは、疑似ランダム[RFC 1750]ラベルにドメイン名のサフィックスを付けて、キー名となるグローバルに一意のドメイン名を作成する必要があります（SHOULD）。サーバーの。たとえば、89n3mDgX072pp.server1.example.comです。いずれの場合も新しい疑似ランダム名の生成が過度の計算負荷またはエントロピー流出である場合は、シリアル番号のプレフィックスを、1001.89n3mDgX072pp.server1.exampleなどのDNSサーバー開始時間を生成する固定疑似ランダム名に追加できます。 .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です。
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フィールドはTKEY RRでは意味がありません。古いDNS実装がTKEY RRをキャッシュしないようにするために、常にゼロにする必要があります。
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]と同じ意味のドメイン名の形式です。アルゴリズムは、TKEY RRを使用することに同意した秘密鍵情報が実際にアルゴリズム固有の鍵を導出するために使用される方法を決定します。
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日のGMTからの秒数で、リング演算を使用して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.
TKEY RRの開始時間と有効期限の解釈が異なるのを避けるために、リゾルバとそれらを交換するサーバーは、現在の時間について同じ考えを持っている必要があります。これを行う1つの方法は、NTPプロトコル[RFC 2030]を使用することですが、それまたはこの目的で使用される他の時間同期は、安全に行う必要があります。
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:
モードフィールドは、キーアグリーメントの一般的なスキームまたはTKEY DNSメッセージの目的を指定します。この仕様をサポートするサーバーとリゾルバーは、Diffie-Hellman鍵合意モードとクエリの鍵削除モードを実装する必要があります。他のすべてのモードはオプションです。サポートしていないモードのTKEY要求を受信するTKEYをサポートしているサーバーは、BADMODEエラーを返します。 Modeオクテットの次の値が定義、利用、または予約されています。
Value Description
----- -----------
0 - reserved, see section 7
1 server assignment
2 Diffie-Hellman exchange
3 GSS-API negotiation
4 resolver assignment
5 key deletion
6-65534 - available, see section 7
65535 - reserved, see section 7
The error code field is an extended RCODE. The following values are defined:
エラーコードフィールドは拡張RCODEです。以下の値が定義されています。
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.
TKEYクエリへの応答でTKEYエラーフィールドがゼロ以外の場合、DNSヘッダーのRCODEフィールドはエラーがないことを示します。ただし、TKEYが自発的に応答に含まれている場合、TKEY RRおよびDNSヘッダーのエラーフィールドに、関連しないゼロ以外のエラーコードが含まれる可能性があります。
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ビット整数で、オクテットでキー交換データフィールドのサイズを指定します。このデータの意味はモードによって異なります。
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.
Other SizeおよびOther Dataフィールドは、この仕様では使用されていませんが、将来の拡張で使用される可能性があります。 RDLENフィールドは、他のデータの終わりまでのRDATAセクションの長さに等しい必要があります。そうでない場合、RRは不正と見なされ、拒否されます。
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.
TKEYは、DNSに格納またはキャッシュされないメタRRであり、ゾーンファイルには表示されません。 DNSリゾルバとサーバー間の共有秘密鍵情報の確立と削除のためのさまざまなモードをサポートしています。このような共有鍵を確立するには、両端で状態を維持する必要があり、そのような状態を維持するためのリソースの割り当てには相互の合意が必要になる場合があります。そのような状態を提供する意思がない場合、サーバーはTKEYを使用する試みに対してNOTIMPやREFUSEDなどのエラーを返さなければならず、リゾルバは受け取ったTKEY RRを自由に無視できます。
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.
TKEYを使用して開発された共有秘密鍵の素材は、単純なオクテットシーケンスです。 TKEYを介して交換されるこの共有秘密鍵素材が実際に特定のTSIGアルゴリズムで使用される方法は、アルゴリズムに依存し、そのアルゴリズムに関連して定義されます。たとえば、TKEYが合意した共有秘密鍵の素材がHMAC-MD5アルゴリズムまたは他のHMACアルゴリズムでどのように使用されるかについては、[RFC 2104]を参照してください。
There MUST NOT be more than one TKEY RR in a DNS query or response.
DNSクエリまたは応答に複数のTKEY RRがあってはなりません。
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モードを除き、TKEY応答には、キーイングデータ、エラーコードなどの整合性を保護するために、常にDNSトランザクション認証が必要です。この認証では、以前に確立されたシークレット（TSIG）またはパブリック（SIG（0）を使用する必要があります[RFC 2931 ]）キー。検証する応答自体が提供するキーを使用してはなりません。
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.
TKEYクエリは、GSS-APIを除くすべてのモード、および状況によってはサーバー割り当てモードで認証される必要があります。特に、サーバーに割り当てられたキーのクエリが、更新権限などの特権をアサートするキーに対するものである場合、なりすましを防ぐためにクエリを認証する必要があります。ただし、キーがトランザクションのセキュリティのためだけに使用される場合、スプーフィングは最悪の場合、サービス拒否につながります。クエリ認証は、可能であれば、確立された秘密（TSIG）キー認証システムを使用する必要があります（SHOULD）。それ以外の場合は、公開（SIG（0））鍵署名を使用する必要があります。クエリ自体が提供するキーを使用してはなりません。
In the absence of required TKEY authentication, a NOTAUTH error MUST be returned.
必要なTKEY認証がない場合、NOTAUTHエラーを返す必要があります。
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年）またはその倍数のオーダーでリプレイした場合、TKEY応答またはクエリが無効になる必要があります。これを達成するために、TKEYメッセージを認証するTSIGまたはSIG（0）RRで使用されるキーイングマテリアルは、2 ** 31-1秒（約68年）を超える有効期間を持つことはできません。したがって、再生が試行されると、キーの有効期限が原因で認証中のTSIGまたはSIG（0）RRを検証できなくなり、再生は失敗します。
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.
リゾルバーとサーバーがTSIGで使用する共有秘密鍵素材について合意するための1つの方法は、リゾルバーからのDNSリクエストによるもので、これは構文的にはTKEYタイプのDNSクエリです。そのようなクエリは、使用中のモードを示すために追加情報セクションにTKEY RRを伴い、必要に応じて他の情報を伴う必要があります。
Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY ignore the recursive header bit in TKEY queries they receive.
タイプTKEYクエリは再帰的としてフラグを立ててはならず（SHOULD NOT）、サーバーは受信するTKEYクエリの再帰的ヘッダービットを無視してもよい（MAY）。
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モードを指定する追加情報セクションでTKEY RRを伴い、リゾルバーDiffie-Hellmanキーを指定する追加情報セクションでもKEY RRを伴う、タイプTKEYのクエリを送信します。 TKEY RRアルゴリズムフィールドは、リゾルバーが使用する予定の認証アルゴリズムに設定されます。 TKEYで提供される「鍵データ」は、ランダムな[RFC 1750]ナンスとして使用され、DH KEYの同じペアに対して同じ鍵情報を常に導き出すことを避けます。
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モードの応答セクションにTKEYが含まれています。このTKEYで提供される「キーデータ」は、DH KEYの同じペアに対して常に同じキー情報を導出することを回避するための追加のナンスとして使用されます。 TKEYエラーフィールドがゼロ以外の場合、指定された理由によりクエリが失敗しました。クエリにDHキーが含まれていない場合はFORMERRが返され、クエリに互換性のないDHキーが含まれている場合はBADKEYが返されます。
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:
TKEYエラーフィールドがゼロの場合、リゾルバが提供するDiffie-Hellman KEY RRは追加情報セクションにエコーされるべきであり、サーバーDiffie-Hellman KEY RRも応答の回答セクションに存在します。両方の当事者は、使用されたDiffie-Hellman（DH）キーのペア[Schneier]（これらのDHキーが同じジェネレーターとモジュラスを使用する場合）とTKEY RRのデータから同じ共有秘密量を計算できます。 TKEY RRデータは、次のようにDH結果と混合されます。
keying material = XOR ( DH value, MD5 ( query data | DH value ) | MD5 ( server data | DH value ) )
キー情報= XOR（DH値、MD5（クエリデータ| DH値）| MD5（サーバーデータ| DH値））
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値」は、KEY RRから導出されたDiffie-Hellman値です。クエリデータとサーバーデータは、TKEY RRデータフィールドで送信される値です。これらの「クエリデータ」と「サーバーデータ」のナンスには、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.
クエリTKEY RRの開始時間と有効期限は、キー生成情報に対して要求された時間です。応答TKEY RRの開始時間と有効期限は、サーバーがキー情報を有効と見なす最大期間です。サーバーはキーを事前に期限切れにする可能性があるため、これは保証されません。
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.
TKEYを介して確立されたキーは、ソフトステートとして扱うことができます。 DNSトランザクションはリゾルバーによって発信されるため、リゾルバーは単にキーをトスすることができますが、後でキー交換が必要になった場合は別のキー交換を経由する必要がある場合があります。同様に、サーバーはキーを破棄できますが、破棄されたキーを使用するTSIGでクエリを受信するとエラーが発生します。
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.
有効でなくなったキーへの要求への依存の試みを回避するために、サーバーはキー削除を実装する必要があります。これにより、サーバーは、キーの名前を持つTKEY RRの認証済み削除要求のリゾルバからの受信時にキーを「破棄」します。サーバーにその名前のキーのレコードがない場合、サーバーはBADNAMEを返します。
Key deletion TKEY queries MUST be authenticated. This authentication MAY be a TSIG RR using the key to be deleted.
キーの削除TKEYクエリは認証される必要があります。この認証は、削除されるキーを使用するTSIG RRである場合があります。
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キーの場合、サーバーは、キーに関連付けられたすべてのアクティブな状態を本当に「破棄」する必要があります。サーバーによって割り当てられたキーの場合、サーバーは、クライアントによって保持されなくなったキーをマークするだけでよく、サーバーによって割り当てられたキー情報の今後のクエリに応答して、キーを再送信できます。
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モードを指定するTKEY RRとTKEY RRのキーデータ部分でGSS-APIトークンを指定して、タイプTKEYのクエリと応答を交換できます。
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レベルは独自の認証を提供するため、このTKEYクエリと応答のモードは、TSIG RRまたはSIG（0）RRで認証される場合がありますが、必ずしも認証される必要はありません[RFC 2931]。
The inception and expiry times in a GSS-API mode TKEY RR are ignored.
GSS-APIモードのTKEY RRの開始および有効期限は無視されます。
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.
リゾルバーは、「サーバー割り当て」モードを指定するTKEY RRと応答の暗号化に使用されるリゾルバーKEY RRの両方が追加情報セクションにあるTKEYタイプのクエリを送信します。 TKEYアルゴリズムフィールドは、リゾルバーが使用する予定の認証アルゴリズムに設定されます。クエリTKEY RRでリゾルバーによって提供される「キーデータ」は、サーバーがサーバー生成のランダム性[RFC 1750]と強く混合して、使用するキー素材を導き出すことをお勧めします。クエリに表示されるKEY RRは、SIG（KEY）RRを伴う必要はありません。クエリがリゾルバーによってTSIG RR [RFC 2845]またはSIG（0）RRで認証され、その認証が検証される場合、クエリで提供されるSIG（KEY）はすべて無視されるべきです（SHOULD）。このようなクエリのKEY RRには、リゾルバーに対応する名前を付ける必要があります（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.
サーバーの応答には、サーバーの割り当てられたモードの応答セクションにTKEY RRが含まれており、追加情報セクションのクエリで提供されたKEY RRをエコーします。
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.
応答TKEYエラーフィールドがゼロの場合、応答TKEY RRのキーデータ部分は、リゾルバー提供のKEY RRの公開キーで暗号化されたサーバー割り当てのキーイングデータになります。この場合、応答TKEY RRの所有者名は、サーバーが割り当てたキーの名前になります。
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.
応答TKEYのエラーフィールドがゼロ以外の場合、指定された理由によりクエリが失敗しました。クエリが暗号化キーを指定しなかった場合、FORMERRが表示されます。
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.
クエリTKEY RRの開始時間と有効期限は、キー生成情報に対して要求された時間です。応答TKEYの開始時間と有効期限は、サーバーがキー情報を有効と見なす最大期間です。サーバーはキーを事前に期限切れにする可能性があるため、これは保証されません。
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.
TSIGまたはSIG（0）を使用したこのクエリの認証、またはSIG（KEY）を使用したリゾルバーKEYの署名を通じて、リゾルバーKEY RRを認証する必要があります。それ以外の場合、攻撃者は秘密鍵を知っているリゾルバKEYを偽造でき、それにより攻撃者はサーバーから有効な共有秘密鍵を取得する可能性があります。
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で説明されているように、送信時の保護のために、キー素材はサーバーキーで暗号化する必要があります。
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.
リゾルバーは、暗号化された鍵情報を指定するTKEY RRと、データの暗号化に使用されるサーバー公開鍵を指定するKEY RRを両方ともTKEYクエリに送信します。どちらも追加情報セクションにあります。キーの名前とキーイングデータは送信リゾルバによって完全に制御されるため、グローバルに一意のキー名を使用する必要があります（SHOULD）。使用されるKEY RRは、サーバーが対応する秘密鍵を持っているものでなければなりません。そうでない場合、鍵情報を復号化できず、FORMERRを返します。信頼できない当事者（できればサーバー以外の当事者）がKEY RRに対応する秘密キーを持たないことも重要です。秘密キーを持っている場合、サーバーへのメッセージをキャプチャし、共有シークレットを学習し、有効なTSIGを偽装できるためです。 。
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.
クエリTKEY RRの開始と有効期限は、クエリアがキー情報を有効であると見なす予定の期間を示します。サーバーはより短い時間間隔を返して、その状態を長く維持せず、どのような場合でもキーを事前に期限切れにすることができることを通知します。
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.
このクエリモードは、TSIGまたはSIG（0）で認証される必要があります。それ以外の場合、攻撃者はリゾルバが割り当てたTKEYクエリを偽造できるため、攻撃者はサーバーによって受け入れられ、使用され、受け入れられる共有秘密キーを指定する可能性があります。
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サーバーは、応答の追加情報としてTKEY RRを自発的に含めることができます。これは、クエリアがTKEYを理解し、このオプションが実装されていることをサーバーが知っている場合にのみ実行してください。この手法は、キーの削除に使用でき、将来定義されるモードに指定される可能性があります。この手法の欠点は、サーバーがエラーや成功の兆候を取り戻す方法がなく、UDPの場合、DNS応答がリゾルバーに到達したかどうかさえ知る方法がないことです。
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.
サーバーはオプションで、キーの名前を含む応答の追加情報セクションにTKEY RRを自発的に含め、キーの削除モードを指定することで、秘密キーを削除したことをクライアントに通知できます。そのような応答は認証されるべきです（SHOULD）。認証されると、指定された名前のキーを「削除」します。削除TKEY RRの開始および有効期限は無視されます。クライアントが応答でそのような追加情報を受信または適切に処理できない場合、クライアントはサーバーが破棄したキーを使用し、エラーを示す可能性があります。
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キーの場合、クライアントはキーに関連付けられたアクティブな状態を「破棄」する必要があります。クエリアによって割り当てられたキーの場合、クエリアはサーバーによって保持されなくなったキーを単にマークするだけでよく、クエリアによって割り当てられたキー情報を指定する将来のクエリでそれを再送信できます。
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.
サーバーが割り当てられ、リゾルバーが割り当てられた鍵合意モードの場合、鍵素材は、付随するKEY RR [RFC 2535]の公開鍵で暗号化されたTKEY RRの鍵データフィールド内で送信されます。このKEY RRは、公開鍵と秘密鍵を暗号化と、元の暗号化されたデータを復元する対応する復号化に使用できる公開鍵アルゴリズム用である必要があります。 KEY RRは、解読プロセスが対応する秘密鍵にアクセスしてデータを解読できるように、解読リゾルバー/サーバーの名前に対応する必要があります（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.
KEY RRがRSAアルゴリズムを指定する場合、PKCS＃1 [RFC 2437]のRSAES-PKCS1-v1_5暗号化の説明に従って、キー情報が暗号化されます。 （注意：送信される秘密の鍵素材は、PKCS＃1形式で直接RSA暗号化されます。他の対称アルゴリズムでは「エンベロープ」されません。）万が一、鍵素材が選択した1つのRSA係数に収まらない場合公開鍵、追加のRSA暗号化ブロックが含まれています。各ブロックの長さは、指定された公開RSAキーから明確であり、RSAES-PKCS1-v1_5パディングにより、暗号化されたデータのどの部分が実際にキー情報であり、どの部分がフォーマットされているか、または必要な少なくとも8バイトのランダム[RFC 1750]パディング。
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.
TKEYのRRタイプ249。
TKEY Modes 1 through 5 as listed in section 2.5.
セクション2.5に記載されているTKEYモード1〜5。
Extended RCODE Error values of 19, 20, and 21 as listed in section 2.6.
セクション2.6にリストされている19、20、および21の拡張RCODEエラー値。
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].
この仕様の全体は、TSIG [RFC 2845]をサポートするDNSクライアントとサーバー間の共有秘密の安全な確立に関係しています。
Protection against denial of service via the use of TKEY is not provided.
TKEYの使用によるサービス拒否に対する保護は提供されていません。
References
参考文献
[Schneier] Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1996, John Wiley and Sons
[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 1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC 1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC 1750] Eastlake、D.、Crocker、S。およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, September 1996.
[RFC 1982] Elz、R。およびR. Bush、「Serial Number Arithmetic」、RFC 1982、1996年9月。
[RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC 1995]太田雅明、「DNSの増分ゾーン転送」、RFC 1995、1996年8月。
[RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC 2030] Mills、D。、「Simple Network Time Protocol（SNTP）Version 4 for IPv4、IPv6 and OSI」、RFC 2030、1996年10月。
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC 2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[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 UPDATE）」、RFC 2136、1997年4月。
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC 2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998.
[RFC 2437] Kaliski、B。およびJ. Staddon、「PKCS＃1：RSA Cryptography Specifications Version 2.0」、RFC 2437、1998年10月。
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC 2535] Eastlake、D。、「ドメインネームシステムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999.
[RFC 2539] Eastlake、D。、「Storage in Diffie-Hellman Keys in the Domain Name System（DNS）」、RFC 2539、1999年3月。
[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC 2845] Vixie、P.、Gudmundsson、O.、Eastlake、D。およびB. Wellington、「DNSの秘密鍵トランザクション認証（TSIG）」、RFC 2845、2000年5月。
[RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000.
[RFC 2931] Eastlake、D。、「DNS Request and Transaction Signatures（SIG（0）s）」、RFC 2931、2000年9月。
Author's Address
著者のアドレス
Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA
ドナルドE.イーストレイク第3モトローラ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.
Copyright（C）The Internet Society（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 Editor機能への資金提供は、現在Internet Societyから提供されています。