Network Working Group P. Vixie
Request for Comments: 2845 ISC
Category: Standards Track O. Gudmundsson
Updates: 1035 NAI Labs
D. Eastlake 3rd
Motorola
B. Wellington
Nominum
May 2000
Network Working Group P. Vixie
Request for Comments: 2845 ISC
Category: Standards Track O. Gudmundsson
Updates: 1035 NAI Labs
D. Eastlake 3rd
Motorola
B. Wellington
Nominum
May 2000
Secret Key Transaction Authentication for DNS (TSIG)
DNS的密钥事务验证（TSIG）
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.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server.
该协议允许使用共享机密和单向散列进行事务级身份验证。它可用于验证来自经批准的客户端的动态更新，或验证来自经批准的递归名称服务器的响应。
No provision has been 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 such as sneaker-net until a secure automated mechanism for key distribution is available.
此处未规定分发共享机密；预计网络管理员将使用一些带外机制（如sneaker net）静态配置名称服务器和客户端，直到安全的自动密钥分发机制可用。
1 - Introduction
1-导言
1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated hierarchical distributed database system that provides information fundamental to Internet operations, such as name <=> address translation and mail handling information. DNS has recently been extended [RFC2535] 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
1.1. 域名系统（DNS）[RFC1034，RFC1035]是一个复制的分层分布式数据库系统，提供互联网操作的基本信息，如名称<=>地址转换和邮件处理信息。DNS最近已扩展[RFC2535]，以提供数据源身份验证和公钥分发，所有这些都基于公钥加密和基于公钥的数字签名。实际上，这种形式的
security generally requires extensive local caching of keys and tracing of authentication through multiple keys and signatures to a pre-trusted locally configured key.
安全性通常需要对密钥进行广泛的本地缓存，并通过多个密钥和签名对预信任的本地配置密钥进行身份验证跟踪。
1.2. One difficulty with the [RFC2535] 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 [RFC2535] 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. [RFC2535] 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. This document specifies use of a message authentication code (MAC), specifically HMAC-MD5 (a keyed hash function), to provide an efficient means of point-to-point authentication and integrity checking for transactions.
1.2. [RFC2535]方案的一个困难是，常见的DNS实现包括没有缓存的简单“存根”解析器。这种解析器通常依赖于另一台主机上的缓存DNS服务器。这些存根解析程序执行通用[RFC2535]身份验证是不切实际的，它们自然会依赖其缓存DNS服务器为其执行此类服务。要安全地执行此操作，需要对查询和响应进行安全通信。[RFC2535]提供公钥事务签名来支持这一点，但生成此类签名的计算成本非常高。一般来说，它们需要相同的复杂公钥逻辑，这对于存根来说是不切实际的。本文档规定使用消息身份验证码（MAC），特别是HMAC-MD5（键控哈希函数），为事务提供点对点身份验证和完整性检查的有效方法。
1.3. A second area where use of straight [RFC2535] public key based mechanisms may be impractical is authenticating dynamic update [RFC2136] requests. [RFC2535] provides for request signatures but with [RFC2535] they, like transaction signatures, require computationally expensive public key cryptography and complex authentication logic. Secure Domain Name System Dynamic Update ([RFC2137]) describes how different keys are used in dynamically updated zones. This document's secret key based MACs can be used to authenticate DNS update requests as well as transaction responses, providing a lightweight alternative to the protocol described by [RFC2137].
1.3. 使用基于直接[RFC2535]公钥的机制可能不切实际的第二个领域是验证动态更新[RFC2136]请求。[RFC2535]提供请求签名，但使用[RFC2535]时，它们与事务签名一样，需要计算昂贵的公钥加密和复杂的身份验证逻辑。安全域名系统动态更新（[RFC2137]）描述了如何在动态更新的区域中使用不同的密钥。本文档基于密钥的MAC可用于验证DNS更新请求和事务响应，为[RFC2137]所述协议提供了一种轻量级替代方案。
1.4. 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 [RFC2535] does not protect glue records and unsigned records unless SIG(0) (transaction signature) is used.
1.4. 该机制的另一个用途是保护区域传输。在这种情况下，涵盖的数据将是整个区域传输，包括发送的任何胶水记录。[RFC2535]描述的协议不保护粘合记录和未签名记录，除非使用SIG（0）（事务签名）。
1.5. The authentication mechanism proposed in this document uses shared secret keys to establish a trust relationship between two entities. Such keys must be protected in a fashion similar to private keys, lest a third party masquerade as one of the intended parties (forge MACs). There is an urgent need to provide simple and efficient authentication between clients and local servers and this proposal addresses that need. This proposal is unsuitable for general server to server authentication for servers which speak with many other servers, since key management would become unwieldy with
1.5. 本文提出的身份验证机制使用共享密钥在两个实体之间建立信任关系。此类密钥必须以类似于私钥的方式进行保护，以免第三方冒充目标方之一（伪造MAC）。迫切需要在客户端和本地服务器之间提供简单高效的身份验证，本提案解决了这一需要。此方案不适用于与许多其他服务器通信的服务器的一般服务器到服务器身份验证，因为密钥管理将变得难以处理
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.
按二次方递增的共享密钥数。但它适用于主机上的许多解析器，这些解析器只与少数递归服务器通信。
1.6. A server acting as an indirect caching resolver -- a "forwarder" in common usage -- might use transaction-based authentication when communicating with its small number of preconfigured "upstream" servers. Other uses of DNS secret key authentication and possible systems for automatic secret key distribution may be proposed in separate future documents.
1.6. 充当间接缓存解析程序的服务器（常用的“转发器”）在与其少量预配置的“上游”服务器通信时可能会使用基于事务的身份验证。DNS密钥认证的其他用途和自动密钥分发的可能系统可在单独的未来文件中提出。
1.7. New Assigned Numbers
1.7. 新分配的号码
RRTYPE = TSIG (250) ERROR = 0..15 (a DNS RCODE) ERROR = 16 (BADSIG) ERROR = 17 (BADKEY) ERROR = 18 (BADTIME)
RRTYPE=TSIG（250）ERROR=0..15（DNS RCODE）ERROR=16（BADSIG）ERROR=17（BADKEY）ERROR=18（BADTIME）
1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC 2119].
1.8. 本文件中的关键词“必须”、“要求”、“应该”、“建议”和“可能”应按照[RFC 2119]中所述进行解释。
2 - TSIG RR Format
2-TSIG RR格式
2.1 TSIG RR Type
2.1 TSIG-RR型
To provide secret key authentication, we use a new 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.
为了提供密钥认证，我们使用了一种新的RR类型，其助记符为TSIG，类型代码为250。TSIG是元RR，不能缓存。TSIG RRs用于已建立共享密钥的DNS实体之间的身份验证。TSIG RRs是动态计算的，以覆盖特定的DNS事务，而不是通常意义上的DNS RRs。
2.2 TSIG Calculation
2.2 TSIG计算
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. The only message digest algorithm specified in this document is "HMAC-MD5" (see [RFC1321], [RFC2104]). The "HMAC-MD5" algorithm is mandatory to implement for interoperability. Other algorithms can be specified at a later date. Names and definitions of new algorithms MUST be registered with IANA. All multi-octet integers in the TSIG record are sent in network byte order (see [RFC1035 2.3.2]).
由于TSIG RR与一个DNS请求/响应相关，因此存储或重新传输它们没有任何价值，因此一旦TSIG RR被用于验证DNS消息，它就会被丢弃。本文档中指定的唯一消息摘要算法是“HMAC-MD5”（参见[RFC1321]、[RFC2104]）。为了实现互操作性，“HMAC-MD5”算法是必需的。其他算法可在以后指定。新算法的名称和定义必须向IANA注册。TSIG记录中的所有多八位整数均以网络字节顺序发送（请参见[RFC1035 2.3.2]）。
2.3. Record Format
2.3. 记录格式
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. 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. The name only needs to be meaningful to the communicating hosts but a meaningful mnemonic name as above is strongly recommended.
NAME域名语法中使用的密钥的名称。该名称应反映主机的名称，并在这两个主机在任何给定时间共享的一组密钥中唯一标识密钥。如果主机A.site.example和B.example.net共享一个密钥，则密钥名称可能包括<id>.A.site.example、<id>.B.example.net和<id>.A.site.example.B.example.net。在一组交互主机之间，应该可以同时使用多个密钥。该名称只需要对通信主机有意义，但强烈建议使用如上所述的有意义的助记名称。
The name may be used as a local index to the key involved and it is recommended that it be globally unique. Where a key is just shared between two hosts, its name actually only need only be meaningful to them but it is recommended that the key name be mnemonic and incorporate the resolver and server host names in that order.
该名称可以用作所涉及密钥的本地索引，建议其全局唯一。如果密钥仅在两台主机之间共享，则其名称实际上只需要对它们有意义，但建议密钥名称为助记名称，并按顺序合并解析程序和服务器主机名。
TYPE TSIG (250: Transaction SIGnature)
TSIG类型（250：交易签名）
CLASS ANY
任何类别
TTL 0
TTL0
RdLen (variable)
RdLen（变量）
RDATA
RDATA
Field Name Data Type Notes
--------------------------------------------------------------
Algorithm Name domain-name Name of the algorithm
in domain name syntax.
Time Signed u_int48_t seconds since 1-Jan-70 UTC.
Fudge u_int16_t seconds of error permitted
in Time Signed.
MAC Size u_int16_t number of octets in MAC.
MAC octet stream defined by Algorithm Name.
Original ID u_int16_t original message ID
Error u_int16_t expanded RCODE covering
TSIG processing.
Other Len u_int16_t length, in octets, of
Other Data.
Other Data octet stream empty unless Error == BADTIME
Field Name Data Type Notes
--------------------------------------------------------------
Algorithm Name domain-name Name of the algorithm
in domain name syntax.
Time Signed u_int48_t seconds since 1-Jan-70 UTC.
Fudge u_int16_t seconds of error permitted
in Time Signed.
MAC Size u_int16_t number of octets in MAC.
MAC octet stream defined by Algorithm Name.
Original ID u_int16_t original message ID
Error u_int16_t expanded RCODE covering
TSIG processing.
Other Len u_int16_t length, in octets, of
Other Data.
Other Data octet stream empty unless Error == BADTIME
2.4. Example
2.4. 实例
NAME HOST.EXAMPLE.
NAME HOST.EXAMPLE。
TYPE TSIG
TSIG型
CLASS ANY
任何类别
TTL 0
TTL0
RdLen as appropriate
视情况而定
RDATA
RDATA
Field Name Contents
-------------------------------------
Algorithm Name SAMPLE-ALG.EXAMPLE.
Time Signed 853804800
Fudge 300
MAC Size as appropriate
MAC as appropriate
Original ID as appropriate
Error 0 (NOERROR)
Other Len 0
Other Data empty
Field Name Contents
-------------------------------------
Algorithm Name SAMPLE-ALG.EXAMPLE.
Time Signed 853804800
Fudge 300
MAC Size as appropriate
MAC as appropriate
Original ID as appropriate
Error 0 (NOERROR)
Other Len 0
Other Data empty
3 - Protocol Operation
3-协议操作
3.1. Effects of adding TSIG to outgoing message
3.1. 将TSIG添加到传出消息的效果
Once the outgoing message has been constructed, the keyed message digest operation can be performed. The resulting message digest will then be stored in a TSIG which is appended to the additional data section (the ARCOUNT is incremented to reflect this). If the TSIG record cannot be added without causing the message to be truncated, the server MUST alter the response so that a TSIG can be included. This response consists of only the question and a TSIG record, and has the TC bit set and RCODE 0 (NOERROR). The client SHOULD at this point retry the request using TCP (per [RFC1035 4.2.2]).
构建传出消息后，可以执行键控消息摘要操作。生成的消息摘要随后将存储在TSIG中，TSIG附加到附加数据部分（ARCOUNT递增以反映这一点）。如果在不导致消息被截断的情况下无法添加TSIG记录，则服务器必须更改响应，以便可以包含TSIG。此响应仅由问题和TSIG记录组成，并且设置了TC位和RCODE 0（无错误）。此时，客户端应使用TCP重试请求（根据[RFC1035 4.2.2]）。
3.2. TSIG processing on incoming messages
3.2. 对传入消息的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 a TSIG record is present in any other position, the packet is dropped and a response with RCODE 1 (FORMERR) MUST be returned. Upon receipt of a message with a correctly placed TSIG RR, the TSIG RR is copied to a safe location, removed from the DNS
如果传入消息包含TSIG记录，则它必须是附加部分中的最后一条记录。不允许有多个TSIG记录。如果TSIG记录存在于任何其他位置，则数据包将被丢弃，并且必须返回带有RCODE 1（FORMERR）的响应。在收到具有正确放置的TSIG RR的消息后，TSIG RR将被复制到安全位置，并从DNS中删除
Message, and decremented out of the DNS message header's ARCOUNT. At this point the keyed message digest operation is performed. If the algorithm name or key name is unknown to the recipient, or if the message digests do not match, the whole DNS message MUST be discarded. If the message is a query, a response with RCODE 9 (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17 (BADKEY) or TSIG ERROR 16 (BADSIG). If no key is available to sign this message it MUST be sent unsigned (MAC size == 0 and empty MAC). A message to the system operations log SHOULD be generated, to warn the operations staff of a possible security incident in progress. Care should be taken to ensure that logging of this type of event does not open the system to a denial of service attack.
消息，并从DNS消息头的ARCOUNT中递减。此时，执行键控消息摘要操作。如果收件人不知道算法名称或密钥名称，或者如果消息摘要不匹配，则必须丢弃整个DNS消息。如果消息是查询，则必须将带有RCODE 9（NOTAUTH）的响应发送回具有TSIG错误17（BADKEY）或TSIG错误16（BADSIG）的发起人。如果没有密钥可用于签署此消息，则必须发送未签名的消息（MAC大小==0，MAC为空）。应生成发送至系统操作日志的消息，以警告操作人员正在发生可能的安全事件。应注意确保记录此类事件不会使系统遭受拒绝服务攻击。
3.3. Time values used in TSIG calculations
3.3. TSIG计算中使用的时间值
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. This data is named "TSIG Timers", and for the purpose of digest calculation they are invoked in their "on the wire" format, in the following order: first Time Signed, then Fudge. For example:
摘要的数据包括TSIG报头中的两个计时器值，以便防御重播攻击。如果不这样做，攻击者可以重播旧消息，但会更新“时间签名”和“伪造”字段以使消息看起来是新的。这些数据被命名为“TSIG定时器”，为了进行摘要计算，它们以“在线”格式调用，顺序如下：第一次签名，然后是伪造。例如：
Field Name Value Wire Format Meaning
----------------------------------------------------------------------
Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997
Fudge 300 01 2C 5 minutes
Field Name Value Wire Format Meaning
----------------------------------------------------------------------
Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997
Fudge 300 01 2C 5 minutes
3.4. TSIG Variables and Coverage
3.4. TSIG变量和覆盖率
When generating or verifying the contents of a TSIG record, the following data are digested, in network byte order or wire format, as appropriate:
生成或验证TSIG记录的内容时，以下数据将以网络字节顺序或导线格式（视情况而定）进行摘要处理：
3.4.1. DNS Message
3.4.1. DNS消息
A whole and complete DNS message in wire format, before the TSIG RR has been added to the additional data section and before the DNS Message Header's ARCOUNT field has been incremented to contain the TSIG RR. If the message ID differs from the original message ID, the original message ID is substituted for the message ID. This could happen when forwarding a dynamic update request, for example.
在TSIG RR添加到附加数据部分之前，以及在DNS消息头的ARCOUNT字段增加以包含TSIG RR之前，以有线格式显示的完整DNS消息。如果消息ID与原始消息ID不同，则原始消息ID将替换为消息ID。例如，转发动态更新请求时可能会发生这种情况。
3.4.2. TSIG Variables
3.4.2. TSIG变量
Source Field Name Notes
-----------------------------------------------------------------------
TSIG RR NAME Key name, in canonical wire format
TSIG RR CLASS (Always ANY in the current specification)
TSIG RR TTL (Always 0 in the current specification)
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
Source Field Name Notes
-----------------------------------------------------------------------
TSIG RR NAME Key name, in canonical wire format
TSIG RR CLASS (Always ANY in the current specification)
TSIG RR TTL (Always 0 in the current specification)
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
The RR RDLEN and RDATA MAC Length are not included in the hash since they are not guaranteed to be knowable before the MAC is generated.
RR RDLEN和RDATA 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 [RFC2535], for label type 01, this is defined in [RFC2673]. The use of label types other than 00 and 01 is not defined for this specification.
对于每种标签类型，必须有一个定义的“规范导线格式”，指定如何以明确的方式表示标签。对于标签类型00，在[RFC2535]中定义；对于标签类型01，在[RFC2673]中定义。本规范未规定使用00和01以外的标签类型。
3.4.3. Request MAC
3.4.3. 请求MAC
When generating the MAC to be included in a response, the request MAC must be included in the digest. The request's MAC is digested in wire format, including the following fields:
生成要包含在响应中的MAC时，请求MAC必须包含在摘要中。请求的MAC以wire格式进行摘要，包括以下字段：
Field Type Description
---------------------------------------------------
MAC Length u_int16_t in network byte order
MAC Data octet stream exactly as transmitted
Field Type Description
---------------------------------------------------
MAC Length u_int16_t in network byte order
MAC Data octet stream exactly as transmitted
3.5. Padding
3.5. 衬料
Digested components are fed into the hashing function as a continuous octet stream with no interfield padding.
已消化的组件作为连续的八位字节流输入哈希函数，没有字段间填充。
4 - Protocol Details
4-协议详情
4.1. TSIG generation on requests
4.1. 根据请求生成TSIG
Client performs the message digest operation and appends a TSIG record to the additional data section and transmits the request to the server. The client MUST store the message digest from the request while awaiting an answer. The digest components for a request are:
客户端执行消息摘要操作，并将TSIG记录附加到附加数据部分，并将请求传输到服务器。客户端必须在等待应答时存储来自请求的消息摘要。请求的摘要组件包括：
DNS Message (request) TSIG Variables (request)
DNS消息（请求）TSIG变量（请求）
Note that some older name servers will not accept requests with a nonempty additional data section. Clients SHOULD only attempt signed transactions with servers who are known to support TSIG and share some secret key with the client -- so, this is not a problem in practice.
请注意，一些较旧的名称服务器将不接受具有非空附加数据节的请求。客户机应该只尝试与已知支持TSIG并与客户机共享一些密钥的服务器进行签名事务——因此，这在实践中不是问题。
4.2. TSIG on Answers
4.2. 关于答案的TSIG
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 an unsigned request. The digest components are:
当服务器生成对已签名请求的响应时，它将使用相同的算法和密钥对响应进行签名。服务器不得对未签名的请求生成已签名的响应。摘要部分包括：
Request MAC DNS Message (response) TSIG Variables (response)
请求MAC DNS消息（响应）TSIG变量（响应）
4.3. TSIG on TSIG Error returns
4.3. TSIG on TSIG错误返回
When a server detects an error relating to the key or MAC, the server SHOULD send back an unsigned error message (MAC size == 0 and empty MAC). If an error is detected relating to the TSIG validity period, the server SHOULD send back a signed error message. The digest components are:
当服务器检测到与密钥或MAC相关的错误时，服务器应发回一条未签名的错误消息（MAC大小==0，MAC为空）。如果检测到与TSIG有效期相关的错误，服务器应发回已签名的错误消息。摘要部分包括：
Request MAC (if the request MAC validated) DNS Message (response) TSIG Variables (response)
请求MAC（如果请求MAC已验证）DNS消息（响应）TSIG变量（响应）
The reason that the request is not included in this digest 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 [4.2].
在某些情况下，请求未包含在此摘要中的原因是为了使客户端能够验证错误。如果错误不是TSIG错误，则必须按照[4.2]中的规定生成响应。
4.4. TSIG on TCP connection
4.4. TCP连接上的TSIG
A DNS TCP session can include multiple DNS envelopes. This is, for example, commonly used by zone transfer. Using TSIG on such a connection can protect the connection from hijacking and provide data integrity. The TSIG MUST be included on the first and last DNS envelopes. It can be optionally placed on any intermediary envelopes. It is expensive to include it on every envelopes, but it MUST be placed on at least every 100'th envelope. The first envelope is processed as a standard answer, and subsequent messages have the following digest components:
DNS TCP会话可以包括多个DNS信封。例如，这通常由分区传输使用。在这样的连接上使用TSIG可以保护连接免受劫持，并提供数据完整性。TSIG必须包含在第一个和最后一个DNS信封中。可以选择将其放置在任何中间信封上。在每个信封上都写上它是很昂贵的，但必须至少每100个信封上写一次。第一个信封作为标准答案进行处理，后续消息具有以下摘要组件：
Prior Digest (running) DNS Messages (any unsigned messages since the last TSIG) TSIG Timers (current message)
先前摘要（正在运行）DNS消息（自上次TSIG以来的任何未签名消息）TSIG计时器（当前消息）
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记录（如上所述），则应假定连接已被劫持，并应关闭连接。客户机应该像对待任何其他中断传输一样对待此问题（尽管没有指定确切的行为）。
4.5. Server TSIG checks
4.5. 服务器TSIG检查
Upon receipt of a message, server will check if there is a TSIG RR. If one exists, the server is REQUIRED to return a TSIG RR in the response. The server MUST perform the following checks in the following order, check KEY, check TIME values, check MAC.
收到消息后，服务器将检查是否存在TSIG RR。如果存在，服务器需要在响应中返回TSIG RR。服务器必须按以下顺序执行以下检查：检查密钥、检查时间值、检查MAC。
4.5.1. KEY check and error handling
4.5.1. 密钥检查和错误处理
If a non-forwarding server does not recognize the key used by the client, the server MUST generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned as specified in [4.3]. The server SHOULD log the error.
如果非转发服务器无法识别客户端使用的密钥，则服务器必须生成带有RCODE 9（NOTAUTH）和TSIG error 17（BADKEY）的错误响应。按照[4.3]中的规定，此响应必须是无符号的。服务器应该记录错误。
4.5.2. TIME check and error handling
4.5.2. 时间检查和错误处理
If the server time is outside the time interval specified by the request (which is: Time Signed, plus/minus Fudge), 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
如果服务器时间超出请求指定的时间间隔（即：时间签名，加/减Fudge），则服务器必须生成带有RCODE 9（NOTAUTH）和TSIG error 18（BADTIME）的错误响应。服务器还应该在由密钥生成的消息中缓存最近的时间签名值，如果稍后收到的消息具有较早的时间签名值，则应该返回BADTIME。指示错误时间错误的响应必须由与
request. It MUST include the client's current time in the time signed field, the server's current time (a u_int48_t) in the other data field, and 6 in the other data length 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. The data signed is specified in [4.3]. The server SHOULD log the error.
要求它必须在时间签名字段中包含客户端的当前时间，在其他数据字段中包含服务器的当前时间（u_int48_t），在其他数据长度字段中包含6。这样做的目的是，客户端可以验证具有错误时间错误的消息，而不会因为另一个错误时间错误而导致验证失败。[4.3]中规定了签名的数据。服务器应该记录错误。
4.5.3. MAC check and error handling
4.5.3. MAC检查和错误处理
If a TSIG fails to verify, the server MUST generate an error response as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG). This response MUST be unsigned as specified in [4.3]. The server SHOULD log the error.
如果TSIG无法验证，服务器必须生成[4.3]中指定的错误响应，其中包含RCODE 9（NOTAUTH）和TSIG error 16（BADSIG）。按照[4.3]中的规定，此响应必须是无符号的。服务器应该记录错误。
4.6. Client processing of answer
4.6. 客户机应答处理
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. Otherwise, the response is treated as having a format error and discarded. The client then extracts the TSIG, adjusts the ARCOUNT, and calculates the keyed digest in the same way as the server. If the TSIG does not validate, that response MUST be discarded, unless the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to verify the response as if it were a TSIG Error response, as specified in [4.3]. A message containing an unsigned TSIG record or a TSIG record which fails verification SHOULD not be considered an acceptable response; the client SHOULD log an error and continue to wait for a signed response until the request times out.
当客户端从服务器接收到响应并期望看到TSIG时，它首先检查响应中是否存在TSIG RR。否则，响应将被视为存在格式错误并被丢弃。然后，客户端提取TSIG，调整ARCOUNT，并以与服务器相同的方式计算键控摘要。如果TSIG未验证，则必须丢弃该响应，除非RCODE为9（NOTAUTH），在这种情况下，客户机应尝试验证该响应，就像[4.3]中规定的TSIG错误响应一样。包含未签名TSIG记录或验证失败的TSIG记录的消息不应视为可接受的响应；客户端应记录错误并继续等待签名响应，直到请求超时。
4.6.1. Key error handling
4.6.1. 关键错误处理
If an RCODE on a response is 9 (NOTAUTH), and the response TSIG validates, and the TSIG key is different from the key used on the request, then this is a KEY error. The client MAY retry the request using the key specified by the server. This should never occur, as a server MUST NOT sign a response with a different key than signed the request.
如果响应上的RCODE为9（NOTAUTH），且响应TSIG验证，且TSIG密钥与请求上使用的密钥不同，则这是一个密钥错误。客户端可以使用服务器指定的密钥重试请求。这不应该发生，因为服务器不能使用与已签名请求不同的密钥对响应进行签名。
4.6.2. Time error handling
4.6.2. 时间错误处理
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 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（BADTIME），或者当前时间不在TSIG记录中指定的范围内，则这是一个时间错误。这表示客户端和服务器时钟不同步。在这种情况下，客户端应该记录事件。DNS解析程序不得根据错误时间错误调整客户端中的任何时钟，但应记录服务器在其他数据字段中的时间。
4.6.3. MAC error handling
4.6.3. MAC错误处理
If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this is a MAC error, and client MAY retry the request with a new request ID but it would be better to try a different shared key if one is available. Client SHOULD keep track of how many MAC errors are associated with each key. Clients SHOULD log this event.
如果响应RCODE为9（NOTAUTH）且TSIG ERROR为16（BADSIG），则这是一个MAC错误，客户端可能会使用新的请求ID重试该请求，但如果有可用的共享密钥，则最好尝试其他共享密钥。客户端应跟踪每个密钥关联的MAC错误数。客户端应记录此事件。
4.7. Special considerations for forwarding servers
4.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 his own, to the destination or the next forwarder. If no transaction security is available to the destination and the response has the AD flag (see [RFC2535]), the forwarder MUST unset the AD flag before adding the TSIG to the answer.
充当DNS消息转发服务器的服务器应检查TSIG记录是否存在。如果TSIG上的名称不是服务器与发起人共享的秘密，则服务器必须转发未更改的消息，包括TSIG。如果TSIG的名称是此服务器与发起人共享的密钥，则必须处理TSIG。如果TSIG通过了所有检查，则转发服务器必须（如有可能）包含一个自己的TSIG，以发送到目的地或下一个转发器。如果目的地没有可用的交易安全性，且响应具有AD标志（请参见[RFC2535]），则转发器必须在将TSIG添加到应答之前取消设置AD标志。
5 - Shared Secrets
5-共享秘密
5.1. 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 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 is used by the resolver.
5.1. 密钥是非常敏感的信息，应在存储它们的每台主机上采取所有可用步骤来保护它们。通常，此类主机需要物理保护。如果它们是多用户机器，则应特别注意，未经授权的用户无法访问键控材料。解析程序通常不受权限地运行，这意味着主机的所有用户都可以看到解析程序使用的任何配置数据。
5.2. 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.
5.2. 名称服务器通常运行特权服务器，这意味着其配置数据不必对主机的所有用户都可见。因此，实现基于事务的身份验证的主机可能应该配置“存根解析器”和本地缓存和转发名称服务器。这给[RFC2136]带来了一个特殊的问题，否则它将依赖客户端仅与区域的权威名称服务器通信。
5.3. Use of strong random shared secrets is essential to the security of TSIG. See [RFC1750] for a discussion of this issue. The secret should be at least as long as the keyed message digest, i.e. 16 bytes for HMAC-MD5 or 20 bytes for HMAC-SHA1.
5.3. 使用强随机共享秘密对TSIG的安全性至关重要。有关此问题的讨论，请参见[RFC1750]。机密应至少与密钥消息摘要一样长，即HMAC-MD5为16字节，HMAC-SHA1为20字节。
6 - Security Considerations
6-安全考虑
6.1. The approach specified here is computationally much less expensive than the signatures specified in [RFC2535]. As long as the shared secret key is not compromised, strong authentication is provided for the last hop from a local name server to the user resolver.
6.1. 这里指定的方法在计算上比[RFC2535]中指定的签名便宜得多。只要共享密钥不被泄露，就会为从本地名称服务器到用户解析程序的最后一跳提供强身份验证。
6.2. Secret keys should be changed periodically. 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 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. Secrets should never be shared by more than two entities.
6.2. 应定期更改密钥。如果客户端主机已被泄露，服务器应暂停使用该客户端已知的所有机密。如果可能，机密应以加密形式存储。秘密绝不能通过任何网络以透明的方式传播。本文件不涉及如何传播机密的问题。秘密不得由两个以上的实体共享。
6.3. 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 [RFC2535] security checks, then only security checked data will be available to the client.
6.3. 此机制不验证源数据，只验证共享某些秘密的双方之间的传输。原始源数据可能来自受损的区域主机，也可能在从真实的区域主机传输到某个“缓存转发器”的过程中损坏。但是，如果服务器忠实地执行完整的[RFC2535]安全检查，则客户端只能使用经安全检查的数据。
6.4. 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 situation is 300 seconds.
6.4. 伪造值太大可能会使服务器打开以重播攻击。如果机器没有时间同步或存在意外的网络延迟，则过小的fudge值可能会导致故障。大多数情况下的建议值为300秒。
7 - IANA Considerations
7-IANA考虑事项
IANA is expected to create and maintain a registry of algorithm names to be used as "Algorithm Names" as defined in Section 2.3. The initial value should be "HMAC-MD5.SIG-ALG.REG.INT". Algorithm names are text strings encoded using the syntax of a domain name. There is no structure required other than names for different algorithms must be unique when compared as DNS names, i.e., comparison is case insensitive. Note that the initial value mentioned above is not a domain name, and therefore need not be a registered name within the DNS. New algorithms are assigned using the IETF Consensus policy defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT looks like a FQDN for historical reasons; future algorithm names are expected to be simple (i.e., single-component) names.
IANA应创建并维护一个算法名称注册表，用作第2.3节中定义的“算法名称”。初始值应为“HMAC-MD5.SIG-ALG.REG.INT”。算法名称是使用域名语法编码的文本字符串。除了不同算法的名称之外，不需要任何结构。当与DNS名称进行比较时，不同算法的名称必须是唯一的，即比较不区分大小写。请注意，上面提到的初始值不是域名，因此不需要是DNS中的注册名称。使用RFC 2434中定义的IETF共识策略分配新算法。由于历史原因，算法名称HMAC-MD5.SIG-ALG.REG.INT看起来像FQDN；未来的算法名称应为简单（即单个组件）名称。
IANA is expected to create and maintain a registry of "TSIG Error values" to be used for "Error" values as defined in section 2.3. Initial values should be those defined in section 1.7. New TSIG error codes for the TSIG error field are assigned using the IETF Consensus policy defined in RFC 2434.
IANA应创建并维护一个“TSIG错误值”注册表，用于第2.3节中定义的“错误”值。初始值应为第1.7节中定义的值。使用RFC 2434中定义的IETF共识策略为TSIG错误字段分配新的TSIG错误代码。
8 - References
8-参考文献
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1034, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1034，1987年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1995.
[RFC1750]Eastlake，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1995年12月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5: Keyed-MD5 for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC-MD5:Keyed-MD5用于消息认证”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic Updates in the Domain Name System", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.和J.合著《域名系统中的动态更新》，RFC 21361997年4月。
[RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC2137]Eastlake 3rd，D.，“安全域名系统动态更新”，RFC 2137，1997年4月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673]克劳福德，M.，“域名系统中的二进制标签”，RFC2673，1999年8月。
9 - Authors' Addresses
9-作者地址
Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063
Paul Vixie互联网软件联合体950 Charter Street Redwood City，加利福尼亚州94063
Phone: +1 650 779 7001
EMail: vixie@isc.org
Phone: +1 650 779 7001
EMail: vixie@isc.org
Olafur Gudmundsson NAI Labs 3060 Washington Road, Route 97 Glenwood, MD 21738
马里兰州格兰伍德97号路华盛顿路3060号Olafur Gudmundsson NAI实验室，邮编21738
Phone: +1 443 259 2389
EMail: ogud@tislabs.com
Phone: +1 443 259 2389
EMail: ogud@tislabs.com
Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA
美国马萨诸塞州哈德逊森林大道140号唐纳德E东湖第三摩托罗拉01749
Phone: +1 508 261 5434
EMail: dee3@torque.pothole.com
Phone: +1 508 261 5434
EMail: dee3@torque.pothole.com
Brian Wellington Nominum, Inc. 950 Charter Street Redwood City, CA 94063
Brian Wellington Nominum，Inc.加利福尼亚州红木市Charter Street 950号，邮编94063
Phone: +1 650 779 6022
EMail: Brian.Wellington@nominum.com
Phone: +1 650 779 6022
EMail: Brian.Wellington@nominum.com
10 Full Copyright Statement
10完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。