draft-ietf-dnsop-name-server-management-reqs-00.txt   draft-ietf-dnsop-name-server-management-reqs-01.txt 
DNSOP W. Hardaker DNSOP W. Hardaker
Internet-Draft Sparta, Inc. Internet-Draft Sparta, Inc.
Intended status: Informational August 25, 2008 Intended status: Informational September 3, 2008
Expires: February 26, 2009 Expires: March 7, 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-00.txt draft-ietf-dnsop-name-server-management-reqs-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 February 26, 2009. This Internet-Draft will expire on March 7, 2009.
Abstract Abstract
Management of name servers for the Domain Name Service (DNS) has Management of name servers for the Domain Name Service (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 a
interoperable way to manage (monitor, control and configure) the 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 2, line 29 skipping to change at page 2, line 29
2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
3. Management Operation Types . . . . . . . . . . . . . . . . . . 7 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
3.2.5. DNS Protocol Authorization Management . . . . . . . . 10 3.2.5. DNS Protocol Authorization Management . . . . . . . . 9
3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
5.1.2. Extension Identification . . . . . . . . . . . . . . . 13 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
5.1.3. Namespace Collision Protection . . . . . . . . . . . . 13 5.1.3. Namespace Collision Protection . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Document History . . . . . . . . . . . . . . . . . . . . . . . 14 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15 Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15
A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16 A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16 A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
Management of name servers for the Domain Name Service (DNS) Management of name servers for the Domain Name Service (DNS)
[RFC1034] [RFC1035] has traditionally been done using vendor-specific [RFC1034] [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 a 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.
skipping to change at page 5, line 8 skipping to change at page 5, line 8
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.1.1. 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 are 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
skipping to change at page 7, line 4 skipping to change at page 7, line 4
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 model is needed for of the operations discussion in Section 3. Note
Section 3. Note that this does not preclude the fact that name that this does not preclude the fact that name server vendors might
server vendors might provide additional management infrastructure provide additional management infrastructure beyond a base management
beyond a base management specification, as discussed further in specification, as discussed further in Section 5.1.
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
skipping to change at page 8, line 8 skipping to change at page 8, line 8
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 for management This section discusses requirements for each of these four management
types in detail. types in detail.
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
skipping to change at page 8, line 50 skipping to change at page 8, line 50
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 which discusses Also, see the related discussion in Section 3.4 on notification
notification messages for supporting delivery of alarm and event messages for supporting delivery of alarm and event messages.
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
skipping to change at page 9, line 39 skipping to change at page 9, line 38
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.
skipping to change at page 10, line 22 skipping to change at page 10, line 17
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 examples and is not a Note: the above list is expected to be used as a collection of
complete list of needed authorization protections. examples and is not a complete list of needed authorization
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, average response latency
skipping to change at page 10, line 46 skipping to change at page 10, line 42
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).
Note: the above list is expected to be used as examples and is not a Note: the above list is expected to be used as a collection of
complete list of needed monitoring operations. In particular, some examples and is not a complete list of needed monitoring operations.
monitoring statistics are expected to be computationally or resource In particular, some monitoring statistics are expected to be
expensive and are considered to be "nice to haves" as opposed to computationally or resource expensive and are considered to be "nice
"necessary to have". to haves" 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:
skipping to change at page 12, line 29 skipping to change at page 12, line 24
served served
o Access to the management system infrastructure o Access to the management system infrastructure
o Access to other control operations o Access to other control operations
o Access to other configuration operations o Access to other configuration operations
o Access to monitoring operations o Access to monitoring operations
Note: the above list is expected to be used as examples and is not a Note: the above list is expected to be used as a collection of
complete list of needed authorization protections. examples and is not a complete list of needed authorization
protections.
4.5. Solution Impacts on Security 4.5. Solution Impacts on Security
The solution MUST minimize the security risks introduced to the The solution MUST minimize the security risks introduced to the
complete name server system. It is impossible to add new complete name server system. It is impossible to add new
infrastructure to a server and not impact the security in some infrastructure to a server and not impact the security in some
fashion as the introduction of a management protocol alone will fashion as the introduction of a management protocol alone will
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.
skipping to change at page 14, line 32 skipping to change at page 14, line 26
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:
Alfred Hines.
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.
skipping to change at page 17, line 5 skipping to change at page 16, line 47
company). 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
There are many different DNSSEC deployment strategies that may be
used for mission-critical zones. The following list describes some
example deployment scenarios that might warrant different management
strategies.
All contents and DNSSEC keying information controlled and operated
by a single organization
Zone contents controlled and operated by one organization, all
DNSSEC keying information controlled and operated by a second
organization.
Zone contents controlled and operated by one organization, zone
signing keys (ZSKs) controlled and operated by a second
organization, and key signing keys (KSKs) controlled and operated
by a third organization.
Although this list is not exhaustive in the potential ways that zone
data can be divided up, it should be sufficient to illustrate the
potential ways in which zone data can be controlled by multiple
entities.
The end result of all of these strategies, however, will be the same:
a live zone containing DNSSEC related resource records. Many of the
above strategies are merely different ways of preparing a zone for
serving. A management solution that includes support for managing
DNSSEC zone data may wish to take into account these potential
management scenarios.
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. 18 change blocks. 
29 lines changed or deleted 64 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/