[要約] RFC 8945はDNSのトランザクション認証のための秘密鍵方式であるTSIGに関するものです。このプロトコルの目的は、DNS更新やゾーン転送などのプロセスにおいて、データの完全性と認証を保証することです。利用場面には、セキュアなDNS更新、信頼できるゾーン転送、およびクライアントとサーバー間の認証が含まれます。
Internet Engineering Task Force (IETF) F. Dupont
Request for Comments: 8945 ISC
STD: 93 S. Morris
Obsoletes: 2845, 4635 Unaffiliated
Category: Standards Track P. Vixie
ISSN: 2070-1721 Farsight
D. Eastlake 3rd
Futurewei
O. Gudmundsson
Cloudflare
B. Wellington
Akamai
November 2020
Secret Key Transaction Authentication for DNS (TSIG)
DNSの秘密鍵トランザクション認証（TSIG）
Abstract
概要
This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server.
この文書では、共有秘密と一方向ハッシュを使用したトランザクションレベル認証のためのプロトコルについて説明します。承認されたクライアントからのDNSゾーンへの動的更新を認証したり、承認済みネームサーバーからの応答を認証したりするために使用できます。
No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism.
共有秘密を配布するための推奨事項はありません。ネットワーク管理者は、帯域外のメカニズムを使用してネームサーバーとクライアントを静的に設定することが予想されます。
This document obsoletes RFCs 2845 and 4635.
この文書はRFCS 2845と4635を廃止します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8945.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8945で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008年11月10日以前に公開されたIETF文書または公開されたIETFの貢献からの資料を含めることができます。この材料のいくつかの著作権を制御する人は、そのような材料の修正を許可する権利を信頼する権利を与えられなかった人物IETF標準の外部プロセス。そのような材料の著作権を制御する人から適切なライセンスを取得せずに、この文書はIETF規格プロセスの外で修正されていない可能性があり、それをフォーマットすること以外はIETF標準プロセスの外ではデリバティブ作品が作成されない可能性があります。RFCとしての出版物、または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction
1.1. Background
1.2. Protocol Overview
1.3. Document History
2. Key Words
3. Assigned Numbers
4. TSIG RR Format
4.1. TSIG RR Type
4.2. TSIG Record Format
4.3. MAC Computation
4.3.1. Request MAC
4.3.2. DNS Message
4.3.3. TSIG Variables
5. Protocol Details
5.1. Generation of TSIG on Requests
5.2. Server Processing of Request
5.2.1. Key Check and Error Handling
5.2.2. MAC Check and Error Handling
5.2.3. Time Check and Error Handling
5.2.4. Truncation Check and Error Handling
5.3. Generation of TSIG on Answers
5.3.1. TSIG on TCP Connections
5.3.2. Generation of TSIG on Error Returns
5.4. Client Processing of Answer
5.4.1. Key Error Handling
5.4.2. MAC Error Handling
5.4.3. Time Error Handling
5.4.4. Truncation Error Handling
5.5. Special Considerations for Forwarding Servers
6. Algorithms and Identifiers
7. TSIG Truncation Policy
8. Shared Secrets
9. IANA Considerations
10. Security Considerations
10.1. Issue Fixed in This Document
10.2. Why Not DNSSEC?
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
The Domain Name System (DNS) ([RFC1034] [RFC1035]) is a replicated hierarchical distributed database system that provides information fundamental to Internet operations, such as name-to-address translation and mail-handling information.
ドメインネームシステム（DNS）（[RFC1034] [RFC1035]）は、名前への翻訳とメール処理情報など、インターネット操作に情報を提供する複製された階層分散データベースシステムです。
This document specifies use of a message authentication code (MAC), generated using certain keyed hash functions, to provide an efficient means of point-to-point authentication and integrity checking for DNS transactions. Such transactions include DNS update requests and responses for which this can provide a lightweight alternative to the secure DNS dynamic update protocol described by [RFC3007].
このドキュメントは、特定のキー付きハッシュ関数を使用して生成されたメッセージ認証コード（MAC）の使用を指定して、DNSトランザクションのためのポイントツーポイント認証と整合性チェックの効率的な手段を提供します。そのようなトランザクションには、[RFC3007]によって記述されたセキュアDNS動的更新プロトコルに代わる軽量化が可能なDNS更新要求および応答が含まれる。
A further use of this mechanism is to protect zone transfers. In this case, the data covered would be the whole zone transfer including any glue records sent. The protocol described by DNSSEC ([RFC4033], [RFC4034], [RFC4035]) does not protect glue records and unsigned records.
このメカニズムのさらなる使用は、ゾーン転送を保護することです。この場合、カバーされたデータは、送信されたグルーレコードを含むゾーン転送全体になります。DNSSEC（[RFC4033]、[RFC4034]、[RFC4035]）によって記述されたプロトコルは、接着剤記録と符号なしレコードを保護しません。
The authentication mechanism proposed here provides a simple and efficient authentication between clients and servers, by using shared secret keys to establish a trust relationship between two entities. Such keys must be protected in a manner similar to private keys, lest a third party masquerade as one of the intended parties (by forging the MAC). The proposal is unsuitable for general server-to-server authentication and for servers that speak with many other servers, since key management would become unwieldy with the number of shared keys going up quadratically. But it is suitable for many resolvers on hosts that only talk to a few recursive servers.
ここで提案されている認証メカニズムは、共有秘密鍵を使用して2つのエンティティ間の信頼関係を確立することによって、クライアントとサーバー間の簡単で効率的な認証を提供します。そのようなキーは、秘密鍵と同様の方法で保護されなければなりません（Macを鍛えることによって）、意図された締約国の1つとして第三者のマスカレードを覆いました。この提案は、著作権管理が四分位の共有キーの数で扱いにくくなるため、一般的なサーバー間の認証および他の多くのサーバーで話すサーバーには適していません。しかし、いくつかの再帰的サーバーと通信するためだけにホスト上の多くのリゾルバに適しています。
Secret Key Transaction Authentication makes use of signatures on messages sent between the parties involved (e.g., resolver and server). These are known as "transaction signatures", or TSIG. For historical reasons, in this document, they are referred to as message authentication codes (MACs).
秘密鍵トランザクション認証は、関係する当事者（例えば、Resolver、Server）間で送信されたメッセージに関する署名を利用します。これらは「取引署名」、またはTSIGとして知られています。歴史的な理由から、この文書では、それらはメッセージ認証コード（MAC）と呼ばれます。
Use of TSIG presumes prior agreement between the two parties involved (e.g., resolver and server) as to any algorithm and key to be used. The way that this agreement is reached is outside the scope of the document.
TSIGの使用は、使用される任意のアルゴリズムおよび鍵に関する2つの締約国（例えば、リゾルバおよびサーバー）間の事前の合意を推定します。本契約に達する方法は文書の範囲外です。
A DNS message exchange involves the sending of a query and the receipt of one of more DNS messages in response. For the query, the MAC is calculated based on the hash of the contents and the agreed TSIG key. The MAC for the response is similar but also includes the MAC of the query as part of the calculation. Where a response comprises multiple packets, the calculation of the MAC associated with the second and subsequent packets includes in its inputs the MAC for the preceding packet. In this way, it is possible to detect any interruption in the packet sequence, although not its premature termination.
DNSメッセージ交換には、応答内のDNSメッセージのうちの1つのクエリの送信と受信が含まれます。クエリの場合、MACは、コンテンツのハッシュと合意されたTSIGキーに基づいて計算されます。応答のMacは似ていますが、計算の一部としてのクエリのMacも含まれています。応答が複数のパケットを含む場合、第2および後続のパケットに関連するMACの計算は、その入力内に先行するパケットのMACを含む。このようにして、その時期尚早の終了ではないが、パケットシーケンス内の割り込みを検出することが可能である。
The MAC is contained in a TSIG resource record included in the additional section of the DNS message.
MACは、DNSメッセージの追加セクションに含まれるTSIGリソースレコードに含まれています。
TSIG was originally specified by [RFC2845]. In 2017, two name server implementations strictly following that document (and the related [RFC4635]) were discovered to have security problems related to this feature ([CVE-2017-3142], [CVE-2017-3143], [CVE-2017-11104]). The implementations were fixed, but to avoid similar problems in the future, the two documents were updated and merged, producing this revised specification for TSIG.
TSIGはもともと[RFC2845]によって指定されました。2017年には、その文書（および関連する[RFC4635]）を厳守した2つのネームサーバー実装が、この機能に関連するセキュリティ上の問題を抱えていた（[CVE-2017-3142]、[CVE-2017-3143]、[CVE-2017]-11104]）。実装は修正されましたが、将来的にも同様の問題を回避するために、2つの文書が更新され合併され、この修正仕様をTSIGの仕様を生み出しています。
While TSIG implemented according to this RFC provides for enhanced security, there are no changes in interoperability. TSIG on the wire is still the same mechanism described in [RFC2845]; only the checking semantics have been changed. See Section 10.1 for further details.
このRFCに従って実装されているTSIGはセキュリティ強化を提供しますが、相互運用性に変更はありません。ワイヤーのTSIGはまだ[RFC2845]に記載されているのと同じメカニズムです。チェックセマンティクスのみが変更されました。詳細については10.1項を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document defines the following Resource Record (RR) type and associated value:
このドキュメントでは、次のリソースレコード（RR）タイプと関連付けられている値を定義します。
TSIG (250)
Tsig（250）
In addition, the document also defines the following DNS RCODEs and associated names:
さらに、この文書は、次のDNS RCODEと関連する名前も定義します。
16 (BADSIG) 17 (BADKEY) 18 (BADTIME) 22 (BADTRUNC)
16（BADSIG）17（BADKEY）18（BADTIME）22（BADTRUNC）
(See Section 2.3 of [RFC6895] concerning the assignment of the value 16 to BADSIG.)
（BADSIGへの値16の割り当てについては、[RFC6895のセクション2.3を参照）。）
These RCODES may appear within the "Error" field of a TSIG RR.
これらのRCODEはTSIG RRの「エラー」フィールド内に表示されることがあります。
To provide secret key authentication, we use an RR type whose mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and MUST NOT be cached. TSIG RRs are used for authentication between DNS entities that have established a shared secret key. TSIG RRs are dynamically computed to cover a particular DNS transaction and are not DNS RRs in the usual sense.
秘密鍵認証を提供するために、ニーモニックがT T T T T T T T T T T T T T T T T T T T T T T T T T Typeであり、そのタイプコードはMeta-RRで、キャッシュしてはいけません。TSIG RRSは、共有秘密鍵を確立したDNSエンティティ間の認証に使用されます。TSIG RRSは特定のDNSトランザクションをカバーするように動的に計算され、通常の意味ではDNS RRSではありません。
As the TSIG RRs are related to one DNS request/response, there is no value in storing or retransmitting them; thus, the TSIG RR is discarded once it has been used to authenticate a DNS message.
TSIG RRSが1つのDNS要求/応答に関連しているため、それらを格納または再送信するための値はありません。したがって、TSIG RRは、DNSメッセージを認証するために使用されたら、TSIG RRが破棄されます。
The fields of the TSIG RR are described below. All multi-octet integers in the record are sent in network byte order (see Section 2.3.2 of [RFC1035]).
TSIG RRのフィールドについては後述する。レコード内のすべてのマルチオクテット整数はネットワークバイト順序で送信されます（[RFC1035]のセクション2.3.2を参照）。
NAME: The name of the key used, in domain name syntax. The name should reflect the names of the hosts and uniquely identify the key among a set of keys these two hosts may share at any given time. For example, if hosts A.site.example and B.example.net share a key, possibilities for the key name include <id>.A.site.example, <id>.B.example.net, and <id>.A.site.example.B.example.net. It should be possible for more than one key to be in simultaneous use among a set of interacting hosts. This allows for periodic key rotation as per best operational practices, as well as algorithm agility as indicated by [RFC7696].
名前：ドメイン名構文で使用されるキーの名前。名前は、ホストの名前を反映し、これら2つのホストの中からキーを一意に識別する必要があります。これら2つのホストは、任意の時間に共有することがあります。たとえば、hosts a.site.exampleとb.example.netがキーを共有している場合、キー名の可能性は<id> .a.site.example、<id> .c.example.net、<id>です。.a.site.example.b.example.net。一連の対話ホスト間で複数の鍵を同時に使用することが可能であるべきです。これにより、[RFC7696]で示されるように、最良の運用慣行およびアルゴリズムの敏捷性のように周期的なキー回転が可能になる。
The name may be used as a local index to the key involved, but it is recommended that it be globally unique. Where a key is just shared between two hosts, its name actually need only be meaningful to them, but it is recommended that the key name be mnemonic and incorporate the names of participating agents or resources as suggested above.
名前は、関与するキーへのローカルインデックスとして使用されることがありますが、グローバルに一意になることをお勧めします。キーが2つのホスト間で共有されている場合、その名前は実際には意味があるだけですが、キー名は上記のように参加しているエージェントまたはリソースの名前を明らかにしています。
TYPE: This MUST be TSIG (250: Transaction SIGnature).
タイプ：これはTSIG（250：トランザクション署名）でなければなりません。
CLASS: This MUST be ANY.
クラス：これは任意でなければなりません。
TTL: This MUST be 0.
TTL：これは0でなければなりません。
RDLENGTH: (variable)
RDLENGTH :(変数）
RDATA: The RDATA for a TSIG RR consists of a number of fields, described below:
RDATA：TSIG RRのRDATAは、以下の数のフィールドで構成されています。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Algorithm Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Time Signed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Fudge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Size | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original ID | Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Len | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Other Data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the RDATA fields are:
RDATAフィールドの内容は次のとおりです。
Algorithm Name: an octet sequence identifying the TSIG algorithm in the domain name syntax. (Allowed names are listed in Table 3.) The name is stored in the DNS name wire format as described in [RFC1034]. As per [RFC3597], this name MUST NOT be compressed.
アルゴリズム名ドメイン名構文のTSIGアルゴリズムを識別するオクテットシーケンス。（許可された名前は表3にリストされています）名前は[RFC1034]に記載されているように、DNSネームワイヤフォーマットに格納されています。[RFC3597]に従って、この名前は圧縮されてはならない。
Time Signed: an unsigned 48-bit integer containing the time the message was signed as seconds since 00:00 on 1970-01-01 UTC, ignoring leap seconds.
時間署名：1970-01-01 UTCの00:00以降のメッセージが秒として署名されたunsigned 48ビット整数は、うるう秒を無視します。
Fudge: an unsigned 16-bit integer specifying the allowed time difference in seconds permitted in the Time Signed field.
Fudge：符号付きフィールドで許可された許容時間差を秒単位で指定する符号なし16ビット整数。
MAC Size: an unsigned 16-bit integer giving the length of the MAC field in octets. Truncation is indicated by a MAC Size less than the size of the keyed hash produced by the algorithm specified by the Algorithm Name.
MACサイズ：OctetsのMACフィールドの長さを与える符号なし16ビット整数。切り捨ては、アルゴリズム名によって指定されたアルゴリズムによって生成されたキー付きハッシュのサイズよりも小さいMACサイズによって示されます。
MAC: a sequence of octets whose contents are defined by the TSIG algorithm used, possibly truncated as specified by the MAC Size. The length of this field is given by the MAC Size. Calculation of the MAC is detailed in Section 4.3.
Mac：内容が使用されているTSIGアルゴリズムによって定義されている一連のオクテットは、MACサイズによって指定されているとおりに切り捨てられます。このフィールドの長さはMACサイズによって与えられます。MACの計算はセクション4.3に詳述されています。
Original ID: an unsigned 16-bit integer holding the message ID of the original request message. For a TSIG RR on a request, it is set equal to the DNS message ID. In a TSIG attached to a response -- or in cases such as the forwarding of a dynamic update request -- the field contains the ID of the original DNS request.
元のID：元の要求メッセージのメッセージIDを保持している符号なし16ビット整数。リクエストのTSIG RRの場合は、DNSメッセージIDに等しく設定されています。応答に添付されているTSIGで、または動的更新要求の転送などの場合は、フィールドには元のDNS要求のIDが含まれています。
Error: in responses, an unsigned 16-bit integer containing the extended RCODE covering TSIG processing. In requests, this MUST be zero.
エラー：応答では、拡張RCODEカバーTSIG処理を含む符号なし16ビット整数。要求では、これはゼロでなければなりません。
Other Len: an unsigned 16-bit integer specifying the length of the Other Data field in octets.
その他のLEN：オクテット内の他のデータフィールドの長さを指定する符号なし16ビット整数。
Other Data: additional data relevant to the TSIG record. In responses, this will be empty (i.e., Other Len will be zero) unless the content of the Error field is BADTIME, in which case it will be a 48-bit unsigned integer containing the server's current time as the number of seconds since 00:00 on 1970-01-01 UTC, ignoring leap seconds (see Section 5.2.3). This document assigns no meaning to its contents in requests.
その他のデータ：TSIGレコードに関連する追加データ。応答では、エラーフィールドの内容が不良時間でない限り、これは空（つまり、他のLENはゼロになります）、その場合、サーバーの現在時刻を含む48ビットの符号なし整数となります。：00 Leap Secondsを無視して、1970-01-01 UTCで（セクション5.2.3を参照）。このドキュメントは、その内容には要求に意味がありません。
When generating or verifying the contents of a TSIG record, the data listed in the rest of this section are passed, in the order listed below, as input to MAC computation. The data are passed in network byte order or wire format, as appropriate and are fed into the hashing function as a continuous octet sequence with no interfield separator or padding.
TSIGレコードの内容を生成または検証する場合、このセクションの残りの部分にリストされているデータは、MAC計算への入力として、以下にリストされている順序で渡されます。データは必要に応じてネットワークバイト順またはワイヤフォーマットに渡され、フィールド分離文字またはパディングなしの連続オクテットシーケンスとしてハッシュ関数に供給されます。
Only included in the computation of a MAC for a response message (or the first message in a multi-message response), the validated request MAC MUST be included in the MAC computation. If the request MAC failed to validate, an unsigned error message MUST be returned instead (Section 5.3.2).
応答メッセージ（またはマルチメッセージ応答内の最初のメッセージ）のMACの計算にのみ含まれていて、検証済みの要求MACをMACの計算に含める必要があります。リクエストMACが検証できなかった場合は、代わりに符号なしエラーメッセージを返す必要があります（セクション5.3.2）。
The request's MAC, comprising the following fields, is digested in wire format:
次のフィールドを含む要求のMacは、ワイヤフォーマットで消化されます。
+==========+=========================+========================+
| Field | Type | Description |
+==========+=========================+========================+
| MAC Size | Unsigned 16-bit integer | in network byte order |
+----------+-------------------------+------------------------+
| MAC Data | octet sequence | exactly as transmitted |
+----------+-------------------------+------------------------+
Table 1: Request's MAC
表1：リクエストのMac.
Special considerations apply to the TSIG calculation for the second and subsequent messages in a response that consists of multiple DNS messages (e.g., a zone transfer). These are described in Section 5.3.1.
特別な考慮事項は、複数のDNSメッセージ（例えば、ゾーン転送）で構成されている応答内の2番目以降のメッセージのTSIG計算に適用されます。これらはセクション5.3.1で説明されています。
In the MAC computation, the whole/complete DNS message in wire format is used.
MACの計算では、ワイヤフォーマットの全/完全なDNSメッセージが使用されます。
When creating an outgoing message, the TSIG is based on the message content before the TSIG RR has been added to the additional section and before the DNS Message Header's ARCOUNT has been incremented to include the TSIG RR.
送信メッセージを作成するとき、TSIGはTSIG RRが追加のセクションに追加され、DNSメッセージヘッダのARCOUNTがTSIG RRを含むようにインクリメントされる前にメッセージ内容に基づいています。
When verifying an incoming message, the TSIG is checked against the message after the TSIG RR has been removed, the ARCOUNT decremented, and the message ID replaced by the original message ID from the TSIG if those IDs differ. (This could happen, for example, when forwarding a dynamic update request.)
着信メッセージを検証するとき、TSIG RRが削除された後、TSIGがメッセージに対してチェックされ、ARCOUNTがデクリメントされ、それらのIDが異なる場合はTSIGから元のメッセージIDに置き換えられたメッセージIDが変更されます。（これは、例えば動的更新要求を転送するときに発生する可能性があります。）
Also included in the digest is certain information present in the TSIG RR. Adding this data provides further protection against an attempt to interfere with the message.
ダイジェストにも含まれているのは、TSIG RRに存在する特定の情報です。このデータを追加すると、メッセージを妨害しようとする試みに対するさらなる保護があります。
+============+================+====================================+
| Source | Field Name | Notes |
+============+================+====================================+
| TSIG RR | NAME | Key name, in canonical wire format |
+------------+----------------+------------------------------------+
| TSIG RR | CLASS | MUST be ANY |
+------------+----------------+------------------------------------+
| TSIG RR | TTL | MUST be 0 |
+------------+----------------+------------------------------------+
| TSIG RDATA | Algorithm Name | in canonical wire format |
+------------+----------------+------------------------------------+
| TSIG RDATA | Time Signed | in network byte order |
+------------+----------------+------------------------------------+
| TSIG RDATA | Fudge | in network byte order |
+------------+----------------+------------------------------------+
| TSIG RDATA | Error | in network byte order |
+------------+----------------+------------------------------------+
| TSIG RDATA | Other Len | in network byte order |
+------------+----------------+------------------------------------+
| TSIG RDATA | Other Data | exactly as transmitted |
+------------+----------------+------------------------------------+
Table 2: TSIG Variables
表2：TSIG変数
The RR RDLENGTH and RDATA MAC Size are not included in the input to MAC computation, since they are not guaranteed to be knowable before the MAC is generated.
RR RDLENGTHおよびRDATA MACサイズは、MACが生成される前に知られていることが保証されていないため、MACの計算への入力には含まれません。
The Original ID field is not included in this section, as it has already been substituted for the message ID in the DNS header and hashed.
元のIDフィールドは、DNSヘッダーのメッセージIDの代わりになっているため、このセクションには含まれていません。
For each label type, there must be a defined "Canonical wire format" that specifies how to express a label in an unambiguous way. For label type 00, this is defined in Section 6.2 of [RFC4034]. The use of label types other than 00 is not defined for this specification.
各ラベルの種類について、ラベルを明確な方法で表現する方法を指定する定義された「正規ワイヤフォーマット」が必要です。ラベルタイプ00の場合、これは[RFC4034]のセクション6.2で定義されています。この仕様には00以外のラベルタイプの使用は定義されていません。
The data digested includes the two timer values in the TSIG header in order to defend against replay attacks. If this were not done, an attacker could replay old messages but update the Time Signed and Fudge fields to make the message look new. The two fields are collectively named "TSIG Timers", and for the purpose of MAC calculation, they are hashed in their wire format, in the following order: first Time Signed, then Fudge.
消化されたデータは、再生攻撃に対して守るためにTSIGヘッダー内の2つのタイマ値を含みます。これが行われなかった場合、攻撃者は古いメッセージを再生することができますが、メッセージを新しいメッセージとファッジフィールドを更新してメッセージを新しく見えます。2つのフィールドはまとめて "TSIG Timers"という名前で、MAC計算の目的で、それらは次の順序で、次の順序でハッシュされます。
Once the outgoing record has been constructed, the client performs the keyed hash (Hashed Message Authentication Code (HMAC)) computation, appends a TSIG record with the calculated MAC to the additional section (incrementing the ARCOUNT to reflect the additional RR), and transmits the request to the server. This TSIG record MUST be the only TSIG RR in the message and MUST be the last record in the additional data section. The client MUST store the MAC and the key name from the request while awaiting an answer.
発信レコードが構築されると、クライアントはキー付きハッシュ（ハッシュメッセージ認証コード（HMAC））計算を実行し、計算されたMACとのTSIGレコードを追加のセクション（追加のRRを反映するようにインクリメントする）を追加して送信する。サーバーへの要求このTSIGレコードはメッセージ内の唯一のTSIG RRでなければならず、追加のデータセクションの最後のレコードである必要があります。クライアントは、答えを待っている間に、要求からMacとキー名を保存する必要があります。
The digest components for a request are:
リクエストのダイジェストコンポーネントは次のとおりです。
DNS Message (request) TSIG Variables (request)
DNSメッセージ（要求）TSIG変数（リクエスト）
If an incoming message contains a TSIG record, it MUST be the last record in the additional section. Multiple TSIG records are not allowed. If multiple TSIG records are detected or a TSIG record is present in any other position, the DNS message is dropped and a response with RCODE 1 (FORMERR) MUST be returned. Upon receipt of a message with exactly one correctly placed TSIG RR, a copy of the TSIG RR is stored and the TSIG RR is removed from the DNS message and decremented out of the DNS message header's ARCOUNT.
着信メッセージにTSIGレコードが含まれている場合は、追加のセクションの最後のレコードでなければなりません。複数のTSIGレコードは許可されていません。複数のTSIGレコードが検出された場合、またはTSIGレコードが他の位置にある場合は、DNSメッセージがドロップされ、RCODE 1（以前）を使用した応答が返されなければなりません。正確に1つずつ設定されたTSIG RRを含むメッセージを受信すると、TSIG RRのコピーが格納され、TSIG RRがDNSメッセージから削除され、DNSメッセージヘッダのARCOUNTからデクリメントされる。
If the TSIG RR cannot be interpreted, the server MUST regard the message as corrupt and return a FORMERR to the server. Otherwise, the server is REQUIRED to return a TSIG RR in the response.
TSIG RRを解釈できない場合、サーバーはメッセージを破損してサーバーに返却する必要があります。それ以外の場合、サーバーは応答にTSIG RRを返す必要があります。
To validate the received TSIG RR, the server MUST perform the following checks in the following order:
受信したTSIG RRを検証するには、サーバーは次の順序で次のチェックを実行する必要があります。
1. Check key
1. キーの確認
2. Check MAC
2. Macをチェックしてください
3. Check time values
3. 時間値を確認してください
4. Check truncation policy
4. 切り捨て方針を確認してください
If a non-forwarding server does not recognize the key or algorithm used by the client (or recognizes the algorithm but does not implement it), the server MUST generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned as specified in Section 5.3.2. The server SHOULD log the error. (Special considerations apply to forwarding servers; see Section 5.5.)
非転送サーバがクライアントによって使用されるキーまたはアルゴリズムを認識しない場合（またはアルゴリズムを認識しているが実装されていない）場合、サーバはRCODE 9（NotAuth）およびTSIGエラー17（BADKEY）を使用してエラー応答を生成する必要があります。この応答はセクション5.3.2で指定されているように符号なしでなければなりません。サーバーはエラーを記録する必要があります。（特別な考慮事項は、転送サーバーに適用されます。セクション5.5を参照）
Using the information in the TSIG, the server MUST verify the MAC by doing its own calculation and comparing the result with the MAC received. If the MAC fails to verify, the server MUST generate an error response as specified in Section 5.3.2 with RCODE 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG). This response MUST be unsigned, as specified in Section 5.3.2. The server SHOULD log the error.
TSIG内の情報を使用して、サーバーは独自の計算を行い、結果を受信したMACと比較することによってMACを検証する必要があります。MACが検証に失敗した場合、サーバーはセクション5.3.2で指定されているようにエラー応答を生成する必要があります。セクション5.3.2で指定されているように、この応答は符号なしでなければなりません。サーバーはエラーを記録する必要があります。
When space is at a premium and the strength of the full length of a MAC is not needed, it is reasonable to truncate the keyed hash and use the truncated value for authentication. HMAC SHA-1 truncated to 96 bits is an option available in several IETF protocols, including IPsec and TLS. However, while this option is kept for backwards compatibility, it may not provide a security level appropriate for all cases in the modern environment. In these cases, it is preferable to use a hashing algorithm such as SHA-256-128, SHA-384-192, or SHA-512-256 [RFC4868].
スペースが保険料になっていて、MACの全長の強さが不要な場合は、キー付きハッシュを切り捨て、認証に切り捨てられた値を使用することが合理的です。HMAC SHA-1は96ビットに切り捨てられた、IPsecやTLSを含むいくつかのIETFプロトコルで利用可能なオプションです。ただし、このオプションは下位互換性のために保持されている間、現代の環境のすべての場合に適したセキュリティレベルを提供することはできません。このような場合、SHA-256-128、SHA-384-192、またはSHA-512-256 [RFC4868]などのハッシュアルゴリズムを使用することが好ましい。
Processing of a truncated MAC follows these rules:
切り捨てられたMacの処理は、次の規則に従います。
If the MAC Size field is greater than the keyed hash output length: This case MUST NOT be generated and, if received, MUST cause the DNS message to be dropped and RCODE 1 (FORMERR) to be returned.
MACサイズフィールドがキー付きハッシュ出力長より大きい場合：このケースは生成されてはならず、受信した場合はDNSメッセージをドロップさせてRCODE 1（以前）を返す必要があります。
If the MAC Size field equals the keyed hash output length: The entire keyed hash output is present and used.
MACサイズフィールドがキー付きハッシュ出力長に等しい場合：キー付きハッシュ出力全体が存在して使用されます。
If the MAC Size field is less than the larger of 10 (octets) and half the length of the hash function in use: With the exception of certain TSIG error messages described in Section 5.3.2, where it is permitted that the MAC Size be zero, this case MUST NOT be generated and, if received, MUST cause the DNS message to be dropped and RCODE 1 (FORMERR) to be returned.
MACサイズフィールドが10（オクテット）の大きい10（オクテット）よりも小さい場合、使用中のハッシュ関数の長さの半数以下である場合：5.3.2項で説明されている特定のTSIGエラーメッセージを除いて、MACサイズが許可されている場合ゼロ、このケースは生成されてはならず、受信した場合はDNSメッセージをドロップし、RCode 1（以前）を返す必要があります。
Otherwise: This is sent when the signer has truncated the keyed hash output to an allowable length, as described in [RFC2104], taking initial octets and discarding trailing octets. TSIG truncation can only be to an integral number of octets. On receipt of a DNS message with truncation thus indicated, the locally calculated MAC is similarly truncated, and only the truncated values are compared for authentication. The request MAC used when calculating the TSIG MAC for a reply is the truncated request MAC.
それ以外の場合：これは、初期オクテットと末尾のオクテットを廃棄して、[RFC2104]で説明されているように、署名者がキー付きハッシュ出力を許容された長さに切り捨てたときに送信されます。TSIGの切り捨ては、整数のオクテットのみにしかありません。このように表示された切り捨てでDNSメッセージを受信すると、ローカルに計算されたMACも同様に切り捨てられ、切り捨てられた値だけが認証のために比較されます。応答のTSIG MACを計算するときに使用される要求MACは、切り捨てられた要求Macです。
If the server time is outside the time interval specified by the request (which is the Time Signed value plus/minus the Fudge value), the server MUST generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 (BADTIME). The server SHOULD also cache the most recent Time Signed value in a message generated by a key and SHOULD return BADTIME if a message received later has an earlier Time Signed value. A response indicating a BADTIME error MUST be signed by the same key as the request. It MUST include the client's current time in the Time Signed field, the server's current time (an unsigned 48-bit integer) in the Other Data field, and 6 in the Other Len field. This is done so that the client can verify a message with a BADTIME error without the verification failing due to another BADTIME error. In addition, the Fudge field MUST be set to the fudge value received from the client. The data signed is specified in Section 5.3.2. The server SHOULD log the error.
サーバーの時間が要求によって指定された時間間隔（時間符号付き値とファッジ値）で指定された時間間隔の外側にある場合、サーバーはRCODE 9（NotAuth）とTSIGエラー18（BADTIME）でエラー応答を生成する必要があります。サーバーはまた、キーによって生成されたメッセージ内の最新の時間符号付き値をキャッシュする必要があり、後で受信したメッセージが早い時間符号付き値を持つ場合には不良時間を返すべきです。不正なエラーを示す応答は、要求と同じキーによって署名されなければなりません。それはQualit符号付きフィールドのクライアントの現在の時刻を含める必要があります。サーバーの他のデータフィールドの現在の時刻（符号なし48ビット整数）、および他のLENフィールドの6。これは、クライアントが別の不正なエラーのために検証に失敗しないように、クライアントが不正なエラーを持つメッセージを検証できるようにします。さらに、ファッジフィールドは、クライアントから受信したファッジ値に設定する必要があります。署名されたデータはセクション5.3.2で指定されています。サーバーはエラーを記録する必要があります。
Caching the most recent Time Signed value and rejecting requests with an earlier one could lead to valid messages being rejected if transit through the network led to UDP packets arriving in a different order to the one in which they were sent. Implementations should be aware of this possibility and be prepared to deal with it, e.g., by retransmitting the rejected request with a new TSIG once outstanding requests have completed or the time given by their Time Signed value plus the Fudge value has passed. If implementations do retry requests in these cases, a limit SHOULD be placed on the maximum number of retries.
最新の時間符号付き値と早期の要求を拒否する要求を拒否すると、ネットワークを通過すると、送信されたIDPパケットが送信されたものに到着したUDPパケットが到着した場合、有効なメッセージが拒否される可能性があります。実装はこの可能性を認識し、それに対処するために準備されるべきである、例えば、拒否された要求を新しいTSIGで再送信することによって、未処理の要求が完了したか、またはそれらの時間符号付き値とファッジ値に与えられた時間が経過した。この場合、実装がリクエストを再試行している場合は、最大再試行回数に制限を配置する必要があります。
If a TSIG is received with truncation that is permitted per Section 5.2.2.1 but the MAC is too short for the local policy in force, an RCODE 9 (NOTAUTH) and TSIG ERROR 22 (BADTRUNC) MUST be returned. The server SHOULD log the error.
セクション5.2.2.1で許可されている切り捨てでTSIGを受信した場合は、ローカルポリシーが強制的に短すぎる場合は、RCODE 9（NotAuth）とTSIGエラー22（BADTRUNC）を返す必要があります。サーバーはエラーを記録する必要があります。
When a server has generated a response to a signed request, it signs the response using the same algorithm and key. The server MUST NOT generate a signed response to a request if either the key is invalid (e.g., key name or algorithm name are unknown) or the MAC fails validation; see Section 5.3.2 for details of responding in these cases.
サーバーが署名付き要求に対する応答を生成した場合は、同じアルゴリズムとキーを使用して応答に署名します。キーが無効である場合（例えば、キー名またはアルゴリズム名が不明な）、またはMACが検証に失敗した場合、サーバーは要求に対して署名された応答を生成してはいけません。これらの場合の応答の詳細については、5.3.2項を参照してください。
It also MUST NOT generate a signed response to an unsigned request, except in the case of a response to a client's unsigned TKEY request if the secret key is established on the server side after the server processed the client's request. Signing responses to unsigned TKEY requests MUST be explicitly specified in the description of an individual secret key establishment algorithm [RFC3645].
また、サーバがクライアントの要求を処理した後にサーバ側でシークレットキーが確立された場合、クライアントの符号なしTKEY要求に対する応答の場合を除いて、符号なし要求に対する符号付き応答を生成してはいけません。符号なしTKEY要求への応答の署名は、個々の秘密鍵確立アルゴリズム[RFC3645]の説明で明示的に指定する必要があります。
The digest components used to generate a TSIG on a response are:
応答に対してTSIGを生成するために使用されるダイジェストコンポーネントは次のとおりです。
Request MAC DNS Message (response) TSIG Variables (response)
Mac DNSメッセージ（応答）TSIG変数（応答）
(This calculation is different for the second and subsequent message in a multi-message answer; see below.)
（この計算は、マルチメッセージ回答の2番目以降のメッセージとは異なります。下記参照）
If addition of the TSIG record will cause the message to be truncated, the server MUST alter the response so that a TSIG can be included. This response contains only the question and a TSIG record, has the TC bit set, and has an RCODE of 0 (NOERROR). At this point, the client SHOULD retry the request using TCP (as per Section 4.2.2 of [RFC1035]).
TSIGレコードの追加がメッセージを切り捨てると、TSIGを含めることができるようにサーバーは応答を変更する必要があります。この応答には質問とTSIGレコードのみが含まれており、TCビットが設定されており、RCODEが0（NOERROR）にあります。この時点で、クライアントはTCPを使用してリクエストを再試行する必要があります（[RFC1035]のセクション4.2.2）。
A DNS TCP session, such as a zone transfer, can include multiple DNS messages. Using TSIG on such a connection can protect the connection from an attack and provide data integrity. The TSIG MUST be included on all DNS messages in the response. For backward compatibility, a client that receives DNS messages and verifies TSIG MUST accept up to 99 intermediary messages without a TSIG and MUST verify that both the first and last message contain a TSIG.
ゾーン転送などのDNS TCPセッションは、複数のDNSメッセージを含めることができます。そのような接続でTSIGを使用すると、攻撃からの接続を保護し、データの整合性を提供できます。TSIGは、応答内のすべてのDNSメッセージに含める必要があります。下位互換性のために、DNSメッセージを受信し、TSIgを検証するクライアントはTSIGなしで最大99の中間メッセージを受け入れ、最初と最後のメッセージの両方にTSIGが含まれていることを確認する必要があります。
The first message is processed as a standard answer (see Section 5.3), but subsequent messages have the following digest components:
最初のメッセージは標準回答として処理されます（セクション5.3を参照）が、その後のメッセージには次のダイジェストコンポーネントがあります。
Prior MAC (running) DNS Messages (any unsigned messages since the last TSIG) TSIG Timers (current message)
従来のMAC（実行中）DNSメッセージ（最後のTSIG以降の符号なしメッセージ）TSIGタイマー（現在のメッセージ）
The "Prior MAC" is the MAC from the TSIG attached to the last message containing a TSIG. "DNS Messages" comprises the concatenation (in message order) of all messages after the last message that included a TSIG and includes the current message. "TSIG Timers" comprises the Time Signed and Fudge fields (in that order) pertaining to the message for which the TSIG was created; this means that the successive TSIG records in the stream will have non-decreasing Time Signed values. Note that only the timers are included in the second and subsequent messages, not all the TSIG variables.
「前のMAC」は、TSIGを含む最後のメッセージに接続されているTSIGのMACです。「DNSメッセージ」は、TSIGを含む最後のメッセージの後のすべてのメッセージの連結（メッセージ順序）を含み、現在のメッセージを含む。「Tsig Timers」は、TSIGが作成されたメッセージに関する時間署名およびファッジフィールド（その順序）を含む。これは、ストリーム内の連続するTSIGレコードが減少しない時間符号付き値を持つことを意味します。タイマーだけが、すべてのTSIG変数ではなく、2番目以降のメッセージに含まれています。
This allows the client to rapidly detect when the session has been altered; at which point, it can close the connection and retry. If a client TSIG verification fails, the client MUST close the connection. If the client does not receive TSIG records frequently enough (as specified above), it SHOULD assume the connection has been hijacked, and it SHOULD close the connection. The client SHOULD treat this the same way as they would any other interrupted transfer (although the exact behavior is not specified).
これにより、セッションが変更されたときにクライアントは迅速に検出できます。どの時点で、接続を閉じて再試行することができます。クライアントTSIGの検証が失敗した場合、クライアントは接続を閉じる必要があります。クライアントがTSIGレコードを十分に頻繁に受信しない場合（上記のように）、接続がハイジャックされていると仮定する必要があります。接続を閉じる必要があります。クライアントは、他の中断された転送と同じ方法でこれを扱う必要があります（正確な動作は指定されていません）。
When a server detects an error relating to the key or MAC in the incoming request, the server SHOULD send back an unsigned error message (MAC Size == 0 and empty MAC). It MUST NOT send back a signed error message.
サーバーが着信要求でキーまたはMACに関するエラーを検出すると、サーバーは符号なしエラーメッセージ（MACサイズ== 0と空のMAC）を送ります。署名付きエラーメッセージを送ってはいけません。
If an error is detected relating to the TSIG validity period or the MAC is too short for the local policy, the server SHOULD send back a signed error message. The digest components are:
TSIGの有効期間に関連するエラーが検出された場合、またはローカルポリシーにMACが短すぎる場合、サーバーは署名付きエラーメッセージを送り返す必要があります。ダイジェストコンポーネントは次のとおりです。
Request MAC (if the request MAC validated) DNS Message (response) TSIG Variables (response)
リクエストMAC（リクエストMACが検証された場合）DNSメッセージ（応答）TSIG変数（応答）
The reason that the request MAC is not included in this MAC in some cases is to make it possible for the client to verify the error. If the error is not a TSIG error, the response MUST be generated as specified in Section 5.3.
要求MACがこのMacに含まれていないのは、クライアントがエラーを検証できるようにすることです。エラーがTSIGエラーでない場合は、セクション5.3で指定されているとおりに応答を生成する必要があります。
When a client receives a response from a server and expects to see a TSIG, it first checks if the TSIG RR is present in the response. If not, the response is treated as having a format error and is discarded.
クライアントがサーバーからの応答を受信し、TSIGを見ることを期待している場合、最初にTSIG RRが応答に存在するかどうかを確認します。そうでない場合、応答はフォーマットエラーを持つように扱われ、破棄されます。
If the TSIG RR is present, the client performs the same checks as described in Section 5.2. If the TSIG RR is unsigned as specified in Section 5.3.2 or does not validate, the message MUST be discarded unless the RCODE is 9 (NOAUTH). In this case, the client SHOULD attempt to verify the response as if it were a TSIG error, as described in the following subsections.
TSIG RRが存在する場合、クライアントはセクション5.2で説明されているのと同じチェックを実行します。TSIG RRがセクション5.3.2で指定されているか検証しない場合は、rコードが9（NOAUTH）の場合を除いて、メッセージを破棄する必要があります。この場合、クライアントは、次のサブセクションで説明されているように、それがTSIGエラーであるかのように応答を検証しようとしているはずです。
Regardless of the RCODE, a message containing a TSIG RR that is unsigned as specified in Section 5.3.2 or that fails verification SHOULD NOT be considered an acceptable response, as it may have been spoofed or manipulated. Instead, the client SHOULD log an error and continue to wait for a signed response until the request times out.
RCODEに関係なく、セクション5.3.2で指定されている場合、または検証に失敗したTSIG RRを含むメッセージは、偽装または操作された可能性があるため、許容できる応答と見なされるべきではありません。代わりに、クライアントはエラーを記録し、要求がタイムアウトするまで署名された応答を待ち続けるべきです。
If an RCODE on a response is 9 (NOTAUTH), but the response TSIG validates and the TSIG key is recognized by the client but is different from that used on the request, then this is a key-related error. The client MAY retry the request using the key specified by the server. However, this should never occur, as a server MUST NOT sign a response with a different key to that used to sign the request.
応答上のRCODEが9（NotAuth）であるが、応答TSIGが検証され、TSIGキーがクライアントによって認識されているが、要求に使用されるものとは異なるが、これはキー関連のエラーである。クライアントは、サーバーによって指定された鍵を使用して要求を再試行することができます。ただし、サーバーがリクエストに署名するために使用されていた異なるキーで応答に署名してはいけませんので、これは発生しません。
If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this is a MAC-related error, and clients MAY retry the request with a new request ID, but it would be better to try a different shared key if one is available. Clients SHOULD keep track of how many MAC errors are associated with each key. Clients SHOULD log this event.
応答RCODEが9（NotAuth）とTSIGエラーの場合（BADSIG）、これはMAC関連のエラーであり、クライアントは新しいリクエストIDを使用して要求を再試行することができますが、異なる共有キーを試すことをお勧めします。1つが利用可能です。クライアントは、各キーに関連するMACエラーの数を追跡する必要があります。クライアントはこのイベントを記録する必要があります。
If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18 (BADTIME) or the current time does not fall in the range specified in the TSIG record, then this is a time-related error. This is an indication that the client and server clocks are not synchronized. In this case, the client SHOULD log the event. DNS resolvers MUST NOT adjust any clocks in the client based on BADTIME errors, but the server's time in the Other Data field SHOULD be logged.
応答RCODEが9（NotAuth）で、TSIGエラーが18（不良）、またはTSIGレコードで指定された範囲内にある場合は、時間関連のエラーです。これは、クライアントのクロックとサーバーのクロックが同期されていないことを示しています。この場合、クライアントはイベントを記録する必要があります。DNSリゾルバは、不正なエラーに基づいてクライアント内のクロックを調整してはいけませんが、他のデータフィールドのサーバーの時間を記録する必要があります。
If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 22 (BADTRUNC), then this is a truncation-related error. The client MAY retry with a lesser truncation up to the full HMAC output (no truncation), using the truncation used in the response as a hint for what the server policy allowed (Section 7). Clients SHOULD log this event.
応答RCODEが9（NotAuth）で、TSIGエラーが22（BADTRUNC）の場合、これは切り捨て関連のエラーです。クライアントは、サーバーポリシーの許可されているもののヒントとして、応答で使用されている切り捨てを使用して、フルHMAC出力（切り捨てなし）までの切り捨てで再試行することができます（セクション7）。クライアントはこのイベントを記録する必要があります。
A server acting as a forwarding server of a DNS message SHOULD check for the existence of a TSIG record. If the name on the TSIG is not of a secret that the server shares with the originator, the server MUST forward the message unchanged including the TSIG. If the name of the TSIG is of a key this server shares with the originator, it MUST process the TSIG. If the TSIG passes all checks, the forwarding server MUST, if possible, include a TSIG of its own to the destination or the next forwarder. If no transaction security is available to the destination and the message is a query, and if the corresponding response has the AD flag (see [RFC4035]) set, the forwarder MUST clear the AD flag before adding the TSIG to the response and returning the result to the system from which it received the query.
DNSメッセージの転送サーバとして機能するサーバは、TSIGレコードの存在を確認する必要があります。TSIGの名前がサーバーが発信者と共有する秘密ではない場合、サーバーはTSIGを含めて変更されずにメッセージを転送する必要があります。TSIGの名前がこのサーバーが発信者と共有するキーの場合は、TSIGを処理する必要があります。TSIGがすべてのチェックを渡す場合、転送サーバーは可能であれば、宛先または次のフォワーダに独自のTSIGを含める必要があります。宛先でトランザクションセキュリティが利用できず、メッセージがクエリであり、対応する応答がADフラグ（[RFC4035]を参照）を設定している場合は、転送先はTSIGを応答に追加して返す前にADフラグをクリアする必要があります。その結果、クエリを受け取ったシステムになります。
The only message digest algorithm specified in the first version of these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321] and [RFC2104]). Although a review of its security some years ago [RFC6151] concluded that "it may not be urgent to remove HMAC-MD5 from the existing protocols", with the availability of more secure alternatives, the opportunity has been taken to make the implementation of this algorithm optional.
これらの仕様[RFC2845]の最初のバージョンで指定された唯一のメッセージダイジェストアルゴリズムは "HMAC-MD5"でした（[RFC1321]、[RFC2104]参照）。200年前のセキュリティのレビューは、「既存のプロトコルからHMAC-MD5を削除することは緊急ではないかもしれません」と、より安全な代替手段の可用性を持つ、この機会はこれを実装するために取られました。アルゴリズムオプション。
[RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4]
[RFC3174]. SHA-1 collisions have been demonstrated [SHA1SHAMBLES],
so the MD5 security considerations described in Section 2 of
[RFC6151] apply to SHA-1 in a similar manner. Although support for
hmac-sha1 in TSIG is still mandatory for compatibility reasons,
existing uses SHOULD be replaced with hmac-sha256 or other SHA-2
digest algorithms ([FIPS180-4], [RFC3874], [RFC6234]).
Use of TSIG between two DNS agents is by mutual agreement. That agreement can include the support of additional algorithms and criteria as to which algorithms and truncations are acceptable, subject to the restriction and guidelines in Section 5.2.2.1. Key agreement can be by the TKEY mechanism [RFC2930] or some other mutually agreeable method.
2つのDNSエージェント間のTSIGの使用は相互合意によるものです。その契約には、5.2.2.1の制限およびガイドラインに従って、どのアルゴリズムと切り捨てが許容できる追加のアルゴリズムと基準のサポートも含まれます。主な合意は、TKEYメカニズム[RFC2930]またはその他の相互に賛成の方法によるものです。
Implementations that support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig and the other algorithms listed below. SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
TSIGをサポートする実装はまた、HMAC SHA1およびHMAC SHA256を実行しなければならず、GSS-TSIGおよび以下にリストされている他のアルゴリズムを実装することができる。SHA-1は96ビット（12オクテット）に切り捨てられた（12オクテット）を実装する必要があります。
+==========================+================+=================+
| Algorithm Name | Implementation | Use |
+==========================+================+=================+
| HMAC-MD5.SIG-ALG.REG.INT | MAY | MUST NOT |
+--------------------------+----------------+-----------------+
| gss-tsig | MAY | MAY |
+--------------------------+----------------+-----------------+
| hmac-sha1 | MUST | NOT RECOMMENDED |
+--------------------------+----------------+-----------------+
| hmac-sha224 | MAY | MAY |
+--------------------------+----------------+-----------------+
| hmac-sha256 | MUST | RECOMMENDED |
+--------------------------+----------------+-----------------+
| hmac-sha256-128 | MAY | MAY |
+--------------------------+----------------+-----------------+
| hmac-sha384 | MAY | MAY |
+--------------------------+----------------+-----------------+
| hmac-sha384-192 | MAY | MAY |
+--------------------------+----------------+-----------------+
| hmac-sha512 | MAY | MAY |
+--------------------------+----------------+-----------------+
| hmac-sha512-256 | MAY | MAY |
+--------------------------+----------------+-----------------+
Table 3: Algorithms for Implementations Supporting TSIG
表3：Tsigをサポートする実装のためのアルゴリズム
As noted above, two DNS agents (e.g., resolver and server) must mutually agree to use TSIG. Implicit in such an "agreement" are criteria as to acceptable keys, algorithms, and (with the extensions in this document) truncations. Local policies MAY require the rejection of TSIGs, even though they use an algorithm for which implementation is mandatory.
上記のように、2つのDNSエージェント（例えば、レゾルバおよびサーバー）はTSIGを使用することに相互に同意されなければならない。そのような「契約」に暗黙のうちに、許容できるキー、アルゴリズム、および（この文書の拡張子を持つ）の切り捨てに関する基準です。ローカルポリシーは、実装が必須のアルゴリズムを使用していても、TSIGの拒絶を必要とする場合があります。
When a local policy permits acceptance of a TSIG with a particular algorithm and a particular non-zero amount of truncation, it SHOULD also permit the use of that algorithm with lesser truncation (a longer MAC) up to the full keyed hash output.
ローカルポリシーが特定のアルゴリズムと特定のゼロ以外の切り捨てを伴うTSIGの受け入れを許可する場合、それはまた、フルキー付きハッシュ出力までの切り捨て（より長いMAC）を用いてそのアルゴリズムの使用を可能にするべきである。
Regardless of a lower acceptable truncated MAC length specified by local policy, a reply SHOULD be sent with a MAC at least as long as that in the corresponding request. Note, if the request specified a MAC length longer than the keyed hash output, it will be rejected by processing rules (Section 5.2.2.1, case 1).
ローカルポリシーで指定されたより低い許容された切り捨てられたMAC長に関係なく、少なくとも対応する要求のそれ以外の長い長い間、返信をMACと送信する必要があります。注意、要求がキー付きハッシュ出力よりもMAC長を指定した場合は、ルールの処理ルールによって拒否されます（セクション5.2.2.1、ケース1）。
Implementations permitting multiple acceptable algorithms and/or truncations SHOULD permit this list to be ordered by presumed strength and SHOULD allow different truncations for the same algorithm to be treated as separate entities in this list. When so implemented, policies SHOULD accept a presumed stronger algorithm and truncation than the minimum strength required by the policy.
複数の許容可能なアルゴリズムおよび/または切り捨てを可能にする実装は、このリストを推定された強さによって順序付けされるべきであり、同じアルゴリズムに対する異なる切り捨てをこのリストの別々のエンティティとして扱うことを可能にする必要があります。そのように実装されたとき、ポリシーは、ポリシーによって必要とされる最小の強さよりも推定されたより強いアルゴリズムと切り捨てを受け入れるべきです。
Secret keys are very sensitive information and all available steps should be taken to protect them on every host on which they are stored. Generally, such hosts need to be physically protected. If they are multi-user machines, great care should be taken so that unprivileged users have no access to keying material. Resolvers often run unprivileged, which means all users of a host would be able to see whatever configuration data are used by the resolver.
秘密鍵は非常に機密性の高い情報であり、それらが保存されているすべてのホストでそれらを保護するためにすべての利用可能なステップをとるべきです。一般に、そのような宿主は物理的に保護される必要があります。それらがマルチユーザーマシンである場合、特権のないユーザーがキーイング資料にアクセスできないように、細心の注意を払う必要があります。resolversが頻繁に実行されることがよくあるため、これはホストのすべてのユーザーがリゾルバによってどのような構成データが使用されていても確認できることを意味します。
A name server usually runs privileged, which means its configuration data need not be visible to all users of the host. For this reason, a host that implements transaction-based authentication should probably be configured with a "stub resolver" and a local caching and forwarding name server. This presents a special problem for [RFC2136], which otherwise depends on clients to communicate only with a zone's authoritative name servers.
ネームサーバーは通常特権を実行します。つまり、その構成データはホストのすべてのユーザーに表示される必要はありません。このため、トランザクションベースの認証を実装するホストは、おそらく「スタブリゾルバ」とローカルキャッシュおよび転送ネームサーバーで設定する必要があります。これは[RFC2136]に特別な問題を示しています。
Use of strong, random shared secrets is essential to the security of TSIG. See [RFC4086] for a discussion of this issue. The secret SHOULD be at least as long as the keyed hash output [RFC2104].
強力なランダムな共有秘密の使用はTSIGのセキュリティにとって不可欠です。この問題の議論については[RFC4086]を参照してください。秘密は少なくともキー付きハッシュ出力[RFC2104]でなければなりません。
IANA maintains a registry of algorithm names to be used as "Algorithm Names", as defined in Section 4.2 [IANA-TSIG]. Algorithm names are text strings encoded using the syntax of a domain name. There is no structure to the names, and algorithm names are compared as if they were DNS names, i.e., comparison is case insensitive. Previous specifications ([RFC2845] and [RFC4635]) defined values for the HMAC-MD5 and some HMAC-SHA algorithms. IANA has also registered "gss-tsig" as an identifier for TSIG authentication where the cryptographic operations are delegated to the Generic Security Service (GSS) [RFC3645]. This document adds to the allowed algorithms, and the registry has been updated with the names listed in Table 3.
IANAは、セクション4.2 [IANA-TSIG]で定義されているように、「アルゴリズム名」として使用されるアルゴリズム名のレジストリを管理しています。アルゴリズム名は、ドメイン名の構文を使用してエンコードされたテキスト文字列です。名前に構造はありません。また、アルゴリズム名は、あたかもDNS名、すなわち比較の場合と比較されます。前の仕様（[RFC2845]および[RFC4635]）HMAC-MD5およびいくつかのHMAC-SHAアルゴリズムの定義値。また、暗号化操作がGeneric Security Service（GSS）に委任されているTSIG認証の識別子として「GSS-TSIG」を登録しています[RFC3645]。このドキュメントは許可されたアルゴリズムに追加され、レジストリは表3にリストされている名前で更新されました。
New algorithms are assigned using the IETF Review policy defined in [RFC8126]. The algorithm name HMAC-MD5.SIG-ALG.REG.INT looks like a fully qualified domain name for historical reasons; other algorithm names are simple, single-component names.
新しいアルゴリズムは、[RFC8126]で定義されているIETFレビューポリシーを使用して割り当てられています。アルゴリズム名hmac-md5.sig-alg.reg.intは、履歴上の理由から完全修飾ドメイン名のように見えます。他のアルゴリズム名は単純な単一コンポーネント名です。
IANA maintains a registry of RCODEs (error codes) (see [IANA-RCODEs], including "TSIG Error values" to be used for "Error" values, as defined in Section 4.2. This document defines the RCODEs as described in Section 3. New error codes are assigned and specified as in [RFC6895].
IANAは、4.2項で定義されているように、「エラー」値に使用される「TSIGエラー値」を含む[IANA RCODES]を含む[IANA-RCODES]を参照）を維持しています。このドキュメントはセクション3で説明されているようにRコードを定義します。[RFC6895]のように、新しいエラーコードが割り当てられ指定されます。
The approach specified here is computationally much less expensive than the signatures specified in DNSSEC. As long as the shared secret key is not compromised, strong authentication is provided between two DNS systems, e.g., for the last hop from a local name server to the user resolver or between primary and secondary name servers.
ここで指定されたアプローチは、DNSSECで指定された署名よりも計算上高価です。共有秘密鍵が妥協されていない限り、2つのDNSシステム間、例えばローカルネームサーバからユーザリゾルバへの最後のホップ、またはプライマリネームサーバ間の最後のホップの間に強い認証が提供される。
Recommendations for choosing and maintaining secret keys can be found in [RFC2104]. If the client host has been compromised, the server should suspend the use of all secrets known to that client. If possible, secrets should be stored in an encrypted form. Secrets should never be transmitted in the clear over any network. This document does not address the issue on how to distribute secrets except that it mentions the possibilities of manual configuration and the use of TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than two entities; any such additional sharing would allow any party knowing the key to impersonate any other such party to members of the group.
秘密鍵を選択して維持するための推奨事項は[RFC2104]にあります。クライアントホストが危険にさらされた場合、サーバーはそのクライアントに既知のすべての秘密の使用を中断する必要があります。可能であれば、秘密は暗号化された形式で保存されるべきです。秘密は任意のネットワーク経由で明確に送信されるべきではありません。このドキュメントは、手動構成の可能性とTKEY [RFC2930]の可能性について説明したことを除いて、秘密を分配する方法についての問題に対処しません。秘密は2つ以上のエンティティによって共有されるべきではありません。そのような追加の共有は、鍵を知っている任意の当事者が、そのグループのメンバーに他のそのような当事者を偽装することを可能にするでしょう。
This mechanism does not authenticate source data, only its transmission between two parties who share some secret. The original source data can come from a compromised zone master or can be corrupted during transit from an authentic zone master to some "caching forwarder". However, if the server is faithfully performing the full DNSSEC security checks, then only security-checked data will be available to the client.
このメカニズムはソースデータを認証しません。これは、ある秘密を共有する2人の締約国間の送信だけです。元のソースデータは、本物のゾーンマスタからの遷移中に侵入先のゾーンマスタからの侵入を破損する可能性があります。ただし、サーバーが完全なDNSSECセキュリティチェックを忠実に実行している場合は、セキュリティチェックされたデータのみがクライアントに利用可能になります。
A Fudge value that is too large may leave the server open to replay attacks. A Fudge value that is too small may cause failures if machines are not time synchronized or there are unexpected network delays. The RECOMMENDED value in most situations is 300 seconds.
大きすぎるファッジ値は、サーバーが攻撃を再生するために開かれたままになることがあります。マシンが時間同期していない場合、または予期しないネットワーク遅延がある場合、障害の原因となる可能性があります。ほとんどの状況で推奨される値は300秒です。
To prevent cross-algorithm attacks, there SHOULD only be one algorithm associated with any given key name.
クロスアルゴリズム攻撃を防ぐために、特定のキー名に関連する1つのアルゴリズムしかありません。
In several cases where errors are detected, an unsigned error message must be returned. This can allow for an attacker to spoof or manipulate these responses. Section 5.4 recommends logging these as errors and continuing to wait for a signed response until the request times out.
エラーが検出された場合のいくつかの場合では、符号なしエラーメッセージを返す必要があります。これにより、攻撃者がこれらの回答を偽装または操作することを可能にします。セクション5.4はこれらをエラーとしてログ記録し、要求がタイムアウトするまで署名された応答を待ち続けることを推奨します。
Although the strength of an algorithm determines its security, there have been some arguments that mild truncation can strengthen a MAC by reducing the information available to an attacker. However, excessive truncation clearly weakens authentication by reducing the number of bits an attacker has to try to break the authentication by brute force [RFC2104].
アルゴリズムの強さはそのセキュリティを決定しますが、攻撃者が利用できる情報を縮小することによって穏やかな切り捨てがMacを強化することができるといういくつかの引数がありました。ただし、過度の切り捨ては明らかに攻撃者がブルートフォースで認証を破るためのビット数を減らすことで認証を弱めます[RFC2104]。
Significant progress has been made recently in cryptanalysis of hash functions of the types used here. While the results so far should not affect HMAC, the stronger SHA-256 algorithm is being made mandatory as a precaution.
ここで使用されているタイプのハッシュ関数の暗号解読では、最近大きな進歩がありました。これまでのところHMACに影響を与えるべきではありませんが、より強いSHA-256アルゴリズムは予防措置として必須になっています。
See also the Security Considerations section of [RFC2104] from which the limits on truncation in this RFC were taken.
このRFCの切り捨ての制限が取られた[RFC2104]の[セキュリティ上の考慮事項]セクションも参照してください。
When signing a DNS reply message using TSIG, the MAC computation uses the request message's MAC as an input to cryptographically relate the reply to the request. The original TSIG specification [RFC2845] required that the time values be checked before the request's MAC. If the time was invalid, some implementations failed to carry out further checks and could use an invalid request MAC in the signed reply.
TSIGを使用してDNS応答メッセージに署名するとき、MAC計算は要求メッセージのMacを入力として要求に応答を暗号的に関連付けます。元のTSIG仕様[RFC2845]は、要求のMACの前に時間値を確認する必要があります。時間が無効であれば、いくつかの実装はさらにチェックを実行できず、署名された返信で無効な要求Macを使用することができました。
This document makes it mandatory that the request MAC is considered to be invalid until it has been validated; until then, any answer must be unsigned. For this reason, the request MAC is now checked before the time values.
このドキュメントは、要求Macが検証されるまで無効であると見なされることを必須にします。それまでは、答えを署名する必要があります。このため、要求MACは時間値の前にチェックされるようになりました。
DNS has been extended by DNSSEC ([RFC4033], [RFC4034], and [RFC4035]) to provide for data origin authentication, and public key distribution, all based on public key cryptography and public key based digital signatures. To be practical, this form of security generally requires extensive local caching of keys and tracing of authentication through multiple keys and signatures to a pre-trusted locally configured key.
DNSは、DNSSEC（[RFC4033]、[RFC4034]、[RFC4035]）によって拡張されて、データの原点認証、および公開鍵の分布、および公開鍵の暗号化および公開鍵ベースのデジタル署名に基づいて拡張されています。実用的なものでは、この形式のセキュリティは一般に、複数のキーと署名を介して、事前信頼できるローカルに設定されているキーへの継続者と署名を介して認証の広範なローカルキャッシングを必要とします。
One difficulty with the DNSSEC scheme is that common DNS implementations include simple "stub" resolvers which do not have caches. Such resolvers typically rely on a caching DNS server on another host. It is impractical for these stub resolvers to perform general DNSSEC authentication and they would naturally depend on their caching DNS server to perform such services for them. To do so securely requires secure communication of queries and responses. DNSSEC provides public key transaction signatures to support this, but such signatures are very expensive computationally to generate. In general, these require the same complex public key logic that is impractical for stubs.
DNSSEC方式の1つの難しさは、一般的なDNS実装には、キャッシュがない単純な「スタブ」リゾルバが含まれることです。そのようなリゾルバは通常、別のホスト上のCaching DNSサーバに依存しています。これらのスタブリゾルバが一般的なDNSSEC認証を実行するのは実用的ではなく、それらはそれらのためにそのようなサービスを実行するためにそれらのキャッシングDNSサーバに自然に依存するであろう。そのために安全にクエリと応答の安全なコミュニケーションを必要とします。DNSSECはこれをサポートするための公開鍵トランザクション署名を提供しますが、そのような署名は生成するために計算的に非常に高価です。一般に、これらはスタブに実用的ではないのと同じ複雑な公開鍵ロジックを必要とします。
A second area where use of straight DNSSEC public key based mechanisms may be impractical is authenticating dynamic update [RFC2136] requests. DNSSEC provides for request signatures but with DNSSEC they, like transaction signatures, require computationally expensive public key cryptography and complex authentication logic. Secure Domain Name System Dynamic Update ([RFC3007]) describes how different keys are used in dynamically updated zones.
直線DNSSEC公開鍵ベースのメカニズムを使用する2番目の領域は、動的更新[RFC2136]要求を認証していません。DNSSECはリクエストシグネチャを提供しますが、トランザクションシグネチャのように、それらがDNSSECを使用すると、計算上高価な公開鍵暗号化と複雑な認証ロジックが必要です。セキュアドメイン名システム動的更新（[RFC3007]）は、動的に更新されたゾーンでさまざまなキーがどのように使用されるかを説明しています。
[FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://doi.org/10.6028/NIST.FIPS.180-4>.
[FIPS180-4]国立標準技術研究所、「セキュアハッシュスタンダード（SHS）」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<https：//doi.org/10.6028 / NIST.FIPS.180-4>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P.、「ドメイン名 - コンセプトと施設」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https：//www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, <https://www.rfc-editor.org/info/rfc2845>.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastleake 3RD、D.、B.Welientton、「DNS（TSIG）の秘密鍵取引認証」、RFC 2845、DOI 10.17487 / RFC2845、2000年5月、<https：//www.rfc-editor.org/info/rfc2845>。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC3597] Gustafsson、A。、「未知のDNSリソースレコード（RR）タイプの取り扱い」、RFC 3597、DOI 10.17487 / RFC3597、2003年9月、<https：//www.rfc-editor.org/info/rfc3597>。
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", RFC 4635, DOI 10.17487/RFC4635, August 2006, <https://www.rfc-editor.org/info/rfc4635>.
[RFC4635]イーストレイク3RD、D。、「HMAC SHA（ハッシュ型メッセージ認証コード、セキュアハッシュアルゴリズム）TSIGアルゴリズム識別子」、RFC 4635、DOI 10.17487 / RFC4635、2006年8月、<https://www.rfc-editor.org/ info / rfc4635>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[CVE-2017-11104] Common Vulnerabilities and Exposures, "CVE-2017-11104: Improper TSIG validity period check can allow TSIG forgery", June 2017, <https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2017-11104>.
[CVE-2017-11104]一般的な脆弱性とエクスポージャー、「CVE-2017-11104：不適切なTSIGの有効期間の確認は、2017年6月、https://cve.mitre.org/cgi-bin/ Cvenameを許可することができます。CGI？名前= CVE-2017-11104>。
[CVE-2017-3142] Common Vulnerabilities and Exposures, "CVE-2017-3142: An error in TSIG authentication can permit unauthorized zone transfers", June 2017, <https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2017-3142>.
[CVE-2017-3142]一般的な脆弱性とエクスポージャー、「CVE-2017-3142：TSIG認証のエラーは、不正なゾーン転送を許可することができます」、2017年6月、<https：//cve.mitre.org/cgi-bin/ Cvename.cgi？name = cve-2017-3142>。
[CVE-2017-3143] Common Vulnerabilities and Exposures, "CVE-2017-3143: An error in TSIG authentication can permit unauthorized dynamic updates", June 2017, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3143>.
[CVE-2017-3143]一般的な脆弱性とエクスポージャー、「CVE-2017-3143：TSIG認証のエラーは、2017年6月、https://cve.mitre.org/cgi-bin/cvenameの不正な動的更新を許可できます」.cgi？name = cve-2017-3143>。
[IANA-RCODEs] IANA, "DNS RCODEs", <https://www.iana.org/assignments/dns-parameters/>.
[IANA-RCODES] IANA、「DNS RCODES」、<https：//www.iana.org/assignments/dns-parameters/>。
[IANA-TSIG] IANA, "TSIG Algorithm Names", <https://www.iana.org/assignments/tsig-algorithm-names/>.
[IANA-TSIG] IANA、「TSIGアルゴリズム名」、<https：//www.iana.org/assignments/tsig-algorithm-names/>。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/info/rfc1321>.
[RFC1321] RIVEST、R。、「MD5メッセージ - ダイジェストアルゴリズム」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<https：//www.rfc-editor.org/info/rfc1321>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR. Canetti、 "HMAC：メッセージ認証用keyed-hashing"、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-編集者.org / info / rfc2104>。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.
[RFC2136] Vixie、P.、ED。、Thomson、S.、Rekhter、Y.、J.Bound、「ドメイン名システム（DNSアップデート）の動的更新（DNSアップデート）」、RFC 2136、DOI 10.17487 / RFC2136、1997年4月<https://www.rfc-editor.org/info/rfc2136>。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000, <https://www.rfc-editor.org/info/rfc2930>.
[RFC2930]イーストレイク3RD、D.、「DNS（TKEY RR）のための秘密鍵設立（TKEY RR）」、RFC 2930、DOI 10.17487 / RFC2930、2000年9月、<https：//www.rfc-editor.org/info/rfc2930>。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <https://www.rfc-editor.org/info/rfc3007>.
[RFC3007]ウェリントン、B.、「セキュアドメインネームシステム（DNS）動的更新」、RFC 3007、DOI 10.17487 / RFC3007、2000年11月、<https：//www.rfc-editor.org/info/rfc3007>。
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, <https://www.rfc-editor.org/info/rfc3174>.
[RFC3174]イーストレイク3RD、D.およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、DOI 10.17487 / RFC3174、2001年9月、<https：//www.rfc-editor.org/info/RFC3174>。
[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., and R. Hall, "Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, DOI 10.17487/RFC3645, October 2003, <https://www.rfc-editor.org/info/rfc3645>.
[RFC3645] KWAN、S、Garg、P.、Gilroy、J.、Esibov、L.、Westhead、J.、R. Hall、「DNSの秘密鍵取引認証のための一般的なセキュリティサービスアルゴリズム（GSS-TSIG）"、RFC 3645、DOI 10.17487 / RFC3645、2003年10月、<https：//www.rfc-editor.org/info/rfc3645>。
[RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, DOI 10.17487/RFC3874, September 2004, <https://www.rfc-editor.org/info/rfc3874>.
[RFC3874] housley、R.、 "224ビットの一方向ハッシュ関数：SHA-224"、RFC 3874、DOI 10.17487 / RFC3874、2004年9月、<https：//www.rfc-editor.org/info/RFC3874>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ紹介および要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https：//www.rfc-editor.org/info/rfc4033>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張のためのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、<https://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、M.、Massey、D.、およびS. Rose、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、<https://www.rfc-editor.org/info/rfc4035>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]イーストレイク3RD、D.、Schiller、J.、S. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、2005年6月、<https：//www.rfc-編集者.org / info / rfc4086>。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.
[RFC4868] Kelly、S.およびS.Frankel、「HMAC-SHA-256、HMAC-SHA-384、およびIPSecとHMAC-SHA-512を使用する」、RFC 4868、DOI 10.17487 / RFC4868、2007年5月、<HTTPS：//www.rfc-editor.org/info/rfc4868>。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.
[RFC6151]ターナー、S.およびL.Chen、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムのための更新されたセキュリティ上の考慮事項」、RFC 6151、DOI 10.17487 / RFC6151、2011年3月、<https：///www.rfc-editor.org/info/rfc6151>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234]イーストレイク3RD、D.およびT.Hansen、「米国セキュアハッシュアルゴリズム（SHAおよびSHAベースのHMACおよびHKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：///www.rfc-editor.org/info/rfc6234>。
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC6895]イーストレイク3RD、D.、「ドメインネームシステム（DNS）IANA考慮事項」、BCP 42、RFC 6895、DOI 10.17487 / RFC6895、2013年4月、<https：//www.rfc-editor.org/info/rfc6895>。
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <https://www.rfc-editor.org/info/rfc7696>.
[RFC7696]ハウスリー、R.、「暗号化アルゴリズムの敏捷性のためのガイドラインと必須の実施のアルゴリズムの選択」、BCP 201、RFC 7696、DOI 10.17487 / RFC7696、2015年11月、<https：//www.rfc-editor.org/ info / rfc7696>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[SHA1SHAMBLES] Leurent, G. and T. Peyrin, "SHA-1 is a Shambles", January 2020, <https://eprint.iacr.org/2020/014.pdf>.
[SHA1SHAMBLES] Leurent、G.およびT.Peyrin、「SHA-1は、2020年1月、https://eprint.iacr.org/2020/014.pdf>です。
Acknowledgements
謝辞
The security problem addressed by this document was reported by Clément Berthaux from Synacktiv.
この文書によって対処されたセキュリティ問題は、SynacktivからClémentBerthauxによって報告されました。
Peter van Dijk, Benno Overeinder, Willem Toroop, Ondrej Sury, Mukund Sivaraman, and Ralph Dolmans participated in the discussions that prompted this document. Mukund Sivaraman, Martin Hoffman, and Tony Finch made extremely helpful suggestions concerning the structure and wording of the updated document.
Peter Van Dijk、Benno Overeinder、Willem Toroop、Ondrej Sury、Mukund Sivaraman、およびRalph Dolmansはこの文書に促された議論に参加しました。Martin Hoffman、およびTony Finchは、更新された文書の構造と表現に関する優れた提案をしました。
Stephen Morris would like to thank Internet Systems Consortium for its support of his participation in the creation of this document.
Stephen Morrisは、この文書の作成への彼の参加を支援するためにインターネットシステムコンソーシアムに感謝します。
Authors' Addresses
著者の住所
Francis Dupont Internet Systems Consortium, Inc. PO Box 360 Newmarket, NH 03857 United States of America
Francis Dupontインターネットシステムコンソーチウム、Inc。PO BOX 360 Newmarket、NH 03857アメリカ合衆国
Email: Francis.Dupont@fdupont.fr
Stephen Morris Unaffiliated United Kingdom
Stephen Morrisは影響を与えられていないイギリス
Email: sa.morris8@gmail.com
Paul Vixie Farsight Security Inc Suite 180 177 Bovet Road San Mateo, CA 94402 United States of America
Paul Vixie Farsight Security Inc Suite 180 177 Bovet Road San Mateo、CA 94402アメリカ
Email: paul@redbarn.org
Donald E. Eastlake 3rd Futurewei Technologies 2386 Panoramic Circle Apopka, FL 32703 United States of America
Donald E.イーストレイク3RDフューチャーワイテクノロジーズ2386パノラマサークルアポッカ、FL 32703アメリカ合衆国
Email: d3e3e3@gmail.com
Olafur Gudmundsson Cloudflare United States of America
Olafur Gudmundsson CloudFlareアメリカ合衆国
Email: olafur+ietf@cloudflare.com
Brian Wellington Akamai United States of America
Brian Wellington Akamaiアメリカ合衆国
Email: bwelling@akamai.com