No empty .Rs/.Re

[netbsd-mini2440.git] / external / bsd / bind / dist / doc / draft / draft-ietf-dnsop-name-server-management-reqs-02.txt

DNSOP                                                        W. Hardaker
Internet-Draft                                              Sparta, Inc.
Intended status: Informational                         February 12, 2009
Expires: August 16, 2009


        Requirements for Management of Name Servers for the DNS
          draft-ietf-dnsop-name-server-management-reqs-02.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 16, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   Management of name servers for the Domain Name Service (DNS) has
   traditionally been done using vendor-specific monitoring,



Hardaker                 Expires August 16, 2009                [Page 1]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   configuration and control methods.  Although some service monitoring
   platforms can test the functionality of the DNS itself there is not a
   interoperable way to manage (monitor, control and configure) the
   internal aspects of a name server itself.

   This document discusses the requirements of a management system for
   DNS name servers.  A management solution that is designed to manage
   the DNS can use this document as a shopping list of needed features.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  4
       1.1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . .  5
       1.1.2.  Document Layout and Requirements . . . . . . . . . . .  5
   2.  Management Architecture Requirements . . . . . . . . . . . . .  5
     2.1.  Expected Deployment Scenarios  . . . . . . . . . . . . . .  5
       2.1.1.  Zone Size Constraints  . . . . . . . . . . . . . . . .  5
       2.1.2.  Name Server Discovery  . . . . . . . . . . . . . . . .  6
       2.1.3.  Configuration Data Volatility  . . . . . . . . . . . .  6
       2.1.4.  Protocol Selection . . . . . . . . . . . . . . . . . .  6
       2.1.5.  Common Data Model  . . . . . . . . . . . . . . . . . .  6
       2.1.6.  Operational Impact . . . . . . . . . . . . . . . . . .  7
     2.2.  Name Server Types  . . . . . . . . . . . . . . . . . . . .  7
   3.  Management Operation Types . . . . . . . . . . . . . . . . . .  7
     3.1.  Control Requirements . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  Needed Control Operations  . . . . . . . . . . . . . .  8
       3.1.2.  Asynchronous Status Notifications  . . . . . . . . . .  8
     3.2.  Configuration Requirements . . . . . . . . . . . . . . . .  9
       3.2.1.  Served Zone Modification . . . . . . . . . . . . . . .  9
       3.2.2.  Trust Anchor Management  . . . . . . . . . . . . . . .  9
       3.2.3.  Security Expectations  . . . . . . . . . . . . . . . .  9
       3.2.4.  TSIG Key Management  . . . . . . . . . . . . . . . . .  9
       3.2.5.  DNS Protocol Authorization Management  . . . . . . . .  9
     3.3.  Monitoring Requirements  . . . . . . . . . . . . . . . . . 10
     3.4.  Alarm and Event Requirements . . . . . . . . . . . . . . . 10
   4.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  Integrity Protection . . . . . . . . . . . . . . . . . . . 11
     4.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 11
     4.5.  Solution Impacts on Security . . . . . . . . . . . . . . . 12
   5.  Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . 12
       5.1.1.  Vendor Extensions  . . . . . . . . . . . . . . . . . . 13
       5.1.2.  Extension Identification . . . . . . . . . . . . . . . 13
       5.1.3.  Name-Space Collision Protection  . . . . . . . . . . . 13



Hardaker                 Expires August 16, 2009                [Page 2]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Document History . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Deployment Scenarios  . . . . . . . . . . . . . . . . 15
     A.1.  Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
     A.2.  Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
     A.3.  DNSSEC Management  . . . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17







































Hardaker                 Expires August 16, 2009                [Page 3]
\f
Internet-Draft     Name Server Management Requirements     February 2009


