Network Working Group S. Kwan
Request for Comments: 3645 P. Garg
Updates: 2845 J. Gilroy
Category: Standards Track L. Esibov
J. Westhead
Microsoft Corp.
R. Hall
Lucent Technologies
October 2003
Network Working Group S. Kwan
Request for Comments: 3645 P. Garg
Updates: 2845 J. Gilroy
Category: Standards Track L. Esibov
J. Westhead
Microsoft Corp.
R. Hall
Lucent Technologies
October 2003
Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)
DNS密钥事务认证通用安全服务算法（GSS-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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). This document updates RFC 2845.
DNS密钥事务认证（TSIG）协议为DNS提供事务级认证。TSIG可通过定义新算法进行扩展。本文件规定了基于通用安全服务应用程序接口（GSS-API）（RFC2743）的算法。本文档更新了RFC 2845。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . . 3
2.1. GSS Details. . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Modifications to the TSIG protocol (RFC 2845). . . . . . 4
3. Client Protocol Details. . . . . . . . . . . . . . . . . . . . 5
3.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 5
3.1.1. Call GSS_Init_sec_context. . . . . . . . . . . . . 6
3.1.2. Send TKEY Query to Server. . . . . . . . . . . . . 8
3.1.3. Receive TKEY Query-Response from Server. . . . . . 8
3.2. Context Established. . . . . . . . . . . . . . . . . . . 11
3.2.1. Terminating a Context. . . . . . . . . . . . . . . 11
4. Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12
4.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 12
4.1.1. Receive TKEY Query from Client . . . . . . . . . . 12
4.1.2. Call GSS_Accept_sec_context. . . . . . . . . . . . 12
4.1.3. Send TKEY Query-Response to Client . . . . . . . . 13
4.2. Context Established. . . . . . . . . . . . . . . . . . . 15
4.2.1. Terminating a Context. . . . . . . . . . . . . . . 15
5. Sending and Verifying Signed Messages. . . . . . . . . . . . . 15
5.1. Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15
5.2. Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16
6. Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
9. Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References. . . . . . . . . . . . . . . . . . 24
12.2. Informative References. . . . . . . . . . . . . . . . . 24
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . . 3
2.1. GSS Details. . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Modifications to the TSIG protocol (RFC 2845). . . . . . 4
3. Client Protocol Details. . . . . . . . . . . . . . . . . . . . 5
3.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 5
3.1.1. Call GSS_Init_sec_context. . . . . . . . . . . . . 6
3.1.2. Send TKEY Query to Server. . . . . . . . . . . . . 8
3.1.3. Receive TKEY Query-Response from Server. . . . . . 8
3.2. Context Established. . . . . . . . . . . . . . . . . . . 11
3.2.1. Terminating a Context. . . . . . . . . . . . . . . 11
4. Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12
4.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 12
4.1.1. Receive TKEY Query from Client . . . . . . . . . . 12
4.1.2. Call GSS_Accept_sec_context. . . . . . . . . . . . 12
4.1.3. Send TKEY Query-Response to Client . . . . . . . . 13
4.2. Context Established. . . . . . . . . . . . . . . . . . . 15
4.2.1. Terminating a Context. . . . . . . . . . . . . . . 15
5. Sending and Verifying Signed Messages. . . . . . . . . . . . . 15
5.1. Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15
5.2. Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16
6. Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
9. Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References. . . . . . . . . . . . . . . . . . 24
12.2. Informative References. . . . . . . . . . . . . . . . . 24
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845] protocol was developed to provide a lightweight authentication and integrity of messages between two DNS entities, such as client and server or server and server. TSIG can be used to protect dynamic update messages, authenticate regular message or to off-load complicated DNSSEC [RFC2535] processing from a client to a server and still allow the client to be assured of the integrity of the answers.
DNS密钥交易认证（TSIG）[RFC2845]协议是为了在两个DNS实体（如客户端和服务器或服务器和服务器）之间提供消息的轻量级认证和完整性而开发的。TSIG可用于保护动态更新消息、验证常规消息或将复杂的DNSSEC[RFC2535]处理从客户端卸载到服务器，并且仍然允许客户端确保答案的完整性。
The TSIG protocol [RFC2845] is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) [RFC2743]. GSS-API is a framework that provides an abstraction of security to the application protocol developer. The security services offered can include authentication, integrity, and confidentiality.
TSIG协议[RFC2845]可通过定义新算法进行扩展。本文件规定了基于通用安全服务应用程序接口（GSS-API）[RFC2743]的算法。GSS-API是一个为应用程序协议开发人员提供安全性抽象的框架。提供的安全服务可以包括身份验证、完整性和机密性。
The GSS-API framework has several benefits:
GSS-API框架有几个好处：
* Mechanism and protocol independence. The underlying mechanisms that realize the security services can be negotiated on the fly and varied over time. For example, a client and server MAY use Kerberos [RFC1964] for one transaction, whereas that same server MAY use SPKM [RFC2025] with a different client.
* 机制和协议独立性。实现安全服务的底层机制可以动态协商并随时间变化。例如，客户机和服务器可以对一个事务使用Kerberos[RFC1964]，而同一服务器可以对不同的客户机使用SPKM[RFC2025]。
* The protocol developer is removed from the responsibility of creating and managing a security infrastructure. For example, the developer does not need to create new key distribution or key management systems. Instead the developer relies on the security service mechanism to manage this on its behalf.
* 协议开发人员不再负责创建和管理安全基础设施。例如，开发人员不需要创建新的密钥分发或密钥管理系统。相反，开发人员依赖于安全服务机制来代表其进行管理。
The scope of this document is limited to the description of an authentication mechanism only. It does not discuss and/or propose an authorization mechanism. Readers that are unfamiliar with GSS-API concepts are encouraged to read the characteristics and concepts section of [RFC2743] before examining this protocol in detail. It is also assumed that the reader is familiar with [RFC2845], [RFC2930], [RFC1034] and [RFC1035].
本文档的范围仅限于对身份验证机制的描述。它没有讨论和/或提出授权机制。鼓励不熟悉GSS-API概念的读者在详细检查本协议之前阅读[RFC2743]的特征和概念部分。还假设读者熟悉[RFC2845]、[RFC2930]、[RFC1034]和[RFC1035]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”和“可能”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
In GSS, client and server interact to create a "security context". The security context can be used to create and verify transaction signatures on messages between the two parties. A unique security context is required for each unique connection between client and server.
在GSS中，客户端和服务器交互以创建“安全上下文”。安全上下文可用于在双方之间的消息上创建和验证事务签名。客户端和服务器之间的每个唯一连接都需要一个唯一的安全上下文。
Creating a security context involves a negotiation between client and server. Once a context has been established, it has a finite lifetime for which it can be used to secure messages. Thus there are three states of a context associated with a connection:
创建安全上下文涉及客户端和服务器之间的协商。一旦建立了上下文，它就有一个有限的生命周期，可以用来保护消息。因此，与连接关联的上下文有三种状态：
+----------+
| |
V |
+---------------+ |
| Uninitialized | |
| | |
+---------------+ |
| |
V |
+---------------+ |
| Negotiating | |
| Context | |
+---------------+ |
| |
V |
+---------------+ |
| Context | |
| Established | |
+---------------+ |
| |
+----------+
+----------+
| |
V |
+---------------+ |
| Uninitialized | |
| | |
+---------------+ |
| |
V |
+---------------+ |
| Negotiating | |
| Context | |
+---------------+ |
| |
V |
+---------------+ |
| Context | |
| Established | |
+---------------+ |
| |
+----------+
Every connection begins in the uninitialized state.
每个连接都以未初始化状态开始。
Client and server MUST be locally authenticated and have acquired default credentials before using this protocol as specified in Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
按照RFC 2743[RFC2743]第1.1.1节“凭据”的规定，在使用本协议之前，客户端和服务器必须经过本地身份验证，并已获得默认凭据。
The GSS-TSIG algorithm consists of two stages:
GSS-TSIG算法包括两个阶段：
I. Establish security context. The Client and Server use the GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate the tokens that they pass to each other using [RFC2930] as a transport mechanism.
I.建立安全环境。客户机和服务器使用GSS_Init_sec_上下文和GSS_Accept_sec_上下文API生成令牌，并使用[RFC2930]作为传输机制相互传递。
II. Once the security context is established it is used to generate and verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. These signatures are exchanged by the Client and Server as a part of the TSIG records exchanged in DNS messages sent between the Client and Server, as described in [RFC2845].
二、一旦建立了安全上下文，它将用于使用GSS_GetMIC和GSS_VerifyMIC API生成和验证签名。这些签名由客户端和服务器交换，作为在客户端和服务器之间发送的DNS消息中交换的TSIG记录的一部分，如[RFC2845]所述。
Modification to RFC 2845 allows use of TSIG through signing server's response in an explicitly specified place in multi message exchange between two DNS entities even if client's request wasn't signed.
对RFC 2845的修改允许通过在两个DNS实体之间的多消息交换中明确指定的位置对服务器的响应进行签名来使用TSIG，即使客户端的请求没有签名。
Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
具体而言，RFC 2845第4.2节必须修改如下：
Replace: "The server MUST not generate a signed response to an unsigned request."
替换：“服务器不得对未签名的请求生成已签名的响应。”
With: "The server MUST not generate a signed response to an unsigned request, except in case of response to client's unsigned TKEY query if secret key is established on server side after server processed client's query. Signing responses to unsigned TKEY queries MUST be explicitly specified in the description of an individual secret key establishment algorithm."
与：“服务器不得对未签名的请求生成签名响应，除非在服务器处理客户端查询后在服务器端建立了密钥，否则对客户端未签名的TKEY查询进行响应。必须在单个密钥建立算法的说明中明确指定对未签名TKEY查询的签名响应。”
A unique context is required for each server to which the client sends secure messages. A context is identified by a context handle. A client maintains a mapping of servers to handles:
客户端向其发送安全消息的每个服务器都需要唯一的上下文。上下文由上下文句柄标识。客户端维护服务器到句柄的映射：
(target_name, key_name, context_handle)
（目标名称、键名称、上下文句柄）
The value key_name also identifies a context handle. The key_name is the owner name of the TKEY and TSIG records sent between a client and a server to indicate to each other which context MUST be used to process the current request.
值key_name还标识上下文句柄。key_name是在客户端和服务器之间发送的TKEY和TSIG记录的所有者名称，用于相互指示必须使用哪个上下文来处理当前请求。
DNS client and server MAY use various underlying security mechanisms to establish security context as described in sections 3 and 4. At the same time, in order to guarantee interoperability between DNS clients and servers that support GSS-TSIG it is REQUIRED that security mechanism used by client enables use of Kerberos v5 (see Section 9 for more information).
DNS客户端和服务器可以使用各种底层安全机制来建立安全上下文，如第3节和第4节所述。同时，为了保证DNS客户端和支持GSS-TSIG的服务器之间的互操作性，要求客户端使用的安全机制能够使用Kerberos v5（有关更多信息，请参阅第9节）。
In GSS, establishing a security context involves the passing of opaque tokens between the client and the server. The client generates the initial token and sends it to the server. The server processes the token and if necessary, returns a subsequent token to the client. The client processes this token, and so on, until the negotiation is complete. The number of times the client and server exchange tokens depends on the underlying security mechanism. A completed negotiation results in a context handle.
在GSS中，建立安全上下文涉及在客户端和服务器之间传递不透明令牌。客户端生成初始令牌并将其发送到服务器。服务器处理令牌，如有必要，将后续令牌返回给客户端。客户机处理此令牌，依此类推，直到协商完成。客户端和服务器交换令牌的次数取决于底层安全机制。已完成的协商将产生上下文句柄。
The TKEY resource record [RFC2930] is used as the vehicle to transfer tokens between client and server. The TKEY record is a general mechanism for establishing secret keys for use with TSIG. For more information, see [RFC2930].
TKEY资源记录[RFC2930]用作在客户端和服务器之间传输令牌的工具。TKEY记录是建立用于TSIG的密钥的通用机制。有关更多信息，请参阅[RFC2930]。
To obtain the first token to be sent to a server, a client MUST call GSS_Init_sec_context API.
要获取发送到服务器的第一个令牌，客户端必须调用GSS_Init_sec_上下文API。
The following input parameters MUST be used. The outcome of the call is indicated with the output values below. Consult Sections 2.2.1, "GSS_Init_sec_context call", of [RFC2743] for syntax definitions.
必须使用以下输入参数。调用的结果用下面的输出值表示。有关语法定义，请参阅[RFC2743]第2.2.1节“GSS_Init_sec_上下文调用”。
INPUTS CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use default"). Client MAY instead specify some other valid handle to its credentials. CONTEXT HANDLE input_context_handle = 0 INTERNAL NAME targ_name = "DNS@<target_server_name>" OBJECT IDENTIFIER mech_type = Underlying security mechanism chosen by implementers. To guarantee interoperability of the implementations of the GSS-TSIG mechanism client MUST specify a valid underlying security mechanism that enables use of Kerberos v5 (see Section 9 for more information). OCTET STRING input_token = NULL BOOLEAN replay_det_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE BOOLEAN deleg_req_flag = TRUE BOOLEAN sequence_req_flag = TRUE BOOLEAN anon_req_flag = FALSE BOOLEAN integ_req_flag = TRUE INTEGER lifetime_req = 0 (0 requests a default value). Client MAY instead specify another upper bound for the lifetime of the context to be established in seconds. OCTET STRING chan_bindings = Any valid channel bindings as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
输入凭证句柄\u cred\u HANDLE=NULL（NULL指定“使用默认值”）。客户端可以为其凭据指定其他一些有效句柄。上下文句柄输入\u CONTEXT\u HANDLE=0内部名称target\u NAME=“DNS@<target\u server\u NAME>”对象标识符mech\u type=由实现者选择的底层安全机制。为了保证GSS-TSIG机制实现的互操作性，客户端必须指定一个有效的底层安全机制，以支持使用Kerberos v5（有关更多信息，请参阅第9节）。八位字节字符串输入\ U标记=空布尔回放\数据\请求\标志=真布尔相互\请求\标志=真布尔删除\请求\标志=真布尔序列\请求\标志=真布尔anon\请求\标志=假布尔整数请求\标志=真整数生存期\请求=0（0请求默认值）。客户机可以为要建立的上下文的生存期指定另一个上限（以秒为单位）。八位字节字符串chan_bindings=任何有效通道绑定，如[RFC2743]第1.1.6节“通道绑定”中所述
OUTPUTS INTEGER major_status CONTEXT HANDLE output_context_handle OCTET STRING output_token BOOLEAN replay_det_state BOOLEAN mutual_state INTEGER minor_status OBJECT IDENTIFIER mech_type BOOLEAN deleg_state
输出整数主要\状态上下文句柄输出\上下文\句柄八位字符串输出\令牌布尔回放\数据\状态布尔交互\状态整数次要\状态对象标识符机械类型布尔删除\状态
BOOLEAN sequence_state BOOLEAN anon_state BOOLEAN trans_state BOOLEAN prot_ready_state BOOLEAN conf_avail BOOLEAN integ_avail INTEGER lifetime_rec
布尔序列\状态布尔非状态布尔转换\状态布尔保护\就绪\状态布尔配置\可用布尔整数\可用整数生命周期\记录
If returned major_status is set to one of the following errors:
如果返回的“主要错误”状态设置为以下错误之一：
GSS_S_DEFECTIVE_TOKEN GSS_S_DEFECTIVE_CREDENTIAL GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_NO_CRED GSS_S_CREDENTIALS_EXPIRED GSS_S_BAD_BINDINGS GSS_S_OLD_TOKEN GSS_S_DUPLICATE_TOKEN GSS_S_NO_CONTEXT GSS_S_BAD_NAMETYPE GSS_S_BAD_NAME GSS_S_BAD_MECH GSS_S_FAILURE
GSS\U S\U有缺陷的GSS\U有缺陷的GSS\U凭证GSS\U有缺陷的GSS\U有缺陷的GSS\U有缺陷的GSS\U有缺陷的GSS\U有缺陷的GSS\U凭证GSS\U过期的GSS\U有缺陷的GSS\U凭证GSS\U旧的GSS\U有缺陷的GSS\U有重复的GSS\U凭证GSS\U无上下文GSS\U有缺陷的GSS\U名称类型GSS\U有缺陷的GSS\U有缺陷的GSS\U有故障
then the client MUST abandon the algorithm and MUST NOT use the GSS-TSIG algorithm to establish this security context. This document does not prescribe which other mechanism could be used to establish a security context. Next time when this client needs to establish security context, the client MAY use GSS-TSIG algorithm.
然后，客户端必须放弃该算法，并且不得使用GSS-TSIG算法来建立该安全上下文。本文件未规定可使用哪些其他机制来建立安全上下文。下次当该客户端需要建立安全上下文时，该客户端可以使用GSS-TSIG算法。
Success values of major_status are GSS_S_CONTINUE_NEEDED and GSS_S_COMPLETE. The exact success code is important during later processing.
主要状态的成功值是GSS\U S\U CONTINUE\U NEEDED和GSS\U COMPLETE。在以后的处理过程中，准确的成功代码非常重要。
The values of replay_det_state and mutual_state indicate if the security package provides replay detection and mutual authentication, respectively. If returned major_status is GSS_S_COMPLETE AND one or both of these values are FALSE, the client MUST abandon this algorithm.
replay_det_state和mutual_state的值分别指示安全包是否提供重播检测和相互身份验证。如果返回的主要_状态为GSS_S_COMPLETE，并且其中一个或两个值为FALSE，则客户端必须放弃此算法。
Client's behavior MAY depend on other OUTPUT parameters according to the policy local to the client.
根据客户端本地策略，客户端的行为可能取决于其他输出参数。
The handle output_context_handle is unique to this negotiation and is stored in the client's mapping table as the context_handle that maps to target_name.
句柄输出\u上下文\u句柄对此协商是唯一的，并作为映射到目标\u名称的上下文\u句柄存储在客户端的映射表中。
An opaque output_token returned by GSS_Init_sec_context is transmitted to the server in a query request with QTYPE=TKEY. The token itself will be placed in a Key Data field of the RDATA field in the TKEY resource record in the additional records section of the query. The owner name of the TKEY resource record set queried for and the owner name of the supplied TKEY resource record in the additional records section MUST be the same. This name uniquely identifies the security context to both the client and server, and thus the client SHOULD use a value which is globally unique as described in [RFC2930]. To achieve global uniqueness, the name MAY contain a UUID/GUID [ISO11578].
GSS_Init_sec_上下文返回的不透明输出_令牌在QTYPE=TKEY的查询请求中传输到服务器。令牌本身将被放置在查询的附加记录部分的TKEY资源记录的RDATA字段的Key Data字段中。查询的TKEY资源记录集的所有者名称与“附加记录”部分中提供的TKEY资源记录的所有者名称必须相同。此名称唯一地标识客户端和服务器的安全上下文，因此客户端应使用一个全局唯一的值，如[RFC2930]所述。为了实现全局唯一性，名称可以包含UUID/GUID[ISO1578]。
TKEY Record NAME = client-generated globally unique domain name string (as described in [RFC2930]) RDATA Algorithm Name = gss-tsig Mode = 3 (GSS-API negotiation - per [RFC2930]) Key Size = size of output_token in octets Key Data = output_token
TKEY记录名称=客户端生成的全局唯一域名字符串（如[RFC2930]中所述）RDATA算法名称=gss tsig模式=3（gss-API协商-每[RFC2930]）密钥大小=以八位字节为单位的输出令牌大小密钥数据=输出令牌
The remaining fields in the TKEY RDATA, i.e., Inception, Expiration, Error, Other Size and Data Fields, MUST be set according to [RFC2930].
TKEY RDATA中的其余字段，即起始、到期、错误、其他大小和数据字段，必须根据[RFC2930]进行设置。
The query is transmitted to the server.
查询被传输到服务器。
Note: if the original client call to GSS_Init_sec_context returned any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then the client MUST NOT send TKEY query. Client's behavior in this case is described above in Section 3.1.1.
注意：如果对GSS_Init_sec_上下文的原始客户端调用返回除GSS_CONTINUE_NEEDED或GSS_COMPLETE之外的任何主要_状态，则客户端不得发送TKEY查询。上述第3.1.1节描述了客户在这种情况下的行为。
Upon the reception of the TKEY query the DNS server MUST respond according to the description in Section 4. This section specifies the behavior of the client after it receives the matching response to its query.
接收到TKEY查询后，DNS服务器必须根据第4节中的描述进行响应。本节指定客户端在收到对其查询的匹配响应后的行为。
The next processing step depends on the value of major_status from the most recent call that client performed to GSS_Init_sec_context: either GSS_S_COMPLETE or GSS_S_CONTINUE.
下一个处理步骤取决于客户端对GSS_Init_sec_上下文执行的最新调用中的主_status值：GSS_S_COMPLETE或GSS_S_CONTINUE。
If the last call to GSS_Init_sec_context yielded a major_status value of GSS_S_COMPLETE and a non-NULL output_token was sent to the server, then the client side component of the negotiation is complete and the client is awaiting confirmation from the server.
如果对GSS_Init_sec_context的最后一次调用产生了GSS_S_COMPLETE的主_状态值，并且向服务器发送了非空输出_令牌，则协商的客户端组件已完成，客户端正在等待服务器的确认。
Confirmation is in the form of a query response with RCODE=NOERROR and with the last client supplied TKEY record in the answer section of the query. The response MUST be signed with a TSIG record. Note that the server is allowed to sign a response to unsigned client's query due to modification to the RFC 2845 specified in Section 2.2 above. The signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages. If the response is not signed, OR if the response is signed but the signature is invalid, then an attacker has tampered with the message in transit or has attempted to send the client a false response. In this case, the client MAY continue waiting for a response to its last TKEY query until the time period since the client sent last TKEY query expires. Such a time period is specified by the policy local to the client. This is a new option that allows the DNS client to accept multiple answers for one query ID and select one (not necessarily the first one) based on some criteria.
确认是以查询响应的形式进行的，其中RCODE=NOERROR，最后一个客户端提供的TKEY记录位于查询的应答部分。必须使用TSIG记录对响应进行签名。请注意，由于修改了上文第2.2节中指定的RFC 2845，因此允许服务器对未签名的客户端查询的响应进行签名。TSIG记录中的签名必须使用第5节“发送和验证签名消息”中详述的程序进行验证。如果响应未签名，或者响应已签名但签名无效，则攻击者篡改了传输中的消息或试图向客户端发送错误响应。在这种情况下，客户机可以继续等待对其最后一个TKEY查询的响应，直到客户机发送最后一个TKEY查询后的时间段到期。此时间段由客户端本地策略指定。这是一个新选项，允许DNS客户端接受一个查询ID的多个答案，并根据某些条件选择一个（不一定是第一个）。
If the signature is verified, the context state is advanced to Context Established. Proceed to section 3.2 for usage of the security context.
如果签名已验证，则上下文状态将前进到上下文已建立。有关安全上下文的使用，请转至第3.2节。
If the last call to GSS_Init_sec_context yielded a major_status value of GSS_S_CONTINUE_NEEDED, then the negotiation is not yet complete. The server will return to the client a query response with a TKEY record in the Answer section. If the DNS message error is not NO_ERROR or error field in the TKEY record is not 0 (i.e., no error), then the client MUST abandon this negotiation sequence. The client MUST delete an active context by calling GSS_Delete_sec_context providing the associated context_handle. The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1. To prevent infinite looping the number of attempts to establish a security context MUST be limited to ten or less.
如果对GSS_Init_sec_context的最后一次调用产生了所需的GSS_S_CONTINUE_的主要_状态值，则协商尚未完成。服务器将向客户机返回一个查询响应，其中应答部分包含TKEY记录。如果DNS消息错误不是NO_error或TKEY记录中的error字段不是0（即无错误），则客户端必须放弃此协商序列。客户端必须通过调用GSS_delete_sec_context（提供关联的上下文句柄）来删除活动上下文。客户可以从第3.1节所述的未初始化状态开始重复协商顺序。为了防止无限循环，尝试建立安全上下文的次数必须限制在十次或更少。
If the DNS message error is NO_ERROR and the error field in the TKEY record is 0 (i.e., no error), then the client MUST pass a token specified in the Key Data field in the TKEY resource record to
如果DNS消息错误为NO_error且TKEY记录中的错误字段为0（即无错误），则客户端必须将TKEY资源记录中的密钥数据字段中指定的令牌传递给
GSS_Init_sec_context using the same parameters values as in previous call except values for CONTEXT HANDLE input_context_handle and OCTET STRING input_token as described below:
GSS_Init_sec_context使用与上一次调用中相同的参数值，上下文句柄输入_context_HANDLE和八位字符串输入_令牌的值除外，如下所述：
INPUTS CONTEXT HANDLE input_context_handle = context_handle (this is the context_handle corresponding to the key_name which is the owner name of the TKEY record in the answer section in the TKEY query response)
INPUTS CONTEXT HANDLE input_CONTEXT_HANDLE=CONTEXT_HANDLE（这是与key_名称对应的CONTEXT_HANDLE，key_名称是TKEY查询响应中应答部分中TKEY记录的所有者名称）
OCTET STRING input_token = token from Key field of TKEY record
八位字节字符串输入\ u token=TKEY记录的Key字段中的token
Depending on the following OUTPUT values of GSS_Init_sec_context
根据GSS_Init_sec_上下文的以下输出值
INTEGER major_status OCTET STRING output_token
整数主\u状态八位字符串输出\u标记
the client MUST take one of the following actions:
客户必须采取以下行动之一：
If OUTPUT major_status is set to one of the following values:
如果输出主输出状态设置为以下值之一：
GSS_S_DEFECTIVE_TOKEN GSS_S_DEFECTIVE_CREDENTIAL GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_NO_CRED GSS_S_CREDENTIALS_EXPIRED GSS_S_BAD_BINDINGS GSS_S_OLD_TOKEN GSS_S_DUPLICATE_TOKEN GSS_S_NO_CONTEXT GSS_S_BAD_NAMETYPE GSS_S_BAD_NAME GSS_S_BAD_MECH GSS_S_FAILURE
GSS\U S\U有缺陷的GSS\U有缺陷的GSS\U凭证GSS\U有缺陷的GSS\U有缺陷的GSS\U有缺陷的GSS\U有缺陷的GSS\U有缺陷的GSS\U凭证GSS\U过期的GSS\U有缺陷的GSS\U凭证GSS\U旧的GSS\U有缺陷的GSS\U有重复的GSS\U凭证GSS\U无上下文GSS\U有缺陷的GSS\U名称类型GSS\U有缺陷的GSS\U有缺陷的GSS\U有故障
the client MUST abandon this negotiation sequence. This means that the client MUST delete an active context by calling GSS_Delete_sec_context providing the associated context_handle. The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1. To prevent infinite looping the number of attempts to establish a security context MUST be limited to ten or less.
客户必须放弃此协商顺序。这意味着客户端必须通过调用GSS_delete_sec_context（提供关联的上下文句柄）来删除活动上下文。客户可以从第3.1节所述的未初始化状态开始重复协商顺序。为了防止无限循环，尝试建立安全上下文的次数必须限制在十次或更少。
If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then client MUST act as described below.
如果输出主要状态为需要GSS\U S\U CONTINUE\U或GSS\U COMPLETE，则客户机必须按如下所述操作。
If the response from the server was signed, and the OUTPUT major_status is GSS_S_COMPLETE,then the signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages. If the signature is invalid, then the client MUST abandon this negotiation sequence. This means that the client MUST delete an active context by calling GSS_Delete_sec_context providing the associated context_handle. The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1. To prevent infinite looping the number of attempts to establish a security context MUST be limited to ten or less.
如果来自服务器的响应已签名，且输出主要_状态为GSS_S_COMPLETE，则必须使用第5节“发送和验证签名消息”中详述的程序验证TSIG记录中的签名。如果签名无效，则客户端必须放弃此协商序列。这意味着客户端必须通过调用GSS_delete_sec_context（提供关联的上下文句柄）来删除活动上下文。客户可以从第3.1节所述的未初始化状态开始重复协商顺序。为了防止无限循环，尝试建立安全上下文的次数必须限制在十次或更少。
If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet finished. The token output_token MUST be passed to the server in a TKEY record by repeating the negotiation sequence beginning with section 3.1.2. The client MUST place a limit on the number of continuations in a context negotiation to prevent endless looping. Such limit SHOULD NOT exceed value of 10.
如果主要状态为需要GSS S SU SU CONTINUE，则谈判尚未完成。必须通过重复从第3.1.2节开始的协商顺序，将令牌输出\令牌以TKEY记录的形式传递给服务器。客户机必须限制上下文协商中的连续次数，以防止无休止的循环。该限值不应超过10。
If major_status is GSS_S_COMPLETE and output_token is non-NULL, the client-side component of the negotiation is complete but the token output_token MUST be passed to the server by repeating the negotiation sequence beginning with section 3.1.2.
如果主_状态为GSS_S_COMPLETE且输出_令牌为非空，则协商的客户端组件已完成，但必须通过重复从第3.1.2节开始的协商顺序将令牌输出_令牌传递给服务器。
If major_status is GSS_S_COMPLETE and output_token is NULL, context negotiation is complete. The context state is advanced to Context Established. Proceed to section 3.2 for usage of the security context.
如果主_状态为GSS_S_COMPLETE且输出_令牌为空，则上下文协商完成。上下文状态被提升到上下文已建立状态。有关安全上下文的使用，请转至第3.2节。
When context negotiation is complete, the handle context_handle MUST be used for the generation and verification of transaction signatures.
上下文协商完成后，必须使用句柄context\u handle生成和验证事务签名。
The procedures for sending and receiving signed messages are described in section 5, Sending and Verifying Signed Messages.
第5节“发送和验证签名消息”中描述了发送和接收签名消息的过程。
When the client is not intended to continue using the established security context, the client SHOULD delete an active context by calling GSS_Delete_sec_context providing the associated context_handle, AND client SHOULD delete the established context on the DNS server by using TKEY RR with the Mode field set to 5, i.e., "key deletion" [RFC2930].
当客户端不打算继续使用已建立的安全上下文时，客户端应通过调用提供关联上下文句柄的GSS_delete_sec_context来删除活动上下文，并且客户端应通过使用模式字段设置为5的TKEY RR来删除DNS服务器上已建立的上下文，即“密钥删除”[RFC2930]。
As on the client-side, the result of a successful context negotiation is a context handle used in future generation and verification of the transaction signatures.
在客户端，成功的上下文协商的结果是在将来生成和验证事务签名时使用的上下文句柄。
A server MAY be managing several contexts with several clients. Clients identify their contexts by providing a key name in their request. The server maintains a mapping of key names to handles:
一台服务器可能正在使用多个客户端管理多个上下文。客户端通过在其请求中提供密钥名称来识别其上下文。服务器维护密钥名称到句柄的映射：
(key_name, context_handle)
（键名称、上下文句柄）
A server MUST recognize TKEY queries as security context negotiation messages.
服务器必须将TKEY查询识别为安全上下文协商消息。
Upon receiving a query with QTYPE = TKEY, the server MUST examine whether the Mode and Algorithm Name fields of the TKEY record in the additional records section of the message contain values of 3 and gss-tsig, respectively. If they do, then the (key_name, context_handle) mapping table is searched for the key_name matching the owner name of the TKEY record in the additional records section of the query. If the name is found in the table and the security context for this name is established and not expired, then the server MUST respond to the query with BADNAME error in the TKEY error field. If the name is found in the table and the security context is not established, the corresponding context_handle is used in subsequent GSS operations. If the name is found but the security context is expired, then the server deletes this security context, as described in Section 4.2.1, and interprets this query as a start of new security context negotiation and performs operations described in Section 4.1.2 and 4.1.3. If the name is not found, then the server interprets this query as a start of new security context negotiation and performs operations described in Section 4.1.2 and 4.1.3.
在收到QTYPE=TKEY的查询时，服务器必须检查消息的附加记录部分中TKEY记录的模式和算法名称字段是否分别包含值3和gss tsig。如果有，则在查询的“附加记录”部分中，在（key\u name，context\u handle）映射表中搜索与TKEY记录的所有者名称匹配的key\u名称。如果在表中找到该名称，并且该名称的安全上下文已建立且未过期，则服务器必须在TKEY错误字段中使用BADNAME错误响应查询。如果在表中找到该名称且未建立安全上下文，则在后续GSS操作中使用相应的上下文句柄。如果找到名称但安全上下文已过期，则服务器将删除此安全上下文（如第4.2.1节所述），并将此查询解释为新安全上下文协商的开始，并执行第4.1.2节和第4.1.3节所述的操作。如果未找到名称，则服务器将此查询解释为新安全上下文协商的开始，并执行第4.1.2节和第4.1.3节中描述的操作。
The server performs its side of a context negotiation by calling GSS_Accept_sec_context. The following input parameters MUST be used. The outcome of the call is indicated with the output values below. Consult Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743 [RFC2743] for syntax definitions.
服务器通过调用GSS_Accept_secu_context来执行其上下文协商。必须使用以下输入参数。调用的结果用下面的输出值表示。有关语法定义，请参阅RFC 2743[RFC2743]第2.2.2节“GSS_接受_秒_上下文调用”。
INPUTS CONTEXT HANDLE input_context_handle = 0 if new negotiation, context_handle matching key_name if ongoing negotiation OCTET STRING input_token = token specified in the Key field from TKEY RR (from Additional records Section of the client's query)
INPUTS CONTEXT HANDLE input_CONTEXT_HANDLE=0（如果是新协商），CONTEXT_HANDLE匹配key_name（如果是正在进行的协商），八位字节字符串input_token=TKEY RR（从客户端查询的附加记录部分）的key字段中指定的token
CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use default"). Server MAY instead specify some other valid handle to its credentials. OCTET STRING chan_bindings = Any valid channel bindings as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
凭据句柄接受器\u cred\u HANDLE=NULL（NULL指定“使用默认值”）。服务器可以为其凭据指定其他一些有效句柄。八位字节字符串chan_bindings=任何有效通道绑定，如[RFC2743]第1.1.6节“通道绑定”中所述
OUTPUTS INTEGER major_status CONTEXT_HANDLE output_context_handle OCTET STRING output_token INTEGER minor_status INTERNAL NAME src_name OBJECT IDENTIFIER mech_type BOOLEAN deleg_state BOOLEAN mutual_state BOOLEAN replay_det_state BOOLEAN sequence_state BOOLEAN anon_state BOOLEAN trans_state BOOLEAN prot_ready_state BOOLEAN conf_avail BOOLEAN integ_avail INTEGER lifetime_rec CONTEXT_HANDLE delegated_cred_handle
输出整数主要\状态上下文\句柄输出\上下文\句柄八位字符串输出\令牌次要\状态内部名称src \名称对象标识符机械类型布尔删除状态布尔互态布尔重放\状态布尔序列\状态布尔非状态布尔转换状态布尔保护就绪\状态布尔配置可用布尔整数有效整数生命周期记录上下文句柄委托句柄凭据句柄
If this is the first call to GSS_Accept_sec_context in a new negotiation, then output_context_handle is stored in the server's key-mapping table as the context_handle that maps to the name of the TKEY record.
如果这是新协商中对GSS_Accept_sec_context的第一次调用，则输出_context_句柄将作为映射到TKEY记录名称的上下文_句柄存储在服务器的密钥映射表中。
The server MUST respond to the client with a TKEY query response with RCODE = NOERROR, that contains a TKEY record in the answer section.
服务器必须使用RCODE=NOERROR的TKEY查询响应响应客户端，该响应包含应答部分中的TKEY记录。
If OUTPUT major_status is one of the following errors the error field in the TKEY record set to BADKEY.
如果输出主_状态为以下错误之一，则TKEY记录中的错误字段将设置为BADKEY。
GSS_S_DEFECTIVE_TOKEN GSS_S_DEFECTIVE_CREDENTIAL GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_DUPLICATE_TOKEN GSS_S_OLD_TOKEN GSS_S_NO_CRED GSS_S_CREDENTIALS_EXPIRED GSS_S_BAD_BINDINGS GSS_S_NO_CONTEXT GSS_S_BAD_MECH GSS_S_FAILURE
GSS\U S\U缺陷\U令牌GSS\U S\U缺陷\U凭证GSS\U BAD\U SIG（GSS\U S\U BAD\U MIC）GSS\U复制\U令牌GSS\U旧令牌GSS\U无凭证GSS\U过期GSS\U BAD\U绑定GSS\U无上下文GSS\U BAD\U机械GSS\U故障
If OUTPUT major_status is set to GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED then server MUST act as described below.
如果输出主\u状态设置为GSS\u S\u COMPLETE或GSS\u CONTINUE\u Required，则服务器必须按如下所述操作。
If major_status is GSS_S_COMPLETE the server component of the negotiation is finished. If output_token is non-NULL, then it MUST be returned to the client in a Key Data field of the RDATA in TKEY. The error field in the TKEY record is set to NOERROR. The message MUST be signed with a TSIG record as described in section 5, Sending and Verifying Signed Messages. Note that server is allowed to sign a response to unsigned client's query due to modification to the RFC 2845 specified in Section 2.2 above. The context state is advanced to Context Established. Section 4.2 discusses the usage of the security context.
如果主会话状态为GSS会话完成，则协商的服务器组件完成。如果output_标记为非NULL，则必须将其返回到TKEY中RDATA的密钥数据字段中的客户端。TKEY记录中的错误字段设置为NOERROR。必须使用第5节“发送和验证签名消息”中所述的TSIG记录对消息进行签名。请注意，由于修改了上面第2.2节中指定的RFC 2845，服务器可以对未签名客户端的查询的响应进行签名。上下文状态被提升到上下文已建立状态。第4.2节讨论了安全上下文的用法。
If major_status is GSS_S_COMPLETE and output_token is NULL, then the TKEY record received from the client MUST be returned in the Answer section of the response. The message MUST be signed with a TSIG record as described in section 5, Sending and Verifying Signed Messages. Note that server is allowed to sign a response to unsigned client's query due to modification to the RFC 2845 specified in section 2.2 above. The context state is advanced to Context Established. Section 4.2 discusses the usage of the security context.
如果主_状态为GSS_S_COMPLETE且输出_令牌为NULL，则必须在响应的应答部分返回从客户端接收的TKEY记录。必须使用第5节“发送和验证签名消息”中所述的TSIG记录对消息进行签名。请注意，由于修改了上面第2.2节中指定的RFC 2845，服务器可以对未签名客户端的查询的响应进行签名。上下文状态被提升到上下文已建立状态。第4.2节讨论了安全上下文的用法。
If major_status is GSS_S_CONTINUE_NEEDED, the server component of the negotiation is not yet finished. The server responds to the TKEY query with a standard query response, placing in the answer section a TKEY record containing output_token in the Key Data RDATA field. The error field in the TKEY record is set to NOERROR. The server MUST limit the number of times that a given context is allowed to repeat, to prevent endless looping. Such limit SHOULD NOT exceed value of 10.
如果主要状态为GSS\U S\U CONTINUE\U REQUIRED，则协商的服务器组件尚未完成。服务器使用标准查询响应响应TKEY查询，在应答部分中放置一个TKEY记录，该记录包含Key Data RDATA字段中的output_标记。TKEY记录中的错误字段设置为NOERROR。服务器必须限制给定上下文允许重复的次数，以防止无休止的循环。该限值不应超过10。
In all cases, except if major_status is GSS_S_COMPLETE and output_token is NULL, other TKEY record fields MUST contain the following values:
在所有情况下，除非主要_状态为GSS_S_COMPLETE且输出_令牌为NULL，否则其他TKEY记录字段必须包含以下值：
NAME = key_name RDATA Algorithm Name = gss-tsig Mode = 3 (GSS-API negotiation - per [RFC2930]) Key Size = size of output_token in octets
名称=密钥\名称RDATA算法名称=gss tsig模式=3（gss-API协商-每[RFC2930]）密钥大小=输出\令牌大小（以八位字节为单位）
The remaining fields in the TKEY RDATA, i.e., Inception, Expiration, Error, Other Size and Data Fields, MUST be set according to [RFC2930].
TKEY RDATA中的其余字段，即起始、到期、错误、其他大小和数据字段，必须根据[RFC2930]进行设置。
When context negotiation is complete, the handle context_handle is used for the generation and verification of transaction signatures. The handle is valid for a finite amount of time determined by the underlying security mechanism. A server MAY unilaterally terminate a context at any time (see section 4.2.1).
当上下文协商完成时，handle context_handle用于生成和验证事务签名。句柄在由底层安全机制确定的有限时间内有效。服务器可在任何时候单方面终止上下文（见第4.2.1节）。
Server SHOULD limit the amount of memory used to cache established contexts.
服务器应限制用于缓存已建立上下文的内存量。
The procedures for sending and receiving signed messages are given in section 5, Sending and Verifying Signed Messages.
发送和接收签名消息的程序在第5节“发送和验证签名消息”中给出。
A server can terminate any established context at any time. The server MAY hint to the client that the context is being deleted by including a TKEY RR in a response with the Mode field set to 5, i.e., "key deletion" [RFC2930]. An active context is deleted by calling GSS_Delete_sec_context providing the associated context_handle.
服务器可以随时终止任何已建立的上下文。服务器可以通过在模式字段设置为5的响应中包括TKEY RR，即“key deletation”[RFC2930]，向客户端提示正在删除上下文。通过调用GSS_Delete_sec_context（提供关联的上下文句柄）删除活动上下文。
The procedure for sending a signature-protected message is specified in [RFC2845]. The data to be passed to the signature routine includes the whole DNS message with specific TSIG variables appended. For the exact format, see [RFC2845]. For this protocol, use the following TSIG variable values:
[RFC2845]中规定了发送受签名保护的消息的过程。要传递到签名例程的数据包括附加了特定TSIG变量的整个DNS消息。有关确切格式，请参见[RFC2845]。对于本协议，使用以下TSIG变量值：
TSIG Record NAME = key_name that identifies this context RDATA Algorithm Name = gss-tsig
TSIG记录名称=键\标识此上下文的名称RDATA算法名称=gss TSIG
Assign the remaining fields in the TSIG RDATA appropriate values as described in [RFC2845].
按照[RFC2845]中的说明，为TSIG RDATA中的其余字段分配适当的值。
The signature is generated by calling GSS_GetMIC. The following input parameters MUST be used. The outcome of the call is indicated with the output values specified below. Consult Sections 2.3.1 "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions.
签名是通过调用GSS_GetMIC生成的。必须使用以下输入参数。调用的结果用下面指定的输出值表示。有关语法定义，请参阅RFC 2743[RFC2743]的第2.3.1节“GSS_GetMIC call”。
INPUTS CONTEXT HANDLE context_handle = context_handle for key_name OCTET STRING message = outgoing message plus TSIG variables (per [RFC2845]) INTEGER qop_req = 0 (0 requests a default value). Caller MAY instead specify other valid value (for details see Section 1.2.4 in [RFC2743])
输入上下文句柄CONTEXT\u HANDLE=key\u name八进制字符串消息的上下文句柄=传出消息加TSIG变量（根据[RFC2845]）整数qop\u req=0（0请求默认值）。调用方可以指定其他有效值（有关详细信息，请参阅[RFC2743]中的第1.2.4节）
OUTPUTS INTEGER major_status INTEGER minor_status OCTET STRING per_msg_token
每\u msg\u令牌输出整数主\u状态整数次\u状态八位字节字符串
If major_status is GSS_S_COMPLETE, then signature generation succeeded. The signature in per_msg_token is inserted into the Signature field of the TSIG RR and the message is transmitted.
如果主要_状态为GSS_S_COMPLETE，则签名生成成功。将per_msg_令牌中的签名插入TSIG RR的签名字段，并传输消息。
If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED or GSS_S_FAILURE the caller MUST delete the security context, return to the uninitialized state and SHOULD negotiate a new security context, as described above in Section 3.1
如果主要状态为GSS_S_CONTEXT_EXPIRED、GSS_S_CREDENTIALS_EXPIRED或GSS_失败，则调用者必须删除安全上下文，返回未初始化状态，并应协商新的安全上下文，如上文第3.1节所述
If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry for key_name from the (target_ name, key_name, context_handle) mapping table, return to the uninitialized state and SHOULD negotiate a new security context, as described above in Section 3.1
如果MAGIR_状态为GSS_S_NO_CONTEXT，则调用者必须从（target_name、key_name、CONTEXT_handle）映射表中删除key_name条目，返回到未初始化状态，并应协商新的安全上下文，如上文第3.1节所述
If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the GSS_GetMIC call with allowed QOP value. The number of such repetitions MUST be limited to prevent infinite loops.
如果主要_状态为GSS_S_BAD_QOP，则调用者应使用允许的QOP值重复GSS_GetMIC调用。必须限制此类重复的次数，以防止出现无限循环。
The procedure for verifying a signature-protected message is specified in [RFC2845].
[RFC2845]中规定了验证受签名保护的消息的过程。
The NAME of the TSIG record determines which context_handle maps to the context that MUST be used to verify the signature. If the NAME does not map to an established context, the server MUST send a standard TSIG error response to the client indicating BADKEY in the TSIG error field (as described in [RFC2845]).
TSIG记录的名称确定哪个上下文句柄映射到必须用于验证签名的上下文。如果名称未映射到已建立的上下文，则服务器必须向客户端发送标准TSIG错误响应，在TSIG错误字段中指示BADKEY（如[RFC2845]中所述）。
For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
对于GSS算法，使用GSS_VerifyMIC验证签名：
INPUTS CONTEXT HANDLE context_handle = context_handle for key_name OCTET STRING message = incoming message plus TSIG variables (per [RFC2845]) OCTET STRING per_msg_token = Signature field from TSIG RR
输入上下文句柄CONTEXT\u HANDLE=key\u name八位字节字符串消息的上下文句柄=传入消息加上TSIG变量（per[RFC2845]）八位字节字符串per\u msg\u token=来自TSIG RR的签名字段
OUTPUTS INTEGER major_status INTEGER minor_status INTEGER qop_state
输出整数主要\ U状态整数次要\ U状态整数qop\ U状态
If major_status is GSS_S_COMPLETE, the signature is authentic and the message was delivered intact. Per [RFC2845], the timer values of the TSIG record MUST also be valid before considering the message to be authentic. The caller MUST not act on the request or response in the message until these checks are verified.
如果MAJUR_状态为GSS_S_COMPLETE，则签名是真实的，并且消息完整传递。根据[RFC2845]，TSIG记录的计时器值也必须是有效的，然后才能认为消息是真实的。在验证这些检查之前，调用者不得对消息中的请求或响应采取行动。
When a server is processing a client request, the server MUST send a standard TSIG error response to the client indicating BADKEY in the TSIG error field as described in [RFC2845], if major_status is set to one of the following values
当服务器处理客户机请求时，如果MARGER_status设置为以下值之一，则服务器必须向客户机发送标准TSIG error响应，指示[RFC2845]中所述TSIG error字段中的BADKEY
GSS_S_DEFECTIVE_TOKEN GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_DUPLICATE_TOKEN GSS_S_OLD_TOKEN GSS_S_UNSEQ_TOKEN GSS_S_GAP_TOKEN GSS_S_CONTEXT_EXPIRED GSS_S_NO_CONTEXT GSS_S_FAILURE
GSS\U S\U缺陷\U令牌GSS\U S\U BAD\U SIG（GSS\U S\U BAD\U MIC）GSS\U重复\U令牌GSS\U S\U旧令牌GSS\U USU UNSEQ\U令牌GSS\U缺口\U令牌GSS\U上下文\U过期GSS\U无上下文GSS\U故障
If the timer values of the TSIG record are invalid, the message MUST NOT be considered authentic. If this error checking fails when a server is processing a client request, the appropriate error response MUST be sent to the client according to [RFC2845].
如果TSIG记录的计时器值无效，则消息不能被视为真实消息。如果服务器处理客户端请求时此错误检查失败，则必须根据[RFC2845]向客户端发送相应的错误响应。
This Section describes an example where a Client, client.example.com, and a Server, server.example.com, establish a security context according to the algorithm described above.
本节描述了一个示例，其中客户端Client.example.com和服务器Server.example.com根据上述算法建立安全上下文。
I. Client initializes security context negotiation
I.客户端初始化安全上下文协商
To establish a security context with a server, server.example.com, the Client calls GSS_Init_sec_context with the following parameters. (Note that some INPUT and OUTPUT parameters not critical for this algorithm are not described in this example.)
要与服务器server.example.com建立安全上下文，客户端使用以下参数调用GSS_Init_sec_context。（请注意，本例中未描述对该算法不重要的一些输入和输出参数。）
CONTEXT HANDLE input_context_handle = 0 INTERNAL NAME targ_name = "DNS@server.example.com" OCTET STRING input_token = NULL BOOLEAN replay_det_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE
上下文句柄输入上下文句柄=0内部名称目标名称=”DNS@server.example.com“八位字节字符串输入\u标记=空布尔回放\u数据\u请求\u标志=真布尔相互\u请求\u标志=真
The OUTPUTS parameters returned by GSS_Init_sec_context include INTEGER major_status = GSS_S_CONTINUE_NEEDED CONTEXT HANDLE output_context_handle context_handle OCTET STRING output_token output_token BOOLEAN replay_det_state = TRUE BOOLEAN mutual_state = TRUE
GSS_Init_sec_context返回的输出参数包括整数major_status=GSS_S_CONTINUE_need context HANDLE output_context_HANDLE OCTET STRING output_token output_token BOOLEAN replay_det_state=TRUE BOOLEAN mutual_state=TRUE
Client verifies that replay_det_state and mutual_state values are TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a success OUTPUT major_status value, client stores context_handle that maps to "DNS@server.example.com" and proceeds to the next step.
客户端验证replay_det_state和mutual_state值是否为真。由于主要_状态为GSS_S_CONTINUE_NEEDED，这是一个成功输出的主要_状态值，因此客户端存储映射到的上下文_句柄“DNS@server.example.com“然后进行下一步。
II. Client sends a query with QTYPE = TKEY to server
二、客户端向服务器发送QTYPE=TKEY的查询
Client sends a query with QTYPE = TKEY for a client-generated globally unique domain name string, 789.client.example.com.server.example.com. Query contains a TKEY record in its Additional records section with the following fields. (Note that some fields not specific to this algorithm are not specified.)
客户端为客户端生成的全局唯一域名字符串789.Client.example.com.server.example.com发送QTYPE=TKEY的查询。查询在其“附加记录”部分包含一条TKEY记录，其中包含以下字段。（请注意，未指定某些不特定于此算法的字段。）
NAME = 789.client.example.com.server.example.com. RDATA Algorithm Name = gss-tsig Mode = 3 (GSS-API negotiation - per [RFC2930]) Key Size = size of output_token in octets Key Data = output_token
NAME=789.client.example.com.server.example.com。RDATA算法名称=gss tsig模式=3（gss-API协商-per[RFC2930]）密钥大小=八位字节中输出令牌的大小密钥数据=输出令牌
After the key_name 789.client.example.com.server.example.com. is generated it is stored in the client's (target_name, key_name, context_handle) mapping table.
在key_名称789.client.example.com.server.example.com之后。它被生成并存储在客户机的（target_name、key_name、context_handle）映射表中。
III. Server receives a query with QTYPE = TKEY
三、 服务器接收到一个QTYPE=TKEY的查询
When server receives a query with QTYPE = TKEY, the server verifies that Mode and Algorithm fields in the TKEY record in the Additional records section of the query are set to 3 and "gss-tsig" respectively. It finds that the key_name 789.client.example.com.server.example.com. is not listed in its (key_name, context_handle) mapping table.
当服务器接收到QTYPE=TKEY的查询时，服务器将验证查询的附加记录部分中TKEY记录中的模式和算法字段是否分别设置为3和“gss tsig”。它发现密钥名为789.client.example.com.server.example.com。未在其（键名称、上下文句柄）映射表中列出。
IV. Server calls GSS_Accept_sec_context
四、 服务器调用GSS_Accept_sec_上下文
To continue security context negotiation server calls GSS_Accept_sec_context with the following parameters. (Note that some INPUT and OUTPUT parameters not critical for this algorithm are not described in this example.)
要继续安全上下文协商，服务器使用以下参数调用GSS_Accept_sec_context。（请注意，本例中未描述对该算法不重要的一些输入和输出参数。）
INPUTS CONTEXT HANDLE input_context_handle = 0 OCTET STRING input_token = token specified in the Key field from TKEY RR (from Additional records section of the client's query)
INPUTS上下文句柄input\U CONTEXT\U HANDLE=0八位字符串input\U token=TKEY RR（来自客户端查询的附加记录部分）中的键字段中指定的令牌
The OUTPUTS parameters returned by GSS_Accept_sec_context include INTEGER major_status = GSS_S_CONTINUE_NEEDED CONTEXT_HANDLE output_context_handle context_handle OCTET STRING output_token output_token
GSS_Accept_sec_context返回的输出参数包括整数major_status=GSS_S_CONTINUE_NEEDED context_HANDLE output_context_HANDLE context_HANDLE OCTET STRING output_token output_token
Server stores the mapping of the 789.client.example.com.server.example.com. to OUTPUT context_handle in its (key_name, context_handle) mapping table.
服务器存储789.client.example.com.Server.example.com的映射。在其（键名称，上下文句柄）映射表中输出上下文句柄。
V. Server responds to the TKEY query
V.服务器响应TKEY查询
Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's call to GSS_Accept_sec_context, the server responds to the TKEY query placing in the answer section a TKEY record containing output_token in the Key Data RDATA field. The error field in the TKEY record is set to 0. The RCODE in the query response is set to NOERROR.
由于上次服务器调用GSS_Accept_sec_上下文时需要major_status=GSS_S_CONTINUE_，因此服务器响应TKEY查询，在应答部分放置一条TKEY记录，其中包含Key Data RDATA字段中的output_令牌。TKEY记录中的错误字段设置为0。查询响应中的RCODE设置为NOERROR。
VI. Client processes token returned by server
六、 客户端处理服务器返回的令牌
When the client receives the TKEY query response from the server, the client calls GSS_Init_sec_context with the following parameters. (Note that some INPUT and OUTPUT parameters not critical for this algorithm are not described in this example.)
当客户端从服务器接收到TKEY查询响应时，客户端使用以下参数调用GSS_Init_sec_上下文。（请注意，本例中未描述对该算法不重要的一些输入和输出参数。）
CONTEXT HANDLE input_context_handle = the context_handle stored in the client's mapping table entry (DNS@server.example.com., 789.client.example.com.server.example.com., context_handle) INTERNAL NAME targ_name = "DNS@server.example.com" OCTET STRING input_token = token from Key field of TKEY record from the Answer section of the server's response BOOLEAN replay_det_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE
CONTEXT HANDLE input\u CONTEXT\u HANDLE=存储在客户端映射表项中的CONTEXT\u句柄(DNS@server.example.com.，789.client.example.com.server.example.com.，context\u handle）内部名称target\u NAME=”DNS@server.example.com"八位字节字符串输入\u token=来自服务器响应的应答部分的TKEY记录的Key字段的token布尔回放\u det\u req\u flag=TRUE布尔相互\u req\u flag=TRUE
The OUTPUTS parameters returned by GSS_Init_sec_context include INTEGER major_status = GSS_S_COMPLETE CONTEXT HANDLE output_context_handle = context_handle OCTET STRING output_token = output_token BOOLEAN replay_det_state = TRUE BOOLEAN mutual_state = TRUE
GSS_Init_sec_context返回的输出参数包括整数major_status=GSS_S_COMPLETE context HANDLE output_context_HANDLE=context_HANDLE八位字符串output_token=output_token BOOLEAN replay_det_state=TRUE BOOLEAN mutual_state=TRUE
Since the major_status is set to GSS_S_COMPLETE the client side security context is established, but since the output_token is not NULL client MUST send a TKEY query to the server as described below.
由于主_状态设置为GSS_S_COMPLETE，因此建立了客户端安全上下文，但由于输出_令牌不为NULL，客户端必须向服务器发送TKEY查询，如下所述。
VII. Client sends a query with QTYPE = TKEY to server
七、客户端向服务器发送QTYPE=TKEY的查询
Client sends to the server a TKEY query for the 789.client.example.com.server.example.com. name. Query contains a TKEY record in its Additional records section with the following fields. (Note that some INPUT and OUTPUT parameters not critical to this algorithm are not described in this example.)
客户端向服务器发送789.Client.example.com.server.example.com的TKEY查询。名称查询在其“附加记录”部分包含一条TKEY记录，其中包含以下字段。（请注意，本例中未描述对该算法不重要的一些输入和输出参数。）
NAME = 789.client.example.com.server.example.com. RDATA Algorithm Name = gss-tsig Mode = 3 (GSS-API negotiation - per [RFC2930]) Key Size = size of output_token in octets Key Data = output_token
NAME=789.client.example.com.server.example.com。RDATA算法名称=gss tsig模式=3（gss-API协商-per[RFC2930]）密钥大小=八位字节中输出令牌的大小密钥数据=输出令牌
VIII. Server receives a TKEY query
八、服务器接收到一个TKEY查询
When the server receives a TKEY query, the server verifies that Mode and Algorithm fields in the TKEY record in the Additional records section of the query are set to 3 and gss-tsig, respectively. It finds that the key_name 789.client.example.com.server.example.com. is listed in its (key_name, context_handle) mapping table.
当服务器接收到TKEY查询时，服务器验证查询的附加记录部分中TKEY记录中的模式和算法字段是否分别设置为3和gss tsig。它发现密钥名为789.client.example.com.server.example.com。在其（键名称、上下文句柄）映射表中列出。
IX. Server calls GSS_Accept_sec_context
九、 服务器调用GSS_Accept_sec_上下文
To continue security context negotiation server calls GSS_Accept_sec_context with the following parameters (Note that some INPUT and OUTPUT parameters not critical for this algorithm are not described in this example)
若要继续安全上下文协商，服务器将使用以下参数调用GSS_Accept_sec_context（请注意，本示例中未描述对该算法不重要的一些输入和输出参数）
INPUTS CONTEXT HANDLE input_context_handle = context_handle from the (789.client.example.com.server.example.com., context_handle) entry in the server's mapping table OCTET STRING input_token = token specified in the Key field of TKEY RR (from Additional records Section of the client's query)
从服务器映射表中的（789.client.example.com.server.example.com.，CONTEXT\u HANDLE）项输入上下文句柄input\u CONTEXT\u HANDLE=CONTEXT\u HANDLE在TKEY RR的键字段中指定（来自客户端查询的附加记录部分）
The OUTPUTS parameters returned by GSS_Accept_sec_context include INTEGER major_status = GSS_S_COMPLETE CONTEXT_HANDLE output_context_handle = context_handle OCTET STRING output_token = NULL
GSS\u Accept\u sec\u context返回的输出参数包括整数major\u status=GSS\u S\u COMPLETE context\u HANDLE output\u context\u HANDLE=context\u HANDLE八位字符串output\u token=NULL
Since major_status = GSS_S_COMPLETE, the security context on the server side is established, but the server still needs to respond to the client's TKEY query, as described below. The security context state is advanced to Context Established.
由于major_status=GSS_S_COMPLETE，服务器端的安全上下文已建立，但服务器仍需要响应客户端的TKEY查询，如下所述。安全上下文状态被提升到已建立的上下文。
X. Server responds to the TKEY query
X.服务器响应TKEY查询
Since the major_status = GSS_S_COMPLETE in the last server's call to GSS_Accept_sec_context and the output_token is NULL, the server responds to the TKEY query placing in the answer section a TKEY record that was sent by the client in the Additional records section of the client's latest TKEY query. In addition, this server places a TSIG record in additional records section of its response. Server calls GSS_GetMIC to generate a signature to include it in the TSIG record. The server specifies the following GSS_GetMIC INPUT parameters:
由于上次服务器调用GSS_Accept_sec_上下文时，主_status=GSS_S_COMPLETE，且输出_令牌为空，因此服务器响应TKEY查询，将客户端发送的TKEY记录放在客户端最新TKEY查询的附加记录部分的应答部分。此外，此服务器在其响应的“附加记录”部分中放置TSIG记录。服务器调用GSS_GetMIC生成一个签名，将其包含在TSIG记录中。服务器指定以下GSS_GetMIC输入参数：
CONTEXT HANDLE context_handle = context_handle from the (789.client.example.com.server.example.com., context_handle) entry in the server's mapping table OCTET STRING message = outgoing message plus TSIG variables (as described in [RFC2845])
CONTEXT HANDLE CONTEXT\u HANDLE=来自服务器映射表中（789.client.example.com.server.example.com.，CONTEXT\u HANDLE）项的CONTEXT\u HANDLE八进制字符串message=传出消息加TSIG变量（如[RFC2845]中所述）
The OUTPUTS parameters returned by GSS_GetMIC include INTEGER major_status = GSS_S_COMPLETE OCTET STRING per_msg_token
GSS_GetMIC返回的输出参数包括整数major_status=GSS_S_COMPLETE OCTET STRING per_msg_token
Signature field in the TSIG record is set to per_msg_token.
TSIG记录中的签名字段设置为per_msg_令牌。
XI. Client processes token returned by server
席。客户端处理服务器返回的令牌
Client receives the TKEY query response from the server. Since the major_status was GSS_S_COMPLETE in the last client's call to GSS_Init_sec_context, the client verifies that the server's response is signed. To validate the signature, the client calls GSS_VerifyMIC with the following parameters:
客户端从服务器接收TKEY查询响应。由于上次客户端调用GSS_Init_sec_上下文时，主_状态为GSS_S_COMPLETE，因此客户端将验证服务器的响应是否已签名。为了验证签名，客户端使用以下参数调用GSS_VerifyMIC：
INPUTS CONTEXT HANDLE context_handle = context_handle for 789.client.example.com.server.example.com. key_name OCTET STRING message = incoming message plus TSIG variables (as described in [RFC2845]) OCTET STRING per_msg_token = Signature field from TSIG RR included in the server's query response
输入789.client.example.com.server.example.com的上下文句柄CONTEXT\u HANDLE=上下文句柄。key_name八进制字符串message=传入消息加上TSIG变量（如[RFC2845]中所述）每个_msg_token的八进制字符串=服务器查询响应中包含的TSIG RR的签名字段
Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the signature is validated, security negotiation is complete and the security context state is advanced to Context Established. These client and server will use the established security context to sign and validate the signatures when they exchange packets with each other until the context expires.
由于输出参数major_status=GSS_S_COMPLETE，签名被验证，安全协商完成，安全上下文状态被提升到上下文建立状态。这些客户机和服务器将使用已建立的安全上下文在相互交换数据包时对签名进行签名和验证，直到上下文过期。
This document describes a protocol for DNS security using GSS-API. The security provided by this protocol is only as effective as the security provided by the underlying GSS mechanisms.
本文档描述了使用GSS-API的DNS安全协议。本协议提供的安全性仅与底层GSS机制提供的安全性一样有效。
All the security considerations from RFC 2845, RFC 2930 and RFC 2743 apply to the protocol described in this document.
RFC 2845、RFC 2930和RFC 2743中的所有安全注意事项适用于本文档中描述的协议。
The IANA has reserved the TSIG Algorithm name gss-tsig for the use in the Algorithm fields of TKEY and TSIG resource records. This Algorithm name refers to the algorithm described in this document. The requirement to have this name registered with IANA is specified in RFC 2845.
IANA已保留TSIG算法名称gss TSIG，以便在TKEY和TSIG资源记录的算法字段中使用。此算法名称指本文档中描述的算法。RFC 2845中规定了向IANA注册此名称的要求。
The GSS API using SPNEGO [RFC2478] provides maximum flexibility to choose the underlying security mechanisms that enables security context negotiation. GSS API using SPNEGO [RFC2478] enables client and server to negotiate and choose such underlying security mechanisms on the fly. To support such flexibility, DNS clients and servers SHOULD specify SPNEGO mech_type in their GSS API calls. At
使用SPNEGO[RFC2478]的GSS API提供了最大的灵活性，可以选择支持安全上下文协商的底层安全机制。使用SPNEGO[RFC2478]的GSS API使客户机和服务器能够动态协商和选择此类底层安全机制。为了支持这种灵活性，DNS客户端和服务器应该在其GSS API调用中指定SPNEGO mech_类型。在
the same time, in order to guarantee interoperability between DNS clients and servers that support GSS-TSIG it is required that
同时，为了保证DNS客户端和支持GSS-TSIG的服务器之间的互操作性，需要
- DNS servers specify SPNEGO mech_type - GSS APIs called by DNS client support Kerberos v5 - GSS APIs called by DNS server support SPNEGO [RFC2478] and Kerberos v5.
- DNS服务器指定SPNEGO mech_类型-DNS客户端支持Kerberos v5调用的GSS API-DNS服务器支持SPNEGO[RFC2478]和Kerberos v5调用的GSS API。
In addition to these, GSS APIs used by DNS client and server MAY also support other underlying security mechanisms.
除此之外，DNS客户端和服务器使用的GSS API还可能支持其他底层安全机制。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
The authors of this document would like to thank the following people for their contribution to this specification: Chuck Chan, Mike Swift, Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake, 3rd and Erik Nordmark.
本文件的作者感谢以下人士对本规范的贡献：Chuck Chan、Mike Swift、Ram Viswanathan、Olafur Gudmundsson、Donald E.Eastlake、3rd和Erik Nordmark。
[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月。
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998.
[RFC2478]Baize，E.和D.Pinkas，“简单和受保护的GSS-API协商机制”，RFC 2478，1998年12月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface, Version 2 , Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口，版本2，更新1”，RFC 2743，2000年1月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]Eastlake 3rd，D.，“DNS密钥建立（TKEY RR）”，RFC 2930，2000年9月。
[ISO11578] "Information technology", "Open Systems Interconnection", "Remote Procedure Call", ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html.
[ISO1578]“信息技术”、“开放系统互连”、“远程过程调用”，ISO/IEC 11578:1996，http://www.iso.ch/cate/d2229.html.
[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月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025]Adams，C.，“简单公钥GSS-API机制（SPKM）”，RFC 20252996年10月。
[RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC2137]Eastlake 3rd，D.，“安全域名系统动态更新”，RFC 2137，1997年4月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake 3rd，D.，“域名系统安全扩展”，RFC 25351999年3月。
Stuart Kwan Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: skwan@microsoft.com
斯图尔特·关微软公司美国华盛顿州雷德蒙微软大道一号98052电子邮件：skwan@microsoft.com
Praerit Garg Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: praeritg@microsoft.com
Praerit Garg Microsoft Corporation One Microsoft Way Redmond，WA 98052美国电子邮件：praeritg@microsoft.com
James Gilroy Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: jamesg@microsoft.com
James Gilroy Microsoft Corporation One Microsoft Way Redmond，WA 98052美国电子邮件：jamesg@microsoft.com
Levon Esibov Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: levone@microsoft.com
Levon Esibov Microsoft Corporation One Microsoft Way Redmond，WA 98052美国电子邮件：levone@microsoft.com
Randy Hall Lucent Technologies 400 Lapp Road Malvern PA 19355 USA EMail: randyhall@lucent.com
Randy Hall-Lucent Technologies美国宾夕法尼亚州马尔文市拉普路400号邮编：19355电子邮件：randyhall@lucent.com
Jeff Westhead Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: jwesth@microsoft.com
Jeff Westhead Microsoft Corporation One Microsoft Way Redmond，WA 98052美国电子邮件：jwesth@microsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。