GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6168

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6168.txt · Last modified: 2011/05/03 23:40 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki