Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 6168 Sparta, Inc.
Category: Informational May 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 6168 Sparta, Inc.
Category: Informational May 2011
ISSN: 2070-1721
Requirements for Management of Name Servers for the DNS
DNS名称服务器的管理要求
Abstract
摘要
Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.
域名系统（DNS）的名称服务器管理传统上是使用特定于供应商的监视、配置和控制方法来完成的。尽管一些服务监控平台可以测试DNS本身的功能，但没有一种可互操作的方式来管理（监控、控制和配置）名称服务器本身的内部方面。
This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system.
本文档讨论名称服务器管理系统的要求，并可作为此类系统所需功能的购物清单。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6168.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6168.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Document Layout and Requirements . . . . . . . . . . . . . 5
2. Management Architecture Requirements . . . . . . . . . . . . . 5
2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6
2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
3.2.5. DNS Protocol Authorization Management . . . . . . . . 10
3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16
A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Document Layout and Requirements . . . . . . . . . . . . . 5
2. Management Architecture Requirements . . . . . . . . . . . . . 5
2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6
2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
3.2.5. DNS Protocol Authorization Management . . . . . . . . 10
3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16
A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 17
Management of name servers for the Domain Name System (DNS) [RFC1034] [RFC1035] has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.
域名系统（DNS）[RFC1034][RFC1035]的名称服务器管理传统上是使用特定于供应商的监控、配置和控制方法来完成的。尽管一些服务监控平台可以测试DNS本身的功能，但没有一种可互操作的方式来管理（监控、控制和配置）名称服务器本身的内部方面。
Previous standardization work within the IETF resulted in the creation of two SNMP MIB modules [RFC1611] [RFC1612], but they failed to achieve significant implementation and deployment. The perceived reasons behind the failure for the two MIB modules are documented in [RFC3197].
IETF之前的标准化工作导致创建了两个SNMP MIB模块[RFC1611][RFC1612]，但它们未能实现显著的实施和部署。[RFC3197]中记录了两个MIB模块发生故障的原因。
This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. This document only discusses requirements for managing the name server component of a system -- not other elements of the system itself.
本文档讨论名称服务器管理系统的要求，并可作为此类系统所需功能的购物清单。本文档仅讨论管理系统的名称服务器组件的需求，而不是系统本身的其他元素。
Specifically out of scope for this document are requirements associated with the management of stub resolvers. It is not the intent of this document to document stub resolver requirements, although some of the requirements listed are applicable to stub resolvers as well.
与存根解析器管理相关的要求特别超出了本文件的范围。本文档的目的不是记录存根解析器的要求，尽管列出的一些要求也适用于存根解析器。
The task of creating a management system for managing DNS servers is not expected to be a small one. It is likely that components of the solution will need to be designed in parts over time; these requirements take this into consideration. In particular, Section 5.1 discusses the need for future extensibility of the base management solution. This document is intended to be a roadmap towards a desired outcome and is not intended to define an "all-or-nothing" system. Successful interoperable management of name servers, even in part, is expected to be beneficial to network operators compared to the entirely custom solutions that are used at the time of this writing.
创建用于管理DNS服务器的管理系统的任务预计不会很小。随着时间的推移，解决方案的组件可能需要分部分设计；这些要求考虑到了这一点。特别是，第5.1节讨论了基本管理解决方案未来扩展性的需求。本文件旨在成为实现预期结果的路线图，而不是定义“全有或全无”系统。与撰写本文时使用的完全定制的解决方案相比，成功地对名称服务器进行互操作管理（即使是部分管理），预计将对网络运营商有利。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document is consistent with the terminology defined in Section 2 of [RFC4033]. Additional terminology needed for this document is described below:
本文件与[RFC4033]第2节中定义的术语一致。本文件所需的其他术语描述如下：
Name Server: When we are discussing servers that don't fall into a more specific type of server category defined in other documents, this document will refer to them generically as "name servers". In particular, "name servers" can be considered to be any valid combination of authoritative, recursive, validating, or security-aware. The more specific name server labels will be used when this document refers only to a specific type of server. However, the term "name server", in this document, will not include stub resolvers.
名称服务器：当我们讨论不属于其他文档中定义的更具体类型的服务器类别的服务器时，本文档将它们统称为“名称服务器”。特别是，“名称服务器”可以被认为是权威、递归、验证或安全感知的任何有效组合。当本文档仅引用特定类型的服务器时，将使用更具体的名称服务器标签。但是，本文档中的术语“名称服务器”不包括存根解析程序。
This document is written so that each numbered section will contain only a single requirement if it contains one at all. Each requirement will contain needed wording from the terminology described in Section 1.1. Subsections, however, might exist with additional related requirements. The document is laid out in this way so that a specific requirement can be uniquely referred to using the section number itself and the document version from which it came.
本文件的编写使每个编号部分仅包含一个需求（如果它包含一个需求）。每个要求将包含第1.1节所述术语中所需的措辞。但是，可能存在附加相关要求的小节。文件以这种方式进行布局，以便使用章节号本身及其来源的文件版本唯一地引用特定要求。
This section discusses requirements that reflect the needs of the expected deployment environments.
本节讨论反映预期部署环境需求的需求。
DNS zones vary greatly in the type of content published within them. Name servers, too, are deployed with a wide variety of configurations to support the diversity of the deployed content. It is important that a management solution trying to meet the criteria specified in this document consider supporting the largest number of potential deployment cases as possible. Further deployment scenarios that are not used as direct examples of specific requirements are listed in Appendix A.
DNS区域内发布的内容类型差异很大。名称服务器也部署了多种配置，以支持部署内容的多样性。重要的是，设法满足本文档中规定的标准的管理解决方案考虑尽可能支持最大数量的潜在部署案例。附录A中列出了未用作特定需求直接示例的其他部署场景。
The management solution MUST support both name servers that are serving a small number of potentially very large zones (e.g., Top Level Domains (TLDs)) as well as name servers that are serving a very large number of small zones. Both deployment scenarios are common.
管理解决方案必须支持为少量可能非常大的区域（例如顶级域（TLD））提供服务的名称服务器，以及为大量小区域提供服务的名称服务器。这两种部署场景都很常见。
Large enterprise network deployments may contain multiple name servers operating within the boundaries of the enterprise network. These name servers may each be serving multiple zones both in and out of the parent enterprise's zone. Finding and managing large numbers of name servers would be a useful feature of the resulting management solution. The management solution MAY support the ability to discover previously unknown instances of name servers operating within a deployed network.
大型企业网络部署可能包含在企业网络边界内运行的多个名称服务器。这些名称服务器可能分别为父企业区域内外的多个区域提供服务。查找和管理大量名称服务器将是最终管理解决方案的一个有用功能。该管理解决方案可以支持发现在已部署网络中运行的名称服务器的先前未知实例的能力。
Configuration data is defined as data that relates only to the configuration of a server and the zones it serves. It specifically does not include data from the zone contents that is served through DNS itself. The solution MUST support servers that remain statically configured over time as well as servers that have numerous zones being added and removed within an hour. Both deployment scenarios are common.
配置数据定义为仅与服务器及其服务区域的配置相关的数据。它特别不包括来自通过DNS本身提供服务的区域内容的数据。该解决方案必须支持随时间保持静态配置的服务器，以及在一小时内添加和删除多个区域的服务器。这两种部署场景都很常见。
There are many requirements in this document for many different types of management operations (see Section 3 for further details). It is possible that no one protocol will ideally fill all the needs of the requirements listed in this document, and thus multiple protocols might be needed to produce a completely functional management system. Multiple protocols might be used to create the complete management solution, but the solution SHOULD require only one.
本文件中有许多不同类型管理操作的要求（更多详细信息，请参见第3节）。可能没有一个协议能够理想地满足本文件中列出的所有需求，因此可能需要多个协议来生成一个完全功能化的管理系统。可以使用多个协议来创建完整的管理解决方案，但该解决方案只需要一个协议。
Defining a standardized protocol (or set of protocols) to use for managing name servers would be a step forward in achieving an interoperable management solution. However, just defining a protocol to use by itself would not achieve the entire end goal of a complete interoperable management solution. Devices also need to represent their internal management interface using a common management data model. The solution MUST create a common data model that management stations can make use of when sending or collecting data from a
定义用于管理名称服务器的标准化协议（或一组协议）将是实现互操作管理解决方案的一个进步。然而，仅仅定义一个自己使用的协议并不能实现一个完整的可互操作管理解决方案的最终目标。设备还需要使用公共管理数据模型表示其内部管理接口。解决方案必须创建一个公共数据模型，管理站在从服务器发送或收集数据时可以使用该模型
managed device so it can successfully manage equipment from vendors as if they were generic DNS servers. This common data model is needed for the operations discussion in Section 3. Note that this does not preclude the fact that name server vendors might provide additional management infrastructure beyond a base management specification, as discussed further in Section 5.1.
管理设备，使其能够成功地管理来自供应商的设备，就像它们是通用DNS服务器一样。第3节中的操作讨论需要此通用数据模型。请注意，这并不排除名称服务器供应商可能在基本管理规范之外提供额外的管理基础设施这一事实，如第5.1节所述。
It is impossible to add new features to an existing server (such as the inclusion of a management infrastructure) and not impact the existing service and/or server in some fashion. At a minimum, for example, more memory, disk, and/or CPU resources will be required to implement a new management system. However, the impact to the existing DNS service MUST be minimized since the DNS service itself is still the primary service to be offered by the modified name server. The management solution MUST NOT result in an increase of the number of unhandled DNS requests.
不可能向现有服务器添加新功能（例如包括管理基础架构），也不可能以某种方式影响现有服务和/或服务器。例如，实施新的管理系统至少需要更多的内存、磁盘和/或CPU资源。但是，必须尽量减少对现有DNS服务的影响，因为DNS服务本身仍然是修改后的名称服务器提供的主要服务。管理解决方案不得导致未处理DNS请求数量的增加。
There are multiple ways in which name servers can be deployed. Name servers can take on any of the following roles:
可以通过多种方式部署名称服务器。名称服务器可以承担以下任何角色：
o Master Servers
o 主服务器
o Slave Servers
o 从属服务器
o Recursive Servers
o 递归服务器
The management solution SHOULD support all of these types of name servers as they are all equally important. Note that "Recursive Servers" can be further broken down by the security sub-roles they might implement, as defined in section 2 of [RFC4033]. These sub-roles are also important to support within any management solution.
管理解决方案应该支持所有这些类型的名称服务器，因为它们都同样重要。请注意，“递归服务器”可以按它们可能实现的安全子角色进一步细分，如[RFC4033]第2节所定义。这些子角色对于在任何管理解决方案中提供支持也很重要。
As stated earlier, the management of stub resolvers is considered out of scope for this document.
如前所述，存根解析器的管理被认为超出了本文档的范围。
Management operations can traditionally be broken into four categories:
传统上，管理操作可分为四类：
o Control
o 控制
o Configuration
o 配置
o Health and Monitoring
o 健康和监测
o Alarms and Events
o 报警与事件
This section discusses detailed requirements for each of these four management categories.
本节讨论这四个管理类别的详细要求。
The management solution MUST be capable of performing basic service control operations.
管理解决方案必须能够执行基本的服务控制操作。
These operations SHOULD include, at a minimum, the following operations:
这些操作至少应包括以下操作：
o Starting the name server
o 启动名称服务器
o Reloading the service configuration
o 重新加载服务配置
o Reloading all of the zone data
o 重新加载所有区域数据
o Reloading individual zone data sets
o 重新加载单个分区数据集
o Restarting the name server
o 重新启动名称服务器
o Stopping the name server
o 停止名称服务器
Note that no restriction is placed on how the management system implements these operations. In particular, at least "starting the name server" will require a minimal management system component to exist independently of the name server itself.
请注意，管理系统如何实施这些操作没有任何限制。特别是，至少“启动名称服务器”需要一个最小的管理系统组件独立于名称服务器本身存在。
Some control operations might take a long time to complete. As an example, some name servers take a long time to perform reloads of large zones. Because of these timing issues, the management solution SHOULD take this into consideration and offer a mechanism to ease the burden associated with awaiting the status of a long-running command. This could, for example, result in the use of asynchronous notifications for returning the status of a long-running task, or it might require the management station to poll for the status of a given task using monitoring commands. These and other potential solutions need to be evaluated carefully to select one that balances the result delivery needs with the perceived implementation costs.
某些控制操作可能需要很长时间才能完成。例如，一些名称服务器需要很长时间来重新加载大型区域。由于这些时间问题，管理解决方案应该考虑到这一点，并提供一种机制来减轻与等待长时间运行的命令状态相关的负担。例如，这可能导致使用异步通知返回长时间运行任务的状态，或者可能需要管理站使用监视命令轮询给定任务的状态。需要仔细评估这些和其他潜在的解决方案，以选择一个平衡结果交付需求和感知的实施成本的解决方案。
Also, see the related discussion in Section 3.4 on notification messages for supporting delivery of alarm and event messages.
此外，请参阅第3.4节中关于通知消息的相关讨论，以支持警报和事件消息的传递。
Many features of name servers need to be configured before the server can be considered functional. The management solution MUST be able to provide name servers with configuration data. The most important data to be configured, for example, is the served zone data itself.
在服务器可以正常工作之前，需要配置名称服务器的许多功能。管理解决方案必须能够为名称服务器提供配置数据。例如，要配置的最重要数据是服务区域数据本身。
The ability to add, modify, and delete zones being served by name servers is needed. Although there are already solutions for zone content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007], full zone transfer (AXFR) [RFC5936], and incremental zone transfer (IXFR) [RFC1995]) that might be used as part of the final management solution, the management system SHOULD still be able to create a new zone (with enough minimal data to allow the other mechanisms to function as well) and to delete a zone. This might be, for example, a management operation that allows for the creation of at least the initial SOA (Start of Authority) record for a new zone, since that is the minimum amount of zone data needed for the other operations to function.
需要能够添加、修改和删除名称服务器提供服务的区域。尽管已经有一些区域内容修改解决方案（如动态DNS（DDN）[RFC2136][RFC3007]、完整区域传输（AXFR）[RFC5936]和增量区域传输（IXFR）[RFC1995]）可以作为最终管理解决方案的一部分使用，但管理系统仍应能够创建新的区域（具有足够的最小数据以允许其他机制也运行）和删除区域。例如，这可能是一种管理操作，允许至少为新区域创建初始SOA（授权启动）记录，因为这是其他操作运行所需的最小区域数据量。
The solution SHOULD support the ability to add, modify, and delete trust anchors that are used by DNS Security (DNSSEC) [RFC4033] [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust anchors might be configured using the data from the DNSKEY Resource Records (RRs) themselves or by using Delegation Signer (DS) fingerprints.
解决方案应支持添加、修改和删除DNS安全（DNSSEC）[RFC4033][RFC4034][RFC4035][RFC4509][RFC5011][RFC5155]使用的信任锚的功能。这些信任锚可以使用来自DNSKEY资源记录（RRs）本身的数据或使用委托签名者（DS）指纹进行配置。
DNSSEC validating resolvers need to make policy decisions about the requests being processed. For example, they need to be configured with a list of zones expected to be secured by DNSSEC. The management solution SHOULD be able to add, modify, and delete attributes of DNSSEC security policies.
DNSSEC验证解析程序需要对正在处理的请求做出策略决策。例如，它们需要配置一个预期由DNSSEC保护的区域列表。管理解决方案应能够添加、修改和删除DNSSEC安全策略的属性。
TSIG [RFC2845] allows transaction-level authentication of DNS traffic. The management solution SHOULD be able to add, modify, and delete TSIG keys known to the name server.
TSIG[RFC2845]允许对DNS流量进行事务级身份验证。管理解决方案应该能够添加、修改和删除名称服务器已知的TSIG密钥。
The management solution SHOULD have the ability to add, modify, and delete authorization settings for the DNS protocols itself. Do not confuse this with the ability to manage the authorization associated with the management protocol itself, which is discussed later in Section 4.4. There are a number of authorization settings that are used by a name server. Example authorization settings that the solution might need to cover are:
管理解决方案应该能够添加、修改和删除DNS协议本身的授权设置。不要将此与管理协议本身相关的授权管理能力混淆，后者将在第4.4节中讨论。名称服务器使用许多授权设置。解决方案可能需要涵盖的授权设置示例包括：
o Access to operations on zone data (e.g., DDNS)
o 对区域数据（如DDN）操作的访问
o Access to certain zone data from certain sources (e.g., from particular network subnets)
o 从特定来源（例如，从特定网络子网）访问特定区域数据
o Access to specific DNS protocol services (e.g., recursive service)
o 访问特定DNS协议服务（例如，递归服务）
Note: the above list is expected to be used as a collection of examples and is not a complete list of needed authorization protections.
注：上述列表预计将用作示例集合，并非所需授权保护的完整列表。
Monitoring is the process of collecting aspects of the internal state of a name server at a given moment in time. The solution MUST be able to monitor the health of a name server to determine its operational status, load, and other internal attributes. Example parameters that the solution might need to collect and analyze are:
监视是在给定时刻收集名称服务器内部状态方面的过程。解决方案必须能够监视名称服务器的运行状况，以确定其运行状态、负载和其他内部属性。解决方案可能需要收集和分析的示例参数包括：
o Number of requests sent, responses sent, number of errors, average response latency, and other performance counters
o 发送的请求数、发送的响应数、错误数、平均响应延迟和其他性能计数器
o Server status (e.g., "serving data", "starting up", "shutting down", etc.)
o 服务器状态（例如，“服务数据”、“启动”、“关闭”等）
o Access control violations
o 访问控制违规
o List of zones being served
o 正在服务的区域列表
o Detailed statistics about clients interacting with the name server (e.g., top 10 clients requesting data).
o 有关与名称服务器交互的客户端的详细统计信息（例如，请求数据的前10个客户端）。
Note: the above list is expected to be used as a collection of examples and is not a complete list of needed monitoring operations. In particular, some monitoring statistics are expected to be computationally or resource expensive and are considered to be "nice to have" as opposed to "necessary to have".
注：上述列表预计将用作示例集合，并非所需监控操作的完整列表。特别是，一些监测统计数据预计在计算上或资源上都很昂贵，被认为是“很好拥有”，而不是“必须拥有”。
Events occurring at the name server that trigger alarm notifications can quickly inform a management station about critical issues. A management solution SHOULD include support for delivery of alarm conditions.
在名称服务器上发生的触发报警通知的事件可以快速将关键问题通知管理站。管理解决方案应包括对警报条件交付的支持。
Example alarm conditions might include:
示例报警条件可能包括：
o The server's status is changing (e.g., it is starting up, reloading configuration, restarting or shutting down).
o 服务器的状态正在更改（例如，它正在启动、重新加载配置、重新启动或关闭）。
o A needed resource (e.g., memory or disk space) is exhausted or nearing exhaustion.
o 所需资源（如内存或磁盘空间）已耗尽或接近耗尽。
o An authorization violation was detected.
o 检测到授权冲突。
o The server has not received any data traffic (e.g., DNS requests or NOTIFYs) recently (aka the "lonely warning"). This condition might indicate a problem with the server's deployment.
o 服务器最近没有收到任何数据通信（例如DNS请求或NOTIFY）（也称为“孤独警告”）。这种情况可能表明服务器的部署有问题。
o The number of errors has exceeded a configured threshold.
o 错误数已超过配置的阈值。
The management solution will need to be appropriately secured against attacks on the management infrastructure.
需要对管理解决方案进行适当的保护，以防止对管理基础架构的攻击。
The solution MUST support mutual authentication. The management client needs to be assured that the management operations are being transferred to and from the correct name server. The managed name server needs to authenticate the system that is accessing the management infrastructure within itself.
解决方案必须支持相互身份验证。管理客户机需要确保管理操作正在正确的名称服务器之间传输。托管名称服务器需要对访问其内部管理基础结构的系统进行身份验证。
Management operations MUST be protected from modification while in transit from the management client to the server.
在从管理客户端传输到服务器的过程中，必须保护管理操作不受修改。
The management solution MUST support message confidentiality. The potential transfer of sensitive configuration is expected (such as TSIG keys or security policies). The solution does not, however, necessarily need to provide confidentiality to data that would normally be carried without confidentiality by the DNS system itself.
管理解决方案必须支持消息机密性。可能会转移敏感配置（如TSIG密钥或安全策略）。但是，该解决方案不一定需要为通常由DNS系统本身在不保密的情况下携带的数据提供保密性。
The solution SHOULD provide an authorization model capable of selectively authorizing individual management requests for any management protocols it introduces to the completed system. This authorization differs from the authorization previously discussed in Section 3.2.5 in that this requirement is concerned solely with authorization of the management system itself.
该解决方案应提供一个授权模型，能够针对其引入到完整系统的任何管理协议选择性地授权单个管理请求。该授权不同于之前在第3.2.5节中讨论的授权，因为该要求仅涉及管理系统本身的授权。
There are a number of authorization settings that might be used by a managed system to determine whether the managing entity has authorization to perform the given management task. Example authorization settings that the solution might need to cover are:
托管系统可能使用许多授权设置来确定管理实体是否具有执行给定管理任务的授权。解决方案可能需要涵盖的授权设置示例包括：
o Access to the configuration that specifies which zones are to be served
o 访问指定要服务哪些区域的配置
o Access to the management system infrastructure
o 访问管理系统基础架构
o Access to other control operations
o 访问其他控制操作
o Access to other configuration operations
o 访问其他配置操作
o Access to monitoring operations
o 获得监测业务
Note: the above list is expected to be used as a collection of examples and is not a complete list of needed authorization protections.
注：上述列表预计将用作示例集合，并非所需授权保护的完整列表。
The solution MUST minimize the security risks introduced to the complete name server system. It is impossible to add new infrastructure to a server and not impact the security in some fashion as the introduction of a management protocol alone will provide a new avenue for potential attack. Although the added management benefits will be worth the increased risks, the solution still needs to minimize this impact as much as possible.
解决方案必须将引入完整名称服务器系统的安全风险降至最低。不可能向服务器添加新的基础结构，也不可能以某种方式影响安全性，因为引入管理协议本身将为潜在的攻击提供新的途径。虽然增加的管理好处值得增加风险，但解决方案仍需要尽可能减少这种影响。
The management solution is expected to change and expand over time as lessons are learned and new DNS features are deployed. Thus, the solution MUST be flexible and able to accommodate new future management operations. The solution might, for example, make use of protocol versioning or capability description exchanges to ensure
随着经验教训的吸取和新DNS功能的部署，管理解决方案有望随着时间的推移而改变和扩展。因此，解决方案必须灵活，能够适应未来新的管理操作。例如，解决方案可以使用协议版本控制或功能描述交换来确保
that management stations and name servers that weren't written to the same specification version can still interoperate to the best of their combined ability.
没有按照同一规范版本编写的管理站和名称服务器仍然可以充分利用它们的组合能力进行互操作。
It MUST be possible for vendors to extend the standardized management model with vendor-specific extensions to support additional features offered by their products.
供应商必须能够使用特定于供应商的扩展来扩展标准化管理模型，以支持其产品提供的其他功能。
It MUST be possible for a management station to understand which parts of returned data are specific to a given vendor or other standardized extension. The data returned needs to be appropriately marked, through the use of name spaces or similar mechanisms, to ensure that the base management model data can be logically separated from the extension data without needing to understand the extension data itself.
管理站必须能够了解返回数据的哪些部分是特定于给定供应商或其他标准化扩展的。返回的数据需要通过使用名称空间或类似机制进行适当标记，以确保基本管理模型数据可以从逻辑上与扩展数据分离，而无需了解扩展数据本身。
It MUST be possible to protect against multiple extensions conflicting with each other. The use of name-space protection mechanisms for communicated management variables is common practice to protect against such problems. Name-space identification techniques also frequently solve the "Extension Identification" requirement discussed in Section 5.1.2.
必须能够防止多个扩展相互冲突。对沟通的管理变量使用名称空间保护机制是防止此类问题的常见做法。名称空间识别技术也经常解决第5.1.2节中讨论的“扩展识别”要求。
Any management protocol for which conformance to this document is claimed needs to fully support the criteria discussed in Section 4 in order to protect the management infrastructure itself. The DNS is a core Internet service, and management traffic that protects it could be the target of attacks designed to subvert that service. Because the management infrastructure will be adding additional interfaces to that service, it is critical that the management infrastructure support adequate protections against network attacks.
任何声称符合本文件要求的管理协议都需要完全支持第4节中讨论的标准，以保护管理基础设施本身。DNS是一项核心互联网服务，保护它的管理流量可能成为旨在颠覆该服务的攻击目标。由于管理基础架构将向该服务添加额外的接口，因此管理基础架构支持针对网络攻击的充分保护至关重要。
A requirement-gathering discussion was held at the December 2007 IETF meeting in Vancouver, BC, Canada, and a follow-up meeting was held at the March 2008 IETF meeting in Philadelphia. This document is a compilation of the results of those discussions as well as discussions on the DCOMA mailing list.
2007年12月在加拿大不列颠哥伦比亚省温哥华举行的IETF会议上进行了需求收集讨论，2008年3月在费城举行的IETF会议上进行了后续会议。本文件是这些讨论结果以及DCOMA邮件列表讨论结果的汇编。
This document is the result of discussions within the DCOMA design team chaired by Jaap Akkerhuis. This team consisted of a large number of people, all of whom provided valuable insight and input into the discussions surrounding name server management. The text of this document was written from notes taken during meetings as well as from contributions sent to the DCOMA mailing list. This work documents the consensus of the DCOMA design team.
本文件是由Jaap Akkerhuis主持的DCOMA设计团队内部讨论的结果。该团队由大量人员组成，他们都为围绕名称服务器管理的讨论提供了宝贵的见解和意见。本文件的文本是根据会议期间的笔记以及发送给DCOMA邮件列表的稿件编写的。这项工作记录了DCOMA设计团队的共识。
In particular, the following team members contributed significantly to the text in the document:
特别是，以下小组成员对文件中的案文作出了重大贡献：
Stephane Bortzmeyer Stephen Morris Phil Regnauld
斯蒂芬·博茨梅尔·斯蒂芬·莫里斯·菲尔·雷诺尔德
Further editing contributions and wording suggestions were made by Alfred Hoenes and Doug Barton.
阿尔弗雷德·霍恩斯和道格·巴顿提出了进一步的编辑意见和措辞建议。
[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月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]Ohta，M.，“DNS中的增量区域转移”，RFC 1995，1996年8月。
[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., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[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月。
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4509]Hardaker，W.“SHA-256在DNSSEC委托签署人（DS）资源记录（RRs）中的使用”，RFC 4509，2006年5月。
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007.
[RFC5011]StJohns，M.，“DNS安全（DNSSEC）信任锚的自动更新”，RFC5011，2007年9月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 51552008年3月。
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, June 2010.
[RFC5936]Lewis，E.和A.Hoenes，Ed.，“DNS区域传输协议（AXFR）”，RFC 59362010年6月。
[RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", RFC 1611, May 1994.
[RFC1611]Austein，R.和J.Saperia，“DNS服务器MIB扩展”，RFC16111994年5月。
[RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", RFC 1612, May 1994.
[RFC1612]Austein，R.和J.Saperia，“DNS解析器MIB扩展”，RFC16121994年5月。
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1997.
[RFC2182]Elz，R.，Bush，R.，Bradner，S.，和M.Patton，“辅助DNS服务器的选择和操作”，BCP 16，RFC 2182，1997年7月。
[RFC3197] Austein, R., "Applicability Statement for DNS MIB Extensions", RFC 3197, November 2001.
[RFC3197]Austein，R.，“DNS MIB扩展的适用性声明”，RFC 31972001年11月。
This appendix documents some additional deployment scenarios that have been traditionally difficult to manage. They are provided as guidance to protocol developers as data points of real-world name server management problems.
本附录记录了一些传统上难以管理的其他部署场景。它们作为实际名称服务器管理问题的数据点，提供给协议开发人员作为指导。
If an organization uses non-standard zones (for example a purely local TLD), synchronizing all the name servers for these zones is usually a time-consuming task. It is made worse when two organizations with conflicting zones merge. This situation is not a recommended deployment scenario (and is even heavily discouraged), but it is, unfortunately, seen in the wild.
如果组织使用非标准区域（例如纯本地TLD），则同步这些区域的所有名称服务器通常是一项耗时的任务。当两个区域冲突的组织合并时，情况更糟。这种情况不是推荐的部署场景（甚至被严重劝阻），但不幸的是，在野外也可以看到这种情况。
It is typically implemented using "forwarding" zones. But there is no way to ensure automatically that all the resolvers have the same set of zones to forward at any given time. New zones might be added to a local forwarding recursive server, for example, without modifying the rest of the deployed forwarding servers. It is hoped that a management solution that could handle the configuration of zone forwarding would finally allow management of servers deployed in this fashion.
它通常使用“转发”区域来实现。但是，无法自动确保所有冲突解决程序在任何给定时间都具有相同的转发区域集。例如，可以将新区域添加到本地转发递归服务器，而无需修改其余已部署的转发服务器。希望能够处理区域转发配置的管理解决方案能够最终允许以这种方式管理部署的服务器。
For reliability reasons, it is recommended that zone operators follow the guidelines documented in [RFC2182], which recommends that multiple name servers be configured for each zone and that the name servers be separated both physically and via connectivity routes. A common solution is to establish DNS-serving partnerships: "I'll host your zones and you'll host mine". Both entities benefit from increased DNS reliability via the wider service distribution. This frequently occurs between cooperating but otherwise unrelated entities (such as between two distinct companies) as well as between affiliated organizations (such as between branch offices within a single company).
出于可靠性原因，建议区域运营商遵循[RFC2182]中记录的指南，该指南建议为每个区域配置多个名称服务器，并且名称服务器在物理上和通过连接路由进行分离。一个常见的解决方案是建立DNS服务伙伴关系：“我将托管您的区域，您将托管我的区域”。这两个实体都受益于通过更广泛的服务分布提高DNS可靠性。这种情况经常发生在合作但不相关的实体之间（如两个不同的公司之间）以及附属组织之间（如单个公司内的分支机构之间）。
The configuration of these relationships are currently required to be manually configured and maintained. Changes to the list of zones that are cross-hosted are manually negotiated between the cooperating network administrators and configured by hand. A management protocol with the ability to provide selective authorization, as discussed in Section 4.4, would solve many of the management difficulties between cooperating organizations.
这些关系的配置目前需要手动配置和维护。对跨主机区域列表的更改由合作的网络管理员手动协商并手动配置。如第4.4节所述，能够提供选择性授权的管理协议将解决合作组织之间的许多管理难题。
There are many different DNSSEC deployment strategies that may be used for mission-critical zones. The following list describes some example deployment scenarios that might warrant different management strategies.
有许多不同的DNSSEC部署策略可用于任务关键区。下面的列表描述了一些可能需要不同管理策略的示例部署场景。
All contents and DNSSEC keying information controlled and operated by a single organization
由单个组织控制和操作的所有内容和DNSSEC键控信息
Zone contents controlled and operated by one organization, all DNSSEC keying information controlled and operated by a second organization.
区域内容由一个组织控制和操作，所有DNSSEC键控信息由第二个组织控制和操作。
Zone contents controlled and operated by one organization, zone signing keys (ZSKs) controlled and operated by a second organization, and key signing keys (KSKs) controlled and operated by a third organization.
区域内容由一个组织控制和操作，区域签名密钥（ZSK）由第二个组织控制和操作，密钥签名密钥（KSK）由第三个组织控制和操作。
Although this list is not exhaustive in the potential ways that zone data can be divided up, it should be sufficient to illustrate the potential ways in which zone data can be controlled by multiple entities.
虽然该列表并未详尽说明分区数据的可能划分方式，但足以说明分区数据可由多个实体控制的可能方式。
The end result of all of these strategies, however, will be the same: a live zone containing DNSSEC-related resource records. Many of the above strategies are merely different ways of preparing a zone for serving. A management solution that includes support for managing DNSSEC zone data may wish to take into account these potential management scenarios.
然而，所有这些策略的最终结果都是一样的：一个包含DNSSEC相关资源记录的活动区域。上述许多策略只是为服务准备区域的不同方式。包括管理DNSSEC区域数据支持的管理解决方案可能希望考虑这些潜在的管理场景。
Author's Address
作者地址
Wes Hardaker Sparta, Inc. P.O. Box 382 Davis, CA 95617 US
美国加利福尼亚州戴维斯市韦斯哈达克斯巴达公司邮政信箱382号，邮编95617
Phone: +1 530 792 1913
EMail: ietf@hardakers.net
Phone: +1 530 792 1913
EMail: ietf@hardakers.net