Network Working Group E. Lewis
Request for Comments: 3090 NAI Labs
Category: Standards Track March 2001
Network Working Group E. Lewis
Request for Comments: 3090 NAI Labs
Category: Standards Track March 2001
DNS Security Extension Clarification on Zone Status
DNS安全扩展对区域状态的说明
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated.
介绍了安全区的定义，澄清并更新了RFC 2535的章节。RFC 2535基于每个算法定义了要保护的区域，例如，可以使用RSA密钥保护区域，而不使用DSA密钥保护区域。本文档对此进行了更改，以定义要保护或不保护的区域，而不考虑使用（或未使用）的密钥算法。为了进一步简化区域状态的确定，不推荐使用“实验安全”状态。
1 Introduction
1导言
Whether a DNS zone is "secured" or not is a question asked in at least four contexts. A zone administrator asks the question when configuring a zone to use DNSSEC. A dynamic update server asks the question when an update request arrives, which may require DNSSEC processing. A delegating zone asks the question of a child zone when the parent enters data indicating the status the child. A resolver asks the question upon receipt of data belonging to the zone.
DNS区域是否“安全”是至少在四种情况下提出的问题。将区域配置为使用DNSSEC时，区域管理员会询问此问题。动态更新服务器在更新请求到达时询问问题，这可能需要DNSSEC处理。当父区域输入指示子区域状态的数据时，委托区域会询问子区域的问题。冲突解决程序在收到属于该区域的数据时提出该问题。
A zone administrator needs to be able to determine what steps are needed to make the zone as secure as it can be. Realizing that due to the distributed nature of DNS and its administration, any single zone is at the mercy of other zones when it comes to the appearance of security. This document will define what makes a zone qualify as secure.
区域管理员需要能够确定使区域尽可能安全所需的步骤。意识到由于DNS及其管理的分布式性质，任何单个区域在安全性方面都受其他区域的支配。本文档将定义如何使区域符合安全条件。
A name server performing dynamic updates needs to know whether a zone being updated is to have signatures added to the updated data, NXT records applied, and other required processing. In this case, it is conceivable that the name server is configured with the knowledge, but being able to determine the status of a zone by examining the data is a desirable alternative to configuration parameters.
执行动态更新的名称服务器需要知道正在更新的区域是否将签名添加到更新的数据、应用的NXT记录以及其他所需的处理。在这种情况下，可以想象名称服务器是用知识配置的，但是能够通过检查数据来确定区域的状态是配置参数的理想替代方案。
A delegating zone is required to indicate whether a child zone is secured. The reason for this requirement lies in the way in which a resolver makes its own determination about a zone (next paragraph). To shorten a long story, a parent needs to know whether a child should be considered secured. This is a two part question. Under what circumstances does a parent consider a child zone to be secure, and how does a parent know if the child conforms?
需要授权区域来指示子区域是否安全。此要求的原因在于解析器自行确定分区的方式（下一段）。长话短说，父母需要知道孩子是否应该被视为安全的。这是一个由两部分组成的问题。在什么情况下，家长认为儿童区是安全的，家长如何知道孩子是否符合？
A resolver needs to know if a zone is secured when the resolver is processing data from the zone. Ultimately, a resolver needs to know whether or not to expect a usable signature covering the data. How this determination is done is out of the scope of this document, except that, in some cases, the resolver will need to contact the parent of the zone to see if the parent states that the child is secured.
当解析程序处理来自某个区域的数据时，解析程序需要知道该区域是否安全。最终，解析器需要知道是否需要覆盖数据的可用签名。如何确定超出了本文档的范围，但在某些情况下，冲突解决程序需要联系区域的父级，以查看父级是否声明子级已安全。
The goal of DNSSEC is to have each zone secured, from the root zone and the top-level domains down the hierarchy to the leaf zones. Transitioning from an unsecured DNS, as we have now, to a fully secured - or "as much as will be secured" - tree will take some time. During this time, DNSSEC will be applied in various locations in the tree, not necessarily "top down."
DNSSEC的目标是保护每个区域，从根区域和顶级域到层次结构，再到叶区域。从一个不安全的DNS过渡到一个完全安全的——或者“尽可能安全的”——树需要一些时间。在此期间，DNSSEC将应用于树中的不同位置，而不一定是“自上而下”
For example, at a particular instant, the root zone and the "test." TLD might be secured, but region1.test. might not be. (For reference, let's assume that region2.test. is secured.) However, subarea1.region1.test. may have gone through the process of becoming secured, along with its delegations. The dilemma here is that subarea1 cannot get its zone keys properly signed as its parent zone, region1, is not secured.
例如，在特定时刻，根区域和“test.”TLD可能是安全的，但region1.test是安全的。可能不是。（作为参考，我们假设region2.test.是安全的。）但是，subrea1.region1.test。可能与代表团一起经历了安全的过程。这里的困境是，由于其父区域region1不安全，因此Subrea1无法正确签名其区域密钥。
The colloquial phrase describing the collection of contiguous secured zones at or below subarea1.region1.test. is an "island of security." The only way in which a DNSSEC resolver will come to trust any data from this island is if the resolver is pre-configured with the zone key(s) for subarea1.region1.test., i.e., the root of the island of security. Other resolvers (not so configured) will recognize this island as unsecured.
描述在subrea1.region1.test或其下连续安全区集合的口语短语。是一个“安全岛”。DNSSEC解析程序信任来自该岛的任何数据的唯一方式是，如果该解析程序预先配置了Subrea1.region1.test.的区域密钥，即安全岛的根。其他解析程序（未配置）会将此孤岛识别为不安全。
An island of security begins with one zone whose public key is pre-configured in resolvers. Within this island are subzones which are also secured. The "bottom" of the island is defined by delegations to unsecured zones. One island may also be on top of another - meaning that there is at least one unsecured zone between the bottom of the upper island and the root of the lower secured island.
安全岛从一个区域开始，该区域的公钥在解析器中预先配置。在这个岛上有一些分区，这些分区也是安全的。该岛的“底部”由代表团前往无安全区界定。一个岛也可能位于另一个岛的顶部，这意味着在上部岛的底部和下部安全岛的根部之间至少有一个不安全区域。
Although both subarea1.region1.test. and region2.test. have both been properly brought to a secured state by the administering staff, only the latter of the two is actually "globally" secured - in the sense that all DNSSEC resolvers can and will verify its data. The former, subarea1, will be seen as secured by a subset of those resolvers, just those appropriately configured. This document refers to such zones as being "locally" secured.
尽管这两个子区域1.region1.test。和区域2.test。管理人员已将两者适当地置于安全状态，但实际上只有后者是“全局”安全的，即所有DNSSEC解析器都可以并将验证其数据。前者，即Subrea1，将被视为是由这些解析器的子集保护的，只是那些适当配置的解析器。本文件指的是“本地”安全的区域。
In RFC 2535, there is a provision for "certification authorities," entities that will sign public keys for zones such as subarea1. There is another document, [RFC3008], that restricts this activity. Regardless of the other document, resolvers would still need proper configuration to be able to use the certification authority to verify the data for the subarea1 island.
在RFC 2535中，有一个“证书颁发机构”的规定，即为分区1等区域签署公钥的实体。还有另一个文档[RFC3008]限制此活动。不管其他文档如何，解析程序仍然需要正确的配置才能使用证书颁发机构来验证分区1孤岛的数据。
Given a domain, in order to determine whether it is secure or not, the first step is to determine the closest security root. The closest security root is the top of an island of security whose name has the most matching (in order from the root) right-most labels to the given domain.
给定一个域，为了确定它是否安全，第一步是确定最近的安全根。最近的安全根是安全岛的顶部，其名称与给定域的最右端标签最匹配（按根的顺序排列）。
For example, given a name "sub.domain.testing.signed.exp.test.", and given the secure roots "exp.test.", "testing.signed.exp.test." and "not-the-same.xy.", the middle one is the closest. The first secure root shares 2 labels, the middle 4, and the last 0.
例如，给定名称“sub.domain.testing.signed.exp.test.”，并给定安全根“exp.test.”、“testing.signed.exp.test.”和“not the same.xy.”，中间的一个是最接近的。第一个安全根共享2个标签，中间4个，最后0个。
The reason why the closest is desired is to eliminate false senses of
insecurity because of a NULL key. Continuing with the example, the
reason both "testing..." and "exp.test." are listed as secure root is
presumably because "signed.exp.test." is unsecured (has a NULL key).
If we started to descend from "exp.test." to our given domain
(sub...), we would encounter a NULL key and conclude that sub... was
unsigned. However, if we descend from "testing..." and find keys
"domain...." then we can conclude that "sub..." is secured.
The reason why the closest is desired is to eliminate false senses of
insecurity because of a NULL key. Continuing with the example, the
reason both "testing..." and "exp.test." are listed as secure root is
presumably because "signed.exp.test." is unsecured (has a NULL key).
If we started to descend from "exp.test." to our given domain
(sub...), we would encounter a NULL key and conclude that sub... was
unsigned. However, if we descend from "testing..." and find keys
"domain...." then we can conclude that "sub..." is secured.
Note that this example assumes one-label deep zones, and assumes that we do not configure overlapping islands of security. To be clear, the definition given should exclude "short.xy.test." from being a closest security root for "short.xy." even though 2 labels match.
请注意，此示例假设一个标签为深层区域，并且假设我们没有配置重叠的安全岛。为了清楚起见，给出的定义应该将“short.xy.test.”排除在“short.xy.”最接近的安全根之外，即使有两个标签匹配。
Overlapping islands of security introduce no conceptually interesting ideas and do not impact the protocol in anyway. However, protocol implementers are advised to make sure their code is not thrown for a loop by overlaps. Overlaps are sure to be configuration problems as islands of security grow to encompass larger regions of the name space.
重叠的安全孤岛不会引入任何概念上有趣的想法，也不会影响协议。但是，建议协议实现者确保他们的代码不会因重叠而引发循环。重叠肯定是配置问题，因为安全孤岛逐渐扩展到包含更大的名称空间区域。
In 1.1 of this document, there is the comment "the parent states that the child is secured." This has caused quite a bit of confusion.
在本文档的1.1中，有一条注释“家长声明孩子是安全的。”这引起了相当多的混乱。
The need to have the parent "state" the status of a child is derived from the following observation. If you are looking to see if an answer is secured, that it comes from an "island of security" and is properly signed, you must begin at the (appropriate) root of the island of security.
需要让父母“陈述”孩子的状态是从以下观察得出的。如果您希望查看答案是否安全，是否来自“安全岛”并正确签名，则必须从安全岛的（适当）根开始。
To find the answer you are inspecting, you may have to descend through zones within the island of security. Beginning with the trusted root of the island, you descend into the next zone down. As you trust the upper zone, you need to get data from it about the next zone down, otherwise there is a vulnerable point in which a zone can be hijacked. When or if you reach a point of traversing from a secured zone to an unsecured zone, you have left the island of security and should conclude that the answer is unsecured.
为了找到你正在检查的答案，你可能必须穿过安全岛内的区域。从岛的可靠根开始，你下降到下一个区域。由于您信任上层区域，因此需要从上层区域获取关于下层区域的数据，否则存在一个容易被劫持的脆弱点。当或如果您到达从安全区域到不安全区域的穿越点时，您已经离开了安全岛，应该得出结论，答案是不安全的。
However, in RFC 2535, section 2.3.4, these words seem to conflict with the need to have the parent "state" something about a child:
然而，在RFC 2535第2.3.4节中，这些词语似乎与父母“陈述”子女的需要相冲突：
There MUST be a zone KEY RR, signed by its superzone, for every subzone if the superzone is secure. This will normally appear in the subzone and may also be included in the superzone. But, in the case of an unsecured subzone which can not or will not be modified to add any security RRs, a KEY declaring the subzone to be unsecured MUST appear with the superzone signature in the superzone, if the superzone is secure.
如果超区域是安全的，则每个子区域都必须有一个由其超区域签名的区域密钥RR。这通常会出现在分区中，也可能包含在超分区中。但是，如果某个不安全的子区域不能或不会被修改以添加任何安全RRs，则如果该超区域是安全的，则声明该子区域为不安全的密钥必须与超区域签名一起出现在超区域中。
The confusion here is that in RFC 2535, a secured parent states that a child is secured by SAYING NOTHING ("may also be" as opposed to "MUST also be"). This is counter intuitive, the fact that an absence of data means something is "secured." This notion, while acceptable in a theoretic setting has met with some discomfort in an operation setting. However, the use of "silence" to state something does indeed work in this case, so there hasn't been sufficient need demonstrated to change the definition.
这里的混乱之处在于，在RFC 2535中，有担保的父母声明，孩子是通过不说话（“也可以”而不是“也必须”）来担保的。这是违反直觉的，缺少数据意味着某些东西是“安全的”。这一概念虽然在理论环境中可以接受，但在手术环境中却遇到了一些不适。然而，在这种情况下，使用“沉默”来陈述某些事情确实有效，因此没有足够的证据表明需要改变定义。
This document updates sections of RFC 2535. The definition of a secured zone is an update to section 3.4 of the RFC. Section 3.4 is updated to eliminate the definition of experimental keys and illustrate a way to still achieve the functionality they were designed to provide. Section 3.1.3 is updated by the specifying the value of the protocol octet in a zone key.
本文件更新了RFC 2535的章节。安全区的定义是对RFC第3.4节的更新。第3.4节进行了更新，以消除实验键的定义，并说明如何仍然实现其设计提供的功能。第3.1.3节通过指定区域密钥中协议八位字节的值进行更新。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC 2119]. Currently, only "MUST" is used in this document.
本文件中的关键词“必须”、“要求”、“应该”、“建议”和“可能”应按照[RFC 2119]中所述进行解释。目前，本文件中仅使用“必须”。
2 Status of a Zone
2区域的状态
In this section, rules governing a zone's DNSSEC status are presented. There are three levels of security defined: global, local, and unsecured. A zone is globally secure when it complies with the strictest set of DNSSEC processing rules. A zone is locally secured when it is configured in such a way that only resolvers that are appropriately configured see the zone as secured. All other zones are unsecured.
本节介绍了管理区域DNSSEC状态的规则。定义了三个安全级别：全局、本地和无担保。当符合最严格的DNSSEC处理规则集时，区域是全局安全的。当区域的配置方式只有经过适当配置的解析程序才能将该区域视为安全区域时，该区域才处于本地安全状态。所有其他区域都是不安全的。
Note: there currently is no document completely defining DNSSEC verification rules. For the purposes of this document, the strictest rules are assumed to state that the verification chain of zone keys parallels the delegation tree up to the root zone. (See 2.b below.) This is not intended to disallow alternate verification paths, just to establish a baseline definition.
注：目前没有完全定义DNSSEC验证规则的文件。在本文件中，假设最严格的规则规定，区域密钥的验证链与根区域的委托树平行。（参见下面的2.b.）这并不是为了禁止备用验证路径，只是为了建立一个基线定义。
To avoid repetition in the rules below, the following terms are defined.
为避免在以下规则中重复，定义了以下术语。
2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01 for name type (indicating a zone key) and either value 00 or value 01 for key type (indicating a key permitted to authenticate data). (See RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value of DNSSEC (3) or ALL (255).
2.区域签名密钥RR-其标志字段的值01表示名称类型（表示区域密钥），值00或值01表示密钥类型（表示允许对数据进行身份验证的密钥）的密钥RR。（见RFC 2535第3.1.2节）。密钥RR还具有DNSSEC（3）或ALL（255）的协议八位字节值。
The definition updates RFC 2535's definition of a zone key. The requirement that the protocol field be either DNSSEC or ALL is a new requirement (a change to section 3.1.3.)
该定义更新RFC 2535的区域密钥定义。协议字段为DNSSEC或ALL的要求是新的要求（对第3.1.3节的变更）
2.b On-tree Validation - The authorization model in which only the parent zone is recognized to supply a DNSSEC-meaningful signature that is used by a resolver to build a chain of trust from the child's
2.b树上验证-授权模型，其中仅识别父区域以提供DNSSEC有意义的签名，解析程序使用该签名从子区域建立信任链
keys to a recognized root of security. The term "on-tree" refers to following the DNS domain hierarchy (upwards) to reach a trusted key, presumably the root key if no other key is available. The term "validation" refers to the digital signature by the parent to prove the integrity, authentication and authorization of the child's key to sign the child's zone data.
可识别的安全根的密钥。术语“在树上”是指遵循DNS域层次结构（向上）以达到一个受信任的密钥，如果没有其他密钥可用，则可能是根密钥。“验证”一词是指父母为证明儿童密钥的完整性、身份验证和授权而对儿童区域数据进行签名的数字签名。
2.c Off-tree Validation - Any authorization model that permits domain names other than the parent's to provide a signature over a child's zone keys that will enable a resolver to trust the keys.
2.c非树验证-任何授权模型，允许除父域名以外的域名在子域名的区域密钥上提供签名，使解析器能够信任密钥。
A globally secured zone, in a nutshell, is a zone that uses only mandatory to implement algorithms (RFC 2535, section 3.2) and relies on a key certification chain that parallels the delegation tree (on-tree validation). Globally secured zones are defined by the following rules.
简言之，全局安全区域是一个仅使用强制实现算法（RFC 2535，第3.2节）的区域，并且依赖于与委托树平行的密钥认证链（树上验证）。全局安全区域由以下规则定义。
2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least one zone signing KEY RR (2.a) of a mandatory to implement algorithm in the set.
2.1.a。分区的顶点必须设置一个键RR。必须至少有一个强制的区域签名密钥RR（2.a），才能在集合中实现算法。
2.1.b. The zone's apex KEY RR set MUST be signed by a private key belonging to the parent zone. The private key's public companion MUST be a zone signing KEY RR (2.a) of a mandatory to implement algorithm and owned by the parent's apex.
2.1.b。区域的顶点密钥RR集必须由属于父区域的私钥签名。私钥的公共伙伴必须是强制实现算法的区域签名密钥RR（2.a），并由父级apex拥有。
If a zone cannot get a conforming signature from the parent zone, the child zone cannot be considered globally secured. The only exception to this is the root zone, for which there is no parent zone.
如果区域无法从父区域获得一致性签名，则子区域不能被视为全局安全。唯一的例外是根区域，它没有父区域。
2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies RFC 2535, section 2.3.2.) Note: there is some operational discomfort with the current NXT record. This requirement is open to modification when two things happen. First, an alternate mechanism to the NXT is defined and second, a means by which a zone can indicate that it is using an alternate method.
2.1.c。必须在整个区域中部署NXT记录。（澄清RFC 2535，第2.3.2节。）注：当前NXT记录存在一些操作不适。当发生两种情况时，此要求可以修改。首先，定义了NXT的替代机制；其次，定义了一种区域可以指示其正在使用替代方法的方法。
2.1.d. Each RR set that qualifies for zone membership MUST be signed by a key that is in the apex's KEY RR set and is a zone signing KEY RR (2.a) of a mandatory to implement algorithm. (Updates 2535, section 2.3.1.)
2.1.d。每个符合区域成员资格的RR集都必须由apex的密钥RR集中的密钥签名，并且该密钥是强制实现算法的区域签名密钥RR（2.a）。（更新2535，第2.3.1节。）
Mentioned earlier, the root zone is a special case. The root zone will be considered to be globally secured provided that if conforms to the rules for locally secured, with the exception that rule 2.1.a. be also met (mandatory to implement requirement).
前面提到过，根区域是一个特例。根区域将被认为是全局安全的，前提是如果符合本地安全的规则，则规则2.1.a除外。还应满足（强制实施要求）。
The term "locally" stems from the likely hood that the only resolvers to be configured for a particular zone will be resolvers "local" to an organization.
术语“本地”源于这样一种情况，即为特定区域配置的唯一解析程序可能是组织的“本地”解析程序。
A locally secured zone is a zone that complies with rules like those for a globally secured zone with the following exceptions. The signing keys may be of an algorithm that is not mandatory to implement and/or the verification of the zone keys in use may rely on a verification chain that is not parallel to the delegation tree (off-tree validation).
本地安全区域是指符合全球安全区域规则的区域，但以下情况除外。签名密钥可以是非强制实现的算法，和/或正在使用的区域密钥的验证可以依赖于与委托树（树外验证）不平行的验证链。
2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least one zone signing KEY RR (2.a) in the set.
2.2.a。分区的顶点必须设置一个键RR。集合中必须至少有一个区域签名密钥RR（2.a）。
2.2.b. The zone's apex KEY RR set MUST be signed by a private key and one of the following two subclauses MUST hold true.
2.2.b。区域的apex密钥RR集必须由私钥签名，并且以下两个子类之一必须为true。
2.2.b.1 The private key's public companion MUST be pre-configured in all the resolvers of interest.
2.2.b.1私钥的公共伴侣必须在所有感兴趣的解析程序中预先配置。
2.2.b.2 The private key's public companion MUST be a zone signing KEY RR (2.a) authorized to provide validation of the zone's apex KEY RR set, as recognized by resolvers of interest.
2.2.b.2私钥的公共伴侣必须是一个区域签名密钥RR（2.a），该密钥被授权提供区域顶点密钥RR集的验证，如相关解析程序所识别。
The previous sentence is trying to convey the notion of using a trusted third party to provide validation of keys. If the domain name owning the validating key is not the parent zone, the domain name must represent someone the resolver trusts to provide validation.
前一句话试图传达使用可信第三方提供密钥验证的概念。如果拥有验证密钥的域名不是父区域，则该域名必须代表解析程序信任的提供验证的人。
2.2.c. NXT records MUST be deployed throughout the zone. Note: see the discussion following 2.1.c.
2.2.c。必须在整个区域中部署NXT记录。注：见下面2.1.c的讨论。
2.2.d. Each RR set that qualifies for zone membership MUST be signed by a key that is in the apex's KEY RR set and is a zone signing KEY RR (2.a). (Updates 2535, section 2.3.1.)
2.2.d。每个符合区域成员资格的RR集都必须由apex的密钥RR集中的一个密钥签名，该密钥是区域签名密钥RR（2.a）。（更新2535，第2.3.1节。）
All other zones qualify as unsecured. This includes zones that are designed to be experimentally secure, as defined in a later section on that topic.
所有其他区域都属于无担保区。这包括设计为实验安全的区域，如该主题后面一节中所定义。
The designation of globally secured, locally secured, and unsecured are merely labels to apply to zones, based on their contents. Resolvers, when determining whether a signature is expected or not, will only see a zone as secured or unsecured.
全球安全、本地安全和非安全的指定仅仅是根据区域内容应用于区域的标签。解析程序在确定是否需要签名时，只会将区域视为安全区域或非安全区域。
Resolvers that follow the most restrictive DNSSEC verification rules will only see globally secured zones as secured, and all others as unsecured, including zones which are locally secured. Resolvers that are not as restrictive, such as those that implement algorithms in addition to the mandatory to implement algorithms, will see some locally secured zones as secured.
遵循最严格的DNSSEC验证规则的解析程序只会将全局安全区域视为安全区域，而将所有其他区域视为不安全区域，包括本地安全区域。没有那么严格的解析程序（例如除了强制实现算法之外还实现算法的解析程序）会将一些本地安全区域视为安全区域。
The intent of the labels "global" and "local" is to identify the specific attributes of a zone. The words are chosen to assist in the writing of a document recommending the actions a zone administrator take in making use of the DNS security extensions. The words are explicitly not intended to convey a state of compliance with DNS security standards.
“全局”和“局部”标签的目的是识别分区的特定属性。选择这些词是为了帮助编写一份文件，建议区域管理员在使用DNS安全扩展时采取的措施。这些词语明确不表示符合DNS安全标准的状态。
3 Experimental Status
3实验状态
The purpose of an experimentally secured zone is to facilitate the migration from an unsecured zone to a secured zone. This distinction is dropped.
实验性安全区的目的是促进从安全区向安全区的迁移。这一区别已被取消。
The objective of facilitating the migration can be achieved without a special designation of an experimentally secure status. Experimentally secured is a special case of locally secured. A zone administrator can achieve this by publishing a zone with signatures and configuring a set of test resolvers with the corresponding public keys. Even if the public key is published in a KEY RR, as long as there is no parent signature, the resolvers will need some pre-configuration to know to process the signatures. This allows a zone to be secured with in the sphere of the experiment, yet still be registered as unsecured in the general Internet.
促进移民的目标可以在没有特别指定实验安全状态的情况下实现。实验安全是局部安全的一种特殊情况。区域管理员可以通过发布带有签名的区域并使用相应的公钥配置一组测试解析程序来实现这一点。即使公钥是在密钥RR中发布的，只要没有父签名，解析程序也需要一些预配置来知道如何处理签名。这允许在实验范围内对区域进行安全保护，但在通用Internet中仍被注册为不安全。
4 IANA Considerations
4 IANA考虑因素
This document does not request any action from an assigned number authority nor recommends any actions.
本文件不要求指定编号机构采取任何行动，也不建议采取任何行动。
5 Security Considerations
5安全考虑
Without a means to enforce compliance with specified protocols or recommended actions, declaring a DNS zone to be "completely" secured is impossible. Even if, assuming an omnipotent view of DNS, one can declare a zone to be properly configured for security, and all of the zones up to the root too, a misbehaving resolver could be duped into believing bad data. If a zone and resolver comply, a non-compliant or subverted parent could interrupt operations. The best that can be hoped for is that all parties are prepared to be judged secure and that security incidents can be traced to the cause in short order.
如果没有强制遵守指定协议或建议操作的手段，则不可能宣布DNS区域“完全”安全。即使假设DNS是万能的，可以声明一个区域被正确地配置为安全性，并且所有的区域直到根，一个行为不端的解析器也可能被欺骗而相信坏数据。如果区域和冲突解决程序符合要求，则不符合要求或被破坏的父级可能会中断操作。我们所能希望的最好情况是，各方都准备好被判断为安全的，安全事件可以在短时间内追查到原因。
6 Acknowledgements
6致谢
The need to refine the definition of a secured zone has become apparent through the efforts of the participants at two DNSSEC workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-funded research network), and other workshops. Further discussions leading to the document include Olafur Gudmundsson, Russ Mundy, Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen and others have contributed significant input via the namedroppers mailing list.
通过参加由NIC-SE（.SE注册商）、凯恩（DARPA资助的研究网络）和其他研讨会赞助的DNSSEC研讨会的参与者的努力，完善安全区定义的必要性变得显而易见。导致该文件的进一步讨论包括Olafur Gudmundsson、Russ Mundy、Robert Watson和Brian Wellington。罗伊·阿伦兹、特德·林德格林和其他人通过“匿名投递者”邮件列表提供了重要信息。
7 References
7参考文献
[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, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997.
[RFC2136]Vixie，P.（Ed.），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月。
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“简单安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000.
[RFC3008]惠灵顿，B.，“域名系统安全（DNSSEC）签名机构”，RFC3008，2000年11月。
10 Author's Address
10作者地址
Edward Lewis NAI Labs 3060 Washington Road Glenwood MD 21738
爱德华·刘易斯·奈伊实验室美国马里兰州格伦伍德华盛顿路3060号21738
Phone: +1 443 259 2352
EMail: lewis@tislabs.com
Phone: +1 443 259 2352
EMail: lewis@tislabs.com
11 Full Copyright Statement
11完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。