--- 1/draft-ietf-dnsop-name-server-management-reqs-02.txt 2009-05-05 03:12:05.000000000 +0200 +++ 2/draft-ietf-dnsop-name-server-management-reqs-03.txt 2009-05-05 03:12:05.000000000 +0200 @@ -1,136 +1,145 @@ DNSOP W. Hardaker Internet-Draft Sparta, Inc. -Intended status: Informational February 12, 2009 -Expires: August 16, 2009 +Intended status: Informational May 4, 2009 +Expires: November 5, 2009 Requirements for Management of Name Servers for the DNS - draft-ietf-dnsop-name-server-management-reqs-02.txt + draft-ietf-dnsop-name-server-management-reqs-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. + provisions of BCP 78 and BCP 79. 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 16, 2009. + This Internet-Draft will expire on November 5, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 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. + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Abstract - Management of name servers for the Domain Name Service (DNS) has + 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 a - interoperable way to manage (monitor, control and configure) the + 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. This document discusses the requirements of a management system for - DNS name servers. A management solution that is designed to manage - the DNS can use this document as a shopping list of needed features. + name servers and can be used as a shopping list of needed features + for such a system. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 - 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 - 1.1.2. Document Layout and Requirements . . . . . . . . . . . 5 - 2. Management Architecture Requirements . . . . . . . . . . . . . 5 - 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5 - 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5 - 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 . . . . . . . . 9 - 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10 - 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10 - 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 - 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11 - 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11 - 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 - 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11 - 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15 - A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16 - A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16 - A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 + 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 6 + 1.1.2. Document Layout and Requirements . . . . . . . . . . . 6 + 2. Management Architecture Requirements . . . . . . . . . . . . . 6 + 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 6 + 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6 + 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 7 + 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 7 + 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 7 + 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 7 + 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 8 + 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 8 + 3. Management Operation Types . . . . . . . . . . . . . . . . . . 8 + 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 9 + 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 9 + 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 9 + 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 10 + 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 10 + 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 10 + 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 10 + 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 10 + 3.2.5. DNS Protocol Authorization Management . . . . . . . . 10 + 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 11 + 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11 + 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 + 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 12 + 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 12 + 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12 + 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 13 + 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 13 + 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 + 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 14 + 5.1.2. Extension Identification . . . . . . . . . . . . . . . 14 + 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 14 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 14 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 + Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16 + A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 17 + A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 17 + A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 17 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction - Management of name servers for the Domain Name Service (DNS) - [RFC1034] [RFC1035] has traditionally been done using vendor-specific + 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 a interoperable way to manage (monitor, control and + there is not an interoperable way to manage (monitor, control and configure) the internal aspects of a name server itself. 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 further documented in [RFC3197]. This document discusses the requirements of a management system for - DNS name servers. A management solution that is designed to manage - the DNS can use this document as a shopping list of needed features. + name servers and can be used as a shopping list of needed features + for such a system. Specifically out of scope for this document are requirements associated with 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. Also out of scope for this document is management of the host or other components of the host upon which the name server software is running. This document only discusses requirements for managing the @@ -195,43 +204,42 @@ 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. 2.1.1. Zone Size Constraints 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. These scenarios are both commonly seen - deployments. + large number of small zones. Both deployment scenarios are common. 2.1.2. Name Server Discovery 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 - quantities of name servers would be a useful feature of the resulting + of the parent enterprise's zone. Finding and managing a 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. 2.1.3. Configuration Data Volatility 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 fairly statically configured over time as well as servers that have numerous - zones being added and removed within an hour. Both of these - scenarios are also commonly seen deployments. + zones being added and removed within an hour. Both deployment + scenarios are common. 2.1.4. Protocol Selection 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 number of protocols used SHOULD be reduced to a @@ -242,21 +250,21 @@ 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 complete 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 of the operations discussion in Section 3. Note + 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. 2.1.6. Operational Impact 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 @@ -307,21 +315,23 @@ 3.1.1. Needed Control Operations These operations SHOULD include, at a minimum, the following operations: o Starting the name server o Reloading the service configuration - o Reloading zone data + o Reloading of all of the zone data + + o Reloading of individual zone data sets o Restarting the name server o Stopping the name server 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. @@ -593,21 +603,21 @@ 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. + Alfred Hoenes, Doug Barton. 10. References 10.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.