draft-ietf-dnsop-name-server-management-reqs-04.txt   draft-ietf-dnsop-name-server-management-reqs-05.txt 
DNSOP W. Hardaker DNSOP W. Hardaker
Internet-Draft Sparta, Inc. Internet-Draft Sparta, Inc.
Intended status: Informational June 11, 2010 Intended status: Informational January 5, 2011
Expires: December 13, 2010 Expires: July 9, 2011
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-04.txt 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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 13, 2010. This Internet-Draft will expire on July 9, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 29 skipping to change at page 3, line 29
2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 8 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 8
3. Management Operation Types . . . . . . . . . . . . . . . . . . 8 3. Management Operation Types . . . . . . . . . . . . . . . . . . 8
3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 9 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 9
3.1.1. Needed Control Operations . . . . . . . . . . . . . . 9 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 9
3.1.2. Asynchronous Status Notifications . . . . . . . . . . 9 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 9
3.2. Configuration Requirements . . . . . . . . . . . . . . . . 10 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 10
3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 10 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 10
3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 10 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 10
3.2.3. Security Expectations . . . . . . . . . . . . . . . . 10 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 10
3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 10 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 10
3.2.5. DNS Protocol Authorization Management . . . . . . . . 10 3.2.5. DNS Protocol Authorization Management . . . . . . . . 11
3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 11 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 11
3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 12
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 12
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 12 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 12
4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 12 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 12
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 13 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 13
5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 13 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 14 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 14
5.1.2. Extension Identification . . . . . . . . . . . . . . . 14 5.1.2. Extension Identification . . . . . . . . . . . . . . . 14
5.1.3. Name-Space Collision Protection . . . . . . . . . . . 14 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Document History . . . . . . . . . . . . . . . . . . . . . . . 14 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16 Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 17
A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 17 A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 17
A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 17 A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 17
A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 17 A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 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 service
monitoring platforms can test the functionality of the DNS itself monitoring platforms can test the functionality of the DNS itself
there is not an 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
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. 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 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
other components of the host upon which the name server software is
running. This document only discusses requirements for managing the
name server component of a system.
The task of creating a management system for managing DNS servers is 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 and 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 road-map
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 servers
even in part is expected to be beneficial to network operators even in part is expected to be beneficial to network operators
compared to the entirely custom solutions that are used at the time compared to the entirely custom solutions that are used at the time
skipping to change at page 7, line 23 skipping to change at page 7, line 23
numbers 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 statically
statically configured over time as well as servers that have numerous configured over time as well as servers that have numerous zones
zones being added and removed within an hour. Both deployment being added and removed within an hour. Both deployment scenarios
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 number of protocols used SHOULD be reduced to a solution, but the solution SHOULD require only one.
reasonable minimum number.
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 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
skipping to change at page 8, line 17 skipping to change at page 8, line 16
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. server. The management solution MUST NOT result in an increase of
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:
o Master Servers o Master Servers
o Slave Servers o Slave Servers
skipping to change at page 10, line 19 skipping to change at page 10, line 19
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 AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that
might be used as part of the final management solution, the might be used as part of the final management solution, the
management system SHOULD still be able to natively create a new zone management system SHOULD still be able to create a new zone (with
(with enough minimal data to allow the other mechanisms to function enough minimal data to allow the other mechanisms to function as
as well) as well as delete a zone. This might be, for example, a well) as well as delete a zone. This might be, for example, a
management operation that at least allows for the creation of the management operation that at least allows for the creation of the
initial SOA record for a new zone as that's the minimum amount of initial SOA (Start of a zone Of Authority) record for a new zone as
zone data needed for the other operations to function. that's the minimum amount of zone data needed for the other
operations to 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.
skipping to change at page 11, line 29 skipping to change at page 11, line 34
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: management tasks that the solution might need to cover are:
o Number of requests sent, responses sent, average response latency o Number of requests sent, responses sent, number of errors, average
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", ...)
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).
skipping to change at page 12, line 21 skipping to change at page 12, line 26
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 its deployment.
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
transferred to and from the correct name server. The managed name transferred to and from the correct name server. The managed name
skipping to change at page 12, line 49 skipping to change at page 13, line 8
4.3. Confidentiality 4.3. Confidentiality
The management solution MUST support message confidentiality. The The management solution MUST support message confidentiality. The
potential transfer of sensitive configuration is expected (such as potential transfer of sensitive configuration is expected (such as
TSIG keys or security policies). The solution does not, however, TSIG keys or security policies). The solution does not, however,
necessarily need to provide confidentiality to data that would necessarily need to provide confidentiality to data that would
normally be carried without confidentiality by the DNS system itself. normally be carried without confidentiality by the DNS system itself.
4.4. Authorization 4.4. Authorization
The solution SHOULD be capable of providing a fine-grained The solution SHOULD provide an authorization model capable of
authorization model for any management protocols it introduces to the selectively authorizing individual management requests for any
completed system. This authorization differs from the authorization management protocols it introduces to the completed system. This
previously discussed in Section 3.2.5 in that this requirement is authorization differs from the authorization previously discussed in
concerned solely with authorization of the management system itself. Section 3.2.5 in that this requirement is concerned solely with
authorization of the management system itself.
There are a number of authorization settings that might be used by a There are a number of authorization settings that might be used by a
managed system to determine whether the managing entity has managed system to determine whether the managing entity has
authorization to perform the given management task. Example authorization to perform the given management task. Example
authorization settings that the solution might need to cover are: authorization settings that the solution might need to cover are:
o Access to the configuration that specifies which zones are to be o Access to the configuration that specifies which zones are to be
served served
o Access to the management system infrastructure o Access to the management system infrastructure
skipping to change at page 14, line 32 skipping to change at page 14, line 38
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 problems. Name-space identification techniques
also frequently solve the "Extension Identification" requirement also frequently solve the "Extension Identification" requirement
discussed in Section 5.1.2 as well. discussed in Section 5.1.2 as well.
6. Security Considerations 6. Security Considerations
Any management protocol that meets the criteria discussed in this Any management protocol for which conformance to this document is
document needs to 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. IANA Considerations
No action is required from IANA for this document. No action is required from IANA for this document.
 End of changes. 21 change blocks. 
38 lines changed or deleted 39 lines changed or added

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