One document matched: draft-ietf-dnsop-name-server-management-reqs-05.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc1034 PUBLIC '' 'reference.RFC.1034.xml'>
  <!ENTITY rfc1035 PUBLIC '' 'reference.RFC.1035.xml'>
  <!ENTITY rfc1995 PUBLIC '' 'reference.RFC.1995.xml'>
  <!ENTITY rfc2119 PUBLIC '' 'reference.RFC.2119.xml'>
  <!ENTITY rfc2136 PUBLIC '' 'reference.RFC.2136.xml'>
  <!ENTITY rfc2845 PUBLIC '' 'reference.RFC.2845.xml'>
  <!ENTITY rfc3007 PUBLIC '' 'reference.RFC.3007.xml'>
  <!ENTITY rfc4033 PUBLIC '' 'reference.RFC.4033.xml'>
  <!ENTITY rfc4034 PUBLIC '' 'reference.RFC.4034.xml'>
  <!ENTITY rfc4035 PUBLIC '' 'reference.RFC.4035.xml'>
  <!ENTITY rfc4509 PUBLIC '' 'reference.RFC.4509.xml'>
  <!ENTITY rfc5011 PUBLIC '' 'reference.RFC.5011.xml'>
  <!ENTITY rfc5155 PUBLIC '' 'reference.RFC.5155.xml'>
  <!ENTITY rfc1611 PUBLIC '' 'reference.RFC.1611.xml'>
  <!ENTITY rfc1612 PUBLIC '' 'reference.RFC.1612.xml'>
  <!ENTITY rfc2182 PUBLIC '' 'reference.RFC.2182.xml'>
  <!ENTITY rfc3197 PUBLIC '' 'reference.RFC.3197.xml'>
]>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="3" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" ipr="pre5378Trust200902" docName="draft-ietf-dnsop-name-server-management-reqs-05.txt">
    <front>
    <title abbrev="Name Server Management Requirements">
      Requirements for Management of Name Servers for the DNS
    </title>
    <author initials="W.H." surname="Hardaker" fullname="Wes Hardaker">
      <organization>Sparta, Inc.</organization>
      <address>
	<postal>
	  <street>P.O. Box 382</street>
	  <city>Davis</city>
	  <region>CA</region>
	  <code>95617</code>
	  <country>US</country>
	</postal>
	<phone>+1 530 792 1913</phone>
        <email>ietf@hardakers.net</email>
      </address>
    </author>
    <date month="January" year="2011"/>
    <area>Operations and Management</area>
    <workgroup>DNSOP</workgroup>
    <!--
    <keyword ...>
    <keyword ...>
    -->
    <abstract>
      <t>Management of name servers for the Domain Name System (DNS)
      has traditionally been done using vendor-specific monitoring,
      configuration and control methods.  Although some service
      monitoring platforms can test the functionality of the DNS
      itself there is not an interoperable way to manage (monitor,
      control and configure) the internal aspects of a name
      server itself.</t>

      <t>This document discusses the requirements of a management
	system for name servers and can be used as a shopping
	list of needed features for such a system.</t>


    </abstract>
    <!--
    <note ...>
    -->
  </front>

  <middle>
    <section title="Introduction">

      <t>Management of name servers for the Domain Name System (DNS)
      <xref target="RFC1034" /> <xref target="RFC1035" /> has
      traditionally been done using vendor-specific monitoring,
      configuration and control methods.    Although some service
      monitoring platforms can test the functionality of the DNS
      itself there is not an interoperable way to manage (monitor,
      control and configure) the internal aspects of a name
      server itself.</t>


      <t>Previous standardization work within the IETF resulted
      in the creation of two SNMP MIB modules <xref target="RFC1611"
      /> <xref target="RFC1612" /> but they failed to achieve
      significant implementation and deployment.  The perceived
      reasons behind the failure for the two MIB modules are further
      documented in <xref target="RFC3197" />.</t>

      <t>This document discusses the requirements of a management
	system for name servers and can be used as a shopping list of
	needed features 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.</t>

      <t>Specifically out of scope for this document are requirements
      associated with management of stub resolvers.  It is not the
      intent of this document to document stub resolver requirements,
      although some of the requirements listed are applicable to stub
      resolvers as well.</t>

      <t>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 solution will need to be designed in parts
	over time and these requirements take this into consideration.
	In particular, <xref target="extensibility" /> discusses the
	need for future extensibility of the base management solution.
	This document is intended to be a road-map towards a desired
	outcome and is not intended to define an "all-or-nothing"
	system.  Successful interoperable management of name servers
	even in part is expected to be beneficial to network operators
	compared to the entirely custom solutions that are used at
	the time of this writing.</t>
      <section title="Requirements notation" anchor="musts">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	  "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	  and "OPTIONAL" in this document are to be interpreted as
	  described in <xref target="RFC2119"/>.</t>
      <section title="Terminology">
	<t>This document is consistent with the terminology defined in
	  Section 2 of <xref target="RFC4033" />.  Additional terminology
	  needed for this document is described below:
	  <list style="hanging">
	    <t hangText="Name Server:">When we are discussing servers
	      that don't fall into a more specific type of server
	      category defined in other documents, this document will
	      refer to them generically as "name servers".  In
	      particular "name servers" can be considered to be any
	      valid combination of authoritative, recursive,
	      validating, or security-aware.  The more specific name
	      server labels will be used when this document refers
	      only to a specific type of server.  However, the term
	      "name server", in this document, will not include stub
	      resolvers.</t>
	  </list>
	</t>
      </section>
      <section title="Document Layout and Requirements">
	<t>The document is written so that each numbered section will
	contain only a single requirement if it contains one at all.
	Each requirement will contain needed wording from the
	terminology described in <xref target="musts" />.
	Subsections, however, might exist with additional related
	requirements.  The document is laid out in this way so that a
	specific requirement can be uniquely referred to using the
	section number itself and the document version from which it
	came.</t>
      </section>
      </section>
    </section>
    <section title="Management Architecture Requirements">
      <t>This section discusses requirements that reflect the needs of
      the expected deployment environments.</t>
      <section title="Expected Deployment Scenarios">
	<t>DNS zones vary greatly in the type of content published
	within them.  Name Servers, too, are deployed with a wide
	variety of configurations to support the diversity of the
	deployed content.  It is important that a management solution
	trying to meet the criteria specified in this document
	consider supporting the largest number of potential deployment
	cases as possible.  Further deployment scenarios that are not
	used as direct examples of specific requirements are listed in
	<xref target="deployment" />.</t>

	<section title="Zone Size Constraints">
	  <t>The management solution MUST support both
	    name servers that are 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 large number of small
	    zones.  Both deployment scenarios are common.</t>
	</section>
	<section title="Name Server Discovery">
	  <t>Large enterprise network deployments may contain multiple
	  name servers operating within the boundaries of the
	  enterprise network.  These name servers may each be serving
	  multiple zones both in and out of the parent enterprise's
	  zone.  Finding and managing a large numbers of name servers
	  would be a useful feature of the resulting management
	  solution.  The management solution MAY support the ability
	  to discover previously unknown instances of name servers
	  operating within a deployed network.</t>
	</section>
	<section title="Configuration Data Volatility">
	  <t>Configuration data is defined as data that relates only to
	  the configuration of a server and the zones it serves.  It
	  specifically does not include data from the zone contents
	  that is served through DNS itself.
          The solution MUST support servers that
	  remain statically configured over time as well as
	  servers that have numerous zones being added and removed
	  within an hour.  Both deployment scenarios are common.</t>
	</section>
	<section title="Protocol Selection">
	  <t>There are many requirements in this document for many
	  different types of management operations (see <xref
	  target="managementtypes" /> for further details).  It is
	  possible that no one protocol will ideally fill all the
	  needs of the requirements listed in this document and thus
	  multiple protocols might be needed to produce a completely
	  functional management system.  Multiple protocols might be
	  used to create the complete management solution, but the
	  solution SHOULD require only one.</t>
	</section>
	<section title="Common Data Model">
	  <t>Defining a standardized protocol (or set of protocols) to
	  use for managing name servers would be a step forward in
	  achieving an interoperable management solution.  However,
	  just defining a protocol to use by itself would not achieve
	  the complete end goal of a complete interoperable management
	  solution.  Devices also need to represent their internal
	  management interface using a common management data model.
	  The solution MUST create a common data model that management
	  stations can make use of when sending or collecting data
	  from a managed device so it can successfully manage
	  equipment from vendors as if they were generic DNS servers.
	  This common data model is needed for the operations
	  discussion in <xref target="managementtypes" />.
	  Note that this does not preclude the fact that name server
	  vendors might provide additional management infrastructure
	  beyond a base management specification, as discussed further
	  in <xref target="extensibility" />.</t>
	</section>
	<section title="Operational Impact">
	  <t>It is impossible to add new features to an existing
	  server (such as the inclusion of a management
	  infrastructure) and not impact the existing service and/or
	  server in some fashion.  At a minimum, for example, more
	  memory, disk and/or CPU resources will be required to
	  implement a new management system.  However, the impact to
	  the existing DNS service MUST be minimized since the DNS
	  service itself is still the primary service to be offered by
	  the modified name server.  The management solution MUST NOT
	  result in an increase of the number of unhandled DNS
	  requests.</t>
	</section>
      </section>
      <section title="Name Server Types">
	<t>There are multiple ways in which name servers can be
	deployed.  Name servers can take on any of the following roles:
	  <list style="symbols">
	    <t>Master Servers</t>
	    <t>Slave Servers</t>
	    <t>Recursive Servers</t>
	  </list>
	</t>

	<t>The management solution SHOULD support all of these types
	  of name servers as they are all equally important.  Note
	  that "Recursive Servers" can be further broken down by the
	  security sub-roles they might implement, as defined in
	  section 2 of <xref target="RFC4033" />.  These sub-roles are
	  also important to support within any management
	  solution.</t>

	<t>As stated earlier, the management of stub resolvers is
	  considered out of scope for this documents.</t>
      </section>
    </section>

    <section title="Management Operation Types" anchor="managementtypes">
      <t>Management operations can traditionally be broken into
	four categories:
	<list style="symbols">
	  <t>Control</t>
	  <t>Configuration</t>
	  <t>Health and Monitoring</t>
	  <t>Alarms and Events</t>
	</list>
      </t>
      <t>This section discusses requirements for each of these
      four management types in detail.</t>
      <section title="Control Requirements">
	<t>The management solution MUST be capable of performing
	  basic service control operations.</t>
	<section title="Needed Control Operations">
	  <t>These operations SHOULD include, at a minimum, the
	    following operations:
	    <list style="symbols">
	      <t>Starting the name server</t>
	      <t>Reloading the service configuration</t>
	      <t>Reloading of all of the zone data</t>
	      <t>Reloading of individual zone data sets</t>
	      <t>Restarting the name server</t>
	      <t>Stopping the name server</t>
	    </list>
	  </t>

	  <t> Note that no restriction is placed on how the
	    management system implements these operations.  In particular,
	    at least "starting the name server" will require a minimal
	    management system component to exist independently of the name
	    server itself.</t>
	</section>

	<section title="Asynchronous Status Notifications">
	  <t>Some control operations might take a long time to complete.
	    As an example, some name servers take a long time to
	    perform reloads of large zones.  Because of these timing
	    issues, the management solution SHOULD take this into
	    consideration and offer a mechanism to ease the burden
	    associated with awaiting the status of a long-running
	    command.  This could, for example, result in the use of
	    asynchronous notifications for returning the status of a
	    long-running task or it might require the management station
	    to poll for the status of a given task using monitoring
	    commands.  These and other potential solutions need to be
	    evaluated carefully to select one that balances the result
	    delivery needs with the perceived implementation costs.</t>

	    <t>Also, see the related discussion in <xref
	    target="alarms" /> on notification messages
	    for supporting delivery of alarm and event messages.</t>
	</section>
      </section>
      <section title="Configuration Requirements">
	<t>Many features of name servers need to be configured before
	the server can be considered functional.  The management
	solution MUST be able to provide name servers with
	configuration data.  The most important data to be configured,
	for example, is the served zone data itself.</t>
	<section title="Served Zone Modification">
	  <t>The ability to add, modify and delete
	    zones being served by name servers is needed.  Although
	    there are already solutions for zone content modification
	    (such as Dynamic DNS (DDNS) <xref target="RFC2136" />
	    <xref target="RFC3007" />, AXFR <xref target="RFC1035" />,
	    and incremental zone transfer (IXFR) <xref
	    target="RFC1995" />) that might be used as part of the
	    final management solution, the management system SHOULD
	    still be able to create a new zone (with enough minimal
	    data to allow the other mechanisms to function as well) as
	    well as delete a zone.  This might be, for example, a
	    management operation that at least allows for the creation
	    of the initial SOA (Start of a zone Of Authority) record
	    for a new zone as that's the minimum amount of zone data
	    needed for the other operations to function.</t>
	</section>
	<section title="Trust Anchor Management">
	  <t>The solution SHOULD support the ability to add, modify
	    and delete trust anchors that are used by DNS Security
	    (DNSSEC) <xref target="RFC4033" /> <xref target="RFC4034"
	    /> <xref target="RFC4035" /> <xref target="RFC4509" />
	    <xref target="RFC5011" /> <xref target="RFC5155" />.
	    These trust anchors might be configured using the data from
	    the DNSKEY Resource Records (RRs) themselves or by
	    using Delegation Signer (DS) fingerprints.</t>
	</section>
	<section title="Security Expectations">
	  <t>DNSSEC Validating resolvers need to make policy decisions
	    about the requests being processed.  For example, they
	    need to be configured with a list of zones expected to be
	    secured by DNSSEC.  The management solution SHOULD be able
	    to add, modify and delete attributes of DNSSEC security
	    policies.</t>
	</section>
	<section title="TSIG Key Management">
	  <t>TSIG <xref target="RFC2845" /> allows transaction level
	  authentication of DNS traffic.  The management solution SHOULD
	  be able to add, modify and delete TSIG keys known to the name
	  server.</t>
	</section>
	<section title="DNS Protocol Authorization Management" anchor="acls">
	  <t>The management solution SHOULD have the ability to add,
   	    modify and delete authorization settings for the DNS
   	    protocols itself.  Do not confuse this with the ability to
   	    manage the authorization associated with the management
   	    protocol itself, which is discussed later in <xref
   	    target="authorization" />.
	    There are a number of authorization settings that are used
	    by a name server.  Example authorization settings that the
	    solution might need to cover are:
	    <list style="symbols">
	      <t>Access to operations on zone data (e.g. DDNS)</t>
	      <t>Access to certain zone data from certain sources
	      (e.g. from particular network subnets)</t>
	      <t>Access to specific DNS protocol services
	      (e.g. recursive service)</t>
	    </list>
	  </t>
	  <t>Note: the above list is expected to be used as a
	  collection of examples
	  and is not a complete list of needed authorization protections.</t>
	</section>
      </section>
      <section title="Monitoring Requirements">
	<t>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 able to monitor the health of a name
	server to determine its operational status, load and other
	internal attributes.  Example
	management tasks that the solution might need to cover are:
	  <list style="symbols">
	    <t>Number of requests sent, responses sent, number of
	    errors, average response latency and other performance
	    counters</t>
            <t>Server status (e.g. "serving data",
            "starting up", "shutting down", ...)</t>
	    <t>Access control violations</t>
	    <t>List of zones being served</t>
	    <t>Detailed statistics about clients interacting with
	    the name server (e.g. top 10 clients requesting data).</t>
	  </list>
	</t>
	  <t>Note: the above list is expected to be used as a
	  collection of examples and is not a complete list of needed
	  monitoring operations.  In particular, some monitoring
	  statistics are expected to be computationally or resource
	  expensive and are considered to be "nice to haves" as
	  opposed to "necessary to have".</t>
      </section>
      <section title="Alarm and Event Requirements" anchor="alarms">
	<t>Events occurring at the name server that trigger alarm
	notifications can quickly inform a management station about
	critical issues.  A management solution SHOULD include support
	for delivery of alarm conditions.</t>
	  <t>Example alarm conditions might include:
	    <list style="symbols">
	      <t>The server's status is changing.  (e.g it is starting
	      up, reloading configuration, restarting or shutting
	      down)</t>
	      <t>A needed resource (e.g. memory or disk space) is
	      exhausted or nearing exhaustion</t>
	      <t>An authorization violation was detected</t> 
	      <t>The server has not received any data traffic
	      (e.g. DNS requests or NOTIFYs) recently (AKA the "lonely
	      warning").  This condition might
	      indicate a problem with its deployment.</t>
	      <t>The number of errors has exceeded a configured threshold</t>
	    </list>
	  </t>
      </section>
    </section>


    <section title="Security Requirements" anchor="security">
      <t>The management solution will need to be appropriately secured
	against attacks on the management infrastructure.</t>
      <section title="Authentication">
	<t>The solution MUST support mutual authentication.  The
	management client needs to be assured that the management
	operations are being transferred to and from the correct name
	server.  The managed name server needs to authenticate the
	system that is accessing the management infrastructure within
	itself.</t>
      </section>
      <section title="Integrity Protection">
	<t>Management operations MUST be protected from modification
	while in transit from the management client to the server.</t>
      </section>
      <section title="Confidentiality">
	<t>The management solution MUST support message
	confidentiality.  The potential transfer of sensitive
	configuration is expected (such as TSIG keys or security
	policies).  The solution does not, however, necessarily need
	to provide confidentiality to data that would normally be
	carried without confidentiality by the DNS system
	itself.</t>
      </section>
      <section title="Authorization" anchor="authorization">

	<t>The solution SHOULD provide an
	authorization model capable of selectively authorizing
	individual management requests for any management protocols it
	introduces to the completed system.  This authorization
	differs from the authorization previously discussed in <xref
	target="acls" /> in that this requirement is concerned solely
	with authorization of the management system itself.</t>

	<t>There are a number of authorization settings that might be
	used by a managed system to determine whether the managing
	entity has authorization to perform the given management task.
	Example authorization settings that the
        solution might need to cover are:

	  <list style="symbols">
	    <t>Access to the configuration that specifies which
	      zones are to be served</t>
	    <t>Access to the management system infrastructure</t>
	    <t>Access to other control operations</t>
	    <t>Access to other configuration operations</t>
	    <t>Access to monitoring operations</t>
	  </list>
	</t>

	<t>Note: the above list is expected to be used as a collection
	of examples and is not a complete list of needed authorization
	protections.</t>
      </section>
      <section title="Solution Impacts on Security">
	<t>The solution MUST minimize the security risks introduced to
	the complete name server system.  It is impossible to add new
	infrastructure to a server and not impact the security in some
	fashion as the introduction of a management protocol alone
	will provide a new avenue for potential attack.  Although the
	added management benefits will be worth the increased risks,
	the solution still needs to minimize this impact as much as
	possible.</t>
      </section>
    </section>

    <section title="Other Requirements">
      <section title="Extensibility" anchor="extensibility">
        <t>The management solution is expected to change and expand
        over time as lessons are learned and new DNS features are
        deployed.  Thus, the solution MUST be flexible and be able to
        accommodate new future management operations.  The
        solution might, for example, make use of protocol versioning
        or capability description exchanges to ensure that management
        stations and name servers that weren't written to the same
        specification version can still interoperate to the best of
        their combined ability.</t>
	<section title="Vendor Extensions">
	  <t>It MUST be possible for vendors to extend the
	    standardized management model with vendor-specific
	    extensions to support additional features offered by their
	    products.</t>
	</section>
	<section title="Extension Identification" anchor="extensionident">
	  <t>It MUST be possible for a management station to
	  understand which parts of returned data are specific to a
	  given vendor or other standardized extension.  The data
	  returned needs to be appropriately marked through the use of
	  name spaces or similar mechanisms to ensure that the base
	  management model data can be logically separated from
	  extension data without needing to understand the extension
	  data itself.</t>
	</section>
	<section title="Name-Space Collision Protection">
	  <t>It MUST be possible to protect against multiple
	  extensions conflicting with each other.  The use of
	  name-space protection mechanisms for communicated management
	  variables is common practice to protect against problems.
	  Name-space identification techniques also frequently solve
	  the "Extension Identification" requirement discussed in
	  <xref target="extensionident" /> as well.</t>
	</section>
      </section>
    </section>
    <section title="Security Considerations">
      <t>Any management protocol for which conformance to this
      document is claimed needs to fully support the criteria
      discussed in <xref target="security" /> in order to protect the
      management infrastructure itself.  The DNS is a core Internet
      service and management traffic that protects it could be the
      target of attacks designed to subvert that service.  Because the
      management infrastructure will be adding additional interfaces
      to that service, it is critical that the management
      infrastructure support adequate protections against network
      attacks.</t>
    </section>
    <section title="IANA Considerations">
      <t>No action is required from IANA for this document.</t>
    </section>
    <section title="Document History">
      <t>A requirement gathering discussion was held at the December
      2007 IETF meeting in Vancouver, BC, Canada and a follow up
      meeting was held at the March 2008 IETF meeting in Philadelphia.
      This document is a compilation of the results of those
      discussions as well as discussions on the DCOMA mailing
      list.</t>
    </section>
    <section title="Acknowledgments">
      <t>This draft is the result of discussions within the DCOMA
      design team chaired by Jaap Akkerhuis.  This team consisted of a
      large number of people all of whom provided valuable insight and
      input into the discussions surrounding name server management.
      The text of this document was written from notes taken during
      meetings as well as from contributions sent to the DCOMA mailing
      list.  This work documents the consensus of the DCOMA design
      team.</t>
      <t>In particular, the following team members contributed
      significantly to the text in the document:
	<list style="hanging">
	  <t hangText="">Stephane Bortzmeyer</t>
	  <t hangText="">Stephen Morris</t>
	  <t hangText="">Phil Regnauld</t>
	</list>
      </t>
      <t>Further editing contributions and wording suggestions were
      made by: Alfred Hönes, Doug Barton.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      &rfc1034;
      &rfc1035;
      &rfc1995;
      &rfc2119;
      &rfc2136;
      &rfc2845;
      &rfc3007;
      &rfc4033;
      &rfc4034;
      &rfc4035;
      &rfc4509;
      &rfc5011;
      &rfc5155;
    </references>
    <references title="Informative References">
      &rfc1611;
      &rfc1612;
      &rfc2182;
      &rfc3197;
    </references>
    <section title="Deployment Scenarios" anchor="deployment">
      <t>This appendix documents some additional deployment scenarios
	that have been traditionally difficult to manage.  They are
	provided as guidance to protocol developers as data points of
	real-world name server management problems.</t>
      <section title="Non-Standard Zones">
	<t>If an organization uses non-standard zones
	  (for example a purely-local TLD), synchronizing all the
	  name servers for these zones is usually a time-consuming
	  task.  It is made worse when two organizations with
	  conflicting zones merge.  This situation is not a
	  recommended deployment scenario (and is even heavily
	  discouraged) but it is, unfortunately, seen in the wild.</t>

	  <t>It is typically implemented using "forwarding" zones.
	  But there is 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 to a local forwarding
	  recursive server, for example, without modifying the rest of
	  the deployed forwarding servers.  It is hoped that
	  a management solution which could handle the configuration
	  of zone forwarding would finally allow management of servers
	  deployed in this fashion.</t>
      </section>
      <section title="Redundancy Sharing">
	<t>For reliability reasons it is recommended that zone
	  operators follow the guidelines documented in <xref
	    target="RFC2182" /> which recommends that multiple name
	  servers be configured for each zone and that the name servers
	  are separated both physically and via connectivity routes.  A
	  common solution is to establish DNS-serving partnerships:
	  "I'll host your zones and you'll host mine".  Both entities
	  benefit from increased DNS reliability via the wider service
	  distribution.  This frequently occurs between cooperating but
	  otherwise unrelated entities (such as between two distinct
	  companies) as well as between affiliated organizations (such as
	  between branch offices within a single company).</t>

	<t> The configuration of these relationships are
	  currently required to be manually configured and maintained.
	  Changes to the list of zones that are cross-hosted are
	  manually negotiated between the cooperating network
	  administrators and configured by hand.  A management
	  protocol with the ability to provide selective
	  authorization, as discussed in <xref target="authorization"
	    />, would solve many of the management difficulties
	    between cooperating organizations.</t>

      </section>
      <section title="DNSSEC Management">
	<t>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.
	  <list>
	    <t>All contents and DNSSEC keying information controlled and
	    operated by a single organization
	    </t>
	    <t>Zone contents controlled and operated by one
	    organization, all DNSSEC keying information controlled and
	    operated by a second organization.</t>
	    <t>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.</t>
	  </list>
	</t>
	<t>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.</t>

	<t>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.</t>
      </section>
    </section>
  </back>
</rfc>