--- 1/draft-ietf-dnsop-name-server-management-reqs-00.txt 2008-09-03 20:12:19.000000000 +0200 +++ 2/draft-ietf-dnsop-name-server-management-reqs-01.txt 2008-09-03 20:12:19.000000000 +0200 @@ -1,18 +1,18 @@ DNSOP W. Hardaker Internet-Draft Sparta, Inc. -Intended status: Informational August 25, 2008 -Expires: February 26, 2009 +Intended status: Informational September 3, 2008 +Expires: March 7, 2009 Requirements for Management of Name Servers for the DNS - draft-ietf-dnsop-name-server-management-reqs-00.txt + draft-ietf-dnsop-name-server-management-reqs-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -23,21 +23,21 @@ 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 February 26, 2009. + This Internet-Draft will expire on March 7, 2009. Abstract Management of name servers for the Domain Name Service (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 internal aspects of a name server itself. @@ -62,45 +62,46 @@ 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.2.5. DNS Protocol Authorization Management . . . . . . . . 9 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10 - 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11 + 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 . . . . . . . . . . . . . . . . . . . . . . 12 + 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. Namespace Collision Protection . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 14 + 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 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 + A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 1. Introduction Management of name servers for the Domain Name Service (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 configure) the internal aspects of a name server itself. @@ -140,21 +141,21 @@ 1.1. Requirements notation 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]. 1.1.1. Terminology This document is consistent with the terminology defined in Section 2 - of [RFC4033]. Additional terminology needed for this document are + of [RFC4033]. Additional terminology needed for this document is described below: 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 @@ -232,25 +233,24 @@ 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 - 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. + model is needed for of 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 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 @@ -282,21 +282,21 @@ Management operations can traditionally be broken into four categories: o Control o Configuration o Health and Monitoring o Alarms and Events - This section discusses requirements for each of these for management + This section discusses requirements for each of these four management types in detail. 3.1. Control Requirements The management solution MUST be capable of performing basic service control operations. 3.1.1. Needed Control Operations These operations SHOULD include, at a minimum, the following @@ -324,23 +324,22 @@ 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 which discusses - notification messages for supporting delivery of alarm and event - messages. + Also, see the related discussion in Section 3.4 on notification + messages for supporting delivery of alarm and event messages. 3.2. Configuration Requirements 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. 3.2.1. Served Zone Modification @@ -361,21 +360,21 @@ 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. 3.2.3. Security Expectations DNSSEC Validating resolvers need to make policy decisions about the - requests being processed. For example, They need to be configured + 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. 3.2.4. TSIG Key Management 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. @@ -389,22 +388,23 @@ used by a name server. Example authorization settings that the solution might need to cover are: o Access to operations on zone data (e.g. DDNS) o Access to certain zone data from certain sources (e.g. from particular network subnets) o Access to specific DNS protocol services (e.g. recursive service) - Note: the above list is expected to be used as examples and is not a - complete list of needed authorization protections. + Note: the above list is expected to be used as a collection of + examples and is not a complete list of needed authorization + protections. 3.3. Monitoring Requirements 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 management tasks that the solution might need to cover are: o Number of requests sent, responses sent, average response latency @@ -413,25 +413,25 @@ o Server status (e.g. "serving data", "starting up", "shutting down", ...) o Access control violations o List of zones being served o Detailed statistics about clients interacting with the name server (e.g. top 10 clients requesting data). - Note: the above list is expected to be used as 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 haves" as opposed to - "necessary to have". + 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 haves" as opposed to "necessary to have". 3.4. Alarm and Event Requirements 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: @@ -490,22 +490,23 @@ served o Access to the management system infrastructure o Access to other control operations o Access to other configuration operations o Access to monitoring operations - Note: the above list is expected to be used as examples and is not a - complete list of needed authorization protections. + Note: the above list is expected to be used as a collection of + examples and is not a complete list of needed authorization + protections. 4.5. Solution Impacts on Security 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. @@ -583,20 +584,23 @@ 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 Hines. + 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. @@ -694,20 +699,51 @@ company). 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. +A.3. DNSSEC Management + + 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. + + All contents and DNSSEC keying information controlled and operated + by a single organization + + Zone contents controlled and operated by one organization, all + DNSSEC keying information controlled and operated by a second + organization. + + 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. + + 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. + Author's Address Wes Hardaker Sparta, Inc. P.O. Box 382 Davis, CA 95617 US Phone: +1 530 792 1913 Email: ietf@hardakers.net