Network Working Group R. Atkinson
Request for Comments: 2230 NRL
Category: Informational November 1997
Network Working Group R. Atkinson
Request for Comments: 2230 NRL
Category: Informational November 1997
Key Exchange Delegation Record for the DNS
DNS的密钥交换委派记录
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
ABSTRACT
摘要
This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. It can be used with several security services. For example, a system seeking to use IP Security [RFC-1825, RFC-1826, RFC-1827] to protect IP packets for a given destination can use this mechanism to determine the set of authorised remote key exchanger systems for that destination.
本说明描述了一种机制，其中一个节点作为第二个节点的密钥交换机的授权被委派，并通过安全DNS提供。此机制仅用于安全DNS。它可以与多个安全服务一起使用。例如，试图使用IP安全[RFC-1825、RFC-1826、RFC-1827]来保护给定目的地的IP数据包的系统可以使用此机制来确定该目的地的授权远程密钥交换系统集。
The Domain Name System (DNS) is the standard way that Internet nodes locate information about addresses, mail exchangers, and other data relating to remote Internet nodes. [RFC-1035, RFC-1034] More recently, Eastlake and Kaufman have defined standards-track security extensions to the DNS. [RFC-2065] These security extensions can be used to authenticate signed DNS data records and can also be used to store signed public keys in the DNS.
域名系统（DNS）是Internet节点定位有关地址、邮件交换器和其他与远程Internet节点相关数据的信息的标准方式。[RFC-1035，RFC-1034]最近，Eastlake和Kaufman定义了DNS的标准跟踪安全扩展。[RFC-2065]这些安全扩展可用于验证签名的DNS数据记录，也可用于在DNS中存储签名的公钥。
The KX record is useful in providing an authenticatible method of delegating authorisation for one node to provide key exchange services on behalf of one or more, possibly different, nodes. This note specifies the syntax and semantics of the KX record, which is currently in limited deployment in certain IP-based networks. The
KX记录有助于为一个节点提供可认证的授权方法，以代表一个或多个（可能不同的）节点提供密钥交换服务。本说明指定了KX记录的语法和语义，该记录目前在某些基于IP的网络中的部署有限。这个
reader is assumed to be familiar with the basics of DNS, including familiarity with [RFC-1035, RFC-1034]. This document is not on the IETF standards-track and does not specify any level of standard. This document merely provides information for the Internet community.
假定读者熟悉DNS的基础知识，包括熟悉[RFC-1035，RFC-1034]。本文件不在IETF标准轨道上，也未规定任何级别的标准。本文件仅为互联网社区提供信息。
This document relies upon the concept of "identity domination". This concept might be new to the reader and so is explained in this section. The subject of endpoint naming for security associations has historically been somewhat contentious. This document takes no position on what forms of identity should be used. In a network, there are several forms of identity that are possible.
本文件所依据的是“身份支配”的概念。这一概念对读者来说可能是新概念，本节对此进行了解释。安全关联的端点命名问题在历史上一直存在争议。本文件对应使用何种形式的身份不持任何立场。在网络中，有几种形式的身份是可能的。
For example, IP Security has defined notions of identity that include: IP Address, IP Address Range, Connection ID, Fully-Qualified Domain Name (FQDN), and User with Fully Qualified Domain Name (USER FQDN).
例如，IP安全定义了身份的概念，包括：IP地址、IP地址范围、连接ID、完全限定域名（FQDN）和具有完全限定域名的用户（用户FQDN）。
A USER FQDN identity dominates a FQDN identity. A FQDN identity in turn dominates an IP Address identity. Similarly, a Connection ID dominates an IP Address identity. An IP Address Range dominates each IP Address identity for each IP address within that IP address range. Also, for completeness, an IP Address identity is considered to dominate itself.
用户FQDN标识支配FQDN标识。FQDN标识反过来支配IP地址标识。类似地，连接ID控制IP地址标识。IP地址范围支配该IP地址范围内每个IP地址的每个IP地址标识。此外，为了完整性，IP地址标识被认为是支配自身的。
This document specifies a new kind of DNS Resource Record (RR), known as the Key Exchanger (KX) record. A Key Exchanger Record has the mnemonic "KX" and the type code of 36. Each KX record is associated with a fully-qualified domain name. The KX record is modeled on the MX record described in [Part86]. Any given domain, subdomain, or host entry in the DNS might have a KX record.
本文档指定了一种新的DNS资源记录（RR），称为密钥交换器（KX）记录。密钥交换记录的助记符为“KX”，类型代码为36。每个KX记录都与一个完全限定的域名相关联。KX记录以[Part86]中描述的MX记录为模型。DNS中的任何给定域、子域或主机条目都可能有KX记录。
In these two examples, let S be the originating node and let D be the destination node. S2 is another node on the same subnet as S. D2 is another node on the same subnet as D. R1 and R2 are IPsec-capable routers. The path from S to D goes via first R1 and later R2. The return path from D to S goes via first R2 and later R1.
在这两个示例中，让我们作为起始节点，让D作为目标节点。S2是与S在同一子网上的另一个节点。D2是与D在同一子网上的另一个节点。R1和R2是支持IPsec的路由器。从S到D的路径经过第一个R1和第二个R2。从D到S的返回路径经过第一个R2和之后的R1。
IETF-standard IP Security uses unidirectional Security Associations [RFC-1825]. Therefore, a typical IP session will use a pair of related Security Associations, one in each direction. The examples below talk about how to setup an example Security Association, but in practice a pair of matched Security Associations will normally be
IETF标准IP安全使用单向安全关联[RFC-1825]。因此，典型的IP会话将使用一对相关的安全关联，每个方向一个。下面的示例讨论如何设置示例安全关联，但在实践中，通常需要一对匹配的安全关联
used.
习惯于
If neither S nor D implements IPsec, security can still be provided between R1 and R2 by building a secure tunnel. This can use either AH or ESP.
如果S和D都未实现IPsec，则仍可通过构建安全隧道在R1和R2之间提供安全性。这可以使用AH或ESP。
S ---+ +----D
| |
+- R1 -----[zero or more routers]-------R2-+
| |
S2---+ +----D2
S ---+ +----D
| |
+- R1 -----[zero or more routers]-------R2-+
| |
S2---+ +----D2
Figure 1: Network Diagram for Subnet-to-Subnet Example
图1：子网到子网示例的网络图
In this example, R1 makes the policy decision to provide the IPsec service for traffic from R1 destined for R2. Once R1 has decided that the packet from S to D should be protected, it performs a secure DNS lookup for the records associated with domain D. If R1 only knows the IP address for D, then a secure reverse DNS lookup will be necessary to determine the domain D, before that forward secure DNS lookup for records associated with domain D. If these DNS records of domain D include a KX record for the IPsec service, then R1 knows which set of nodes are authorised key exchanger nodes for the destination D.
在本例中，R1做出策略决定，为来自R1、目的地为R2的流量提供IPsec服务。一旦R1决定应保护从S到D的数据包，它将对与域D关联的记录执行安全DNS查找。如果R1只知道D的IP地址，则需要进行安全反向DNS查找以确定域D，在此之前，对与域D关联的记录进行前向安全DNS查找。如果域D的这些DNS记录包括IPsec服务的KX记录，则R1知道哪一组节点是目标D的授权密钥交换机节点。
In this example, let there be at least one KX record for D and let the most preferred KX record for D point at R2. R1 then selects a key exchanger (in this example, R2) for D from the list obtained from the secure DNS. Then R1 initiates a key management session with that key exchanger (in this example, R2) to setup an IPsec Security Association between R1 and D. In this example, R1 knows (either by seeing an outbound packet arriving from S destined to D or via other methods) that S will be sending traffic to D. In this example R1's policy requires that traffic from S to D should be segregated at least on a host-to-host basis, so R1 desires an IPsec Security Association with source identity that dominates S, proxy identity that dominates R1, and destination identity that dominates R2.
在本例中，假设D至少有一个KX记录，并且让D的最首选KX记录指向R2。R1然后从从安全DNS获得的列表中为D选择密钥交换器（在本例中为R2）。然后R1启动与该密钥交换机（在本例中为R2）的密钥管理会话，以在R1和D之间建立IPsec安全关联。在本例中，R1知道（通过查看从S到达D的出站数据包或通过其他方法）S将向D发送流量。在本例中，R1的策略要求从S到D的流量至少在主机到主机的基础上隔离，因此R1希望IPsec安全关联具有支配S的源标识、支配R1的代理标识和支配R2的目标标识。
In turn, R2 is able to authenticate the delegation of Key Exchanger authorisation for target S to R1 by making an authenticated forward DNS lookup for KX records associated with S and verifying that at least one such record points to R1. The identity S is typically given to R2 as part of the key management process between R1 and R2.
反过来，R2能够通过对与S相关联的KX记录进行经验证的前向DNS查找，并验证至少一条此类记录指向R1，从而验证目标S的密钥交换授权委托给R1。标识S通常作为R1和R2之间密钥管理过程的一部分提供给R2。
If D initially only knows the IP address of S, then it will need to perform a secure reverse DNS lookup to obtain the fully-qualified domain name for S prior to that secure forward DNS lookup.
如果D最初只知道S的IP地址，那么它需要执行安全的反向DNS查找，以在安全的正向DNS查找之前获得S的完全限定域名。
If R2 does not receive an authenticated DNS response indicating that R1 is an authorised key exchanger for S, then D will not accept the SA negotiation from R1 on behalf of identity S.
如果R2没有收到表明R1是S的授权密钥交换机的经过身份验证的DNS响应，则D将不会代表标识S接受R1的SA协商。
If the proposed IPsec Security Association is acceptable to both R1 and R2, each of which might have separate policies, then they create that IPsec Security Association via Key Management.
如果R1和R2都可以接受提议的IPsec安全关联（它们可能都有单独的策略），则它们将通过密钥管理创建该IPsec安全关联。
Note that for unicast traffic, Key Management will typically also setup a separate (but related) IPsec Security Association for the return traffic. That return IPsec Security Association will have equivalent identities. In this example, that return IPsec Security Association will have a source identity that dominates D, a proxy identity that dominates R2, and a destination identity that dominates R1.
请注意，对于单播流量，密钥管理通常还将为返回流量设置单独（但相关）的IPsec安全关联。返回的IPsec安全关联将具有等效的标识。在本例中，返回的IPsec安全关联将具有支配D的源标识、支配R2的代理标识和支配R1的目标标识。
Once the IPsec Security Association has been created, then R1 uses it to protect traffic from S destined for D via a secure tunnel that originates at R1 and terminates at R2. For the case of unicast, R2 will use the return IPsec Security Association to protect traffic from D destined for S via a secure tunnel that originates at R2 and terminates at R1.
一旦创建了IPsec安全关联，R1就会使用它通过一个从R1开始并在R2终止的安全隧道来保护来自发送给D的S的流量。对于单播的情况，R2将使用返回IPsec安全关联来保护通过安全隧道发送到S的数据流，该隧道起源于R2，终止于R1。
Consider the case where D and R1 implement IPsec, but S does not implement IPsec, which is an interesting variation on the previous example. This example is shown in Figure 2 below.
考虑D和R1实现IPSec的情况，但是S不实现IPSec，这是前面例子中的一个有趣的变化。该示例如下图2所示。
S ---+
|
+- R1 -----[zero or more routers]-------D
|
S2---+
S ---+
|
+- R1 -----[zero or more routers]-------D
|
S2---+
Figure 2: Network Diagram for Subnet-to-Host Example
图2：子网到主机示例的网络图
In this example, R1 makes the policy decision that IP Security is needed for the packet travelling from S to D. Then, R1 performs the secure DNS lookup for D and determines that D is its own key exchanger, either from the existence of a KX record for D pointing to D or from an authenticated DNS response indicating that no KX record exists for D. If R1 does not initially know the domain name of D, then prior to the above forward secure DNS lookup, R1 performs a
在此示例中，R1做出策略决定，即从S到D的数据包需要IP安全。然后，R1对D执行安全DNS查找，并确定D是其自己的密钥交换机，来自指向D的D的KX记录的存在，或者来自表明不存在D的KX记录的已验证DNS响应。如果R1最初不知道D的域名，则在上述前向安全DNS查找之前，R1执行
secure reverse DNS lookup on the IP address of D to determine the fully-qualified domain name for that IP address. R1 then initiates key management with D to create an IPsec Security Association on behalf of S.
对D的IP地址进行安全的反向DNS查找，以确定该IP地址的完全限定域名。R1然后使用D启动密钥管理，以代表S创建IPsec安全关联。
In turn, D can verify that R1 is authorised to create an IPsec Security Association on behalf of S by performing a DNS KX record lookup for target S. R1 usually provides identity S to D via key management. If D only has the IP address of S, then D will need to perform a secure reverse lookup on the IP address of S to determine domain name S prior to the secure forward DNS lookup on S to locate the KX records for S.
反过来，D可以通过对目标S执行DNS KX记录查找来验证R1是否有权代表S创建IPsec安全关联。R1通常通过密钥管理向D提供标识S。如果D只有S的IP地址，则D需要在S上进行安全正向DNS查找以定位S的KX记录之前，对S的IP地址执行安全反向查找以确定域名S。
If D does not receive an authenticated DNS response indicating that R1 is an authorised key exchanger for S, then D will not accept the SA negotiation from R1 on behalf of identity S.
如果D没有收到表明R1是S的授权密钥交换机的经过身份验证的DNS响应，则D将不会代表标识S接受R1的SA协商。
If the IPsec Security Association is successfully established between R1 and D, that IPsec Security Association has a source identity that dominates S's IP address, a proxy identity that dominates R1's IP address, and a destination identity that dominates D's IP address.
如果在R1和D之间成功建立了IPsec安全关联，则该IPsec安全关联具有支配S IP地址的源标识、支配R1 IP地址的代理标识以及支配D IP地址的目标标识。
Finally, R1 begins providing the security service for packets from S that transit R1 destined for D. When D receives such packets, D examines the SA information during IPsec input processing and sees that R1's address is listed as valid proxy address for that SA and that S is the source address for that SA. Hence, D knows at input processing time that R1 is authorised to provide security on behalf of S. Therefore packets coming from R1 with valid IP security that claim to be from S are trusted by D to have really come from S.
最后，R1开始为从S传输R1到D的数据包提供安全服务。当D接收到这些数据包时，D在IPsec输入处理期间检查SA信息，发现R1的地址列为该SA的有效代理地址，S是该SA的源地址。因此，D在输入处理时知道R1被授权代表S提供安全性。因此，D相信来自R1且具有声称来自S的有效IP安全性的数据包确实来自S。
Now consider the above case from D's perspective (i.e. where D is sending IP packets to S). This variant is sometimes known as the Mobile Host or "roadwarrier" case. The same basic concepts apply, but the details are covered here in hope of improved clarity.
现在从D的角度考虑上面的情况（即D向S发送IP分组）。这种变体有时被称为移动主机或“roadwarrier”案例。同样的基本概念也适用，但此处将详细介绍，以提高清晰度。
S ---+
|
+- R1 -----[zero or more routers]-------D
|
S2---+
S ---+
|
+- R1 -----[zero or more routers]-------D
|
S2---+
Figure 3: Network Diagram for Host-to-Subnet Example
图3：主机到子网示例的网络图
In this example, D makes the policy decision that IP Security is needed for the packets from D to S. Then D performs the secure DNS lookup for S and discovers that a KX record for S exists and points at R1. If D only has the IP address of S, then it performs a secure reverse DNS lookup on the IP address of S prior to the forward secure DNS lookup for S.
在本例中，D作出策略决定，从D到S的数据包需要IP安全。然后D对S执行安全DNS查找，发现S存在KX记录，并指向R1。如果D只有S的IP地址，则在对S进行正向安全DNS查找之前，它会对S的IP地址执行安全反向DNS查找。
D then initiates key management with R1, where R1 is acting on behalf of S, to create an appropriate Security Association. Because D is acting as its own key exchanger, R1 does not need to perform a secure DNS lookup for KX records associated with D.
然后，D启动与R1的密钥管理，其中R1代表S，以创建适当的安全关联。由于D充当自己的密钥交换器，R1不需要对与D关联的KX记录执行安全DNS查找。
D and R1 then create an appropriate IPsec Security Security Association. This IPsec Security Association is setup as a secure tunnel with a source identity that dominates D's IP Address and a destination identity that dominates R1's IP Address. Because D performs IPsec for itself, no proxy identity is needed in this IPsec Security Association. If the proxy identity is non-null in this situation, then the proxy identity must dominate D's IP Address.
然后，D和R1创建适当的IPsec安全关联。此IPsec安全关联设置为一个安全隧道，其中源标识控制D的IP地址，目标标识控制R1的IP地址。因为D本身执行IPsec，所以此IPsec安全关联中不需要代理标识。如果代理身份在这种情况下是非空的，那么代理身份必须控制D的IP地址。
Finally, D sends secured IP packets to R1. R1 receives those packets, provides IPsec input processing (including appropriate inner/outer IP address validation), and forwards valid packets along to S.
最后，D向R1发送安全IP数据包。R1接收这些数据包，提供IPsec输入处理（包括适当的内部/外部IP地址验证），并将有效数据包转发给S。
This mechanism can be extended for use with other services as well. To give some insight into other possible uses, this section discusses use of KX records in environments using a Key Distribution Center (KDC), such as Kerberos [KN93], and a possible use of KX records in conjunction with mobile nodes accessing the network via a dialup service.
此机制也可以扩展以用于其他服务。为了深入了解其他可能的用途，本节讨论了KX记录在使用密钥分发中心（KDC）的环境中的使用，如Kerberos[KN93]，以及KX记录与通过拨号服务访问网络的移动节点结合使用的可能性。
This example considers the situation of a destination node implementing IPsec that can only obtain its Security Association information from a Key Distribution Center (KDC). Let the KDC implement both the KDC protocol and also a non-KDC key management protocol (e.g. ISAKMP). In such a case, each client node of the KDC might have its own KX record pointing at the KDC so that nodes not implementing the KDC protocol can still create Security Associations with each of the client nodes of the KDC.
此示例考虑了目标节点实现IPsec的情况，该目标节点只能从密钥分发中心（KDC）获取其安全关联信息。让KDC实现KDC协议和非KDC密钥管理协议（例如ISAKMP）。在这种情况下，KDC的每个客户机节点可能都有自己的KX记录指向KDC，因此未实现KDC协议的节点仍然可以创建与KDC的每个客户机节点的安全关联。
In the event the session initiator were not using the KDC but the session target was an IPsec node that only used the KDC, the initiator would find the KX record for the target pointing at the
如果会话发起程序未使用KDC，但会话目标是仅使用KDC的IPsec节点，则发起程序将找到指向该会话的目标的KX记录
KDC. Then, the external key management exchange (e.g. ISAKMP) would be between the initiator and the KDC. Then the KDC would distribute the IPsec SA to the KDC-only IPsec node using the KDC. The IPsec traffic itself could travel directly between the initiator and the destination node.
KDC。然后，外部密钥管理交换（例如ISAKMP）将在启动器和KDC之间进行。然后KDC将使用KDC将IPSecSA分发到仅KDC的IPsec节点。IPsec通信本身可以直接在启动器和目标节点之间传输。
In the event the initiator node could only use the KDC and the target were not using the KDC, the initiator would send its request for a key to the KDC. The KDC would then initiate an external key management exchange (e.g. ISAKMP) with a node that the target's KX record(s) pointed to, on behalf of the initiator node.
如果启动器节点只能使用KDC，而目标节点没有使用KDC，则启动器将向KDC发送密钥请求。然后，KDC将代表发起方节点与目标的KX记录指向的节点发起外部密钥管理交换（例如ISAKMP）。
The target node could verify that the KDC were allowed to proxy for the initiator node by looking up the KX records for the initiator node and finding a KX record for the initiator that listed the KDC.
目标节点可以通过查找启动器节点的KX记录并查找列出KDC的启动器的KX记录来验证是否允许KDC代理启动器节点。
Then the external key exchange would be performed between the KDC and the target node. Then the KDC would distribute the resulting IPsec Security Association to the initiator. Again, IPsec traffic itself could travel directly between the initiator and the destination.
然后在KDC和目标节点之间执行外部密钥交换。然后KDC将结果IPsec安全关联分发给启动器。同样，IPsec通信本身可以直接在启动器和目标之间传输。
This example outlines a possible use of KX records with mobile hosts that dial into the network via PPP and are dynamically assigned an IP address and domain-name at dial-in time.
此示例概述了KX记录在移动主机上的可能用途，移动主机通过PPP拨号进入网络，并在拨号时动态分配IP地址和域名。
Consider the situation where each mobile node is dynamically assigned both a domain name and an IP address at the time that node dials into the network. Let the policy require that each mobile node act as its own Key Exchanger. In this case, it is important that dial-in nodes use addresses from one or more well known IP subnets or address pools dedicated to dial-in access. If that is true, then no KX record or other action is needed to ensure that each node will act as its own Key Exchanger because lack of a KX record indicates that the node is its own Key Exchanger.
考虑每个节点在节点向网络拨号时动态分配域名和IP地址的情况。让策略要求每个移动节点充当其自己的密钥交换机。在这种情况下，拨入节点必须使用一个或多个已知IP子网或专用于拨入访问的地址池中的地址。如果这是真的，则不需要KX记录或其他操作来确保每个节点将充当其自己的密钥交换器，因为缺少KX记录表明该节点是其自己的密钥交换器。
Consider the situation where the mobile node's domain name remains constant but its IP address changes. Let the policy require that each mobile node act as its own Key Exchanger. In this case, there might be operational problems when another node attempts to perform a secure reverse DNS lookup on the IP address to determine the corresponding domain name. The authenticated DNS binding (in the form of a PTR record) between the mobile node's currently assigned IP address and its permanent domain name will need to be securely updated each time the node is assigned a new IP address. There are no mechanisms for accomplishing this that are both IETF-standard and widely deployed as of the time this note was written. Use of Dynamic
考虑移动节点的域名保持不变但IP地址改变的情况。让策略要求每个移动节点充当其自己的密钥交换机。在这种情况下，当另一个节点尝试对IP地址执行安全的反向DNS查找以确定相应的域名时，可能会出现操作问题。每次为节点分配新的IP地址时，移动节点当前分配的IP地址与其永久域名之间经过身份验证的DNS绑定（以PTR记录的形式）都需要安全更新。在撰写本说明时，还没有IETF标准和广泛部署的实现这一点的机制。使用动态
DNS Update without authentication is a significant security risk and hence is not recommended for this situation.
未经身份验证的DNS更新存在严重的安全风险，因此不建议在这种情况下进行更新。
A KX record has the DNS TYPE of "KX" and a numeric value of 36. A KX record is a member of the Internet ("IN") CLASS in the DNS. Each KX record is associated with a <domain-name> entry in the DNS. A KX record has the following textual syntax:
KX记录的DNS类型为“KX”，数值为36。KX记录是DNS中Internet（“IN”）类的成员。每个KX记录都与DNS中的<domain name>条目相关联。KX记录具有以下文本语法：
<domain-name> IN KX <preference> <domain-name>
<domain-name> IN KX <preference> <domain-name>
For this description, let the <domain-name> item to the left of the "KX" string be called <domain-name 1> and the <domain-name> item to the right of the "KX" string be called <domain-name 2>. <preference> is a non-negative integer.
对于此描述，将“KX”字符串左侧的<domain name>项称为<domain name 1>，将“KX”字符串右侧的<domain name>项称为<domain name 2><首选项>是非负整数。
Internet nodes about to initiate a key exchange with <domain-name 1> should instead contact <domain-name 2> to initiate the key exchange for a security service between the initiator and <domain-name 2>. If more than one KX record exists for <domain-name 1>, then the <preference> field is used to indicate preference among the systems delegated to. Lower values are preferred over higher values. The <domain-name 2> is authorised to provide key exchange services on behalf of <domain-name 1>. The <domain-name 2> MUST have a CNAME record, an A record, or an AAAA record associated with it.
要启动与<domain name 1>的密钥交换的Internet节点应联系<domain name 2>，以启动启动器与<domain name 2>之间的安全服务密钥交换。如果<domain name 1>存在多个KX记录，则<preference>字段用于指示委派给的系统之间的首选项。较低的值优先于较高的值。<domain name 2>被授权代表<domain name 1>提供密钥交换服务。<domain name 2>必须具有与之关联的CNAME记录、a记录或AAAA记录。
The KX DNS record has the following RDATA format:
KX DNS记录具有以下RDATA格式：
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGER /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGER /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
哪里：
PREFERENCE A 16 bit non-negative integer which specifies the preference given to this RR among other KX records at the same owner. Lower values are preferred.
首选项一个16位非负整数，指定在同一所有者的其他KX记录中对该RR的首选项。首选较低的值。
EXCHANGER A <domain-name> which specifies a host willing to act as a mail exchange for the owner name.
交换器A<domain name>，指定愿意充当所有者名称邮件交换的主机。
KX records MUST cause type A additional section processing for the host specified by EXCHANGER. In the event that the host processing the DNS transaction supports IPv6, KX records MUST also cause type AAAA additional section processing.
KX记录必须对交换器指定的主机进行类型A附加段处理。在处理DNS事务的主机支持IPv6的情况下，KX记录还必须导致AAAA类型的附加节处理。
The KX RDATA field MUST NOT be compressed.
不得压缩KX RDATA字段。
KX records MUST always be signed using the method(s) defined by the DNS Security extensions specified in [RFC-2065]. All unsigned KX records MUST be ignored because of the security vulnerability caused by assuming that unsigned records are valid. All signed KX records whose signatures do not correctly validate MUST be ignored because of the potential security vulnerability in trusting an invalid KX record.
KX记录必须始终使用[RFC-2065]中指定的DNS安全扩展定义的方法进行签名。必须忽略所有未签名的KX记录，因为假定未签名记录有效会导致安全漏洞。由于信任无效KX记录可能存在安全漏洞，因此必须忽略签名未正确验证的所有签名KX记录。
KX records MUST be ignored by systems not implementing Secure DNS because such systems have no mechanism to authenticate the KX record.
未实现安全DNS的系统必须忽略KX记录，因为此类系统没有验证KX记录的机制。
If a node does not have a permanent DNS entry and some form of Dynamic DNS Update is in use, then those dynamic DNS updates MUST be fully authenticated to prevent an adversary from injecting false DNS records (especially the KX, A, and PTR records) into the Domain Name System. If false records were inserted into the DNS without being signed by the Secure DNS mechanisms, then a denial-of-service attack results. If false records were inserted into the DNS and were (erroneously) signed by the signing authority, then an active attack results.
如果节点没有永久DNS条目，并且正在使用某种形式的动态DNS更新，则必须对这些动态DNS更新进行完全身份验证，以防止对手将虚假DNS记录（尤其是KX、a和PTR记录）注入域名系统。如果在未经安全DNS机制签名的情况下将虚假记录插入DNS，则会导致拒绝服务攻击。如果将错误记录插入DNS并由签名机构（错误地）签名，则会导致主动攻击。
Myriad serious security vulnerabilities can arise if the restrictions throuhout this document are not strictly adhered to. Implementers should carefully consider the openly published issues relating to DNS security [Bell95,Vixie95] as they build their implementations. Readers should also consider the security considerations discussed in the DNS Security Extensions document [RFC-2065].
如果不严格遵守本文档中的限制，可能会出现大量严重的安全漏洞。实现者应该仔细考虑与DNS安全相关的公开发布的问题[BEL95，VIXIE995 ]，因为它们构建了它们的实现。读者还应该考虑DNS安全扩展文档[RCF-206]中讨论的安全性考虑。
[RFC-1825] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[RFC-1825]阿特金森，R.，“IP认证头”，RFC 1826，1995年8月。
[RFC-1827] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
[RFC-1827]阿特金森，R.，“IP封装安全有效载荷”，RFC 1827，1995年8月。
[Bell95] Bellovin, S., "Using the Domain Name System for System
Break-ins", Proceedings of 5th USENIX UNIX Security
Symposium, USENIX Association, Berkeley, CA, June 1995.
ftp://ftp.research.att.com/dist/smb/dnshack.ps
[Bell95] Bellovin, S., "Using the Domain Name System for System
Break-ins", Proceedings of 5th USENIX UNIX Security
Symposium, USENIX Association, Berkeley, CA, June 1995.
ftp://ftp.research.att.com/dist/smb/dnshack.ps
[RFC-2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC-2065]伊斯特莱克，D.和C.考夫曼，“域名系统安全扩展”，RFC 2065，1997年1月。
[RFC-1510] Kohl J., and C. Neuman, "The Kerberos Network Authentication Service", RFC 1510, September 1993.
[RFC-1510]Kohl J.和C.Neuman，“Kerberos网络身份验证服务”，RFC 1510，1993年9月。
[RFC-1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC-1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC-1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
the 5th USENIX UNIX Security Symposium, USENIX
Association, Berkeley, CA, June 1995.
ftp://ftp.vix.com/pri/vixie/bindsec.psf
[Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
the 5th USENIX UNIX Security Symposium, USENIX
Association, Berkeley, CA, June 1995.
ftp://ftp.vix.com/pri/vixie/bindsec.psf
ACKNOWLEDGEMENTS
致谢
Development of this DNS record was primarily performed during 1993 through 1995. The author's work on this was sponsored jointly by the Computing Systems Technology Office (CSTO) of the Advanced Research Projects Agency (ARPA) and by the Information Security Program Office (PD71E), Space & Naval Warface Systems Command (SPAWAR). In that era, Dave Mihelcic and others provided detailed review and constructive feedback. More recently, Bob Moscowitz and Todd Welch provided detailed review and constructive feedback of a work in progress version of this document.
该DNS记录的开发主要在1993年至1995年期间进行。作者在这方面的工作由高级研究计划局（ARPA）的计算系统技术办公室（CSTO）和空间与海军作战系统司令部（SPAWAR）的信息安全计划办公室（PD71E）联合赞助。在那个时代，Dave Mihelcic和其他人提供了详细的审查和建设性的反馈。最近，鲍勃·莫斯科维茨（Bob Moscowitz）和托德·韦尔奇（Todd Welch）对本文件的一个正在进行的版本进行了详细审查和建设性反馈。
AUTHOR'S ADDRESS
作者地址
Randall Atkinson Code 5544 Naval Research Laboratory 4555 Overlook Avenue, SW Washington, DC 20375-5337
Randall Atkinson代码5544海军研究实验室华盛顿西南俯瞰大道4555号，邮编20375-5337
Phone: (DSN) 354-8590 EMail: atkinson@itd.nrl.navy.mil
电话：（DSN）354-8590电子邮件：atkinson@itd.nrl.navy.mil
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
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 implmentation may be prepared, copied, published andand 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。