Network Working Group M. StJohns
Request for Comments: 5011 Independent
Category: Standards Track September 2007
Network Working Group M. StJohns
Request for Comments: 5011 Independent
Category: Standards Track September 2007
Automated Updates of DNS Security (DNSSEC) Trust Anchors
DNS安全（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）。本备忘录的分发不受限制。
Abstract
摘要
This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).
本文件描述了DNSSEC“信任锚”的自动、认证和授权更新方法。该方法针对信任点密钥集中N个密钥的N-1密钥泄露提供保护。基于当前锚的存在所建立的信任，可以在层次结构中的相同位置添加其他锚，并最终取代现有锚。
This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record.
此机制将需要更改解析程序管理行为（但不是解析程序解析行为），并向DNSKEY记录中添加单个标志位。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Compliance Nomenclature ....................................3
2. Theory of Operation .............................................3
2.1. Revocation .................................................4
2.2. Add Hold-Down ..............................................4
2.3. Active Refresh .............................................5
2.4. Resolver Parameters ........................................6
2.4.1. Add Hold-Down Time ..................................6
2.4.2. Remove Hold-Down Time ...............................6
2.4.3. Minimum Trust Anchors per Trust Point ...............6
3. Changes to DNSKEY RDATA Wire Format .............................6
4. State Table .....................................................6
4.1. Events .....................................................7
4.2. States .....................................................7
5. Trust Point Deletion ............................................8
6. Scenarios - Informative .........................................9
6.1. Adding a Trust Anchor ......................................9
6.2. Deleting a Trust Anchor ....................................9
6.3. Key Roll-Over .............................................10
6.4. Active Key Compromised ....................................10
6.5. Stand-by Key Compromised ..................................10
6.6. Trust Point Deletion ......................................10
7. IANA Considerations ............................................11
8. Security Considerations ........................................11
8.1. Key Ownership vs. Acceptance Policy .......................11
8.2. Multiple Key Compromise ...................................12
8.3. Dynamic Updates ...........................................12
9. Normative References ...........................................12
10. Informative References ........................................12
1. Introduction ....................................................2
1.1. Compliance Nomenclature ....................................3
2. Theory of Operation .............................................3
2.1. Revocation .................................................4
2.2. Add Hold-Down ..............................................4
2.3. Active Refresh .............................................5
2.4. Resolver Parameters ........................................6
2.4.1. Add Hold-Down Time ..................................6
2.4.2. Remove Hold-Down Time ...............................6
2.4.3. Minimum Trust Anchors per Trust Point ...............6
3. Changes to DNSKEY RDATA Wire Format .............................6
4. State Table .....................................................6
4.1. Events .....................................................7
4.2. States .....................................................7
5. Trust Point Deletion ............................................8
6. Scenarios - Informative .........................................9
6.1. Adding a Trust Anchor ......................................9
6.2. Deleting a Trust Anchor ....................................9
6.3. Key Roll-Over .............................................10
6.4. Active Key Compromised ....................................10
6.5. Stand-by Key Compromised ..................................10
6.6. Trust Point Deletion ......................................10
7. IANA Considerations ............................................11
8. Security Considerations ........................................11
8.1. Key Ownership vs. Acceptance Policy .......................11
8.2. Multiple Key Compromise ...................................12
8.3. Dynamic Updates ...........................................12
9. Normative References ...........................................12
10. Informative References ........................................12
As part of the reality of fielding DNSSEC (Domain Name System Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has come to the realization that there will not be one signed name space, but rather islands of signed name spaces each originating from specific points (i.e., 'trust points') in the DNS tree. Each of those islands will be identified by the trust point name, and validated by at least one associated public key. For the purpose of this document, we'll call the association of that name and a particular key a 'trust anchor'. A particular trust point can have more than one key designated as a trust anchor.
作为部署DNSSEC（域名系统安全扩展）[RFC4033][RFC4034][RFC4035]的现实的一部分，社区已经认识到，将不会有一个签名名称空间，而是来自DNS树中特定点（即“信任点”）的签名名称空间孤岛。这些孤岛中的每一个都将由信任点名称标识，并由至少一个相关联的公钥验证。在本文档中，我们将该名称与特定密钥的关联称为“信任锚”。特定信任点可以有多个密钥指定为信任锚。
For a DNSSEC-aware resolver to validate information in a DNSSEC protected branch of the hierarchy, it must have knowledge of a trust anchor applicable to that branch. It may also have more than one
对于支持DNSSEC的解析程序，要验证层次结构中受DNSSEC保护的分支中的信息，它必须了解适用于该分支的信任锚点。它也可能有不止一个
trust anchor for any given trust point. Under current rules, a chain of trust for DNSSEC-protected data that chains its way back to ANY known trust anchor is considered 'secure'.
任何给定信任点的信任锚。根据当前的规则，DNSSEC保护数据的信任链（链接回任何已知的信任锚点）被认为是“安全的”。
Because of the probable balkanization of the DNSSEC tree due to signing voids at key locations, a resolver may need to know literally thousands of trust anchors to perform its duties (e.g., consider an unsigned ".COM"). Requiring the owner of the resolver to manually manage these many relationships is problematic. It's even more problematic when considering the eventual requirement for key replacement/update for a given trust anchor. The mechanism described herein won't help with the initial configuration of the trust anchors in the resolvers, but should make trust point key replacement/rollover more viable.
由于DNSSEC树可能由于在关键位置上签署空隙而可能发生巴尔干化，所以解析器可能需要知道数以千计的信任锚来执行其职责（例如，考虑未签名的“.com”）。要求解析器的所有者手动管理这些关系是有问题的。考虑到对给定信任锚的密钥替换/更新的最终要求，问题甚至更大。本文描述的机制无助于解析程序中信任锚的初始配置，但应使信任点密钥替换/滚动更可行。
As mentioned above, this document describes a mechanism whereby a resolver can update the trust anchors for a given trust point, mainly without human intervention at the resolver. There are some corner cases discussed (e.g., multiple key compromise) that may require manual intervention, but they should be few and far between. This document DOES NOT discuss the general problem of the initial configuration of trust anchors for the resolver.
如上所述，本文档描述了一种机制，通过该机制，冲突解决程序可以更新给定信任点的信任锚，而无需人为干预。讨论了一些可能需要手动干预的角落案例（例如，多个密钥泄露），但这些案例应该很少。本文档不讨论冲突解决程序信任锚的初始配置的一般问题。
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 BCP 14, [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中所述进行解释。
The general concept of this mechanism is that existing trust anchors can be used to authenticate new trust anchors at the same point in the DNS hierarchy. When a zone operator adds a new SEP key (i.e., a DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is validated by an existing trust anchor, then the resolver can add the new key to its set of valid trust anchors for that trust point.
此机制的一般概念是，现有信任锚可用于在DNS层次结构中的同一点对新信任锚进行身份验证。当区域操作员向信任点DNSKEY RRSet添加新的SEP密钥（即，具有安全入口点位集的DNSKEY）（参见[RFC4034]，第2.1.1节）时，并且当该RRSet由现有信任锚验证时，解析程序可以将新密钥添加到该信任点的有效信任锚集中。
There are some issues with this approach that need to be mitigated. For example, a compromise of one of the existing keys could allow an attacker to add their own 'valid' data. This implies a need for a method to revoke an existing key regardless of whether or not that key is compromised. As another example, assuming a single key compromise, we need to prevent an attacker from adding a new key and revoking all the other old keys.
这种方法存在一些需要缓解的问题。例如，现有密钥之一的泄露可能允许攻击者添加自己的“有效”数据。这意味着需要一种方法来撤销现有密钥，而不管该密钥是否被泄露。另一个例子是，假设单个密钥泄露，我们需要防止攻击者添加新密钥并撤销所有其他旧密钥。
Assume two trust anchor keys A and B. Assume that B has been compromised. Without a specific revocation bit, B could invalidate A simply by sending out a signed trust point key set that didn't contain A. To fix this, we add a mechanism that requires knowledge of the private key of a DNSKEY to revoke that DNSKEY.
假设两个信任锚密钥A和B。假设B已被泄露。如果没有特定的撤销位，B只需发送不包含a的签名信任点密钥集即可使a无效。为了解决此问题，我们添加了一种机制，需要知道DNSKEY的私钥才能撤销该DNSKEY。
A key is considered revoked when the resolver sees the key in a self-signed RRSet and the key has the REVOKE bit (see Section 7 below) set to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this key as a trust anchor or for any other purpose except to validate the RRSIG it signed over the DNSKEY RRSet specifically for the purpose of validating the revocation. Unlike the 'Add' operation below, revocation is immediate and permanent upon receipt of a valid revocation at the resolver.
当冲突解决程序在自签名RRSet中看到密钥，并且该密钥的REVOKE位（参见下面的第7节）设置为“1”时，该密钥被视为已撤销。一旦冲突解决程序看到撤销位，它不得将此密钥用作信任锚或用于任何其他目的，除非验证它在DNSKEY RRSet上签名的RRSIG，该RRSIG专门用于验证撤销。与下面的“添加”操作不同，在解析程序上收到有效的撤销后，撤销是立即和永久的。
A self-signed RRSet is a DNSKEY RRSet that contains the specific DNSKEY and for which there is a corresponding validated RRSIG record. It's not a special DNSKEY RRSet, just a way of describing the validation requirements for that RRSet.
自签名RRSet是一个DNSKEY RRSet，它包含特定的DNSKEY，并且有相应的已验证RRSIG记录。它不是一个特殊的DNSKEY RRSet，只是描述该RRSet的验证需求的一种方式。
N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint than one without the bit set. This affects the matching of a DNSKEY to DS records in the parent [RFC3755], or the fingerprint stored at a resolver used to configure a trust point.
注意：具有撤销位集的DNSKEY与不具有该位集的DNSKEY具有不同的指纹。这会影响父[RFC3755]中DNSKEY与DS记录的匹配，或影响存储在用于配置信任点的解析程序中的指纹的匹配。
In the given example, the attacker could revoke B because it has knowledge of B's private key, but could not revoke A.
在给定的示例中，攻击者可以撤销B，因为它知道B的私钥，但无法撤销A。
Assume two trust point keys A and B. Assume that B has been compromised. An attacker could generate and add a new trust anchor key C (by adding C to the DNSKEY RRSet and signing it with B), and then invalidate the compromised key. This would result in both the attacker and owner being able to sign data in the zone and have it accepted as valid by resolvers.
假设两个信任点密钥A和B。假设B已被泄露。攻击者可以生成并添加新的信任锚密钥C（通过将C添加到DNSKEY RRSet并用B签名），然后使受损密钥无效。这将导致攻击者和所有者能够对区域中的数据进行签名，并使解析程序将其视为有效数据。
To mitigate but not completely solve this problem, we add a hold-down time to the addition of the trust anchor. When the resolver sees a new SEP key in a validated trust point DNSKEY RRSet, the resolver starts an acceptance timer, and remembers all the keys that validated the RRSet. If the resolver ever sees the DNSKEY RRSet without the new key but validly signed, it stops the acceptance process for that key and resets the acceptance timer. If all of the keys that were
为了缓解但不是完全解决这个问题，我们在增加信任锚的基础上增加了一个抑制时间。当冲突解决程序在已验证的信任点DNSKEY RRSet中看到新的SEP密钥时，冲突解决程序启动接受计时器，并记住所有已验证RRSet的密钥。如果解析程序曾经看到没有新密钥但经过有效签名的DNSKEY RRSet，它将停止该密钥的接受过程并重置接受计时器。如果所有的钥匙
originally used to validate this key are revoked prior to the timer expiring, the resolver stops the acceptance process and resets the timer.
最初用于验证此密钥的解析程序在计时器过期之前被吊销，解析程序停止接受过程并重置计时器。
Once the timer expires, the new key will be added as a trust anchor the next time the validated RRSet with the new key is seen at the resolver. The resolver MUST NOT treat the new key as a trust anchor until the hold-down time expires AND it has retrieved and validated a DNSKEY RRSet after the hold-down time that contains the new key.
计时器过期后，下一次在解析器上看到带有新密钥的已验证RRSet时，新密钥将作为信任锚添加。解析程序不得将新密钥视为信任锚点，直到保留时间到期，并且在保留时间之后检索并验证了包含新密钥的DNSKEY RRSet。
N.B.: Once the resolver has accepted a key as a trust anchor, the key MUST be considered a valid trust anchor by that resolver until explicitly revoked as described above.
注意：一旦冲突解决程序接受密钥作为信任锚，该密钥必须被该冲突解决程序视为有效的信任锚，直到如上所述被明确撤销。
In the given example, the zone owner can recover from a compromise by revoking B and adding a new key D and signing the DNSKEY RRSet with both A and B.
在给定的示例中，区域所有者可以通过撤销B并添加新密钥D并使用a和B对DNSKEY RRSet进行签名来从妥协中恢复。
The reason this does not completely solve the problem has to do with the distributed nature of DNS. The resolver only knows what it sees. A determined attacker who holds one compromised key could keep a single resolver from realizing that the key had been compromised by intercepting 'real' data from the originating zone and substituting their own (e.g., using the example, signed only by B). This is no worse than the current situation assuming a compromised key.
这并不能完全解决问题的原因与DNS的分布式性质有关。分解程序只知道它看到了什么。持有一个受损密钥的确定攻击者可以通过截获来自发起区域的“真实”数据并替换其自己的数据（例如，使用仅由B签名的示例），阻止单个解析程序意识到密钥已受损。这并不比当前情况更糟，假设密钥已被泄露。
A resolver that has been configured for an automatic update of keys from a particular trust point MUST query that trust point (e.g., do a lookup for the DNSKEY RRSet and related RRSIG records) no less often than the lesser of 15 days, half the original TTL for the DNSKEY RRSet, or half the RRSIG expiration interval and no more often than once per hour. The expiration interval is the amount of time from when the RRSIG was last retrieved until the expiration time in the RRSIG. That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL, 1/2*RRSigExpirationInterval))
配置用于自动更新特定信任点密钥的冲突解决程序必须查询该信任点（例如，查找DNSKEY RRSet和相关RRSIG记录），查询频率不得少于15天（DNSKEY RRSet原始TTL的一半）中的较短时间，或RRSIG过期时间间隔的一半，且不超过每小时一次。过期时间间隔是从上次检索RRSIG到RRSIG中的过期时间之间的时间量。也就是说，queryInterval=最大值（1小时，最小值（15天，1/2*OrigTTL，1/2*RRSigExpirationInterval））
If the query fails, the resolver MUST repeat the query until satisfied no more often than once an hour and no less often than the lesser of 1 day, 10% of the original TTL, or 10% of the original expiration interval. That is, retryTime = MAX (1 hour, MIN (1 day, .1 * origTTL, .1 * expireInterval)).
如果查询失败，解析程序必须重复查询，直到满足为止，重复次数不得超过每小时一次，且不得少于1天、原始TTL的10%或原始过期时间间隔的10%。也就是说，retryTime=MAX（1小时，MIN（1天，.1*origTTL，.1*expireInterval））。
The add hold-down time is 30 days or the expiration time of the original TTL of the first trust point DNSKEY RRSet that contained the new key, whichever is greater. This ensures that at least two validated DNSKEY RRSets that contain the new key MUST be seen by the resolver prior to the key's acceptance.
添加保留时间为30天或包含新密钥的第一个信任点DNSKEY RRSet的原始TTL的到期时间，以较大者为准。这样可以确保在接受密钥之前，解析器必须看到至少两个包含新密钥的已验证DNSKEY RRSET。
The remove hold-down time is 30 days. This parameter is solely a key management database bookeeping parameter. Failure to remove information about the state of defunct keys from the database will not adversely impact the security of this protocol, but may end up with a database cluttered with obsolete key information.
移除压紧时间为30天。此参数仅是密钥管理数据库簿记参数。如果未能从数据库中删除有关失效密钥状态的信息，则不会对该协议的安全性产生负面影响，但最终可能会导致数据库中充斥着过时的密钥信息。
A compliant resolver MUST be able to manage at least five SEP keys per trust point.
符合要求的冲突解决程序必须能够管理每个信任点至少五个SEP密钥。
Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag. If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY) signed by the associated key, then the resolver MUST consider this key permanently invalid for all purposes except for validating the revocation.
DNSKEY标志字段的第8位被指定为“撤销”标志。如果该位设置为“1”，并且解析器看到由关联密钥签名的RRSIG（DNSKEY），则解析器必须考虑该密钥对于所有目的永久无效，除非验证撤销。
The most important thing to understand is the resolver's view of any key at a trust point. The following state table describes this view at various points in the key's lifetime. The table is a normative part of this specification. The initial state of the key is 'Start'. The resolver's view of the state of the key changes as various events occur.
要理解的最重要的事情是解析器在信任点上对任何密钥的看法。下表描述了密钥生命周期中不同时间点的此视图。该表是本规范的规范性部分。密钥的初始状态为“开始”。冲突解决程序对密钥状态的视图会随着各种事件的发生而改变。
This is the state of a trust-point key as seen from the resolver. The column on the left indicates the current state. The header at the top shows the next state. The intersection of the two shows the event that will cause the state to transition from the current state to the next.
这是从冲突解决程序中看到的信任点密钥的状态。左侧的列表示当前状态。顶部的标题显示下一个状态。两者的交点显示将导致状态从当前状态过渡到下一状态的事件。
NEXT STATE
--------------------------------------------------
FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
----------------------------------------------------------
Start | |NewKey | | | | |
----------------------------------------------------------
AddPend |KeyRem | |AddTime| | | |
----------------------------------------------------------
Valid | | | |KeyRem |Revbit | |
----------------------------------------------------------
Missing | | |KeyPres| |Revbit | |
----------------------------------------------------------
Revoked | | | | | |RemTime|
----------------------------------------------------------
Removed | | | | | | |
----------------------------------------------------------
NEXT STATE
--------------------------------------------------
FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
----------------------------------------------------------
Start | |NewKey | | | | |
----------------------------------------------------------
AddPend |KeyRem | |AddTime| | | |
----------------------------------------------------------
Valid | | | |KeyRem |Revbit | |
----------------------------------------------------------
Missing | | |KeyPres| |Revbit | |
----------------------------------------------------------
Revoked | | | | | |RemTime|
----------------------------------------------------------
Removed | | | | | | |
----------------------------------------------------------
State Table
状态表
NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. That key will become a new trust anchor for the named trust point after it's been present in the RRSet for at least 'add time'.
NewKey冲突解决程序会看到一个带有新SEP密钥的有效DNSKEY RRSet。该密钥在RRSet中存在至少“添加时间”后，将成为命名信任点的新信任锚点。
KeyPres The key has returned to the valid DNSKEY RRSet.
KeyPres密钥已返回到有效的DNSKEY RRSet。
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain this key.
KeyRem冲突解决程序会看到不包含此密钥的有效DNSKEY RRSet。
AddTime The key has been in every valid DNSKEY RRSet seen for at least the 'add time'.
AddTime该密钥已在每个有效DNSKEY RRSet中出现至少一个“add time”。
RemTime A revoked key has been missing from the trust-point DNSKEY RRSet for sufficient time to be removed from the trust set.
RemTime信任点DNSKEY RRSet中缺少已吊销密钥的时间足以从信任集中删除。
RevBit The key has appeared in the trust anchor DNSKEY RRSet with its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet signed by this key.
RevBit密钥已出现在信任锚点DNSKEY RRSet中，其位集为“已撤销”，并且该密钥签名的DNSKEY RRSet上存在RRSig。
Start The key doesn't yet exist as a trust anchor at the resolver. It may or may not exist at the zone server, but either hasn't yet been seen at the resolver or was seen but was absent from the last DNSKEY RRSet (e.g., KeyRem event).
启动密钥在解析程序中尚未作为信任锚点存在。它可能存在于区域服务器上，也可能不存在于区域服务器上，但在解析程序上尚未看到，或者在上次DNSKEY RRSet中未看到（例如，KeyRem事件）。
AddPend The key has been seen at the resolver, has its 'SEP' bit set, and has been included in a validated DNSKEY RRSet. There is a hold-down time for the key before it can be used as a trust anchor.
AddPend已在解析器处看到密钥，设置了其“SEP”位，并已包含在已验证的DNSKEY RRSet中。密钥在用作信任锚之前有一段按住时间。
Valid The key has been seen at the resolver and has been included in all validated DNSKEY RRSets from the time it was first seen through the hold-down time. It is now valid for verifying RRSets that arrive after the hold-down time. Clarification: The DNSKEY RRSet does not need to be continuously present at the resolver (e.g., its TTL might expire). If the RRSet is seen and is validated (i.e., verifies against an existing trust anchor), this key MUST be in the RRSet, otherwise a 'KeyRem' event is triggered.
有效密钥已在冲突解决程序中看到，并且从第一次看到密钥到按下时间，密钥已包含在所有已验证的DNSKEY RRSET中。它现在对验证在按住时间之后到达的RRSET有效。澄清：DNSKEY RRSet不需要持续存在于解析器中（例如，其TTL可能过期）。如果看到并验证了RRSet（即，根据现有信任锚点进行验证），则此密钥必须位于RRSet中，否则会触发“KeyRem”事件。
Missing This is an abnormal state. The key remains a valid trust-point key, but was not seen at the resolver in the last validated DNSKEY RRSet. This is an abnormal state because the zone operator should be using the REVOKE bit prior to removal.
错过这是一种异常状态。密钥仍然是有效的信任点密钥，但在上次验证的DNSKEY RRSet中的解析程序中未看到该密钥。这是一种异常状态，因为区域操作员在删除之前应该使用REVOKE位。
Revoked This is the state a key moves to once the resolver sees an RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains this key with its REVOKE bit set to '1'. Once in this state, this key MUST permanently be considered invalid as a trust anchor.
已撤销这是冲突解决程序看到由该密钥签名的RRSIG（DNSKEY）后密钥移动到的状态，其中DNSKEY RRSet包含该密钥，其撤销位设置为“1”。一旦处于这种状态，此密钥作为信任锚必须被永久视为无效。
Removed After a fairly long hold-down time, information about this key may be purged from the resolver. A key in the removed state MUST NOT be considered a valid trust anchor. (Note: this state is more or less equivalent to the "Start" state, except that it's bad practice to re-introduce previously used keys -- think of this as the holding state for all the old keys for which the resolver no longer needs to track state.)
在相当长的按住时间后删除，有关此密钥的信息可能会从冲突解决程序中清除。处于已删除状态的密钥不能被视为有效的信任锚。（注意：此状态或多或少相当于“开始”状态，只是重新引入以前使用的密钥是一种不好的做法——可以将此视为解析程序不再需要跟踪状态的所有旧密钥的保持状态。）
A trust point that has all of its trust anchors revoked is considered deleted and is treated as if the trust point was never configured. If there are no superior configured trust points, data at and below the deleted trust point are considered insecure by the resolver. If there ARE superior configured trust points, data at and below the deleted trust point are evaluated with respect to the superior trust point(s).
已撤销其所有信任锚点的信任点被视为已删除，并被视为从未配置过该信任点。如果没有高级配置的信任点，则解析程序会认为删除的信任点处及其以下的数据不安全。如果存在已配置的上级信任点，则将根据上级信任点评估已删除信任点处及其下方的数据。
Alternately, a trust point that is subordinate to another configured trust point MAY be deleted by a resolver after 180 days, where such a
或者，从属于另一个配置的信任点的信任点可以在180天后由解析器删除，其中这样的信任点
subordinate trust point validly chains to a superior trust point. The decision to delete the subordinate trust anchor is a local configuration decision. Once the subordinate trust point is deleted, validation of the subordinate zone is dependent on validating the chain of trust to the superior trust point.
下级信任点有效地链接到上级信任点。删除从属信任锚点的决定是本地配置决定。删除下级信任点后，下级区域的验证取决于验证到上级信任点的信任链。
The suggested model for operation is to have one active key and one stand-by key at each trust point. The active key will be used to sign the DNSKEY RRSet. The stand-by key will not normally sign this RRSet, but the resolver will accept it as a trust anchor if/when it sees the signature on the trust point DNSKEY RRSet.
建议的操作模型是在每个信任点有一个活动密钥和一个备用密钥。活动密钥将用于对DNSKEY RRSet进行签名。备用密钥通常不会对此RRSet进行签名，但如果/当冲突解决程序在信任点DNSKEY RRSet上看到签名时，它将接受此RRSet作为信任锚点。
Since the stand-by key is not in active signing use, the associated private key may (and should) be provided with additional protections not normally available to a key that must be used frequently (e.g., locked in a safe, split among many parties, etc). Notionally, the stand-by key should be less subject to compromise than an active key, but that will be dependent on operational concerns not addressed here.
由于备用密钥未处于主动签名使用中，因此相关私钥可能（并且应该）具有通常对必须频繁使用的密钥不可用的附加保护（例如，锁定在保险箱中，在多方之间分割等）。从理论上讲，备用密钥比活动密钥更容易受到损害，但这取决于此处未提及的操作问题。
Assume an existing trust anchor key 'A'.
假设存在信任锚密钥“A”。
1. Generate a new key pair.
1. 生成一个新的密钥对。
2. Create a DNSKEY record from the key pair and set the SEP and Zone Key bits.
2. 从密钥对创建DNSKEY记录，并设置SEP和区域密钥位。
3. Add the DNSKEY to the RRSet.
3. 将DNSKEY添加到RRSet。
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - 'A'.
4. 仅使用现有信任锚密钥“A”对DNSKEY RRSet进行签名。
5. Wait for various resolvers' timers to go off and for them to retrieve the new DNSKEY RRSet and signatures.
5. 等待各种解析程序的计时器关闭，等待它们检索新的DNSKEY RRSet和签名。
6. The new trust anchor will be populated at the resolvers on the schedule described by the state table and update algorithm -- see Sections 2 and 4 above.
6. 新的信任锚将按照状态表和更新算法所描述的时间表在解析器中填充——请参见上面的第2节和第4节。
Assume existing trust anchors 'A' and 'B' and that you want to revoke and delete 'A'.
假设现有信任锚定“A”和“B”，并且您希望撤销和删除“A”。
1. Set the revocation bit on key 'A'.
1. 设置密钥“A”上的吊销位。
2. Sign the DNSKEY RRSet with both 'A' and 'B'. 'A' is now revoked. The operator should include the revoked 'A' in the RRSet for at least the remove hold-down time, but then may remove it from the DNSKEY RRSet.
2. 使用“A”和“B”对DNSKEY RRSet进行签名A'现在被撤销。操作员应在RRSet中包含已撤销的“A”，至少保留删除保留时间，但随后可将其从DNSKEY RRSet中删除。
Assume existing keys A and B. 'A' is actively in use (i.e. has been signing the DNSKEY RRSet). 'B' was the stand-by key. (i.e. has been in the DNSKEY RRSet and is a valid trust anchor, but wasn't being used to sign the RRSet).
假设现有密钥A和B。“A”正在使用中（即已对DNSKEY RRSet进行签名）。”B'是备用钥匙。（即，已在DNSKEY RRSet中，是有效的信任锚点，但未用于签署RRSet）。
1. Generate a new key pair 'C'. 2. Add 'C' to the DNSKEY RRSet. 3. Set the revocation bit on key 'A'. 4. Sign the RRSet with 'A' and 'B'.
1. 生成新密钥对“C”。2.将“C”添加到DNSKEY RRSet。3.设置密钥“A”上的吊销位。4.用“A”和“B”对RRSet进行签名。
'A' is now revoked, 'B' is now the active key, and 'C' will be the stand-by key once the hold-down expires. The operator should include the revoked 'A' in the RRSet for at least the remove hold-down time, but may then remove it from the DNSKEY RRSet.
“A”现在被撤销，“B”现在是活动密钥，“C”将是保留到期后的备用密钥。操作员应在RRSet中包含已撤销的“A”，至少保留删除保留时间，但随后可将其从DNSKEY RRSet中删除。
This is the same as the mechanism for Key Roll-Over (Section 6.3) above, assuming 'A' is the active key.
这与上面的钥匙翻滚机制（第6.3节）相同，假设“A”是活动钥匙。
Using the same assumptions and naming conventions as Key Roll-Over (Section 6.3) above:
使用与上述键翻转（第6.3节）相同的假设和命名约定：
1. Generate a new key pair 'C'. 2. Add 'C' to the DNSKEY RRSet. 3. Set the revocation bit on key 'B'. 4. Sign the RRSet with 'A' and 'B'.
1. 生成新密钥对“C”。2.将“C”添加到DNSKEY RRSet。3.在密钥“B”上设置吊销位。4.用“A”和“B”对RRSet进行签名。
'B' is now revoked, 'A' remains the active key, and 'C' will be the stand-by key once the hold-down expires. 'B' should continue to be included in the RRSet for the remove hold-down time.
“B”现在被撤销，“A”仍然是活动密钥，“C”将在按住到期后成为备用密钥B'应继续包含在RRSet中，以用于移除压紧时间。
To delete a trust point that is subordinate to another configured trust point (e.g., example.com to .com) requires some juggling of the data. The specific process is:
要删除从属于另一个配置的信任点（例如，example.com到.com）的信任点，需要对数据进行一些处理。具体流程为：
1. Generate a new DNSKEY and DS record and provide the DS record to the parent along with DS records for the old keys.
1. 生成新的DNSKEY和DS记录，并将DS记录与旧密钥的DS记录一起提供给父级。
2. Once the parent has published the DSs, add the new DNSKEY to the RRSet and revoke ALL of the old keys at the same time, while signing the DNSKEY RRSet with all of the old and new keys.
2. 父级发布DSs后，将新的DNSKEY添加到RRSet并同时撤销所有旧密钥，同时使用所有旧密钥和新密钥对DNSKEY RRSet进行签名。
3. After 30 days, stop publishing the old, revoked keys and remove any corresponding DS records in the parent.
3. 30天后，停止发布旧的、已撤销的密钥，并删除父级中的任何相应DS记录。
Revoking the old trust-point keys at the same time as adding new keys that chain to a superior trust prevents the resolver from adding the new keys as trust anchors. Adding DS records for the old keys avoids a race condition where either the subordinate zone becomes unsecure (because the trust point was deleted) or becomes bogus (because it didn't chain to the superior zone).
在添加链接到上级信任的新密钥的同时撤消旧信任点密钥，可防止冲突解决程序将新密钥添加为信任锚。为旧密钥添加DS记录可以避免竞争条件，即从属区域变得不安全（因为信任点被删除）或变得虚假（因为它没有链接到上级区域）。
The IANA has assigned a bit in the DNSKEY flags field (see Section 7 of [RFC4034]) for the REVOKE bit (8).
IANA已在DNSKEY标志字段（参见[RFC4034]第7节）中为撤销位（8）分配了一个位。
In addition to the following sections, see also Theory of Operation above (Section 2) and especially Section 2.2 for related discussions.
除以下章节外，相关讨论请参见上述操作理论（第2节），特别是第2.2节。
Security considerations for trust anchor rollover not specific to this protocol are discussed in [RFC4986].
[RFC4986]中讨论了不特定于此协议的信任锚点滚动的安全注意事项。
The reader should note that, while the zone owner is responsible for creating and distributing keys, it's wholly the decision of the resolver owner as to whether to accept such keys for the authentication of the zone information. This implies the decision to update trust-anchor keys based on trusting a current trust-anchor key is also the resolver owner's decision.
读者应该注意，虽然区域所有者负责创建和分发密钥，但是否接受这些密钥以验证区域信息完全由解析器所有者决定。这意味着基于信任当前信任锚密钥来更新信任锚密钥的决定也是冲突解决程序所有者的决定。
The resolver owner (and resolver implementers) MAY choose to permit or prevent key status updates based on this mechanism for specific trust points. If they choose to prevent the automated updates, they will need to establish a mechanism for manual or other out-of-band updates, which are outside the scope of this document.
冲突解决程序所有者（和冲突解决程序实现者）可以选择基于此机制允许或阻止特定信任点的密钥状态更新。如果他们选择阻止自动更新，他们将需要建立手动或其他带外更新的机制，这些更新不在本文档的范围内。
This scheme permits recovery as long as at least one valid trust-anchor key remains uncompromised, e.g., if there are three keys, you can recover if two of them are compromised. The zone owner should determine their own level of comfort with respect to the number of active, valid trust anchors in a zone and should be prepared to implement recovery procedures once they detect a compromise. A manual or other out-of-band update of all resolvers will be required if all trust-anchor keys at a trust point are compromised.
此方案允许恢复，只要至少有一个有效的信任锚密钥保持不妥协，例如，如果有三个密钥，如果其中两个密钥妥协，则可以恢复。区域所有者应根据区域中有效的活动信任锚的数量确定自己的舒适度，并应准备在检测到妥协后实施恢复程序。如果某个信任点上的所有信任锚密钥都被泄露，则需要对所有解析程序进行手动或其他带外更新。
Allowing a resolver to update its trust anchor set based on in-band key information is potentially less secure than a manual process. However, given the nature of the DNS, the number of resolvers that would require update if a trust anchor key were compromised, and the lack of a standard management framework for DNS, this approach is no worse than the existing situation.
允许解析器基于带内密钥信息更新其信任锚集可能比手动过程更不安全。然而，考虑到DNS的性质、信任锚密钥受损时需要更新的解析程序的数量以及DNS缺乏标准管理框架，这种方法并不比现有情况更糟糕。
[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月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[RFC3755]Weiler，S.“委托签名者（DS）的传统解析器兼容性”，RFC 3755，2004年5月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy, "Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover", RFC 4986, August 2007.
[RFC4986]Eland，H.，Mundy，R.，Crocker，S.，和S.Krishnaswamy，“与DNS安全（DNSSEC）信任锚滚动相关的要求”，RFC 49862007年8月。
Author's Address
作者地址
Michael StJohns Independent
迈克尔·斯特约翰独立报
EMail: mstjohns@comcast.net
EMail: mstjohns@comcast.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.