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/