doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc6168.txt b/doc/rfc/rfc6168.txt
new file mode 100644
index 0000000..eb6a25c
--- /dev/null
+++ b/doc/rfc/rfc6168.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       W. Hardaker
+Request for Comments: 6168                                  Sparta, Inc.
+Category: Informational                                         May 2011
+ISSN: 2070-1721
+
+
+        Requirements for Management of Name Servers for the DNS
+
+Abstract
+
+   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.
+
+   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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6168.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                      Informational                     [Page 1]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                      Informational                     [Page 2]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  4
+     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
+     1.3.  Document Layout and Requirements . . . . . . . . . . . . .  5
+   2.  Management Architecture Requirements . . . . . . . . . . . . .  5
+     2.1.  Expected Deployment Scenarios  . . . . . . . . . . . . . .  5
+       2.1.1.  Zone Size Constraints  . . . . . . . . . . . . . . . .  6
+       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  . . . . . . . . 10
+     3.3.  Monitoring Requirements  . . . . . . . . . . . . . . . . . 10
+     3.4.  Alarm and Event Requirements . . . . . . . . . . . . . . . 11
+   4.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 11
+     4.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 11
+     4.2.  Integrity Protection . . . . . . . . . . . . . . . . . . . 11
+     4.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . . . 11
+     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 12
+     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
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   7.  Document History . . . . . . . . . . . . . . . . . . . . . . . 13
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+     9.1. Normative References  . . . . . . . . . . . . . . . . . . . 14
+     9.2. Informative References  . . . . . . . . . . . . . . . . . . 15
+   Appendix A.  Deployment Scenarios  . . . . . . . . . . . . . . . . 16
+     A.1.  Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
+     A.2.  Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
+     A.3.  DNSSEC Management  . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+Hardaker                      Informational                     [Page 3]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+1.  Introduction
+
+   Management of name servers for the Domain Name System (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 an 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 documented in
+   [RFC3197].
+
+   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 -- not other elements
+   of the system itself.
+
+   Specifically out of scope for this document are requirements
+   associated with the 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.
+
+   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; 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 roadmap
+   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                      Informational                     [Page 4]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+1.2.  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.3.  Document Layout and Requirements
+
+   This 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.
+
+
+
+
+
+
+
+
+
+Hardaker                      Informational                     [Page 5]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+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
+   Level Domains (TLDs)) as well as name servers that are serving a very
+   large number of small zones.  Both deployment scenarios are common.
+
+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 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.
+
+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 statically
+   configured over time as well as servers that have numerous zones
+   being added and removed within an hour.  Both deployment scenarios
+   are common.
+
+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 solution SHOULD require only one.
+
+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 entire 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
+
+
+
+Hardaker                      Informational                     [Page 6]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+   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 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.  The management solution MUST NOT result in an increase of
+   the number of unhandled DNS requests.
+
+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 document.
+
+3.  Management Operation Types
+
+   Management operations can traditionally be broken into four
+   categories:
+
+   o  Control
+
+   o  Configuration
+
+
+
+
+Hardaker                      Informational                     [Page 7]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+   o  Health and Monitoring
+
+   o  Alarms and Events
+
+   This section discusses detailed requirements for each of these four
+   management categories.
+
+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 all of the zone data
+
+   o  Reloading individual zone data sets
+
+   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.
+
+
+
+
+Hardaker                      Informational                     [Page 8]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+   Also, see the related discussion in Section 3.4 on notification
+   messages for supporting delivery of alarm and event messages.
+
+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],
+   full zone transfer (AXFR) [RFC5936], 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 create a new
+   zone (with enough minimal data to allow the other mechanisms to
+   function as well) and to delete a zone.  This might be, for example,
+   a management operation that allows for the creation of at least the
+   initial SOA (Start of Authority) record for a new zone, since that is
+   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.
+
+
+
+
+Hardaker                      Informational                     [Page 9]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+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
+   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
+   parameters that the solution might need to collect and analyze are:
+
+   o  Number of requests sent, responses sent, number of errors, average
+      response latency, and other performance counters
+
+   o  Server status (e.g., "serving data", "starting up", "shutting
+      down", etc.)
+
+   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 have" as opposed to "necessary to have".
+
+
+
+
+Hardaker                      Informational                    [Page 10]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+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
+   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 the server's deployment.
+
+   o  The number of errors has exceeded a configured threshold.
+
+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.
+
+
+
+Hardaker                      Informational                    [Page 11]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+4.4.  Authorization
+
+   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
+   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 able to accommodate new future
+   management operations.  The solution might, for example, make use of
+   protocol versioning or capability description exchanges to ensure
+
+
+
+Hardaker                      Informational                    [Page 12]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+   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.
+
+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 the 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 such problems.  Name-space identification
+   techniques also frequently solve the "Extension Identification"
+   requirement discussed in Section 5.1.2.
+
+6.  Security Considerations
+
+   Any management protocol for which conformance to this document is
+   claimed needs to fully 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.  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
+   compilation of the results of those discussions as well as
+   discussions on the DCOMA mailing list.
+
+
+
+
+Hardaker                      Informational                    [Page 13]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+8.  Acknowledgments
+
+   This document 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 and Doug Barton.
+
+9.  References
+
+9.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.
+              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.
+
+
+
+
+
+Hardaker                      Informational                    [Page 14]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+   [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.
+
+   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
+              (AXFR)", RFC 5936, June 2010.
+
+9.2.  Informative References
+
+   [RFC1611]  Austein, R. and J. Saperia, "DNS Server MIB Extensions",
+              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.
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                      Informational                    [Page 15]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+Appendix A.  Deployment Scenarios
+
+   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.
+
+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 that 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 be 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.
+
+
+
+
+
+Hardaker                      Informational                    [Page 16]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+A.3.  DNSSEC Management
+
+   There are many different DNSSEC deployment strategies that may be
+   used for mission-critical zones.  The following list describes some
+   example deployment scenarios that might warrant different management
+   strategies.
+
+      All contents and DNSSEC keying information controlled and operated
+      by a single organization
+
+      Zone contents controlled and operated by one organization, all
+      DNSSEC keying information controlled and operated by a second
+      organization.
+
+      Zone contents controlled and operated by one organization, zone
+      signing keys (ZSKs) controlled and operated by a second
+      organization, and key signing keys (KSKs) controlled and operated
+      by a third organization.
+
+   Although this list is not exhaustive in the potential ways that zone
+   data can be divided up, it should be sufficient to illustrate the
+   potential ways in which zone data can be controlled by multiple
+   entities.
+
+   The end result of all of these strategies, however, will be the same:
+   a live zone containing DNSSEC-related resource records.  Many of the
+   above strategies are merely different ways of preparing a zone for
+   serving.  A management solution that includes support for managing
+   DNSSEC zone data may wish to take into account these potential
+   management scenarios.
+
+Author's Address
+
+   Wes Hardaker
+   Sparta, Inc.
+   P.O. Box 382
+   Davis, CA  95617
+   US
+
+   Phone: +1 530 792 1913
+   EMail: ietf@hardakers.net
+
+
+
+
+
+
+
+
+
+
+Hardaker                      Informational                    [Page 17]
+