Network Working Group D. Massey
Request for Comments: 3445 USC/ISI
Updates: 2535 S. Rose
Category: Standards Track NIST
December 2002
Network Working Group D. Massey
Request for Comments: 3445 USC/ISI
Updates: 2535 S. Rose
Category: Standards Track NIST
December 2002
Limiting the Scope of the KEY Resource Record (RR)
限制密钥资源记录（RR）的范围
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535.
本文档将域名系统（DNS）密钥资源记录（RR）限制为仅由域名系统安全扩展（DNSSEC）使用的密钥。原始密钥RR使用子类型存储DNSSEC密钥和任意应用程序密钥。使用相同的记录类型存储DNSSEC和应用程序密钥是错误的。本文档通过在密钥RR数据中重新定义协议八位字节字段，从密钥记录中删除应用程序密钥。由于删除了应用程序密钥，密钥记录中除一个之外的所有标志都变得不必要，并被重新定义。现有的三个应用程序密钥子类型更改为保留，但密钥记录的格式不变。本文件更新了RFC 2535。
This document limits the scope of the KEY Resource Record (RR). The KEY RR was defined in [3] and used resource record sub-typing to hold arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys. This document eliminates the existing Email, IPSEC, and TLS sub-types and prohibits the introduction of new sub-types. DNSSEC will be the only allowable sub-type for the KEY RR (hence sub-typing is essentially eliminated) and all but one of the KEY RR flags are also eliminated.
本文档限制了关键资源记录（RR）的范围。密钥RR在[3]中定义，并使用资源记录子类型来保存任意公钥，如电子邮件、IPSEC、DNSSEC和TLS密钥。本文档消除了现有的电子邮件、IPSEC和TLS子类型，并禁止引入新的子类型。DNSSEC将是键RR唯一允许的子类型（因此子类型基本上被消除），并且除一个键RR标志外，所有其他键RR标志也被消除。
Section 2 presents the motivation for restricting the KEY record and Section 3 defines the revised KEY RR. Sections 4 and 5 summarize the changes from RFC 2535 and discuss backwards compatibility. It is important to note that this document restricts the use of the KEY RR and simplifies the flags, but does not change the definition or use of DNSSEC keys.
第2节介绍了限制密钥记录的动机，第3节定义了修订的密钥RR。第4节和第5节总结了RFC2535的更改，并讨论了向后兼容性。需要注意的是，本文档限制了密钥RR的使用并简化了标志，但并未更改DNSSEC密钥的定义或使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an Algorithm type, and a Public Key. The Protocol Octet identifies the KEY RR sub-type. DNSSEC public keys are stored in the KEY RR using a Protocol Octet value of 3. Email, IPSEC, and TLS keys were also stored in the KEY RR and used Protocol Octet values of 1,2, and 4 (respectively). Protocol Octet values 5-254 were available for assignment by IANA and values were requested (but not assigned) for applications such as SSH.
密钥RR RDATA[3]由标志、协议八位字节、算法类型和公钥组成。协议八位组标识密钥RR子类型。DNSSEC公钥使用协议八位字节值3存储在密钥RR中。电子邮件、IPSEC和TLS密钥也存储在密钥RR中，使用的协议八位字节值分别为1、2和4。协议八位字节值5-254可由IANA分配，并为SSH等应用程序请求（但未分配）值。
Any use of sub-typing has inherent limitations. A resolver can not specify the desired sub-type in a DNS query and most DNS operations apply only to resource records sets. For example, a resolver can not directly request the DNSSEC subtype KEY RRs. Instead, the resolver has to request all KEY RRs associated with a DNS name and then search the set for the desired DNSSEC sub-type. DNSSEC signatures also apply to the set of all KEY RRs associated with the DNS name, regardless of sub-type.
任何子类型的使用都有其固有的局限性。解析程序无法在DNS查询中指定所需的子类型，大多数DNS操作仅适用于资源记录集。例如，解析程序不能直接请求DNSSEC子类型密钥RRs。相反，解析程序必须请求与DNS名称关联的所有密钥RRs，然后在集合中搜索所需的DNSSEC子类型。DNSSEC签名也适用于与DNS名称相关联的所有密钥RRs集，而不考虑子类型。
In the case of the KEY RR, the inherent sub-type limitations are exacerbated since the sub-type is used to distinguish between DNSSEC keys and application keys. DNSSEC keys and application keys differ in virtually every respect and Section 2.1 discusses these differences in more detail. Combining these very different types of keys into a single sub-typed resource record adds unnecessary complexity and increases the potential for implementation and deployment errors. Limited experimental deployment has shown that application keys stored in KEY RRs are problematic.
在密钥RR的情况下，由于子类型用于区分DNSSEC密钥和应用程序密钥，因此固有的子类型限制会加剧。DNSSEC密钥和应用程序密钥几乎在各个方面都不同，第2.1节更详细地讨论了这些差异。将这些不同类型的密钥组合到一个子类型的资源记录中会增加不必要的复杂性，并增加实现和部署错误的可能性。有限的实验部署表明，存储在密钥RRs中的应用程序密钥存在问题。
This document addresses these issues by removing all application keys from the KEY RR. Note that the scope of this document is strictly limited to the KEY RR and this document does not endorse or restrict the storage of application keys in other, yet undefined, resource records.
本文档通过从密钥RR中删除所有应用程序密钥来解决这些问题。请注意，本文档的范围严格限于密钥RR，并且本文档不认可或限制在其他未定义的资源记录中存储应用程序密钥。
DNSSEC keys are an essential part of the DNSSEC protocol and are used by both name servers and resolvers in order to perform DNS tasks. A DNS zone key, used to sign and authenticate RR sets, is the most common example of a DNSSEC key. SIG(0) [4] and TKEY [3] also use DNSSEC keys.
DNSSEC密钥是DNSSEC协议的重要组成部分，名称服务器和解析程序都使用它来执行DNS任务。用于对RR集进行签名和身份验证的DNS区域密钥是DNSSEC密钥的最常见示例。SIG（0）[4]和TKEY[3]也使用DNSSEC键。
Application keys such as Email keys, IPSEC keys, and TLS keys are simply another type of data. These keys have no special meaning to a name server or resolver.
应用程序密钥（如电子邮件密钥、IPSEC密钥和TLS密钥）只是另一种类型的数据。这些密钥对名称服务器或解析程序没有特殊意义。
The following table summarizes some of the differences between DNSSEC keys and application keys:
下表总结了DNSSEC键和应用程序键之间的一些差异：
1. They serve different purposes.
1. 它们有不同的用途。
2. They are managed by different administrators.
2. 它们由不同的管理员管理。
3. They are authenticated according to different rules.
3. 它们根据不同的规则进行身份验证。
4. Nameservers use different rules when including them in responses.
4. 名称服务器在响应中包含它们时使用不同的规则。
5. Resolvers process them in different ways.
5. 解析程序以不同的方式处理它们。
6. Faults/key compromises have different consequences.
6. 故障/关键妥协会产生不同的后果。
1. The purpose of a DNSSEC key is to sign resource records associated with a DNS zone (or generate DNS transaction signatures in the case of SIG(0)/TKEY). But the purpose of an application key is specific to the application. Application keys, such as PGP/email, IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and the purpose and proper use of application keys is outside the scope of DNS.
1. DNSSEC密钥的用途是对与DNS区域相关联的资源记录进行签名（或者在SIG（0）/TKEY的情况下生成DNS事务签名）。但是应用程序密钥的用途是特定于应用程序的。应用程序密钥（如PGP/email、IPSEC、TLS和SSH密钥）不是任何区域的强制部分，应用程序密钥的用途和正确使用不在DNS的范围内。
2. DNSSEC keys are managed by DNS administrators, but application keys are managed by application administrators. The DNS zone administrator determines the key lifetime, handles any suspected key compromises, and manages any DNSSEC key changes. Likewise, the application administrator is responsible for the same functions for the application keys related to the application. For example, a user typically manages her own PGP key and a server manages its own TLS key. Application key management tasks are outside the scope of DNS administration.
2. DNSSEC密钥由DNS管理员管理，但应用程序密钥由应用程序管理员管理。DNS区域管理员确定密钥生存期，处理任何可疑的密钥泄露，并管理任何DNSSEC密钥更改。同样，应用程序管理员负责与应用程序相关的应用程序密钥的相同功能。例如，用户通常管理自己的PGP密钥，服务器管理自己的TLS密钥。应用程序密钥管理任务不在DNS管理范围内。
3. DNSSEC zone keys are used to authenticate application keys, but by definition, application keys are not allowed to authenticate DNS zone keys. A DNS zone key is either configured as a trusted key or authenticated by constructing a chain of trust in the DNS hierarchy. To participate in the chain of trust, a DNS zone needs to exchange zone key information with its parent zone [3]. Application keys are not configured as trusted keys in the DNS and are never part of any DNS chain of trust. Application key data is not needed by the parent and does not need to be exchanged with the parent zone for secure DNS resolution to work. A resolver considers an application key RRset as authenticated DNS information if it has a valid signature from the local DNS zone keys, but applications could impose additional security requirements before the application key is accepted as authentic for use with the application.
3. DNSSEC区域密钥用于验证应用程序密钥，但根据定义，不允许应用程序密钥验证DNS区域密钥。DNS区域密钥可以配置为受信任密钥，也可以通过在DNS层次结构中构建信任链进行身份验证。要参与信任链，DNS区域需要与其父区域交换区域密钥信息[3]。应用程序密钥在DNS中未配置为受信任密钥，并且从来不是任何DNS信任链的一部分。父级不需要应用程序密钥数据，也不需要与父级区域交换应用程序密钥数据，以便安全DNS解析工作。如果应用程序密钥RRset具有来自本地DNS区域密钥的有效签名，则解析程序将其视为经过身份验证的DNS信息，但在应用程序密钥被接受为可与应用程序一起使用的真实密钥之前，应用程序可能会施加额外的安全要求。
4. It may be useful for nameservers to include DNS zone keys in the additional section of a response, but application keys are typically not useful unless they have been specifically requested. For example, it could be useful to include the example.com zone key along with a response that contains the www.example.com A record and SIG record. A secure resolver will need the example.com zone key in order to check the SIG and authenticate the www.example.com A record. It is typically not useful to include the IPSEC, email, and TLS keys along with the A record. Note that by placing application keys in the KEY record, a resolver would need the IPSEC, email, TLS, and other key associated with example.com if the resolver intends to authenticate the example.com zone key (since signatures only apply to the entire KEY RR set). Depending on the number of protocols involved, the KEY RR set could grow unwieldy for resolvers, and DNS administrators to manage.
4. 名称服务器在响应的附加部分中包含DNS区域密钥可能很有用，但应用程序密钥通常不有用，除非它们已被特别请求。例如，在包含www.example.com a记录和SIG记录的响应中包含example.com区域键可能会很有用。安全解析程序需要example.com区域密钥，以便检查SIG并验证www.example.com A记录。通常，在记录中包含IPSEC、电子邮件和TLS密钥是不有用的。请注意，通过在密钥记录中放置应用程序密钥，如果解析程序打算对example.com区域密钥进行身份验证，则解析程序将需要IPSEC、电子邮件、TLS和其他与example.com关联的密钥（因为签名仅适用于整个密钥集）。根据所涉及的协议数量，密钥RR集可能会变得难以管理，无法由解析程序和DNS管理员进行管理。
5. DNS zone keys require special handling by resolvers, but application keys are treated the same as any other type of DNS data. The DNSSEC keys are of no value to end applications, unless the applications plan to do their own DNS authentication. By definition, secure resolvers are not allowed to use application keys as part of the authentication process. Application keys have no unique meaning to resolvers and are only useful to the application requesting the key. Note that if sub-types are used to identify the application key, then either the interface to the resolver needs to specify the sub-type or the application needs to be able to accept all KEY RRs and pick out the desired sub-type.
5. DNS区域密钥需要解析程序进行特殊处理，但应用程序密钥的处理方式与任何其他类型的DNS数据相同。DNSSEC密钥对终端应用程序没有任何价值，除非应用程序计划进行自己的DNS身份验证。根据定义，安全解析程序不允许在身份验证过程中使用应用程序密钥。应用程序密钥对解析程序没有唯一意义，仅对请求密钥的应用程序有用。请注意，如果使用子类型来标识应用程序密钥，则解析程序的接口需要指定子类型，或者应用程序需要能够接受所有密钥RRs并选择所需的子类型。
6. A fault or compromise of a DNS zone key can lead to invalid or forged DNS data, but a fault or compromise of an application key should have no impact on other DNS data. Incorrectly adding or changing a DNS zone key can invalidate all of the DNS data in the zone and in all of its subzones. By using a compromised key, an
6. DNS区域密钥的错误或泄露可能导致无效或伪造的DNS数据，但应用程序密钥的错误或泄露不应对其他DNS数据产生影响。错误地添加或更改DNS区域密钥会使区域及其所有子区域中的所有DNS数据无效。通过使用泄露的密钥
attacker can forge data from the effected zone and for any of its sub-zones. A fault or compromise of an application key has implications for that application, but it should not have an impact on the DNS. Note that application key faults and key compromises can have an impact on the entire DNS if the application key and DNS zone keys are both stored in the KEY RR.
攻击者可以伪造受影响区域及其任何子区域的数据。应用程序密钥的错误或泄露对该应用程序有影响，但不应影响DNS。请注意，如果应用程序密钥和DNS区域密钥都存储在密钥RR中，则应用程序密钥故障和密钥泄露可能会对整个DNS产生影响。
In summary, DNSSEC keys and application keys differ in most every respect. DNSSEC keys are an essential part of the DNS infrastructure and require special handling by DNS administrators and DNS resolvers. Application keys are simply another type of data and have no special meaning to DNS administrators or resolvers. These two different types of data do not belong in the same resource record.
总之，DNSSEC密钥和应用程序密钥在大多数方面都不同。DNSSEC密钥是DNS基础设施的重要组成部分，需要DNS管理员和DNS解析程序进行特殊处理。应用程序密钥只是另一种数据类型，对DNS管理员或解析程序没有特殊意义。这两种不同类型的数据不属于同一资源记录。
The KEY RR uses type 25 and is used as resource record for storing DNSSEC keys. The RDATA for a KEY RR consists of flags, a protocol octet, the algorithm number octet, and the public key itself. The format is as follows:
密钥RR使用类型25，并用作存储DNSSEC密钥的资源记录。密钥RR的RDATA由标志、协议八位字节、算法编号八位字节和公钥本身组成。格式如下:
---------------------------------------------------------------------
---------------------------------------------------------------------
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEY RR Format
键RR格式
---------------------------------------------------------------------
---------------------------------------------------------------------
In the flags field, all bits except bit 7 are reserved and MUST be zero. If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone key. If Bit 7 is set to 0, the KEY is not a zone key. SIG(0)/TKEY are examples of DNSSEC keys that are not zone keys.
在标志字段中，除第7位外的所有位都保留，并且必须为零。如果位7（区域位）设置为1，则该密钥为DNS区域密钥。如果位7设置为0，则该键不是区域键。SIG（0）/TKEY是非区域键的DNSSEC键的示例。
The protocol field MUST be set to 3.
协议字段必须设置为3。
The algorithm and public key fields are not changed.
算法和公钥字段不变。
The KEY RDATA format is not changed.
密钥RDATA格式未更改。
All flags except for the zone key flag are eliminated:
除区域键标志外的所有标志均被消除：
The A/C bits (bits 0 and 1) are eliminated. They MUST be set to 0 and MUST be ignored by the receiver.
消除A/C位（位0和1）。它们必须设置为0，并且必须被接收器忽略。
The extended flags bit (bit 3) is eliminated. It MUST be set to 0 and MUST be ignored by the receiver.
消除扩展标志位（位3）。它必须设置为0，并且必须被接收器忽略。
The host/user bit (bit 6) is eliminated. It MUST be set to 0 and MUST be ignored by the receiver.
删除主机/用户位（位6）。它必须设置为0，并且必须被接收器忽略。
The zone bit (bit 7) remains unchanged.
区域位（位7）保持不变。
The signatory field (bits 12-15) are eliminated by [5]. They MUST be set to 0 and MUST be ignored by the receiver.
签字人字段（第12-15位）由[5]删除。它们必须设置为0，并且必须被接收器忽略。
Bits 2,4,5,8,9,10,11 remain unchanged. They are reserved, MUST be set to zero and MUST be ignored by the receiver.
位2,4,5,8,9,10,11保持不变。它们是保留的，必须设置为零，并且必须被接收器忽略。
Assignment of any future KEY RR Flag values requires a standards action.
任何未来键RR标志值的分配都需要标准操作。
All Protocol Octet values except DNSSEC (3) are eliminated:
删除除DNSSEC（3）之外的所有协议八位字节值：
Value 1 (Email) is renamed to RESERVED.
值1（电子邮件）重命名为保留。
Value 2 (IPSEC) is renamed to RESERVED.
值2（IPSEC）重命名为保留。
Value 3 (DNSSEC) is unchanged.
值3（DNSSEC）不变。
Value 4 (TLS) is renamed to RESERVED.
值4（TLS）重命名为保留。
Value 5-254 remains unchanged (reserved).
值5-254保持不变（保留）。
Value 255 (ANY) is renamed to RESERVED.
值255（任意）重命名为保留。
The authoritative data for a zone MUST NOT include any KEY records with a protocol octet other than 3. The registry maintained by IANA for protocol values is closed for new assignments.
区域的权威数据不得包括协议八位字节为3以外的任何密钥记录。IANA为协议值维护的注册表因新分配而关闭。
Name servers and resolvers SHOULD accept KEY RR sets that contain KEY RRs with a value other than 3. If out of date DNS zones contain deprecated KEY RRs with a protocol octet value other than 3, then simply dropping the deprecated KEY RRs from the KEY RR set would
名称服务器和解析程序应接受包含值不是3的密钥RRs的密钥RR集。如果过期的DNS区域包含不推荐使用的密钥RRs，其协议八位字节值不是3，则只需从密钥RR集中删除不推荐使用的密钥RRs即可
invalidate any associated SIG record(s) and could create caching consistency problems. Note that KEY RRs with a protocol octet value other than 3 MUST NOT be used to authenticate DNS data.
使任何相关的SIG记录无效，并可能导致缓存一致性问题。请注意，协议八位字节值不是3的密钥RRs不得用于验证DNS数据。
The algorithm and public key fields are not changed.
算法和公钥字段不变。
DNSSEC zone KEY RRs are not changed and remain backwards compatible. A properly formatted RFC 2535 zone KEY would have all flag bits, other than the Zone Bit (Bit 7), set to 0 and would have the Protocol Octet set to 3. This remains true under the restricted KEY.
DNSSEC区域密钥RRs未更改，并保持向后兼容。正确格式化的RFC 2535区域密钥将所有标志位（区域位（位7）除外）设置为0，并将协议八位组设置为3。在受限密钥下仍然如此。
DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible, but the distinction between host and user keys (flag bit 6) is lost.
DNSSEC非区域密钥RRs（SIG（0）/TKEY密钥）向后兼容，但主机密钥和用户密钥（标志位6）之间的区别丢失。
No backwards compatibility is provided for application keys. Any Email, IPSEC, or TLS keys are now deprecated. Storing application keys in the KEY RR created problems such as keys at the apex and large RR sets and some change in the definition and/or usage of the KEY RR would have been required even if the approach described here were not adopted.
没有为应用程序密钥提供向后兼容性。现在不推荐使用任何电子邮件、IPSEC或TLS密钥。将应用程序密钥存储在密钥RR中会产生问题，例如顶点处的密钥和较大的RR集，并且即使未采用此处描述的方法，也需要对密钥RR的定义和/或使用进行一些更改。
Overall, existing nameservers and resolvers will continue to correctly process KEY RRs with a sub-type of DNSSEC keys.
总的来说，现有名称服务器和解析程序将继续使用DNSSEC密钥的子类型正确处理密钥RRs。
The scope of this document is strictly limited to the KEY record. This document prohibits storing application keys in the KEY record, but it does not endorse or restrict the storing application keys in other record types. Other documents can describe how DNS handles application keys.
本文件的范围严格限于关键记录。本文件禁止在密钥记录中存储应用程序密钥，但不认可或限制在其他记录类型中存储应用程序密钥。其他文档可以描述DNS如何处理应用程序密钥。
RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet values. Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and values 5-254 were made available for assignment by IANA. This document makes two sets of changes to this registry.
RFC 2535为DNS密钥RR协议八位字节值创建了IANA注册表。值1、2、3、4和255由RFC 2535分配，值5-254由IANA分配。此文档对此注册表进行了两组更改。
First, this document re-assigns DNS KEY RR Protocol Octet values 1, 2, 4, and 255 to "reserved". DNS Key RR Protocol Octet Value 3 remains unchanged as "DNSSEC".
首先，本文档将DNS密钥RR协议八位字节值1、2、4和255重新分配给“保留”。DNS密钥RR协议八位字节值3保持不变，为“DNSSEC”。
Second, new values are no longer available for assignment by IANA and this document closes the IANA registry for DNS KEY RR Protocol Octet Values. Assignment of any future KEY RR Protocol Octet values requires a standards action.
其次，新值不再可由IANA分配，本文档将关闭DNS密钥RR协议八位字节值的IANA注册表。任何未来密钥RR协议八位字节值的分配都需要标准操作。
This document eliminates potential security problems that could arise due to the coupling of DNS zone keys and application keys. Prior to the change described in this document, a correctly authenticated KEY set could include both application keys and DNSSEC keys. This document restricts the KEY RR to DNS security usage only. This is an attempt to simplify the security model and make it less user-error prone. If one of the application keys is compromised, it could be used as a false zone key to create false DNS signatures (SIG records). Resolvers that do not carefully check the KEY sub-type could believe these false signatures and incorrectly authenticate DNS data. With this change, application keys cannot appear in an authenticated KEY set and this vulnerability is eliminated.
本文档消除了由于DNS区域密钥和应用程序密钥耦合而可能出现的潜在安全问题。在本文档中描述的更改之前，经过正确身份验证的密钥集可以包括应用程序密钥和DNSSEC密钥。本文档仅将密钥RR限制为DNS安全使用。这是一种简化安全模型并减少用户错误倾向的尝试。如果其中一个应用程序密钥被泄露，它可以用作假区域密钥来创建假DNS签名（SIG记录）。未仔细检查密钥子类型的解析程序可能会相信这些虚假签名，并错误地验证DNS数据。通过此更改，应用程序密钥无法出现在经过身份验证的密钥集中，并且此漏洞已被消除。
The format and correct usage of DNSSEC keys is not changed by this document and no new security considerations are introduced.
本文档未更改DNSSEC密钥的格式和正确用法，也未引入新的安全注意事项。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[2] Eastlake，D.，“域名系统安全扩展”，RFC 25351999年3月。
[3] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[3] 伊斯特莱克，D.，“DNS密钥建立（TKEY RR）”，RFC 2930，2000年9月。
[4] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000.
[4] Eastlake，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[5] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[5] 威灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
Dan Massey USC Information Sciences Institute 3811 N. Fairfax Drive Arlington, VA 22203 USA
Dan Massey USC信息科学研究所美国弗吉尼亚州阿灵顿费尔法克斯大道北3811号22203
EMail: masseyd@isi.edu
EMail: masseyd@isi.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-3460 USA
斯科特·罗斯国家标准与技术研究所美国马里兰州盖瑟斯堡100号局道20899-3460
EMail: scott.rose@nist.gov
EMail: scott.rose@nist.gov
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。