draft-ietf-dnsop-name-server-management-reqs-02.txt   draft-ietf-dnsop-name-server-management-reqs-03.txt 
DNSOP W. Hardaker DNSOP W. Hardaker
Internet-Draft Sparta, Inc. Internet-Draft Sparta, Inc.
Intended status: Informational February 12, 2009 Intended status: Informational May 4, 2009
Expires: August 16, 2009 Expires: November 5, 2009
Requirements for Management of Name Servers for the DNS 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract 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, traditionally been done using vendor-specific monitoring,
configuration and control methods. Although some service monitoring configuration and control methods. Although some service monitoring
platforms can test the functionality of the DNS itself there is not a platforms can test the functionality of the DNS itself there is not
interoperable way to manage (monitor, control and configure) the an interoperable way to manage (monitor, control and configure) the
internal aspects of a name server itself. internal aspects of a name server itself.
This document discusses the requirements of a management system for This document discusses the requirements of a management system for
DNS name servers. A management solution that is designed to manage name servers and can be used as a shopping list of needed features
the DNS can use this document as a shopping list of needed features. for such a system.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 6
1.1.2. Document Layout and Requirements . . . . . . . . . . . 5 1.1.2. Document Layout and Requirements . . . . . . . . . . . 6
2. Management Architecture Requirements . . . . . . . . . . . . . 5 2. Management Architecture Requirements . . . . . . . . . . . . . 6
2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 6
2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6
2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 7
2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 7
2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 7
2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 7
2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 8
2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 8
3. Management Operation Types . . . . . . . . . . . . . . . . . . 7 3. Management Operation Types . . . . . . . . . . . . . . . . . . 8
3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 9
3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 9
3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 9
3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 10
3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 10
3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 10
3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 10
3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 10
3.2.5. DNS Protocol Authorization Management . . . . . . . . 9 3.2.5. DNS Protocol Authorization Management . . . . . . . . 10
3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 11
3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 12
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 12
4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 12
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 13
5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 14
5.1.2. Extension Identification . . . . . . . . . . . . . . . 13 5.1.2. Extension Identification . . . . . . . . . . . . . . . 14
5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15 Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16
A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16 A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 17
A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16 A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 17
A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16 A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Management of name servers for the Domain Name Service (DNS) Management of name servers for the Domain Name System (DNS) [RFC1034]
[RFC1034] [RFC1035] has traditionally been done using vendor-specific [RFC1035] has traditionally been done using vendor-specific
monitoring, configuration and control methods. Although some service monitoring, configuration and control methods. Although some service
monitoring platforms can test the functionality of the DNS itself 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. configure) the internal aspects of a name server itself.
Previous standardization work within the IETF resulted in the Previous standardization work within the IETF resulted in the
creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
to achieve significant implementation and deployment. The perceived to achieve significant implementation and deployment. The perceived
reasons behind the failure for the two MIB modules are further reasons behind the failure for the two MIB modules are further
documented in [RFC3197]. documented in [RFC3197].
This document discusses the requirements of a management system for This document discusses the requirements of a management system for
DNS name servers. A management solution that is designed to manage name servers and can be used as a shopping list of needed features
the DNS can use this document as a shopping list of needed features. for such a system.
Specifically out of scope for this document are requirements Specifically out of scope for this document are requirements
associated with management of stub resolvers. It is not the intent associated with management of stub resolvers. It is not the intent
of this document to document stub resolver requirements, although of this document to document stub resolver requirements, although
some of the requirements listed are applicable to stub resolvers as some of the requirements listed are applicable to stub resolvers as
well. well.
Also out of scope for this document is management of the host or 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 other components of the host upon which the name server software is
running. This document only discusses requirements for managing the running. This document only discusses requirements for managing the
skipping to change at page 6, line 5 skipping to change at page 7, line 5
this document consider supporting the largest number of potential this document consider supporting the largest number of potential
deployment cases as possible. Further deployment scenarios that are deployment cases as possible. Further deployment scenarios that are
not used as direct examples of specific requirements are listed in not used as direct examples of specific requirements are listed in
Appendix A. Appendix A.
2.1.1. Zone Size Constraints 2.1.1. Zone Size Constraints
The management solution MUST support both name servers that are The management solution MUST support both name servers that are
serving a small number of potentially very large zones (e.g. Top 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 Level Domains (TLDs)) as well as name servers that are serving a very
large number of small zones. These scenarios are both commonly seen large number of small zones. Both deployment scenarios are common.
deployments.
2.1.2. Name Server Discovery 2.1.2. Name Server Discovery
Large enterprise network deployments may contain multiple name Large enterprise network deployments may contain multiple name
servers operating within the boundaries of the enterprise network. servers operating within the boundaries of the enterprise network.
These name servers may each be serving multiple zones both in and out These name servers may each be serving multiple zones both in and out
of the parent enterprise's zone. Finding and managing large of the parent enterprise's zone. Finding and managing a large
quantities of name servers would be a useful feature of the resulting numbers of name servers would be a useful feature of the resulting
management solution. The management solution MAY support the ability management solution. The management solution MAY support the ability
to discover previously unknown instances of name servers operating to discover previously unknown instances of name servers operating
within a deployed network. within a deployed network.
2.1.3. Configuration Data Volatility 2.1.3. Configuration Data Volatility
Configuration data is defined as data that relates only to the Configuration data is defined as data that relates only to the
configuration of a server and the zones it serves. It specifically configuration of a server and the zones it serves. It specifically
does not include data from the zone contents that is served through does not include data from the zone contents that is served through
DNS itself. The solution MUST support servers that remain fairly DNS itself. The solution MUST support servers that remain fairly
statically configured over time as well as servers that have numerous statically configured over time as well as servers that have numerous
zones being added and removed within an hour. Both of these zones being added and removed within an hour. Both deployment
scenarios are also commonly seen deployments. scenarios are common.
2.1.4. Protocol Selection 2.1.4. Protocol Selection
There are many requirements in this document for many different types There are many requirements in this document for many different types
of management operations (see Section 3 for further details). It is of management operations (see Section 3 for further details). It is
possible that no one protocol will ideally fill all the needs of the possible that no one protocol will ideally fill all the needs of the
requirements listed in this document and thus multiple protocols requirements listed in this document and thus multiple protocols
might be needed to produce a completely functional management system. might be needed to produce a completely functional management system.
Multiple protocols might be used to create the complete management Multiple protocols might be used to create the complete management
solution, but the number of protocols used SHOULD be reduced to a solution, but the number of protocols used SHOULD be reduced to a
skipping to change at page 7, line 4 skipping to change at page 7, line 51
Defining a standardized protocol (or set of protocols) to use for Defining a standardized protocol (or set of protocols) to use for
managing name servers would be a step forward in achieving an managing name servers would be a step forward in achieving an
interoperable management solution. However, just defining a protocol interoperable management solution. However, just defining a protocol
to use by itself would not achieve the complete end goal of a to use by itself would not achieve the complete end goal of a
complete interoperable management solution. Devices also need to complete interoperable management solution. Devices also need to
represent their internal management interface using a common represent their internal management interface using a common
management data model. The solution MUST create a common data model management data model. The solution MUST create a common data model
that management stations can make use of when sending or collecting that management stations can make use of when sending or collecting
data from a managed device so it can successfully manage equipment data from a managed device so it can successfully manage equipment
from vendors as if they were generic DNS servers. This common data 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 that this does not preclude the fact that name server vendors might
provide additional management infrastructure beyond a base management provide additional management infrastructure beyond a base management
specification, as discussed further in Section 5.1. specification, as discussed further in Section 5.1.
2.1.6. Operational Impact 2.1.6. Operational Impact
It is impossible to add new features to an existing server (such as It is impossible to add new features to an existing server (such as
the inclusion of a management infrastructure) and not impact the the inclusion of a management infrastructure) and not impact the
existing service and/or server in some fashion. At a minimum, for existing service and/or server in some fashion. At a minimum, for
example, more memory, disk and/or CPU resources will be required to example, more memory, disk and/or CPU resources will be required to
skipping to change at page 8, line 23 skipping to change at page 9, line 23
3.1.1. Needed Control Operations 3.1.1. Needed Control Operations
These operations SHOULD include, at a minimum, the following These operations SHOULD include, at a minimum, the following
operations: operations:
o Starting the name server o Starting the name server
o Reloading the service configuration 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 Restarting the name server
o Stopping the name server o Stopping the name server
Note that no restriction is placed on how the management system Note that no restriction is placed on how the management system
implements these operations. In particular, at least "starting the implements these operations. In particular, at least "starting the
name server" will require a minimal management system component to name server" will require a minimal management system component to
exist independently of the name server itself. exist independently of the name server itself.
skipping to change at page 14, line 27 skipping to change at page 15, line 27
In particular, the following team members contributed significantly In particular, the following team members contributed significantly
to the text in the document: to the text in the document:
Stephane Bortzmeyer Stephane Bortzmeyer
Stephen Morris Stephen Morris
Phil Regnauld Phil Regnauld
Further editing contributions and wording suggestions were made by: Further editing contributions and wording suggestions were made by:
Alfred Hoenes. Alfred Hoenes, Doug Barton.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
 End of changes. 18 change blocks. 
77 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/