summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6168.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6168.txt')
-rw-r--r--doc/rfc/rfc6168.txt955
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]
+