--- 1/draft-ietf-dnsop-name-server-management-reqs-04.txt 2011-01-05 21:23:10.000000000 +0100 +++ 2/draft-ietf-dnsop-name-server-management-reqs-05.txt 2011-01-05 21:23:10.000000000 +0100 @@ -1,18 +1,18 @@ DNSOP W. Hardaker Internet-Draft Sparta, Inc. -Intended status: Informational June 11, 2010 -Expires: December 13, 2010 +Intended status: Informational January 5, 2011 +Expires: July 9, 2011 Requirements for Management of Name Servers for the DNS - draft-ietf-dnsop-name-server-management-reqs-04.txt + draft-ietf-dnsop-name-server-management-reqs-05.txt 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. @@ -28,25 +28,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on December 13, 2010. + This Internet-Draft will expire on July 9, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 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. 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 @@ -81,77 +81,74 @@ 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.2.5. DNS Protocol Authorization Management . . . . . . . . 11 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 11 - 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11 + 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 12 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 12 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 12 - 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12 + 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 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 + 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16 + Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 17 A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 17 A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 17 - A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 17 + A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction 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. 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 name servers and can be used as a shopping list of needed features - for such a system. + for such a system. This document only discusses requirements for + managing the name server component of a system and not other elements + of the system itself. 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 - name server component of a system. - 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 and 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 road-map 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 @@ -222,35 +219,34 @@ 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 deployment - scenarios are common. + 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. 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 - reasonable minimum number. + solution, but the solution SHOULD require only one. 2.1.5. Common Data Model 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 @@ -264,21 +260,22 @@ 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 - server. + server. The management solution MUST NOT result in an increase of + the number of unhandled DNS requests. 2.2. Name Server Types 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 Slave Servers @@ -359,26 +356,27 @@ 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 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], AXFR [RFC1035], 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 natively create a new zone - (with enough minimal data to allow the other mechanisms to function - as well) as well as delete a zone. This might be, for example, a + management system SHOULD still be able to create a new zone (with + enough minimal data to allow the other mechanisms to function as + well) as well as delete a zone. This might be, for example, a management operation that at least allows for the creation of the - initial SOA record for a new zone as that's the minimum amount of - zone data needed for the other operations to function. + initial SOA (Start of a zone Of Authority) record for a new zone as + that's the minimum amount of zone data needed for the other + operations to function. 3.2.2. Trust Anchor Management 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. @@ -418,22 +416,22 @@ 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 - and other performance counters + o Number of requests sent, responses sent, number of errors, average + response latency and other performance counters 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). @@ -458,20 +456,22 @@ o A needed resource (e.g. memory or disk space) is exhausted or nearing exhaustion o An authorization violation was detected 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 its deployment. + o The number of errors has exceeded a configured threshold + 4. Security Requirements The management solution will need to be appropriately secured against attacks on the management infrastructure. 4.1. Authentication 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 @@ -486,25 +486,26 @@ 4.3. Confidentiality 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. 4.4. Authorization - The solution SHOULD be capable of providing a fine-grained - authorization model 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. + 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. 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 Access to the management system infrastructure @@ -562,22 +563,22 @@ 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 problems. Name-space identification techniques also frequently solve the "Extension Identification" requirement discussed in Section 5.1.2 as well. 6. Security Considerations - Any management protocol that meets the criteria discussed in this - document needs to support the criteria discussed in Section 4 in + 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. 7. IANA Considerations No action is required from IANA for this document.