Network Working Group O. Gudmundsson
Request for Comments: 3658 December 2003
Updates: 3090, 3008, 2535, 1035
Category: Standards Track
Network Working Group O. Gudmundsson
Request for Comments: 3658 December 2003
Updates: 3090, 3008, 2535, 1035
Category: Standards Track
Delegation Signer (DS) Resource Record (RR)
委托签名者（DS）资源记录（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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference.
委派签名者（DS）资源记录（RR）插入到区域切割处（即委派点），以指示委派区域已进行数字签名，并且委派区域将指示的密钥识别为委派区域的有效区域密钥。DS RR是对DNS安全扩展定义的修改，出于操作考虑。其目的是将此资源记录用作有关委托的明确声明，而不是依赖于推断。
This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.
本文档定义了DS RR，给出了如何使用它的示例，并描述了对解析器的影响。此更改与RFC 2535不向后兼容。本文件更新了RFC 1035、RFC 2535、RFC 3008和RFC 3090。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Reserved Words. . . . . . . . . . . . . . . . . . . . . 4
2. Specification of the Delegation key Signer. . . . . . . . . . 4
2.1. Delegation Signer Record Model. . . . . . . . . . . . . 4
2.2. Protocol Change . . . . . . . . . . . . . . . . . . . . 5
2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations
at Delegation Points . . . . . . . . . . . . . 6
2.2.1.1. Special processing for DS queries. . . 6
2.2.1.2. Special processing when child and an
ancestor share nameserver. . . . . . . 7
2.2.1.3. Modification on use of KEY RR in the
construction of Responses. . . . . . . 8
2.2.2. Signer's Name (replaces RFC3008 section 2.7). . 9
2.2.3. Changes to RFC 3090 . . . . . . . . . . . . . . 9
2.2.3.1. RFC 3090: Updates to section 1:
Introduction . . . . . . . . . . . . . 9
2.2.3.2. RFC 3090 section 2.1: Globally
Secured. . . . . . . . . . . . . . . . 10
2.2.3.3. RFC 3090 section 3: Experimental
Status . . . . . . . . . . . . . . . . 10
2.2.4. NULL KEY elimination. . . . . . . . . . . . . . 10
2.3. Comments on Protocol Changes. . . . . . . . . . . . . . 10
2.4. Wire Format of the DS record. . . . . . . . . . . . . . 11
2.4.1. Justifications for Fields . . . . . . . . . . . 12
2.5. Presentation Format of the DS Record. . . . . . . . . . 12
2.6. Transition Issues for Installed Base. . . . . . . . . . 12
2.6.1. Backwards compatibility with RFC 2535 and
RFC 1035. . . . . . . . . . . . . . . . . . . . 12
2.7. KEY and corresponding DS record example . . . . . . . . 13
3. Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. DS Example" . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Resolver Cost Estimates for DS Records" . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Intellectual Property Statement . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References. . . . . . . . . . . . . . . . . . 17
8.2. Informational References. . . . . . . . . . . . . . . . 17
9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Reserved Words. . . . . . . . . . . . . . . . . . . . . 4
2. Specification of the Delegation key Signer. . . . . . . . . . 4
2.1. Delegation Signer Record Model. . . . . . . . . . . . . 4
2.2. Protocol Change . . . . . . . . . . . . . . . . . . . . 5
2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations
at Delegation Points . . . . . . . . . . . . . 6
2.2.1.1. Special processing for DS queries. . . 6
2.2.1.2. Special processing when child and an
ancestor share nameserver. . . . . . . 7
2.2.1.3. Modification on use of KEY RR in the
construction of Responses. . . . . . . 8
2.2.2. Signer's Name (replaces RFC3008 section 2.7). . 9
2.2.3. Changes to RFC 3090 . . . . . . . . . . . . . . 9
2.2.3.1. RFC 3090: Updates to section 1:
Introduction . . . . . . . . . . . . . 9
2.2.3.2. RFC 3090 section 2.1: Globally
Secured. . . . . . . . . . . . . . . . 10
2.2.3.3. RFC 3090 section 3: Experimental
Status . . . . . . . . . . . . . . . . 10
2.2.4. NULL KEY elimination. . . . . . . . . . . . . . 10
2.3. Comments on Protocol Changes. . . . . . . . . . . . . . 10
2.4. Wire Format of the DS record. . . . . . . . . . . . . . 11
2.4.1. Justifications for Fields . . . . . . . . . . . 12
2.5. Presentation Format of the DS Record. . . . . . . . . . 12
2.6. Transition Issues for Installed Base. . . . . . . . . . 12
2.6.1. Backwards compatibility with RFC 2535 and
RFC 1035. . . . . . . . . . . . . . . . . . . . 12
2.7. KEY and corresponding DS record example . . . . . . . . 13
3. Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. DS Example" . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Resolver Cost Estimates for DS Records" . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Intellectual Property Statement . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References. . . . . . . . . . . . . . . . . . 17
8.2. Informational References. . . . . . . . . . . . . . . . 17
9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
Familiarity with the DNS system [RFC1035], DNS security extensions [RFC2535], and DNSSEC terminology [RFC3090] is important.
熟悉DNS系统[RFC1035]、DNS安全扩展[RFC2535]和DNSSEC术语[RFC3090]非常重要。
Experience shows that when the same data can reside in two administratively different DNS zones, the data frequently gets out of sync. The presence of an NS RRset in a zone anywhere other than at the apex indicates a zone cut or delegation. The RDATA of the NS RRset specifies the authoritative nameservers for the delegated or "child" zone. Based on actual measurements, 10-30% of all delegations on the Internet have differing NS RRsets at parent and child. There are a number of reasons for this, including a lack of communication between parent and child and bogus name servers being listed to meet registry requirements.
经验表明，当相同的数据可以驻留在两个管理不同的DNS区域中时，数据常常会不同步。在顶点以外的任何区域中出现NS RRset表示区域切割或委派。NS RRset的RDATA为委托区域或“子”区域指定权威名称服务器。根据实际测量，互联网上10-30%的代表团在家长和孩子身上有不同的RRNS集。造成这种情况的原因有很多，包括父服务器和子服务器之间缺乏通信，以及为满足注册表要求而列出的假名称服务器。
DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs to have its KEY RRset signed by its parent to create a verifiable chain of KEYs. There has been some debate on where the signed KEY RRset should reside, whether at the child [RFC2535] or at the parent. If the KEY RRset resides at the child, maintaining the signed KEY RRset in the child requires frequent two-way communication between the two parties. First, the child transmits the KEY RRset to the parent and then the parent sends the signature(s) to the child. Storing the KEY RRset at the parent was thought to simplify the communication.
DNSSEC[RFC2535、RFC3008、RFC3090]指定子区域需要其父区域对其密钥RRset进行签名，以创建可验证的密钥链。关于签名密钥RRset应该驻留在何处，无论是在子[RFC2535]还是在父级，都存在一些争论。如果密钥RRset驻留在子级，则在子级中维护签名密钥RRset需要双方之间频繁的双向通信。首先，子系统将密钥集传输给父系统，然后父系统将签名发送给子系统。将密钥集存储在父级被认为可以简化通信。
DNSSEC [RFC2535] requires that the parent store a NULL KEY record for an unsecure child zone to indicate that the child is unsecure. A NULL KEY record is a waste: an entire signed RRset is used to communicate effectively one bit of information - that the child is unsecure. Chasing down NULL KEY RRsets complicates the resolution process in many cases, because nameservers for both parent and child need to be queried for the KEY RRset if the child nameserver does not return it. Storing the KEY RRset only in the parent zone simplifies this and would allow the elimination of the NULL KEY RRsets entirely. For large delegation zones, the cost of NULL keys is a significant barrier to deployment.
DNSSEC[RFC2535]要求父级存储不安全子区域的空密钥记录，以指示该子区域不安全。一个空密钥记录是一种浪费：一个完整的有符号RRset被用来有效地传递一位信息，即子项是不安全的。在许多情况下，查找空密钥RRset会使解析过程复杂化，因为如果子名称服务器不返回密钥RRset，则需要查询父级和子级的名称服务器以查找该密钥RRset。仅在父区域中存储密钥RRset简化了这一过程，并允许完全消除空密钥RRset。对于大型委派区域，空密钥的成本是部署的一个重大障碍。
Prior to the restrictions imposed by RFC 3445 [RFC3445], another implication of the DNSSEC key model is that the KEY record could be used to store public keys for other protocols in addition to DNSSEC keys. There are a number of potential problems with this, including:
在RFC 3445[RFC3445]施加限制之前，DNSSEC密钥模型的另一个含义是密钥记录可用于存储除DNSSEC密钥外的其他协议的公钥。这方面存在许多潜在问题，包括：
1. The KEY RRset can become quite large if many applications and protocols store their keys at the zone apex. Possible protocols are IPSEC, HTTP, SMTP, SSH and others that use public key cryptography.
1. 如果许多应用程序和协议将密钥存储在区域顶点，则密钥RRset可能会变得相当大。可能的协议有IPSEC、HTTP、SMTP、SSH和其他使用公钥加密的协议。
2. The KEY RRset may require frequent updates.
2. 密钥RRset可能需要频繁更新。
3. The probability of compromised or lost keys, which trigger emergency key roll-over procedures, increases.
3. 触发紧急钥匙翻滚程序的钥匙受损或丢失的概率增加。
4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone keys.
4. 家长可以拒绝使用非DNSSEC区域密钥对密钥RRSET进行签名。
5. The parent may not meet the child's expectations of turnaround time for resigning the KEY RRset.
5. 父母可能无法满足孩子对辞去关键RRset的周转时间的期望。
Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
基于这些原因,，SIG@parent不比SIG好吗/KEY@Child.
The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED", "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“可”、“不可”、“必须”、“不得”、“要求”、“建议”、“应”和“不应”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
This section defines the Delegation Signer (DS) RR type (type code 43) and the changes to DNS to accommodate it.
本节定义了委托签名者（DS）RR类型（类型代码43）以及对DNS的更改以适应它。
This document presents a replacement for the DNSSEC KEY record chain of trust [RFC2535] that uses a new RR that resides only at the parent. This record identifies the key(s) that the child uses to self-sign its own KEY RRset.
本文档介绍了DNSSEC密钥记录信任链[RFC2535]的替代品，该信任链使用仅驻留在父级的新RR。此记录标识子项用于对自己的密钥集进行自签名的密钥。
Even though DS identifies two roles for KEYs, Key Signing Key (KSK) and Zone Signing Key (ZSK), there is no requirement that zone uses two different keys for these roles. It is expected that many small zones will only use one key, while larger zones will be more likely to use multiple keys.
即使DS为密钥标识了两个角色，即密钥签名密钥（KSK）和区域签名密钥（ZSK），也不要求区域为这些角色使用两个不同的密钥。预计许多小区域将只使用一个键，而较大区域更可能使用多个键。
The chain of trust is now established by verifying the parent KEY RRset, the DS RRset from the parent and the KEY RRset at the child. This is cryptographically equivalent to using just KEY records.
现在，通过验证父密钥RRset、来自父密钥的DS RRset和子密钥RRset来建立信任链。这在密码学上等同于只使用密钥记录。
Communication between the parent and child is greatly reduced, since the child only needs to notify the parent about changes in keys that sign its apex KEY RRset. The parent is ignorant of all other keys in the child's apex KEY RRset. Furthermore, the child maintains full control over the apex KEY RRset and its content. The child can maintain any policies regarding its KEY usage for DNSSEC with minimal impact on the parent. Thus, if the child wants to have frequent key
父级和子级之间的通信大大减少，因为子级只需要通知父级有关对其顶点密钥集进行签名的密钥的更改。父项不知道子项的顶点键集中的所有其他键。此外，子对象对apex键集及其内容保持完全控制。子级可以维护有关其DNSSEC密钥使用的任何策略，并且对父级的影响最小。因此，如果孩子想拥有频繁的密钥
roll-over for its DNS zone keys, the parent does not need to be aware of it. The child can use one key to sign only its apex KEY RRset and a different key to sign the other RRsets in the zone.
对于其DNS区域密钥，父级不需要知道它。子项可以使用一个密钥仅对其顶点密钥RRset进行签名，而使用另一个密钥对区域中的其他RRset进行签名。
This model fits well with a slow roll out of DNSSEC and the islands of security model. In this model, someone who trusts "good.example." can preconfigure a key from "good.example." as a trusted key, and from then on trusts any data signed by that key or that has a chain of trust to that key. If "example." starts advertising DS records, "good.example." does not have to change operations by suspending self-signing. DS records can be used in configuration files to identify trusted keys instead of KEY records. Another significant advantage is that the amount of information stored in large delegation zones is reduced: rather than the NULL KEY record at every unsecure delegation demanded by RFC 2535, only secure delegations require additional information in the form of a signed DS RRset.
该模型非常适合DNSSEC的缓慢推出和安全孤岛模型。在这个模型中，信任“good.example.”的人可以将“good.example.”中的一个密钥预配置为受信任的密钥，然后再信任由该密钥签名或对该密钥具有信任链的任何数据。如果“example.”开始广告DS记录，“good.example.”不必通过挂起自签名来更改操作。DS记录可以在配置文件中用于标识受信任的密钥，而不是密钥记录。另一个显著的优点是，存储在大型委派区域中的信息量减少了：与RFC 2535要求的每个不安全委派的空密钥记录不同，只有安全委派需要以签名DS RRset形式的附加信息。
The main disadvantage of this approach is that verifying a zone's KEY RRset requires two signature verification operations instead of the one in RFC 2535 chain of trust. There is no impact on the number of signatures verified for other types of RRsets.
这种方法的主要缺点是验证区域的密钥RRset需要两个签名验证操作，而不是RFC 2535信任链中的一个。对其他类型的RRSET验证的签名数量没有影响。
All DNS servers and resolvers that support DS MUST support the OK bit [RFC3225] and a larger message size [RFC3226]. In order for a delegation to be considered secure the delegation MUST contain a DS RRset. If a query contains the OK bit, a nameserver returning a referral for the delegation MUST include the following RRsets in the authority section in this order:
所有支持DS的DNS服务器和解析程序必须支持OK位[RFC3225]和更大的消息大小[RFC3226]。为了将委派视为安全的，委派必须包含DS RRset。如果查询包含OK位，则返回委派引用的名称服务器必须按以下顺序在“权限”部分中包括以下RRSET：
If DS RRset is present: parent's copy of child's NS RRset DS and SIG(DS)
如果存在DS RRset：父项的子项NS RRset DS和SIG（DS）副本
If no DS RRset is present: parent's copy of child's NS RRset parent's zone NXT and SIG(NXT)
如果不存在DS RRset：父级的子级NS RRset副本父级的区域NXT和SIG（NXT）
This increases the size of referral messages, possibly causing some or all glue to be omitted. If the DS or NXT RRsets with signatures do not fit in the DNS message, the TC bit MUST be set. Additional section processing is not changed.
这会增加引用消息的大小，可能会导致省略部分或全部胶水。如果带有签名的DS或NXT RRSET不适合DNS消息，则必须设置TC位。附加节处理未更改。
A DS RRset accompanying a NS RRset indicates that the child zone is secure. If a NS RRset exists without a DS RRset, the child zone is unsecure (from the parents point of view). DS RRsets MUST NOT appear at non-delegation points or at a zone's apex.
伴随NS RRset的DS RRset表示子区域是安全的。如果存在没有DS RRset的NS RRset，则子区域是不安全的（从父区域的角度来看）。DS RRSET不得出现在非委派点或分区顶点。
Section 2.2.1 defines special considerations related to authoritative nameservers responding to DS queries and replaces RFC 2535 sections 2.3.4 and 3.4. Section 2.2.2 replaces RFC 3008 section 2.7, and section 2.2.3 updates RFC 3090.
第2.2.1节定义了与响应DS查询的权威名称服务器相关的特殊注意事项，并取代RFC 2535第2.3.4节和第3.4节。第2.2.2节取代RFC 3008第2.7节，第2.2.3节更新RFC 3090。
2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation Points
2.2.1. RFC 2535 2.3.4和3.4：授权点的特殊考虑
DNS security views each zone as a unit of data completely under the control of the zone owner with each entry (RRset) signed by a special private key held by the zone manager. But the DNS protocol views the leaf nodes in a zone that are also the apex nodes of a child zone (i.e., delegation points) as "really" belonging to the child zone. The corresponding domain names appear in two master files and might have RRsets signed by both the parent and child zones' keys. A retrieval could get a mixture of these RRsets and SIGs, especially since one nameserver could be serving both the zone above and below a delegation point [RFC2181].
DNS安全性将每个区域视为完全受区域所有者控制的数据单元，每个条目（RRset）都由区域管理器持有的特殊私钥签名。但是DNS协议将同时也是子区域顶点节点（即，委托点）的区域中的叶节点视为“真正”属于子区域。相应的域名出现在两个主文件中，并且可能具有由父区域和子区域的密钥签名的RRSET。检索可能会混合使用这些RRSET和SIG，特别是因为一个名称服务器可以同时为委托点上方和下方的区域提供服务[RFC2181]。
Each DS RRset stored in the parent zone MUST be signed by at least one of the parent zone's private keys. The parent zone MUST NOT contain a KEY RRset at any delegation point. Delegations in the parent MAY contain only the following RR types: NS, DS, NXT and SIG. The NS RRset MUST NOT be signed. The NXT RRset is the exceptional case: it will always appear differently and authoritatively in both the parent and child zones, if both are secure.
存储在父区域中的每个DS RRset必须由至少一个父区域的私钥签名。父区域不得在任何委派点包含密钥集。父级中的委托只能包含以下RR类型：NS、DS、NXT和SIG。不得对NS RRset进行签名。NXT RRset是一种例外情况：如果父区域和子区域都是安全的，那么它在父区域和子区域中总是以不同的方式出现。
A secure zone MUST contain a self-signed KEY RRset at its apex. Upon verifying the DS RRset from the parent, a resolver MAY trust any KEY identified in the DS RRset as a valid signer of the child's apex KEY RRset. Resolvers configured to trust one of the keys signing the KEY RRset MAY now treat any data signed by the zone keys in the KEY RRset as secure. In all other cases, resolvers MUST consider the zone unsecure.
安全区域的顶点必须包含自签名密钥集。在从父级验证DS RRset后，解析程序可以信任DS RRset中标识为子级apex密钥RRset有效签名者的任何密钥。配置为信任签名密钥RRset的密钥之一的解析程序现在可以将密钥RRset中由区域密钥签名的任何数据视为安全数据。在所有其他情况下，解析器必须考虑区域不安全。
An authoritative nameserver queried for type DS MUST return the DS RRset in the answer section.
查询DS类型的权威名称服务器必须在应答部分返回DS RRset。
When a nameserver is authoritative for the parent zone at a delegation point and receives a query for the DS record at that name, it MUST answer based on data in the parent zone, return DS or negative answer. This is true whether or not it is also authoritative for the child zone.
当名称服务器在委派点对父区域具有权威性并接收到该名称的DS记录查询时，它必须基于父区域中的数据进行应答，返回DS或否定应答。无论它是否对子区域具有权威性，这都是正确的。
When the nameserver is authoritative for the child zone at a delegation point but not the parent zone, there is no natural response, since the child zone is not authoritative for the DS record at the zone's apex. As these queries are only expected to originate from recursive nameservers which are not DS-aware, the authoritative nameserver MUST answer with:
如果名称服务器在委派点对子区域具有权威性，但对父区域没有权威性，则不会有自然响应，因为子区域对区域顶点的DS记录没有权威性。由于这些查询预计只来自不支持DS的递归名称服务器，因此权威名称服务器必须回答：
RCODE: NOERROR
AA bit: set
Answer Section: Empty
Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
RCODE: NOERROR
AA bit: set
Answer Section: Empty
Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
That is, it answers as if it is authoritative and the DS record does not exist. DS-aware recursive nameservers will query the parent zone at delegation points, so will not be affected by this.
也就是说，它的回答就好像它是权威的，并且DS记录不存在一样。支持DS的递归名称服务器将在委派点查询父区域，因此不受此影响。
A nameserver authoritative for only the child zone, that is also a caching server MAY (if the RD bit is set in the query) perform recursion to find the DS record at the delegation point, or MAY return the DS record from its cache. In this case, the AA bit MUST NOT be set in the response.
仅对子区域具有权威性的名称服务器（也是缓存服务器）可以（如果在查询中设置了RD位）执行递归以在委派点查找DS记录，或者可以从其缓存返回DS记录。在这种情况下，不得在响应中设置AA位。
2.2.1.2. Special processing when child and an ancestor share nameserver
2.2.1.2. 子服务器和祖先服务器共享名称服务器时的特殊处理
Special rules are needed to permit DS RR aware nameservers to gracefully interact with older caches which otherwise might falsely label a nameserver as lame because of the placement of the DS RR set.
需要特殊规则来允许支持DS RR的名称服务器与较旧的缓存进行正常交互，否则可能会由于DS RR集的放置而错误地将名称服务器标记为lame。
Such a situation might arise when a nameserver is authoritative for both a zone and it's grandparent, but not the parent. This sounds like an obscure example, but it is very real. The root zone is currently served on 13 machines, and "root-servers.net." is served on 4 of the 13, but "net." is severed on different nameservers.
当名称服务器对区域及其祖辈（而不是父代）都具有权威性时，可能会出现这种情况。这听起来像一个模糊的例子，但它是非常真实的。根区域目前在13台机器上提供服务，“root servers.net.”在13台机器中的4台上提供服务，但“net.”在不同的名称服务器上被切断。
When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the response MUST be determined from reading these rules in order:
当名称服务器收到（<QNAME>、DS、<QCLASS>）的查询时，必须通过按顺序读取这些规则来确定响应：
1) If the nameserver is authoritative for the zone that holds the DS RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent" zone), the response contains the DS RR set as an authoritative answer.
1) 如果名称服务器对保存DS RR集的区域具有权威性（即，代表<QNAME>的区域，也称为“父”区域），则响应包含DS RR集作为权威性答案。
2) If the nameserver is offering recursive service and the RD bit is set in the query, the nameserver performs the query itself (according to the rules for resolvers described below) and returns its findings.
2) 如果名称服务器提供递归服务，并且在查询中设置了RD位，则名称服务器将自己执行查询（根据下面描述的解析器规则）并返回其结果。
3) If the nameserver is authoritative for the zone that holds the <QNAME>'s SOA RR set, the response is an authoritative negative answer as described in 2.2.1.1.
3) 如果名称服务器对包含<QNAME>的SOA RR集的区域具有权威性，则响应为权威性否定回答，如2.2.1.1所述。
4) If the nameserver is authoritative for a zone or zones above the QNAME, a referral to the most enclosing (deepest match) zone's servers is made.
4) 如果名称服务器对QNAME之上的一个或多个区域具有权威性，则会引用最封闭（最深匹配）区域的服务器。
5) If the nameserver is not authoritative for any part of the QNAME, a response indicating a lame nameserver for QNAME is given.
5) 如果名称服务器对于QNAME的任何部分都不是权威的，则会给出一个响应，指示QNAME的lame名称服务器。
Using these rules will require some special processing on the part of a DS RR aware resolver. To illustrate this, an example is used.
使用这些规则需要DS RR感知解析器进行一些特殊处理。为了说明这一点，使用了一个示例。
Assuming a nameserver is authoritative for roots.example.net. and for the root zone but not the intervening two zones (or the intervening two label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS, and QCLASS=IN.
假设名称服务器是root.example.net的权威服务器。对于根区，而不是中间的两个区（或中间的两个标签深区）。假设QNAME=root.example.net.，QTYPE=DS，QCLASS=IN。
The resolver will issue this request (assuming no cached data) expecting a referral to a nameserver for .net. Instead, rule number 3 above applies and a negative answer is returned by the nameserver. The reaction by the resolver is not to accept this answer as final, as it can determine from the SOA RR in the negative answer the context within which the nameserver has answered.
冲突解决程序将发出此请求（假定没有缓存数据），该请求期望引用.net的名称服务器。相反，上面的第3条规则适用，名称服务器返回否定答案。解析程序的反应是不接受此答案作为最终答案，因为它可以从否定答案中的SOA RR确定名称服务器已回答的上下文。
A solution would be to instruct the resolver to hunt for the authoritative zone of the data in a brute force manner.
一个解决方案是指示解析器以暴力方式搜索数据的权威区域。
This can be accomplished by taking the owner name of the returned SOA RR and striping off enough left-hand labels until a successful NS response is obtained. A successful response here means that the answer has NS records in it. (Entertaining the possibility that a cut point can be two labels down in a zone.)
这可以通过获取返回的SOA RR的所有者名称并剥离足够多的左侧标签来实现，直到获得成功的NS响应。这里的成功响应意味着答案中有NS记录。（一个切点可能是一个分区中的两个标签。）
Returning to the example, the response will include a negative answer with either the SOA RR for "roots.example.net." or "example.net." depending on whether roots.example.net is a delegated domain. In either case, removing the left most label of the SOA owner name will lead to the location of the desired data.
返回到示例，响应将包含否定的回答，其中SOARR表示“root.example.net.”或“example.net.”，具体取决于root.example.net是否为委托域。在任何一种情况下，删除SOA所有者名称最左边的标签都会找到所需数据的位置。
This section updates RFC 2535 section 3.5 by replacing it with the following:
本节更新了RFC 2535第3.5节，将其替换为以下内容：
A query for KEY RR MUST NOT trigger any additional section processing. Security aware resolvers will include corresponding SIG records in the answer section.
对键RR的查询不能触发任何额外的节处理。安全感知解析器将在应答部分包含相应的SIG记录。
KEY records SHOULD NOT be added to the additional records section in response to any query.
不应将关键记录添加到“附加记录”部分以响应任何查询。
RFC 2535 specified that KEY records be added to the additional section when SOA or NS records were included in an answer. This was done to reduce round trips (in the case of SOA) and to force out NULL KEYs (in the NS case). As this document obsoletes NULL keys, there is no need for the inclusion of KEYs with NSs. Furthermore, as SOAs are included in the authority section of negative answers, including the KEYs each time will cause redundant transfers of KEYs.
RFC 2535规定，当回答中包含SOA或NS记录时，应将关键记录添加到附加部分。这样做是为了减少往返（在SOA的情况下）和强制输出空键（在NS的情况下）。由于本文档淘汰了空密钥，因此不需要在NSs中包含密钥。此外，由于SOA包含在否定答案的权限部分，每次包含密钥都会导致密钥的冗余传输。
RFC 2535 section 3.5 also included a rule for adding the KEY RRset to the response for a query for A and AAAA types. As Restrict KEY [RFC3445] eliminated use of KEY RR by all applications, this rule is no longer needed.
RFC 2535第3.5节还包括一条规则，用于将密钥RRset添加到a和AAAA类型查询的响应中。由于限制键[RFC3445]消除了所有应用程序对键RR的使用，因此不再需要此规则。
The signer's name field of a SIG RR 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. This document defines a standard policy for DNSSEC validation; local policy MAY override the standard policy.
SIG RR的签名者姓名字段必须包含数据和签名所属区域的名称。如果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），签名者名称、密钥标记和算法的组合必须标识密钥。
A number of sections in RFC 3090 need to be updated to reflect the DS record.
RFC 3090中的许多章节需要更新以反映DS记录。
Most of the text is still relevant but the words "NULL key" are to be replaced with "missing DS RRset". In section 1.3, the last three paragraphs discuss the confusion in sections of RFC 2535 that are replaced in section 2.2.1 above. Therefore, these paragraphs are now obsolete.
大部分文本仍然相关，但“空键”将替换为“缺少DS RRset”。在第1.3节中，最后三段讨论了RFC 2535章节中的混淆，这些混淆在上文第2.2.1节中被替换。因此，这些段落现已过时。
Rule 2.1.b is replaced by the following rule:
规则2.1.b由以下规则取代：
2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a private key whose public counterpart MUST appear in a zone signing KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-implement algorithm. This KEY RR MUST be identified by a DS RR in a signed DS RRset in the parent zone.
2.1.b。区域顶点处的密钥RRset必须由私钥自签名，私钥的公钥必须出现在区域顶点拥有的区域签名密钥RR（2.a）中，并指定强制实现算法。此密钥RR必须由父区域中已签名DS RR集中的DS RR标识。
If a zone cannot get its parent to advertise a DS record for it, the child zone cannot be considered globally secured. The only exception to this is the root zone, for which there is no parent zone.
如果某个区域无法让其父区域为其播发DS记录，则不能将该子区域视为全局安全的。唯一的例外是根区域，它没有父区域。
2.2.3.3. RFC 3090 section 3: Experimental Status.
2.2.3.3. RFC 3090第3节：实验状态。
The only difference between experimental status and globally secured is the missing DS RRset in the parent zone. All locally secured zones are experimental.
实验状态和全局安全状态之间的唯一区别是父区域中缺少DS RRset。所有本地安全区都是实验性的。
RFC 3445 section 3 eliminates the top two bits in the flags field of KEY RR. These two bits were used to indicate NULL KEY or NO KEY. RFC 3090 defines that zone as either secure or not and these rules eliminate the need to put NULL keys in the zone apex to indicate that the zone is not secured for a algorithm. Along with this document, these other two eliminate all uses for the NULL KEY. This document obsoletes NULL KEY.
RFC 3445第3节消除键RR的标志字段中的前两位。这两个位用于表示空键或无键。RFC 3090将该区域定义为安全区域或非安全区域，这些规则消除了在区域顶点中放置空密钥以指示该区域对于算法不安全的需要。与本文档一起，另外两个消除了空键的所有用途。此文档废弃空密钥。
Over the years, there have been various discussions surrounding the DNS delegation model, declaring it to be broken because there is no good way to assert if a delegation exists. In the RFC 2535 version of DNSSEC, the presence of the NS bit in the NXT bit map proves there is a delegation at this name. Something more explicit is required and the DS record addresses this need for secure delegations.
多年来，围绕DNS委派模型进行了各种讨论，宣布它已被破坏，因为没有好的方法来断言委派是否存在。在DNSSEC的RFC 2535版本中，NXT位映射中存在NS位证明此名称存在委派。需要更明确的内容，DS记录解决了这种安全授权的需要。
The DS record is a major change to DNS: it is the first resource record that can appear only on the upper side of a delegation. Adding it will cause interoperability problems and requires a flag day for DNSSEC. Many old nameservers and resolvers MUST be upgraded to take advantage of DS. Some old nameservers will be able to be authoritative for zones with DS records but will not add the NXT or DS records to the authority section. The same is true for caching nameservers; in fact, some might even refuse to pass on the DS or NXT records.
DS记录是对DNS的一个重大更改：它是第一个只能出现在委派上方的资源记录。添加它将导致互操作性问题，并且需要DNSSEC的国旗日。许多旧的名称服务器和解析程序必须升级才能利用DS。一些旧名称服务器将能够对具有DS记录的区域进行授权，但不会将NXT或DS记录添加到授权部分。缓存名称服务器也是如此；事实上，有些人甚至可能拒绝传递DS或NXT记录。
The DS (type=43) record contains these fields: key tag, algorithm, digest type, and the digest of a public key KEY record that is allowed and/or used to sign the child's apex KEY RRset. Other keys MAY sign the child's apex KEY RRset.
DS（type=43）记录包含以下字段：密钥标记、算法、摘要类型和允许和/或用于对子密钥集签名的公钥记录摘要。其他键可能会对孩子的顶点键集进行签名。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | algorithm | Digest type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digest (length depends on type) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (SHA-1 digest is 20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | algorithm | Digest type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digest (length depends on type) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (SHA-1 digest is 20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The key tag is calculated as specified in RFC 2535. Algorithm MUST be allowed to sign DNS data. The digest type is an identifier for the digest algorithm used. The digest is calculated over the canonical name of the delegated domain name followed by the whole RDATA of the KEY record (all four fields).
按照RFC 2535中的规定计算密钥标签。必须允许算法对DNS数据进行签名。摘要类型是所用摘要算法的标识符。摘要是根据委托域名的规范名称，后跟密钥记录的整个RDATA（所有四个字段）计算的。
digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
摘要=散列（键RR |键RR _rdata上的规范FQDN）
KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
KEY_RR_rdata=标志|协议|算法|公钥
Digest type value 0 is reserved, value 1 is SHA-1, and reserving other types requires IETF standards action. For interoperability reasons, keeping number of digest algorithms low is strongly RECOMMENDED. The only reason to reserve additional digest types is to increase security.
摘要类型值0是保留的，值1是SHA-1，保留其他类型需要IETF标准操作。出于互操作性的原因，强烈建议保持摘要算法的数量较低。保留其他摘要类型的唯一原因是为了提高安全性。
DS records MUST point to zone KEY records that are allowed to authenticate DNS data. The indicated KEY records protocol field MUST be set to 3; flag field bit 7 MUST be set to 1. The value of other flag bits is not significant for the purposes of this document.
DS记录必须指向允许对DNS数据进行身份验证的区域密钥记录。指定的密钥记录协议字段必须设置为3；标志字段位7必须设置为1。就本文件而言，其他标志位的值不重要。
The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless of key size. New digest types probably will have larger digests.
类型1（SHA-1）的DS RDATA大小为24字节，与密钥大小无关。新的摘要类型可能会有更大的摘要。
The algorithm and key tag fields are present to allow resolvers to quickly identify the candidate KEY records to examine. SHA-1 is a strong cryptographic checksum: it is computationally infeasible for an attacker to generate a KEY record that has the same SHA-1 digest. Combining the name of the key and the key rdata as input to the digest provides stronger assurance of the binding. Having the key tag in the DS record adds greater assurance than the SHA-1 digest alone, as there are now two different mapping functions.
算法和密钥标记字段的存在使解析器能够快速识别待检查的候选密钥记录。SHA-1是一种强加密校验和：攻击者在计算上不可能生成具有相同SHA-1摘要的密钥记录。将键的名称和键的rdata作为摘要的输入组合在一起，可以更好地保证绑定。在DS记录中使用密钥标记比单独使用SHA-1摘要更能保证安全，因为现在有两种不同的映射函数。
This format allows concise representation of the keys that the child will use, thus keeping down the size of the answer for the delegation, reducing the probability of DNS message overflow. The SHA-1 hash is strong enough to uniquely identify the key and is similar to the PGP key footprint. The digest type field is present for possible future expansion.
此格式允许简洁地表示子级将使用的密钥，从而减小委托的答案大小，降低DNS消息溢出的可能性。SHA-1散列足够强大，可以唯一标识密钥，并且与PGP密钥封装类似。摘要类型字段用于将来可能的扩展。
The DS record is well suited to listing trusted keys for islands of security in configuration files.
DS记录非常适合在配置文件中列出安全孤岛的可信密钥。
The presentation format of the DS record consists of three numbers (key tag, algorithm, and digest type) followed by the digest itself presented in hex:
DS记录的表示格式由三个数字（键标记、算法和摘要类型）组成，后跟以十六进制表示的摘要本身：
example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890
example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890
No backwards compatibility with RFC 2535 is provided.
不提供与RFC 2535的向后兼容性。
RFC 2535-compliant resolvers will assume that all DS-secured delegations are locally secure. This is bad, but the DNSEXT Working Group has determined that rather than dealing with both RFC 2535- secured zones and DS-secured zones, a rapid adoption of DS is preferable. Thus, the only option for early adopters is to upgrade to DS as soon as possible.
符合RFC 2535的解析器将假定所有DS安全的委托都是本地安全的。这是不好的，但DNSEXT工作组已确定，与其同时处理RFC 2535安全区和DS安全区，不如快速采用DS。因此，早期采用者的唯一选择是尽快升级到DS。
This section documents how a resolver determines the type of delegation.
本节说明冲突解决程序如何确定委派类型。
RFC 1035 delegation (in parent) has:
RFC 1035委托（在母公司中）具有：
RFC 1035 NS
RFC1035纳秒
RFC 2535 adds the following two cases:
RFC 2535增加了以下两种情况：
Secure RFC 2535: NS + NXT + SIG(NXT) NXT bit map contains: NS SIG NXT Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) NXT bit map contains: NS SIG KEY NXT KEY must be a NULL key.
安全RFC 2535:NS+NXT+SIG（NXT）NXT位图包含：NS SIG NXT不安全RFC 2535:NS+KEY+SIG（KEY）+NXT+SIG（NXT）NXT位图包含：NS SIG KEY NXT KEY必须是空密钥。
DNSSEC with DS has the following two states:
带有DS的DNSSEC具有以下两种状态：
Secure DS: NS + DS + SIG(DS)
NXT bit map contains: NS SIG NXT DS
Unsecure DS: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT
Secure DS: NS + DS + SIG(DS)
NXT bit map contains: NS SIG NXT DS
Unsecure DS: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT
It is difficult for a resolver to determine if a delegation is secure RFC 2535 or unsecure DS. This could be overcome by adding a flag to the NXT bit map, but only upgraded resolvers would understand this flag, anyway. Having both parent and child signatures for a KEY RRset might allow old resolvers to accept a zone as secure, but the cost of doing this for a long time is much higher than just prohibiting RFC 2535-style signatures at child zone apexes and forcing rapid deployment of DS-enabled nameservers and resolvers.
解析程序很难确定委托是安全的RFC 2535还是不安全的DS。这可以通过向NXT位图添加标志来克服，但无论如何，只有升级的解析器才能理解此标志。密钥RRset同时具有父签名和子签名可能允许旧的解析程序将区域视为安全的，但长期这样做的成本远高于仅在子区域顶点禁止RFC 2535样式的签名并强制快速部署启用DS的名称服务器和解析程序。
RFC 2535 and DS can, in theory, be deployed in parallel, but this would require resolvers to deal with RFC 2535 configurations forever. This document obsoletes the NULL KEY in parent zones, which is a difficult enough change that to cause a flag day.
理论上，RFC2535和DS可以并行部署，但这需要解析器永远处理RFC2535配置。本文档淘汰了父区域中的空键，这是一个非常困难的更改，足以导致卖旗日。
This is an example of a KEY record and the corresponding DS record.
这是密钥记录和相应DS记录的示例。
dskey.example. KEY 256 3 1 (
AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
) ; key id = 28668
DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
dskey.example. KEY 256 3 1 (
AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
) ; key id = 28668
DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
To create a chain of trust, a resolver goes from trusted KEY to DS to KEY.
为了创建信任链，解析器从受信任密钥到DS再到密钥。
Assume the key for domain "example." is trusted. Zone "example." contains at least the following records: example. SOA <soa stuff> example. NS ns.example. example. KEY <stuff> example. NXT secure.example. NS SOA KEY SIG NXT example. SIG(SOA) example. SIG(NS) example. SIG(NXT) example. SIG(KEY) secure.example. NS ns1.secure.example. secure.example. DS tag=12345 alg=3 digest_type=1 <foofoo> secure.example. NXT unsecure.example. NS SIG NXT DS secure.example. SIG(NXT) secure.example. SIG(DS) unsecure.example NS ns1.unsecure.example. unsecure.example. NXT example. NS SIG NXT unsecure.example. SIG(NXT)
假设域“example.”的密钥是可信的。区域“示例”。至少包含以下记录：示例。SOA<SOA stuff>示例。例如。实例键<stuff>示例。NXT-secure.example。NS SOA密钥SIG NXT示例。SIG（SOA）示例。SIG（NS）示例。SIG（NXT）示例。SIG（KEY）secure.example。NS ns1.secure.example。安全。例如。DS tag=12345 alg=3 digest_type=1<foofoo>secure.example。NXT unsecure.example。NS SIG NXT DS secure.example。SIG（NXT）secure.example。SIG（DS）unsecure.example NS ns1.unsecure.example。不安全。NXT示例。NS SIG NXT unsecure.example。SIG（NXT）
In zone "secure.example." following records exist:
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
secure.example. KEY <tag=12345 alg=3>
secure.example. KEY <tag=54321 alg=5>
secure.example. NXT <nxt stuff>
secure.example. SIG(KEY) <key-tag=12345 alg=3>
secure.example. SIG(SOA) <key-tag=54321 alg=5>
secure.example. SIG(NS) <key-tag=54321 alg=5>
secure.example. SIG(NXT) <key-tag=54321 alg=5>
In zone "secure.example." following records exist:
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
secure.example. KEY <tag=12345 alg=3>
secure.example. KEY <tag=54321 alg=5>
secure.example. NXT <nxt stuff>
secure.example. SIG(KEY) <key-tag=12345 alg=3>
secure.example. SIG(SOA) <key-tag=54321 alg=5>
secure.example. SIG(NS) <key-tag=54321 alg=5>
secure.example. SIG(NXT) <key-tag=54321 alg=5>
In this example, the private key for "example." signs the DS record for "secure.example.", making that a secure delegation. The DS record states which key is expected to sign the KEY RRset at "secure.example.". Here "secure.example." signs its KEY RRset with the KEY identified in the DS RRset, thus the KEY RRset is validated and trusted.
在本例中，“example.”的私钥为“secure.example.”的DS记录签名，使其成为安全委托。DS记录说明了希望哪个密钥对“secure.example”处的密钥集进行签名。此处的“secure.example.”使用DS RRset中标识的密钥对其密钥RRset进行签名，从而验证并信任密钥RRset。
This example has only one DS record for the child, but parents MUST allow multiple DS records to facilitate key roll-over and multiple KEY algorithms.
本例中，子项只有一个DS记录，但父项必须允许多个DS记录，以便于密钥滚动和多个密钥算法。
The resolver determines the security status of "unsecure.example." by examining the parent zone's NXT record for this name. The absence of the DS bit indicates an unsecure delegation. Note the NXT record SHOULD only be examined after verifying the corresponding signature.
解析程序通过检查父区域的NXT记录来确定“unsecure.example.”的安全状态。缺少DS位表示不安全的委派。注：NXT记录应仅在验证相应签名后进行检查。
From a RFC 2535 recursive resolver point of view, for each delegation followed to chase down an answer, one KEY RRset has to be verified. Additional RRsets might also need to be verified based on local policy (e.g., the contents of the NS RRset). Once the resolver gets to the appropriate delegation, validating the answer might require verifying one or more signatures. A simple A record lookup requires at least N delegations to be verified and one RRset. For a DS-enabled recursive resolver, the cost is 2N+1. For an MX record, where the target of the MX record is in the same zone as the MX record, the costs are N+2 and 2N+2, for RFC 2535 and DS, respectively. In the case of a negative answer, the same ratios hold true.
从RFC2535递归解析器的角度来看，对于追踪答案所遵循的每个委托，必须验证一个密钥RRset。其他RRset可能还需要根据本地策略进行验证（例如，NS RRset的内容）。一旦解析器到达适当的委托，验证答案可能需要验证一个或多个签名。一个简单的A记录查找需要至少验证N个委托和一个RRset。对于启用DS的递归解析器，成本为2N+1。对于MX记录，当MX记录的目标与MX记录位于同一区域时，RFC 2535和DS的成本分别为N+2和2N+2。在否定答案的情况下，同样的比率成立。
The recursive resolver has to do an extra query to get the DS record, which will increase the overall cost of resolving this question, but it will never be worse than chasing down NULL KEY records from the parent in RFC 2535 DNSSEC.
递归解析程序必须执行额外的查询以获取DS记录，这将增加解决此问题的总体成本，但它永远不会比在RFC 2535 DNSSEC中从父级查找空键记录更糟糕。
DS adds processing overhead on resolvers and increases the size of delegation answers, but much less than storing signatures in the parent zone.
DS增加了解析程序的处理开销，并增加了委派答案的大小，但比在父区域中存储签名要小得多。
This document proposes a change to the validation chain of KEY records in DNSSEC. The change is not believed to reduce security in the overall system. In RFC 2535 DNSSEC, the child zone has to communicate keys to its parent and prudent parents will require some authentication with that transaction. The modified protocol will require the same authentication, but allows the child to exert more local control over its own KEY RRset.
本文件建议更改DNSSEC中关键记录的验证链。据信，这一变化不会降低整个系统的安全性。在RFC 2535 DNSSEC中，子区域必须将密钥传递给其父区域，谨慎的父区域将需要对该事务进行某种身份验证。修改后的协议将需要相同的身份验证，但允许孩子对自己的密钥集施加更多的本地控制。
There is a remote possibility that an attacker could generate a valid KEY that matches all the DS fields, of a specific DS set, and thus forge data from the child. This possibility is considered impractical, as on average more than
攻击者极有可能生成与特定DS集的所有DS字段相匹配的有效密钥，从而伪造来自子级的数据。这种可能性被认为是不切实际的，因为平均而言，这种可能性超过
2 ^ (160 - <Number of keys in DS set>)
2 ^ (160 - <Number of keys in DS set>)
keys would have to be generated before a match would be found.
在找到匹配项之前，必须生成密钥。
An attacker that wants to match any DS record will have to generate on average at least 2^80 keys.
想要匹配任何DS记录的攻击者平均必须生成至少2^80个密钥。
The DS record represents a change to the DNSSEC protocol and there is an installed base of implementations, as well as textbooks on how to set up secure delegations. Implementations that do not understand the DS record will not be able to follow the KEY to DS to KEY chain and will consider all zones secured that way as unsecure.
DS记录表示对DNSSEC协议的更改，有一个安装的实现基础，以及关于如何设置安全委托的教科书。不理解DS记录的实现将无法遵循DS到密钥链的密钥，并且会考虑以不安全的方式安全地保护所有区域。
IANA has allocated an RR type code for DS from the standard RR type space (type 43).
IANA已从标准RR类型空间（类型43）为DS分配了RR类型代码。
IANA has established a new registry for the DS RR type for digest algorithms. Defined types are:
IANA为摘要算法的DS RR类型建立了一个新的注册表。定义的类型包括：
0 is Reserved, 1 is SHA-1.
0是保留的，1是SHA-1。
Adding new reservations requires IETF standards action.
添加新的保留需要IETF标准操作。
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执行董事。
Over the last few years a number of people have contributed ideas that are captured in this document. The core idea of using one key to sign only the KEY RRset comes from discussions with Bill Manning and Perry Metzger on how to put in a single root key in all resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark Andrews, Harald Alvestrand, and others have provided useful comments.
在过去几年中，许多人提出了本文件中包含的想法。使用一个密钥只对密钥RRset签名的核心思想来自于与Bill Manning和Perry Metzger讨论如何在所有解析器中放入一个根密钥。亚历克西斯·尤辛、布赖恩·惠灵顿、萨姆·韦勒、保罗·维克西、雅各布·施莱特、斯科特·罗斯、爱德华·刘易斯、拉尔斯·约翰·利曼、马特·拉森、马克·科斯特斯、丹·梅西、奥拉夫·科尔曼、菲利普·哈拉姆·贝克、米克·吉本、哈瓦德·艾恩斯、唐纳德·伊斯特莱克第三、兰迪·布什、大卫·布莱克、史蒂夫·贝洛文、罗伯·奥斯汀、德里克·阿特金斯、罗伊·阿伦兹、马克·安德鲁斯、，Harald Alvestrand和其他人提供了有用的评论。
[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月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000.
[RFC3008]惠灵顿，B.，“域名系统安全（DNSSEC）签名机构”，RFC3008，2000年11月。
[RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001.
[RFC3090]Lewis，E.“关于区域状态的DNS安全扩展澄清”，RFC 3090，2001年3月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]Conrad，D.“指示DNSSEC的分解器支持”，RFC 3225，2001年12月。
[RFC3445] Massey, D. and S. Rose, "Limiting the scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445]Massey，D.和S.Rose，“限制关键资源记录（RR）的范围”，RFC 34452002年12月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001.
[RFC3226]Gudmundsson，O.，“DNSSEC和IPv6 A6感知服务器/解析器消息大小要求”，RFC 3226，2001年12月。
Olafur Gudmundsson 3821 Village Park Drive Chevy Chase, MD, 20815
马里兰州雪佛兰蔡斯村公园路3821号奥拉弗尔·古德蒙松，邮编：20815
EMail: ds-rfc@ogud.com
EMail: ds-rfc@ogud.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编辑功能的资金目前由互联网协会提供。