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/