Network Working Group B. Wellington
Request for Comments: 3008 Nominum
Updates: 2535 November 2000
Category: Standards Track
Network Working Group B. Wellington
Request for Comments: 3008 Nominum
Updates: 2535 November 2000
Category: Standards Track
Domain Name System Security (DNSSEC) Signing Authority
域名系统安全（DNSSEC）签名机构
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records.
本文件提出了域名系统安全（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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
1 - Introduction
1-导言
This document defines additional restrictions on DNSSEC signatures (SIG) records relating to their authority to sign associated data. The intent is to establish a standard policy followed by a secure resolver; this policy can be augmented by local rules. This builds upon [RFC2535], updating section 2.3.6 of that document.
本文件规定了DNSSEC签名（SIG）记录的附加限制，这些限制与签署相关数据的权限有关。其目的是建立一个标准策略，并遵循一个安全的解析器；此策略可以通过本地规则进行扩展。这以[RFC2535]为基础，更新了该文件的第2.3.6节。
The most significant change is that in a secure zone, zone data is required to be signed by the zone key.
最重要的变化是，在安全区域中，区域数据需要由区域密钥签名。
Familiarity with the DNS system [RFC1034, RFC1035] and the DNS security extensions [RFC2535] is assumed.
假设熟悉DNS系统[RFC1034，RFC1035]和DNS安全扩展[RFC2535]。
2 - The SIG Record
2-SIG记录
A SIG record is normally associated with an RRset, and "covers" (that is, demonstrates the authenticity and integrity of) the RRset. This is referred to as a "data SIG". Note that there can be multiple SIG records covering an RRset, and the same validation process should be repeated for each of them. Some data SIGs are considered "material", that is, relevant to a DNSSEC capable resolver, and some are "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC validation. Immaterial SIGs may have application defined roles. SIG records may exist which are not bound to any RRset; these are also considered immaterial. The validation process determines which SIGs are material; once a SIG is shown to be immaterial, no other validation is necessary.
SIG记录通常与RRset关联，并且“覆盖”（即证明RRset的真实性和完整性）。这被称为“数据信号”。请注意，可以有多个SIG记录覆盖一个RRset，并且应对每个记录重复相同的验证过程。有些数据信号被认为是“重要的”，即与支持DNSSEC的分解器相关，有些数据信号是“非重要的”或“额外的DNSSEC”，因为它们与DNSSEC验证无关。非实质性SIG可能具有应用程序定义的角色。可能存在未绑定到任何RRset的SIG记录；这些也被认为是无关紧要的。验证过程确定哪些SIG是材料；一旦SIG被证明不重要，则无需进行其他验证。
SIGs may also be used for transaction security. In this case, a SIG record with a type covered field of 0 is attached to a message, and is used to protect message integrity. This is referred to as a SIG(0) [RFC2535, RFC2931].
SIG也可用于交易安全。在这种情况下，将类型覆盖字段为0的SIG记录附加到消息，并用于保护消息完整性。这被称为SIG（0）[RFC2535，RFC2931]。
The following sections define requirements for all of the fields of a SIG record. These requirements MUST be met in order for a DNSSEC capable resolver to process this signature. If any of these requirements are not met, the SIG cannot be further processed. Additionally, once a KEY has been identified as having generated this SIG, there are requirements that it MUST meet.
以下各节定义了SIG记录所有字段的要求。必须满足这些要求，才能使具有DNSSEC能力的解析器处理此签名。如果不满足这些要求中的任何一项，则无法进一步处理SIG。此外，一旦确定某个密钥已生成此SIG，则该密钥必须满足一些要求。
For a data SIG, the type covered MUST be the same as the type of data in the associated RRset. For a SIG(0), the type covered MUST be 0.
对于数据SIG，覆盖的类型必须与关联RRset中的数据类型相同。对于SIG（0），覆盖的类型必须为0。
The algorithm specified in a SIG MUST be recognized by the client, and it MUST be an algorithm that has a defined SIG rdata format.
客户机必须识别SIG中指定的算法，并且该算法必须具有已定义的SIG rdata格式。
The labels count MUST be less than or equal to the number of labels in the SIG owner name, as specified in [RFC2535, section 4.1.3].
标签数量必须小于或等于[RFC2535，第4.1.3节]中规定的SIG所有者名称中的标签数量。
The original TTL MUST be greater than or equal to the TTL of the SIG record itself, since the TTL cannot be increased by intermediate servers. This field can be ignored for SIG(0) records.
原始TTL必须大于或等于SIG记录本身的TTL，因为中间服务器不能增加TTL。对于SIG（0）记录，可以忽略此字段。
The current time at the time of validation MUST lie within the validity period bounded by the inception and expiration times.
验证时的当前时间必须在起始时间和到期时间限定的有效期内。
There are no restrictions on the Key Tag field, although it is possible that future algorithms will impose constraints.
密钥标记字段没有限制，尽管未来的算法可能会施加限制。
The signer's name field of a data SIG MUST contain the name of the zone to which the data and signature belong. The combination of signer's name, key tag, and algorithm MUST identify a zone key if the SIG is to be considered material. The only exception that the signer's name field in a SIG KEY at a zone apex SHOULD contain the parent zone's name, unless the KEY set is self-signed. This document defines a standard policy for DNSSEC validation; local policy may override the standard policy.
数据签名的签名者姓名字段必须包含数据和签名所属区域的名称。如果SIG被认为是重要的，则签名者姓名、密钥标签和算法的组合必须识别区域密钥。唯一的例外是，除非密钥集是自签名的，否则区域顶点的SIG密钥中的签名者名称字段应包含父区域的名称。本文件定义了DNSSEC验证的标准政策；本地策略可能会覆盖标准策略。
There are no restrictions on the signer field of a SIG(0) record. The combination of signer's name, key tag, and algorithm MUST identify a key if this SIG(0) is to be processed.
SIG（0）记录的签名者字段没有限制。如果要处理此SIG（0），签名者名称、密钥标记和算法的组合必须标识密钥。
There are no restrictions on the signature field. The signature will be verified at some point, but does not need to be examined prior to verification unless a future algorithm imposes constraints.
签名字段没有限制。签名将在某个点进行验证，但除非未来的算法施加约束，否则不需要在验证之前进行检查。
3 - The Signing KEY Record
3-签名密钥记录
Once a signature has been examined and its fields validated (but before the signature has been verified), the resolver attempts to locate a KEY that matches the signer name, key tag, and algorithm fields in the SIG. If one is not found, the SIG cannot be verified and is considered immaterial. If KEYs are found, several fields of the KEY record MUST have specific values if the SIG is to be considered material and authorized. If there are multiple KEYs, the following checks are performed on all of them, as there is no way to determine which one generated the signature until the verification is performed.
检查签名并验证其字段后（但在验证签名之前），解析程序将尝试查找与SIG中的签名者名称、密钥标记和算法字段匹配的密钥。如果未找到，则无法验证SIG，且认为其不重要。如果找到密钥，则如果要将SIG视为重要和授权，密钥记录的几个字段必须具有特定值。如果有多个密钥，将对所有密钥执行以下检查，因为在执行验证之前无法确定哪个密钥生成了签名。
The signing KEY record MUST have a flags value of 00 or 01 (authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. A DNSSEC resolver MUST only trust signatures generated by keys that are permitted to authenticate data.
签名密钥记录的标志值必须为00或01（允许身份验证，保密性可选）[RFC2535，3.1.2]。DNSSEC解析器只能信任由允许对数据进行身份验证的密钥生成的签名。
The interpretation of this field is considerably different for data SIGs and SIG(0) records.
对于数据SIG和SIG（0）记录，该字段的解释有很大不同。
If the SIG record covers an RRset, the name type of the associated KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section 2.3.6. The DNSSEC validation process performed by a resolver MUST ignore all keys that are not zone keys unless local policy dictates otherwise.
如果SIG记录包含RRset，则相关密钥的名称类型必须为01（区域）[RFC2535，3.1.2]。这更新了RFC 2535第2.3.6节。解析程序执行的DNSSEC验证过程必须忽略所有不是区域密钥的密钥，除非本地策略另有规定。
The primary reason that RFC 2535 allows host and user keys to generate material DNSSEC signatures is to allow dynamic update without online zone keys; that is, avoid storing private keys in an online server. The desire to avoid online signing keys cannot be achieved, though, because they are necessary to sign NXT and SOA sets [RFC3007]. These online zone keys can sign any incoming data. Removing the goal of having no online keys removes the reason to allow host and user keys to generate material signatures.
RFC 2535允许主机和用户密钥生成材料DNSSEC签名的主要原因是允许动态更新，而无需在线区域密钥；也就是说，避免将私钥存储在在线服务器中。但是，避免在线签名密钥的愿望无法实现，因为它们是签署NXT和SOA集所必需的[RFC3007]。这些联机区域密钥可以对任何传入数据进行签名。删除没有联机密钥的目标将删除允许主机密钥和用户密钥生成材质签名的原因。
Limiting material signatures to zone keys simplifies the validation process. The length of the verification chain is bounded by the name's label depth. The authority of a key is clearly defined; a resolver does not need to make a potentially complicated decision to determine whether a key has the proper authority to sign data.
将材质签名限制为区域密钥简化了验证过程。验证链的长度由名称的标签深度限定。密钥的权限已明确定义；解析程序不需要做出可能复杂的决定来确定密钥是否具有签署数据的适当权限。
Finally, there is no additional flexibility granted by allowing host/user key generated material signatures. As long as users and hosts have the ability to authenticate update requests to the primary zone server, signatures by zone keys are sufficient to protect the integrity of the data to the world at large.
最后，允许主机/用户密钥生成的材料签名没有额外的灵活性。只要用户和主机能够对主区域服务器的更新请求进行身份验证，区域密钥签名就足以保护数据对整个世界的完整性。
If the SIG record is a SIG(0) protecting a message, the name type of the associated KEY SHOULD be 00 (user) or 10 (host/entity). Transactions are initiated by a host or user, not a zone, so zone keys SHOULD not generate SIG(0) records.
如果SIG记录是保护消息的SIG（0），则关联密钥的名称类型应为00（用户）或10（主机/实体）。事务由主机或用户而不是区域启动，因此区域密钥不应生成SIG（0）记录。
A client is either explicitly executed by a user or on behalf of a host, therefore the name type of a SIG(0) generated by a client SHOULD be either user or host. A nameserver is associated with a host, and its use of SIG(0) is not associated with a particular zone, so the name type of a SIG(0) generated by a nameserver SHOULD be host.
客户端由用户或代表主机显式执行，因此客户端生成的SIG（0）的名称类型应为用户或主机。名称服务器与主机关联，并且其SIG（0）的使用与特定区域无关，因此名称服务器生成的SIG（0）的名称类型应为主机。
This document does not assign any values to the signatory field, nor require any values to be present.
本文件不向签字人字段分配任何值，也不要求提供任何值。
The signing KEY record MUST have a protocol value of 3 (DNSSEC) or 255 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC resolver MUST NOT trust any signature that it generates.
签名密钥记录的协议值必须为3（DNSSEC）或255（ALL）。如果未指定用于DNSSEC的密钥，则DNSSEC解析器不得信任其生成的任何签名。
The algorithm field MUST be identical to that of the generated SIG record, and MUST meet all requirements for an algorithm value in a SIG record.
算法字段必须与生成的SIG记录的字段相同，并且必须满足SIG记录中算法值的所有要求。
4 - Security Considerations
4-安全考虑
This document defines a standard baseline for a DNSSEC capable resolver. This is necessary for a thorough security analysis of DNSSEC, if one is to be done.
本文档定义了支持DNSSEC的解析器的标准基线。如果要对DNSSEC进行彻底的安全分析，这是必要的。
Specifically, this document places additional restrictions on SIG records that a resolver must validate before the signature can be considered worthy of DNSSEC trust. This simplifies the protocol, making it more robust and able to withstand scrutiny by the security community.
具体而言，本文件对SIG记录施加了额外的限制，在签名被认为值得DNSSEC信任之前，解析程序必须验证SIG记录。这简化了协议，使其更加健壮，能够经受安全社区的审查。
5 - Acknowledgements
5-致谢
The author would like to thank the following people for review and informative comments (in alphabetical order):
作者感谢以下人士的评论和信息性评论（按字母顺序排列）：
Olafur Gudmundsson Ed Lewis
奥拉弗尔·古德蒙德森·埃德·刘易斯
6 - References
6-参考文献
[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 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997.
[RFC2136]Vixie（Ed.），P.，Thomson，S.，Rekhter，Y.和J.Bound，“域名系统中的动态更新”，RFC 21361997年4月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000.
[RFC2931]Eastlake，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“简单安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
7 - Author's Address
7-作者地址
Brian Wellington Nominum, Inc. 950 Charter Street Redwood City, CA 94063
Brian Wellington Nominum，Inc.加利福尼亚州红木市Charter Street 950号，邮编94063
Phone: +1 650 381 6022
EMail: Brian.Wellington@nominum.com
Phone: +1 650 381 6022
EMail: Brian.Wellington@nominum.com
8 Full Copyright Statement
8完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。