1.  Introduction

   Management of name servers for the Domain Name Service (DNS)
   [RFC1034] [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 a interoperable way to manage (monitor, control and
   configure) the internal aspects of a name server itself.

   Previous standardization work within the IETF resulted in the
   creation of two SNMP MIB modules [RFC1611] [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 [RFC3197].

   This document discusses the requirements of a management system for
   DNS name servers.  A management solution that is designed to manage
   the DNS can use this document as a shopping list of needed features.

   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.

   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
   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,
   Section 5.1 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.

1.1.  Requirements notation

   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 [RFC2119].




Hardaker                 Expires August 16, 2009                [Page 4]
\f
Internet-Draft     Name Server Management Requirements     February 2009


1.1.1.  Terminology

   This document is consistent with the terminology defined in Section 2
   of [RFC4033].  Additional terminology needed for this document is
   described below:

   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.

1.1.2.  Document Layout and Requirements

   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 Section 1.1.  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.


2.  Management Architecture Requirements

   This section discusses requirements that reflect the needs of the
   expected deployment environments.

2.1.  Expected Deployment Scenarios

   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
   Appendix A.

2.1.1.  Zone Size Constraints

   The management solution MUST support both name servers that are
   serving a small number of potentially very large zones (e.g.  Top



Hardaker                 Expires August 16, 2009                [Page 5]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   Level Domains (TLDs)) as well as name servers that are serving a very
   large number of small zones.  These scenarios are both commonly seen
   deployments.

2.1.2.  Name Server Discovery

   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 large
   quantities 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.

2.1.3.  Configuration Data Volatility

   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 fairly
   statically configured over time as well as servers that have numerous
   zones being added and removed within an hour.  Both of these
   scenarios are also commonly seen deployments.

2.1.4.  Protocol Selection

   There are many requirements in this document for many different types
   of management operations (see Section 3 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 number of protocols used SHOULD be reduced to a
   reasonable minimum number.

2.1.5.  Common Data Model

   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



Hardaker                 Expires August 16, 2009                [Page 6]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   model is needed for of the operations discussion in Section 3.  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 Section 5.1.

2.1.6.  Operational Impact

   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.

2.2.  Name Server Types

   There are multiple ways in which name servers can be deployed.  Name
   servers can take on any of the following roles:

   o  Master Servers

   o  Slave Servers

   o  Recursive Servers

   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 [RFC4033].  These sub-
   roles are also important to support within any management solution.

   As stated earlier, the management of stub resolvers is considered out
   of scope for this documents.


3.  Management Operation Types

   Management operations can traditionally be broken into four
   categories:

   o  Control

   o  Configuration

   o  Health and Monitoring




Hardaker                 Expires August 16, 2009                [Page 7]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   o  Alarms and Events

   This section discusses requirements for each of these four management
   types in detail.

3.1.  Control Requirements

   The management solution MUST be capable of performing basic service
   control operations.

3.1.1.  Needed Control Operations

   These operations SHOULD include, at a minimum, the following
   operations:

   o  Starting the name server

   o  Reloading the service configuration

   o  Reloading zone data

   o  Restarting the name server

   o  Stopping the name server

   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.

3.1.2.  Asynchronous Status Notifications

   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.

   Also, see the related discussion in Section 3.4 on notification
   messages for supporting delivery of alarm and event messages.





Hardaker                 Expires August 16, 2009                [Page 8]
\f
Internet-Draft     Name Server Management Requirements     February 2009


3.2.  Configuration Requirements

   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.

3.2.1.  Served Zone Modification

   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) [RFC2136] [RFC3007],
   AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that
   might be used as part of the final management solution, the
   management system SHOULD still be able to natively 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 record for a new zone as that's the minimum amount of
   zone data needed for the other operations to function.

3.2.2.  Trust Anchor Management

   The solution SHOULD support the ability to add, modify and delete
   trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
   [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155].  These trust
   anchors might be configured using the data from the DNSKEY Resource
   Records (RRs) themselves or by using Delegation Signer (DS)
   fingerprints.

3.2.3.  Security Expectations

   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.

3.2.4.  TSIG Key Management

   TSIG [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.

3.2.5.  DNS Protocol Authorization Management

   The management solution SHOULD have the ability to add, modify and
   delete authorization settings for the DNS protocols itself.  Do not



Hardaker                 Expires August 16, 2009                [Page 9]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   confuse this with the ability to manage the authorization associated
   with the management protocol itself, which is discussed later in
   Section 4.4.  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:

   o  Access to operations on zone data (e.g.  DDNS)

   o  Access to certain zone data from certain sources (e.g. from
      particular network subnets)

   o  Access to specific DNS protocol services (e.g. recursive service)

   Note: the above list is expected to be used as a collection of
   examples and is not a complete list of needed authorization
   protections.

3.3.  Monitoring Requirements

   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:

   o  Number of requests sent, responses sent, average response latency
      and other performance counters

   o  Server status (e.g. "serving data", "starting up", "shutting
      down", ...)

   o  Access control violations

   o  List of zones being served

   o  Detailed statistics about clients interacting with the name server
      (e.g. top 10 clients requesting data).

   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".

3.4.  Alarm and Event Requirements

   Events occurring at the name server that trigger alarm notifications
   can quickly inform a management station about critical issues.  A



Hardaker                 Expires August 16, 2009               [Page 10]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   management solution SHOULD include support for delivery of alarm
   conditions.

   Example alarm conditions might include:

   o  The server's status is changing. (e.g it is starting up, reloading
      configuration, restarting or shutting down)

   o  A needed resource (e.g. memory or disk space) is exhausted or
      nearing exhaustion

   o  An authorization violation was detected

   o  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.


4.  Security Requirements

   The management solution will need to be appropriately secured against
   attacks on the management infrastructure.

4.1.  Authentication

   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.

4.2.  Integrity Protection

   Management operations MUST be protected from modification while in
   transit from the management client to the server.

4.3.  Confidentiality

   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.

4.4.  Authorization

   The solution SHOULD be capable of providing a fine-grained
   authorization model for any management protocols it introduces to the



Hardaker                 Expires August 16, 2009               [Page 11]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   completed system.  This authorization differs from the authorization
   previously discussed in 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
   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:

   o  Access to the configuration that specifies which zones are to be
      served

   o  Access to the management system infrastructure

   o  Access to other control operations

   o  Access to other configuration operations

   o  Access to monitoring operations

   Note: the above list is expected to be used as a collection of
   examples and is not a complete list of needed authorization
   protections.

4.5.  Solution Impacts on Security

   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.


5.  Other Requirements

5.1.  Extensibility

   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.




Hardaker                 Expires August 16, 2009               [Page 12]
\f
Internet-Draft     Name Server Management Requirements     February 2009


5.1.1.  Vendor Extensions

   It MUST be possible for vendors to extend the standardized management
   model with vendor-specific extensions to support additional features
   offered by their products.

5.1.2.  Extension Identification

   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.

5.1.3.  Name-Space Collision Protection

   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 Section 5.1.2 as well.


6.  Security Considerations

   Any management protocol that meets the criteria discussed in this
   document needs to support the criteria discussed in Section 4 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.


7.  IANA Considerations

   No action is required from IANA for this document.


8.  Document History

   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



Hardaker                 Expires August 16, 2009               [Page 13]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   compilation of the results of those discussions as well as
   discussions on the DCOMA mailing list.


9.  Acknowledgments

   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.

   In particular, the following team members contributed significantly
   to the text in the document:

      Stephane Bortzmeyer

      Stephen Morris

      Phil Regnauld

   Further editing contributions and wording suggestions were made by:
   Alfred Hoenes.


10.  References

10.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.



Hardaker                 Expires August 16, 2009               [Page 14]
\f
Internet-Draft     Name Server Management Requirements     February 2009


              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
              (DS) Resource Records (RRs)", RFC 4509, May 2006.

   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
              Trust Anchors", RFC 5011, September 2007.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, March 2008.

10.2.  Informative References

   [RFC1611]  Austein, R. and J. Saperia, "DNS Server MIB Extensions",
              RFC 1611, May 1994.

   [RFC1612]  Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
              RFC 1612, May 1994.

   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
              July 1997.

   [RFC3197]  Austein, R., "Applicability Statement for DNS MIB
              Extensions", RFC 3197, November 2001.


Appendix A.  Deployment Scenarios

   This appendix documents some additional deployment scenarios that
   have been traditionally difficult to manage.  They are provided as



Hardaker                 Expires August 16, 2009               [Page 15]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   guidance to protocol developers as data points of real-world name
   server management problems.

A.1.  Non-Standard Zones

   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.

   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.

A.2.  Redundancy Sharing

   For reliability reasons it is recommended that zone operators follow
   the guidelines documented in [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).

   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
   Section 4.4, would solve many of the management difficulties between
   cooperating organizations.

A.3.  DNSSEC Management

   There are many different DNSSEC deployment strategies that may be
   used for mission-critical zones.  The following list describes some
   example deployment scenarios that might warrant different management



Hardaker                 Expires August 16, 2009               [Page 16]
\f
Internet-Draft     Name Server Management Requirements     February 2009


   strategies.

      All contents and DNSSEC keying information controlled and operated
      by a single organization

      Zone contents controlled and operated by one organization, all
      DNSSEC keying information controlled and operated by a second
      organization.

      Zone contents controlled and operated by one organization, zone
      signing keys (ZSKs) controlled and operated by a second
      organization, and key signing keys (KSKs) controlled and operated
      by a third organization.

   Although this list is not exhaustive in the potential ways that zone
   data can be divided up, it should be sufficient to illustrate the
   potential ways in which zone data can be controlled by multiple
   entities.

   The end result of all of these strategies, however, will be the same:
   a live zone containing DNSSEC related resource records.  Many of the
   above strategies are merely different ways of preparing a zone for
   serving.  A management solution that includes support for managing
   DNSSEC zone data may wish to take into account these potential
   management scenarios.


Author's Address

   Wes Hardaker
   Sparta, Inc.
   P.O. Box 382
   Davis, CA  95617
   US

   Phone: +1 530 792 1913
   Email: ietf@hardakers.net














Hardaker                 Expires August 16, 2009               [Page 17]
\f