DNSOP W. Hardaker Internet-Draft Sparta, Inc. Intended status: Informational March 19, 2008 Expires: September 20, 2008 Requirements for Management of Name Servers for the DNS draft-hardaker-dnsops-name-server-management-reqs-00.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 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 September 20, 2008. 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 has not been a interoperable way to control, configure and examine the internal performance of a given DNS server. This document discusses the requirements of a management system for DNS name servers. A management solution that is designed to manage the DNS should meet the needs discussed in this document. Hardaker Expires September 20, 2008 [Page 1] Internet-Draft Name Server Management Requirements March 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.2. Document Requirement Layout . . . . . . . . . . . . . 4 2. Management Architecture Requirements . . . . . . . . . . . . . 4 2.1. Expected Deployment Scenerios . . . . . . . . . . . . . . 4 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 4 2.1.2. Configuration Data Volatility . . . . . . . . . . . . 4 2.1.3. Protocol Selection . . . . . . . . . . . . . . . . . . 5 2.1.4. Common Data Model . . . . . . . . . . . . . . . . . . 5 2.1.5. Operational Impact . . . . . . . . . . . . . . . . . . 5 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 6 3. Management Operation Types . . . . . . . . . . . . . . . . . . 6 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 6 3.1.1. Asyncronous status notifications . . . . . . . . . . . 7 3.2. Configuration Requiremets . . . . . . . . . . . . . . . . 7 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 7 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 8 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 8 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 8 3.2.5. DNS Protocol Authorization Management . . . . . . . . 8 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 9 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 9 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 10 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 10 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 11 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Extensiblity . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 11 5.1.2. Extension Identification . . . . . . . . . . . . . . . 11 5.1.3. Namespace Collison Protection . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Deployment Scenerios . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Hardaker Expires September 20, 2008 [Page 2] Internet-Draft Name Server Management Requirements March 2008 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 has not been a interoperable way to control, configure and examine the internal performance of a given DNS server. 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 is 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 should meet the needs discussed in this document. 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 may 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 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 must be used at the time of this writing. 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 described below: Hardaker Expires September 20, 2008 [Page 3] Internet-Draft Name Server Management Requirements March 2008 Name Server: When we are discussing a 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 the servers may 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. 1.1.2. Document Requirement Layout The document is written so that 0 to 1 requirements will be outlined in the text of each numbered section. These requirements will contain needed wording from the terminology described in Section 1.1. Subsections, however, may exist with additional related requirements. This is done so that a specific requirement can be uniquely referred to using the section number itself and the document version that it came from. 2. Management Architecture Requirements This section discusses requirements that reflect the needs of the expected deployment environments. 2.1. Expected Deployment Scenerios 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 scenario's that are not used as direct examples of specific requirements are listed in Appendix A. 2.1.1. Zone Size Constraints The management solution should 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. 2.1.2. 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 Hardaker Expires September 20, 2008 [Page 4] Internet-Draft Name Server Management Requirements March 2008 does not include data from the zone contents that is served through DNS itself. The solution should 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. 2.1.3. 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 may be needed to produce a completely functional management system. Multiple protocols may be used to create the complete management solution, but the number of protocols used should be reduced to a reasonable minimum number. 2.1.4. 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 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 may provide additional management infrastructure beyond a base management specification, as discussed further in section Section 5.1. 2.1.5. 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. Hardaker Expires September 20, 2008 [Page 5] Internet-Draft Name Server Management Requirements March 2008 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 o Recursive Servers All of these types of servers are equally as important to support within the solution. It should be noted that "Recursive Servers" can be further broken down by the security sub-roles they may implementing, as defined in section 2 of [RFC4033]. These sub-roles are also important to support within any management solution. The requirements in this document explicitly exclude dealing with management of stub resolvers. Management of stub resolvers is considered specifically out of scope of this document. 3. Management Operation Types 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 types in detail. 3.1. Control Requirements The management solution must be capable of performing basic service control operations. These operations must include, at a minimum, the following operations o Starting the name server o Reloading the service configuration Hardaker Expires September 20, 2008 [Page 6] Internet-Draft Name Server Management Requirements March 2008 o Reloading zone data o Restarting the name server o Stopping the name server It should be noted that no further restriction is placed on how the management system be implemented so that these operations can be performed. In particular, at least "starting the name server" will require a minimal management system component to exist independently of the name server itself. 3.1.1. Asyncronous status notifications Some control operations may 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 may 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. 3.2. Configuration Requiremets Many features of name servers need to be configured before the server can be considered functional. 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 must still be able to natively create a new zone with enough minimal data to allow the other mechanisms to function. This may 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 Hardaker Expires September 20, 2008 [Page 7] Internet-Draft Name Server Management Requirements March 2008 function.. 3.2.2. Trust Anchor Management The ability to add, modify and delete trust anchors that are used by DNS Security (DNSSEC) [RFC4033] [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155] validating resolvers is needed. These trust anchors may be configured using the data from the DNSKEY key 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. They need to be, for example, be configured with a list of zones they should expect to be secured with DNSSEC. The management solution must 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 must be able to add, modify and delete TSIG keys known to the name server. 3.2.5. DNS Protocol Authorization Management The management solution must have the ability to add, modify and delete authorization settings for the DNS protocols itself. This should not be confused with the ability to manage the authorization associated with the management protocol itself, which is discussed later in section Section 4.4. There are a number of authorization settings that are used by a name server. Example authorization settings that the solution may 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. Hardaker Expires September 20, 2008 [Page 8] Internet-Draft Name Server Management Requirements March 2008 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 it's operational status, load and other internal attributes. Example management tasks that the solution may need to cover are: o Number of requests sent, responses sent and other counting statistics 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 statics are expected to be computationally or resource expensive and should be considered "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 may include: o The server's status is changing. (E.G it is starting up, reloading configuration, restarting or shutting down) 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 it's deployment. Hardaker Expires September 20, 2008 [Page 9] Internet-Draft Name Server Management Requirements March 2008 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 must be able to ensure that the management operations are being transferred to and from the correct name server. The managed name server must be able to authenticate the system that is accessing the management infrastructure within itself. 4.2. Integrity Protection Management operations must be protected from modification while in transit from the management client to the server. 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. There are a number of authorization settings that may 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 may need to cover are: o Access to the configuration that specifies which zones are to be served o Access to the management system infrastructure o Access to other control operations o Access to other configuration operations Hardaker Expires September 20, 2008 [Page 10] Internet-Draft Name Server Management Requirements March 2008 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. 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. 5. Other Requirements 5.1. Extensiblity 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 be able to accommodate new future management operations. The solution might, for example, make use of protocol versioning or capability description exchanges to ensure 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. 5.1.1. Vendor Extensions It must be possible for vendors to extend the standardized management model with vendor-specific extensions to support additional features offered by their products. 5.1.2. Extension Identification 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 extension data without needing to understand the extension data itself. Hardaker Expires September 20, 2008 [Page 11] Internet-Draft Name Server Management Requirements March 2008 5.1.3. Namespace Collison Protection 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 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. 8. Document History 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. 9. Acknowledgements This draft 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. This work documents the consensus of the DCOMA design team. 10. References Hardaker Expires September 20, 2008 [Page 12] Internet-Draft Name Server Management Requirements March 2008 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. [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. Hardaker Expires September 20, 2008 [Page 13] Internet-Draft Name Server Management Requirements March 2008 10.2. Informative References [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", RFC 1611, May 1994. [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", RFC 1612, May 1994. [RFC3197] Austein, R., "Applicability Statement for DNS MIB Extensions", RFC 3197, November 2001. Appendix A. Deployment Scenerios Author's Address Wes Hardaker Sparta, Inc. P.O. Box 382 Davis, CA 95617 US Phone: +1 530 792 1913 Email: hardaker@tislabs.com Hardaker Expires September 20, 2008 [Page 14] Internet-Draft Name Server Management Requirements March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Hardaker Expires September 20, 2008 [Page 15]