draft-ietf-dnsop-name-server-management-reqs-05.txt   rfc6168.txt 
DNSOP W. Hardaker Internet Engineering Task Force (IETF) W. Hardaker
Internet-Draft Sparta, Inc. Request for Comments: 6168 Sparta, Inc.
Intended status: Informational January 5, 2011 Category: Informational May 2011
Expires: July 9, 2011 ISSN: 2070-1721
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-05.txt
Abstract Abstract
Management of name servers for the Domain Name System (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 platforms can test the functionality of the DNS itself, there is not
an 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
name servers and can be used as a shopping list of needed features name servers and can be used as a shopping list of needed features
for such a system. for such a system.
Status of this Memo Status of This Memo
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 This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on July 9, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6168.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.2. Document Layout and Requirements . . . . . . . . . . . 6 1.3. Document Layout and Requirements . . . . . . . . . . . . . 5
2. Management Architecture Requirements . . . . . . . . . . . . . 6 2. Management Architecture Requirements . . . . . . . . . . . . . 5
2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 6 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6
2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 7 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
2.1.3. Configuration Data Volatility . . . . . . . . . . . . 7 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 7 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 7 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 8 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 8 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
3. Management Operation Types . . . . . . . . . . . . . . . . . . 8 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 9 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
3.1.1. Needed Control Operations . . . . . . . . . . . . . . 9 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
3.1.2. Asynchronous Status Notifications . . . . . . . . . . 9 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
3.2. Configuration Requirements . . . . . . . . . . . . . . . . 10 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 10 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 10 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
3.2.3. Security Expectations . . . . . . . . . . . . . . . . 10 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 10 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
3.2.5. DNS Protocol Authorization Management . . . . . . . . 11 3.2.5. DNS Protocol Authorization Management . . . . . . . . 10
3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 11 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 12 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 12 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 12 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 13 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 13 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 14 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
5.1.2. Extension Identification . . . . . . . . . . . . . . . 14 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
5.1.3. Name-Space Collision Protection . . . . . . . . . . . 14 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
8. Document History . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16
Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . 17
A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Management of name servers for the Domain Name System (DNS) [RFC1034] Management of name servers for the Domain Name System (DNS) [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
monitoring platforms can test the functionality of the DNS itself service monitoring platforms can test the functionality of the DNS
there is not an interoperable way to manage (monitor, control and itself, there is not an interoperable way to manage (monitor,
configure) the internal aspects of a name server itself. control, and 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 documented in
documented in [RFC3197]. [RFC3197].
This document discusses the requirements of a management system for This document discusses the requirements of a management system for
name servers and can be used as a shopping list of needed features name servers and can be used as a shopping list of needed features
for such a system. This document only discusses requirements for for such a system. This document only discusses requirements for
managing the name server component of a system and not other elements managing the name server component of a system -- not other elements
of the system itself. of the system itself.
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 the management of stub resolvers. It is not the
of this document to document stub resolver requirements, although intent of this document to document stub resolver requirements,
some of the requirements listed are applicable to stub resolvers as although some of the requirements listed are applicable to stub
well. resolvers as well.
The task of creating a management system for managing DNS servers is 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 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 solution will need to be designed in parts over time; these
requirements take this into consideration. In particular, requirements take this into consideration. In particular,
Section 5.1 discusses the need for future extensibility of the base Section 5.1 discusses the need for future extensibility of the base
management solution. This document is intended to be a road-map management solution. This document is intended to be a roadmap
towards a desired outcome and is not intended to define an "all-or- towards a desired outcome and is not intended to define an "all-or-
nothing" system. Successful interoperable management of name servers nothing" system. Successful interoperable management of name
even in part is expected to be beneficial to network operators servers, even in part, is expected to be beneficial to network
compared to the entirely custom solutions that are used at the time operators compared to the entirely custom solutions that are used at
of this writing. the time of this writing.
1.1. Requirements notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.1.1. Terminology 1.2. Terminology
This document is consistent with the terminology defined in Section 2 This document is consistent with the terminology defined in Section 2
of [RFC4033]. Additional terminology needed for this document is of [RFC4033]. Additional terminology needed for this document is
described below: described below:
Name Server: When we are discussing servers that don't fall into a Name Server: When we are discussing servers that don't fall into a
more specific type of server category defined in other documents, more specific type of server category defined in other documents,
this document will refer to them generically as "name servers". this document will refer to them generically as "name servers".
In particular "name servers" can be considered to be any valid In particular, "name servers" can be considered to be any valid
combination of authoritative, recursive, validating, or security- combination of authoritative, recursive, validating, or security-
aware. The more specific name server labels will be used when aware. The more specific name server labels will be used when
this document refers only to a specific type of server. However, this document refers only to a specific type of server. However,
the term "name server", in this document, will not include stub the term "name server", in this document, will not include stub
resolvers. resolvers.
1.1.2. Document Layout and Requirements 1.3. Document Layout and Requirements
The document is written so that each numbered section will contain This document is written so that each numbered section will contain
only a single requirement if it contains one at all. Each only a single requirement if it contains one at all. Each
requirement will contain needed wording from the terminology requirement will contain needed wording from the terminology
described in Section 1.1. Subsections, however, might exist with described in Section 1.1. Subsections, however, might exist with
additional related requirements. The document is laid out in this additional related requirements. The document is laid out in this
way so that a specific requirement can be uniquely referred to using way so that a specific requirement can be uniquely referred to using
the section number itself and the document version from which it the section number itself and the document version from which it
came. came.
2. Management Architecture Requirements 2. Management Architecture Requirements
This section discusses requirements that reflect the needs of the This section discusses requirements that reflect the needs of the
expected deployment environments. expected deployment environments.
2.1. Expected Deployment Scenarios 2.1. Expected Deployment Scenarios
DNS zones vary greatly in the type of content published within them. DNS zones vary greatly in the type of content published within them.
Name Servers, too, are deployed with a wide variety of configurations Name servers, too, are deployed with a wide variety of configurations
to support the diversity of the deployed content. It is important to support the diversity of the deployed content. It is important
that a management solution trying to meet the criteria specified in that a management solution trying to meet the criteria specified in
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. Both deployment scenarios are common. large number of small zones. Both deployment scenarios are common.
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 a large of the parent enterprise's zone. Finding and managing large numbers
numbers of name servers would be a useful feature of the resulting of name servers would be a useful feature of the resulting management
management solution. The management solution MAY support the ability solution. The management solution MAY support the ability to
to discover previously unknown instances of name servers operating 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 statically DNS itself. The solution MUST support servers that remain statically
configured over time as well as servers that have numerous zones configured over time as well as servers that have numerous zones
being added and removed within an hour. Both deployment scenarios being added and removed within an hour. Both deployment scenarios
are common. 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 solution SHOULD require only one. solution, but the solution SHOULD require only one.
2.1.5. Common Data Model 2.1.5. Common Data Model
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 entire end goal of a complete
complete interoperable management solution. Devices also need to interoperable management solution. Devices also need to represent
represent their internal management interface using a common their internal management interface using a common management data
management data model. The solution MUST create a common data model model. The solution MUST create a common data model that management
that management stations can make use of when sending or collecting stations can make use of when sending or collecting data from a
data from a managed device so it can successfully manage equipment managed device so it can successfully manage equipment from vendors
from vendors as if they were generic DNS servers. This common data as if they were generic DNS servers. This common data model is
model is needed for the operations discussion in Section 3. Note needed for the operations discussion in Section 3. Note that this
that this does not preclude the fact that name server vendors might does not preclude the fact that name server vendors might provide
provide additional management infrastructure beyond a base management 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
implement a new management system. However, the impact to the implement a new management system. However, the impact to the
existing DNS service MUST be minimized since the DNS service itself existing DNS service MUST be minimized since the DNS service itself
is still the primary service to be offered by the modified name is still the primary service to be offered by the modified name
server. The management solution MUST NOT result in an increase of server. The management solution MUST NOT result in an increase of
the number of unhandled DNS requests. the number of unhandled DNS requests.
2.2. Name Server Types 2.2. Name Server Types
There are multiple ways in which name servers can be deployed. Name There are multiple ways in which name servers can be deployed. Name
servers can take on any of the following roles: servers can take on any of the following roles:
skipping to change at page 8, line 37 skipping to change at page 7, line 41
o Recursive Servers o Recursive Servers
The management solution SHOULD support all of these types of name The management solution SHOULD support all of these types of name
servers as they are all equally important. Note that "Recursive servers as they are all equally important. Note that "Recursive
Servers" can be further broken down by the security sub-roles they Servers" can be further broken down by the security sub-roles they
might implement, as defined in section 2 of [RFC4033]. These sub- might implement, as defined in section 2 of [RFC4033]. These sub-
roles are also important to support within any management solution. roles are also important to support within any management solution.
As stated earlier, the management of stub resolvers is considered out As stated earlier, the management of stub resolvers is considered out
of scope for this documents. of scope for this document.
3. Management Operation Types 3. Management Operation Types
Management operations can traditionally be broken into four Management operations can traditionally be broken into four
categories: categories:
o Control o Control
o Configuration o Configuration
o Health and Monitoring o Health and Monitoring
o Alarms and Events o Alarms and Events
This section discusses requirements for each of these four management This section discusses detailed requirements for each of these four
types in detail. management categories.
3.1. Control Requirements 3.1. Control Requirements
The management solution MUST be capable of performing basic service The management solution MUST be capable of performing basic service
control operations. control operations.
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 of all of the zone data o Reloading all of the zone data
o Reloading of individual zone data sets o Reloading 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.
3.1.2. Asynchronous Status Notifications 3.1.2. Asynchronous Status Notifications
Some control operations might take a long time to complete. As an Some control operations might take a long time to complete. As an
example, some name servers take a long time to perform reloads of example, some name servers take a long time to perform reloads of
large zones. Because of these timing issues, the management solution large zones. Because of these timing issues, the management solution
SHOULD take this into consideration and offer a mechanism to ease the SHOULD take this into consideration and offer a mechanism to ease the
burden associated with awaiting the status of a long-running command. burden associated with awaiting the status of a long-running command.
This could, for example, result in the use of asynchronous This could, for example, result in the use of asynchronous
notifications for returning the status of a long-running task or it notifications for returning the status of a long-running task, or it
might require the management station to poll for the status of a might require the management station to poll for the status of a
given task using monitoring commands. These and other potential given task using monitoring commands. These and other potential
solutions need to be evaluated carefully to select one that balances solutions need to be evaluated carefully to select one that balances
the result delivery needs with the perceived implementation costs. the result delivery needs with the perceived implementation costs.
Also, see the related discussion in Section 3.4 on notification Also, see the related discussion in Section 3.4 on notification
messages for supporting delivery of alarm and event messages. messages for supporting delivery of alarm and event messages.
3.2. Configuration Requirements 3.2. Configuration Requirements
Many features of name servers need to be configured before the server Many features of name servers need to be configured before the server
can be considered functional. The management solution MUST be able can be considered functional. The management solution MUST be able
to provide name servers with configuration data. The most important to provide name servers with configuration data. The most important
data to be configured, for example, is the served zone data itself. data to be configured, for example, is the served zone data itself.
3.2.1. Served Zone Modification 3.2.1. Served Zone Modification
The ability to add, modify and delete zones being served by name The ability to add, modify, and delete zones being served by name
servers is needed. Although there are already solutions for zone servers is needed. Although there are already solutions for zone
content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007], content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that full zone transfer (AXFR) [RFC5936], and incremental zone transfer
might be used as part of the final management solution, the (IXFR) [RFC1995]) that might be used as part of the final management
management system SHOULD still be able to create a new zone (with solution, the management system SHOULD still be able to create a new
enough minimal data to allow the other mechanisms to function as zone (with enough minimal data to allow the other mechanisms to
well) as well as delete a zone. This might be, for example, a function as well) and to delete a zone. This might be, for example,
management operation that at least allows for the creation of the a management operation that allows for the creation of at least the
initial SOA (Start of a zone Of Authority) record for a new zone as initial SOA (Start of Authority) record for a new zone, since that is
that's the minimum amount of zone data needed for the other the minimum amount of zone data needed for the other operations to
operations to function. function.
3.2.2. Trust Anchor Management 3.2.2. Trust Anchor Management
The solution SHOULD support the ability to add, modify and delete The solution SHOULD support the ability to add, modify, and delete
trust anchors that are used by DNS Security (DNSSEC) [RFC4033] trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
[RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust
anchors might be configured using the data from the DNSKEY Resource anchors might be configured using the data from the DNSKEY Resource
Records (RRs) themselves or by using Delegation Signer (DS) Records (RRs) themselves or by using Delegation Signer (DS)
fingerprints. fingerprints.
3.2.3. Security Expectations 3.2.3. Security Expectations
DNSSEC Validating resolvers need to make policy decisions about the DNSSEC validating resolvers need to make policy decisions about the
requests being processed. For example, they need to be configured requests being processed. For example, they need to be configured
with a list of zones expected to be secured by DNSSEC. The with a list of zones expected to be secured by DNSSEC. The
management solution SHOULD be able to add, modify and delete management solution SHOULD be able to add, modify, and delete
attributes of DNSSEC security policies. attributes of DNSSEC security policies.
3.2.4. TSIG Key Management 3.2.4. TSIG Key Management
TSIG [RFC2845] allows transaction level authentication of DNS TSIG [RFC2845] allows transaction-level authentication of DNS
traffic. The management solution SHOULD be able to add, modify and traffic. The management solution SHOULD be able to add, modify, and
delete TSIG keys known to the name server. delete TSIG keys known to the name server.
3.2.5. DNS Protocol Authorization Management 3.2.5. DNS Protocol Authorization Management
The management solution SHOULD have the ability to add, modify and The management solution SHOULD have the ability to add, modify, and
delete authorization settings for the DNS protocols itself. Do not delete authorization settings for the DNS protocols itself. Do not
confuse this with the ability to manage the authorization associated confuse this with the ability to manage the authorization associated
with the management protocol itself, which is discussed later in with the management protocol itself, which is discussed later in
Section 4.4. There are a number of authorization settings that are Section 4.4. There are a number of authorization settings that are
used by a name server. Example authorization settings that the used by a name server. Example authorization settings that the
solution might need to cover are: solution might need to cover are:
o Access to operations on zone data (e.g. DDNS) o Access to operations on zone data (e.g., DDNS)
o Access to certain zone data from certain sources (e.g. from o Access to certain zone data from certain sources (e.g., from
particular network subnets) particular network subnets)
o Access to specific DNS protocol services (e.g. recursive service) o Access to specific DNS protocol services (e.g., recursive service)
Note: the above list is expected to be used as a collection of Note: the above list is expected to be used as a collection of
examples and is not a complete list of needed authorization examples and is not a complete list of needed authorization
protections. protections.
3.3. Monitoring Requirements 3.3. Monitoring Requirements
Monitoring is the process of collecting aspects of the internal state 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 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 able to monitor the health of a name server to determine its
operational status, load and other internal attributes. Example operational status, load, and other internal attributes. Example
management tasks that the solution might need to cover are: parameters that the solution might need to collect and analyze are:
o Number of requests sent, responses sent, number of errors, average o Number of requests sent, responses sent, number of errors, average
response latency and other performance counters response latency, and other performance counters
o Server status (e.g. "serving data", "starting up", "shutting o Server status (e.g., "serving data", "starting up", "shutting
down", ...) down", etc.)
o Access control violations o Access control violations
o List of zones being served o List of zones being served
o Detailed statistics about clients interacting with the name server o Detailed statistics about clients interacting with the name server
(e.g. top 10 clients requesting data). (e.g., top 10 clients requesting data).
Note: the above list is expected to be used as a collection of Note: the above list is expected to be used as a collection of
examples and is not a complete list of needed monitoring operations. examples and is not a complete list of needed monitoring operations.
In particular, some monitoring statistics are expected to be In particular, some monitoring statistics are expected to be
computationally or resource expensive and are considered to be "nice computationally or resource expensive and are considered to be "nice
to haves" as opposed to "necessary to have". to have" as opposed to "necessary to have".
3.4. Alarm and Event Requirements 3.4. Alarm and Event Requirements
Events occurring at the name server that trigger alarm notifications Events occurring at the name server that trigger alarm notifications
can quickly inform a management station about critical issues. A can quickly inform a management station about critical issues. A
management solution SHOULD include support for delivery of alarm management solution SHOULD include support for delivery of alarm
conditions. conditions.
Example alarm conditions might include: Example alarm conditions might include:
o The server's status is changing. (e.g it is starting up, reloading o The server's status is changing (e.g., it is starting up,
configuration, restarting or shutting down) reloading configuration, restarting or shutting down).
o A needed resource (e.g. memory or disk space) is exhausted or o A needed resource (e.g., memory or disk space) is exhausted or
nearing exhaustion nearing exhaustion.
o An authorization violation was detected o An authorization violation was detected.
o The server has not received any data traffic (e.g. DNS requests o The server has not received any data traffic (e.g., DNS requests
or NOTIFYs) recently (AKA the "lonely warning"). This condition or NOTIFYs) recently (aka the "lonely warning"). This condition
might indicate a problem with its deployment. might indicate a problem with the server's deployment.
o The number of errors has exceeded a configured threshold o The number of errors has exceeded a configured threshold.
4. Security Requirements 4. Security Requirements
The management solution will need to be appropriately secured against The management solution will need to be appropriately secured against
attacks on the management infrastructure. attacks on the management infrastructure.
4.1. Authentication 4.1. Authentication
The solution MUST support mutual authentication. The management The solution MUST support mutual authentication. The management
client needs to be assured that the management operations are being client needs to be assured that the management operations are being
skipping to change at page 14, line 4 skipping to change at page 12, line 50
provide a new avenue for potential attack. Although the added provide a new avenue for potential attack. Although the added
management benefits will be worth the increased risks, the solution management benefits will be worth the increased risks, the solution
still needs to minimize this impact as much as possible. still needs to minimize this impact as much as possible.
5. Other Requirements 5. Other Requirements
5.1. Extensibility 5.1. Extensibility
The management solution is expected to change and expand over time as The management solution is expected to change and expand over time as
lessons are learned and new DNS features are deployed. Thus, the lessons are learned and new DNS features are deployed. Thus, the
solution MUST be flexible and be able to accommodate new future solution MUST be flexible and able to accommodate new future
management operations. The solution might, for example, make use of management operations. The solution might, for example, make use of
protocol versioning or capability description exchanges to ensure protocol versioning or capability description exchanges to ensure
that management stations and name servers that weren't written to the that management stations and name servers that weren't written to the
same specification version can still interoperate to the best of same specification version can still interoperate to the best of
their combined ability. their combined ability.
5.1.1. Vendor Extensions 5.1.1. Vendor Extensions
It MUST be possible for vendors to extend the standardized management It MUST be possible for vendors to extend the standardized management
model with vendor-specific extensions to support additional features model with vendor-specific extensions to support additional features
offered by their products. offered by their products.
5.1.2. Extension Identification 5.1.2. Extension Identification
It MUST be possible for a management station to understand which It MUST be possible for a management station to understand which
parts of returned data are specific to a given vendor or other parts of returned data are specific to a given vendor or other
standardized extension. The data returned needs to be appropriately standardized extension. The data returned needs to be appropriately
marked through the use of name spaces or similar mechanisms to ensure marked, through the use of name spaces or similar mechanisms, to
that the base management model data can be logically separated from ensure that the base management model data can be logically separated
extension data without needing to understand the extension data from the extension data without needing to understand the extension
itself. data itself.
5.1.3. Name-Space Collision Protection 5.1.3. Name-Space Collision Protection
It MUST be possible to protect against multiple extensions It MUST be possible to protect against multiple extensions
conflicting with each other. The use of name-space protection conflicting with each other. The use of name-space protection
mechanisms for communicated management variables is common practice mechanisms for communicated management variables is common practice
to protect against problems. Name-space identification techniques to protect against such problems. Name-space identification
also frequently solve the "Extension Identification" requirement techniques also frequently solve the "Extension Identification"
discussed in Section 5.1.2 as well. requirement discussed in Section 5.1.2.
6. Security Considerations 6. Security Considerations
Any management protocol for which conformance to this document is Any management protocol for which conformance to this document is
claimed needs to fully support the criteria discussed in Section 4 in claimed needs to fully support the criteria discussed in Section 4 in
order to protect the management infrastructure itself. The DNS is a order to protect the management infrastructure itself. The DNS is a
core Internet service and management traffic that protects it could core Internet service, and management traffic that protects it could
be the target of attacks designed to subvert that service. Because be the target of attacks designed to subvert that service. Because
the management infrastructure will be adding additional interfaces to the management infrastructure will be adding additional interfaces to
that service, it is critical that the management infrastructure that service, it is critical that the management infrastructure
support adequate protections against network attacks. support adequate protections against network attacks.
7. IANA Considerations 7. Document History
No action is required from IANA for this document.
8. Document History
A requirement gathering discussion was held at the December 2007 IETF A requirement-gathering discussion was held at the December 2007 IETF
meeting in Vancouver, BC, Canada and a follow up meeting was held at meeting in Vancouver, BC, Canada, and a follow-up meeting was held at
the March 2008 IETF meeting in Philadelphia. This document is a the March 2008 IETF meeting in Philadelphia. This document is a
compilation of the results of those discussions as well as compilation of the results of those discussions as well as
discussions on the DCOMA mailing list. discussions on the DCOMA mailing list.
9. Acknowledgments 8. Acknowledgments
This draft is the result of discussions within the DCOMA design team This document is the result of discussions within the DCOMA design
chaired by Jaap Akkerhuis. This team consisted of a large number of team chaired by Jaap Akkerhuis. This team consisted of a large
people all of whom provided valuable insight and input into the number of people, all of whom provided valuable insight and input
discussions surrounding name server management. The text of this into the discussions surrounding name server management. The text of
document was written from notes taken during meetings as well as from this document was written from notes taken during meetings as well as
contributions sent to the DCOMA mailing list. This work documents from contributions sent to the DCOMA mailing list. This work
the consensus of the DCOMA design team. documents the consensus of the DCOMA design team.
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, Doug Barton. Alfred Hoenes and Doug Barton.
10. References 9. References
10.1. Normative References 9.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.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996. August 1996.
skipping to change at page 16, line 38 skipping to change at page 15, line 27
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006. (DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007. Trust Anchors", RFC 5011, September 2007.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, March 2008.
10.2. Informative References [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, June 2010.
9.2. Informative References
[RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions",
RFC 1611, May 1994. RFC 1611, May 1994.
[RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
RFC 1612, May 1994. RFC 1612, May 1994.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182, and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
July 1997. July 1997.
skipping to change at page 17, line 14 skipping to change at page 16, line 14
Appendix A. Deployment Scenarios Appendix A. Deployment Scenarios
This appendix documents some additional deployment scenarios that This appendix documents some additional deployment scenarios that
have been traditionally difficult to manage. They are provided as have been traditionally difficult to manage. They are provided as
guidance to protocol developers as data points of real-world name guidance to protocol developers as data points of real-world name
server management problems. server management problems.
A.1. Non-Standard Zones A.1. Non-Standard Zones
If an organization uses non-standard zones (for example a purely- If an organization uses non-standard zones (for example a purely
local TLD), synchronizing all the name servers for these zones is local TLD), synchronizing all the name servers for these zones is
usually a time-consuming task. It is made worse when two usually a time-consuming task. It is made worse when two
organizations with conflicting zones merge. This situation is not a organizations with conflicting zones merge. This situation is not a
recommended deployment scenario (and is even heavily discouraged) but recommended deployment scenario (and is even heavily discouraged),
it is, unfortunately, seen in the wild. but it is, unfortunately, seen in the wild.
It is typically implemented using "forwarding" zones. But there is It is typically implemented using "forwarding" zones. But there is
no way to ensure automatically that all the resolvers have the same 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 set of zones to forward at any given time. New zones might be added
to a local forwarding recursive server, for example, without to a local forwarding recursive server, for example, without
modifying the rest of the deployed forwarding servers. It is hoped modifying the rest of the deployed forwarding servers. It is hoped
that a management solution which could handle the configuration of that a management solution that could handle the configuration of
zone forwarding would finally allow management of servers deployed in zone forwarding would finally allow management of servers deployed in
this fashion. this fashion.
A.2. Redundancy Sharing A.2. Redundancy Sharing
For reliability reasons it is recommended that zone operators follow For reliability reasons, it is recommended that zone operators follow
the guidelines documented in [RFC2182] which recommends that multiple the guidelines documented in [RFC2182], which recommends that
name servers be configured for each zone and that the name servers multiple name servers be configured for each zone and that the name
are separated both physically and via connectivity routes. A common servers be separated both physically and via connectivity routes. A
solution is to establish DNS-serving partnerships: "I'll host your common solution is to establish DNS-serving partnerships: "I'll host
zones and you'll host mine". Both entities benefit from increased your zones and you'll host mine". Both entities benefit from
DNS reliability via the wider service distribution. This frequently increased DNS reliability via the wider service distribution. This
occurs between cooperating but otherwise unrelated entities (such as frequently occurs between cooperating but otherwise unrelated
between two distinct companies) as well as between affiliated entities (such as between two distinct companies) as well as between
organizations (such as between branch offices within a single affiliated organizations (such as between branch offices within a
company). single company).
The configuration of these relationships are currently required to be The configuration of these relationships are currently required to be
manually configured and maintained. Changes to the list of zones manually configured and maintained. Changes to the list of zones
that are cross-hosted are manually negotiated between the cooperating that are cross-hosted are manually negotiated between the cooperating
network administrators and configured by hand. A management protocol network administrators and configured by hand. A management protocol
with the ability to provide selective authorization, as discussed in with the ability to provide selective authorization, as discussed in
Section 4.4, would solve many of the management difficulties between Section 4.4, would solve many of the management difficulties between
cooperating organizations. cooperating organizations.
A.3. DNSSEC Management A.3. DNSSEC Management
skipping to change at page 18, line 30 skipping to change at page 17, line 30
signing keys (ZSKs) controlled and operated by a second signing keys (ZSKs) controlled and operated by a second
organization, and key signing keys (KSKs) controlled and operated organization, and key signing keys (KSKs) controlled and operated
by a third organization. by a third organization.
Although this list is not exhaustive in the potential ways that zone Although this list is not exhaustive in the potential ways that zone
data can be divided up, it should be sufficient to illustrate the data can be divided up, it should be sufficient to illustrate the
potential ways in which zone data can be controlled by multiple potential ways in which zone data can be controlled by multiple
entities. entities.
The end result of all of these strategies, however, will be the same: The end result of all of these strategies, however, will be the same:
a live zone containing DNSSEC related resource records. Many of the a live zone containing DNSSEC-related resource records. Many of the
above strategies are merely different ways of preparing a zone for above strategies are merely different ways of preparing a zone for
serving. A management solution that includes support for managing serving. A management solution that includes support for managing
DNSSEC zone data may wish to take into account these potential DNSSEC zone data may wish to take into account these potential
management scenarios. management scenarios.
Author's Address Author's Address
Wes Hardaker Wes Hardaker
Sparta, Inc. Sparta, Inc.
P.O. Box 382 P.O. Box 382
Davis, CA 95617 Davis, CA 95617
US US
Phone: +1 530 792 1913 Phone: +1 530 792 1913
Email: ietf@hardakers.net EMail: ietf@hardakers.net
 End of changes. 75 change blocks. 
198 lines changed or deleted 191 lines changed or added

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