| TOC |
|
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.
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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 July 9, 2011.
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 described in the Simplified BSD License.
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.
1.
Introduction
1.1.
Requirements notation
1.1.1.
Terminology
1.1.2.
Document Layout and Requirements
2.
Management Architecture Requirements
2.1.
Expected Deployment Scenarios
2.1.1.
Zone Size Constraints
2.1.2.
Name Server Discovery
2.1.3.
Configuration Data Volatility
2.1.4.
Protocol Selection
2.1.5.
Common Data Model
2.1.6.
Operational Impact
2.2.
Name Server Types
3.
Management Operation Types
3.1.
Control Requirements
3.1.1.
Needed Control Operations
3.1.2.
Asynchronous Status Notifications
3.2.
Configuration Requirements
3.2.1.
Served Zone Modification
3.2.2.
Trust Anchor Management
3.2.3.
Security Expectations
3.2.4.
TSIG Key Management
3.2.5.
DNS Protocol Authorization Management
3.3.
Monitoring Requirements
3.4.
Alarm and Event Requirements
4.
Security Requirements
4.1.
Authentication
4.2.
Integrity Protection
4.3.
Confidentiality
4.4.
Authorization
4.5.
Solution Impacts on Security
5.
Other Requirements
5.1.
Extensibility
5.1.1.
Vendor Extensions
5.1.2.
Extension Identification
5.1.3.
Name-Space Collision Protection
6.
Security Considerations
7.
IANA Considerations
8.
Document History
9.
Acknowledgments
10.
References
10.1.
Normative References
10.2.
Informative References
Appendix A.
Deployment Scenarios
A.1.
Non-Standard Zones
A.2.
Redundancy Sharing
A.3.
DNSSEC Management
§
Author's Address
| TOC |
Management of name servers for the Domain Name System (DNS) [RFC1034] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) 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] (Austein, R. and J. Saperia, “DNS Server MIB Extensions,” May 1994.) [RFC1612] (Austein, R. and J. Saperia, “DNS Resolver MIB Extensions,” May 1994.) 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] (Austein, R., “Applicability Statement for DNS MIB Extensions,” November 2001.).
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 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.
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 (Extensibility) 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 of this writing.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
This document is consistent with the terminology defined in Section 2 of [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.). 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 resolvers.
| TOC |
The 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 (Requirements notation). 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.
| TOC |
This section discusses requirements that reflect the needs of the expected deployment environments.
| TOC |
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 (Deployment Scenarios).
| TOC |
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.
| TOC |
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 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.
| TOC |
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.
| TOC |
There are many requirements in this document for many different types of management operations (see Section 3 (Management Operation Types) 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.
| TOC |
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 the operations discussion in Section 3 (Management Operation Types). 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 (Extensibility).
| TOC |
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.
| TOC |
There are multiple ways in which name servers can be deployed. Name servers can take on any of the following roles:
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] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.). These sub-roles are also important to support within any management solution.
As stated earlier, the management of stub resolvers is considered out of scope for this documents.
| TOC |
Management operations can traditionally be broken into four categories:
This section discusses requirements for each of these four management types in detail.
| TOC |
The management solution MUST be capable of performing basic service control operations.
| TOC |
These operations SHOULD include, at a minimum, the following operations:
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.
| TOC |
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 (Alarm and Event Requirements) on notification messages for supporting delivery of alarm and event messages.
| TOC |
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.
| TOC |
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] (Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, “Dynamic Updates in the Domain Name System (DNS UPDATE),” April 1997.) [RFC3007] (Wellington, B., “Secure Domain Name System (DNS) Dynamic Update,” November 2000.), AXFR [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.), and incremental zone transfer (IXFR) [RFC1995] (Ohta, M., “Incremental Zone Transfer in DNS,” August 1996.)) 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) 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 (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.
| TOC |
The solution SHOULD support the ability to add, modify and delete trust anchors that are used by DNS Security (DNSSEC) [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.) [RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.) [RFC4509] (Hardaker, W., “Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs),” May 2006.) [RFC5011] (StJohns, M., “Automated Updates of DNS Security (DNSSEC) Trust Anchors,” September 2007.) [RFC5155] (Laurie, B., Sisson, G., Arends, R., and D. Blacka, “DNS Security (DNSSEC) Hashed Authenticated Denial of Existence,” March 2008.). These trust anchors might be configured using the data from the DNSKEY Resource Records (RRs) themselves or by using Delegation Signer (DS) fingerprints.
| TOC |
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.
| TOC |
TSIG [RFC2845] (Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, “Secret Key Transaction Authentication for DNS (TSIG),” May 2000.) 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.
| TOC |
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 (Authorization). 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:
Note: the above list is expected to be used as a collection of examples and is not a complete list of needed authorization protections.
| TOC |
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:
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".
| TOC |
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:
| TOC |
The management solution will need to be appropriately secured against attacks on the management infrastructure.
| TOC |
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.
| TOC |
Management operations MUST be protected from modification while in transit from the management client to the server.
| TOC |
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.
| TOC |
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 (DNS Protocol Authorization Management) 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:
Note: the above list is expected to be used as a collection of examples and is not a complete list of needed authorization protections.
| TOC |
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.
| TOC |
| TOC |
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.
| TOC |
It MUST be possible for vendors to extend the standardized management model with vendor-specific extensions to support additional features offered by their products.
| TOC |
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.
| TOC |
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 (Extension Identification) as well.
| TOC |
Any management protocol for which conformance to this document is claimed needs to fully support the criteria discussed in Section 4 (Security Requirements) 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.
| TOC |
No action is required from IANA for this document.
| TOC |
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.
| TOC |
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. 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.
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 Hönes, Doug Barton.
| TOC |
| TOC |
| TOC |
| [RFC1611] | Austein, R. and J. Saperia, “DNS Server MIB Extensions,” RFC 1611, May 1994 (TXT). |
| [RFC1612] | Austein, R. and J. Saperia, “DNS Resolver MIB Extensions,” RFC 1612, May 1994 (TXT). |
| [RFC2182] | Elz, R., Bush, R., Bradner, S., and M. Patton, “Selection and Operation of Secondary DNS Servers,” BCP 16, RFC 2182, July 1997 (TXT, HTML, XML). |
| [RFC3197] | Austein, R., “Applicability Statement for DNS MIB Extensions,” RFC 3197, November 2001 (TXT). |
| TOC |
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.
| TOC |
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.
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 which could handle the configuration of zone forwarding would finally allow management of servers deployed in this fashion.
| TOC |
For reliability reasons it is recommended that zone operators follow the guidelines documented in [RFC2182] (Elz, R., Bush, R., Bradner, S., and M. Patton, “Selection and Operation of Secondary DNS Servers,” July 1997.) which recommends that multiple name servers be configured for each zone and that the name servers are 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).
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 (Authorization), would solve many of the management difficulties between cooperating organizations.
| TOC |
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.
| TOC |
| Wes Hardaker | |
| Sparta, Inc. | |
| P.O. Box 382 | |
| Davis, CA 95617 | |
| US | |
| Phone: | +1 530 792 1913 |
| Email: | ietf@hardakers.net |